About Hightouch
Hightouch is a platform we designed to help business teams sync data from a central source of truth like a data warehouse such as Postgres or Snowflake, to the apps and tools that sales and marketing professionals use everyday like Salesforce, Hubspot, and Google Sheets.
The term ETL (Extract data, Transform data, Load data) had been around for a while thanks to Fivetran and similar offerings. Hightouch coined the term “Reverse ETL” because it was essentially doing the same thing, but in Reverse. All this to help “operationalized” team processes so that members of Sales and Marketing teams can make data-driven decisions without having to worry about pinging a data analyst to generate reports which then had to beinterpreted — a time-consuming process.
Eventually the term “Reverse ETL” gave way to “Data Activation” in the sense that data from an organizations warehouse (like BigQuery or Snowflake) would no longer sit stale and unused but would instead be activated by enriching existing tools with valuable insights that were previously hidden and untapped.
My Role
I joined Hightouch as the first product designer, tasked with establishing the design practice and working with engineering to address outstanding design debt, build new highly requested features, and scale our practice to deliver quality designs at regular milestones.
Initial Brand Design
I contributed to the brand and marketing materials before we hired a full time art director and brand designer. Before committing to forest green, we were one of many purple/indigo themed brands in this product category.
Application Design System
As lead product designer, I had to establish a reusable pattern and component library which engineers could easily build components from, and understand usage rules for. I collaborated with a couple frontend engineers to codify both the foundations such as color and type, and a set of common components that we gradually rolled out across the application. Below is a snippet displaying a few common components.
Customer Journey
I mapped out our customer journey and through user interviews I identified areas where the UX could be streamlined for easier use.
Project 1: Observability Dashboard
Problem statement
Users experience a lot of friction when trying to identify and resolve errors in their sync activity, or anomalous behaviors which are cause for investigation. Given the scale of enterprise customer environments, the number of resources in a Hightouch workspace requires better visualizations and interactions to help users quickly find what specific resource they need for a recent history of their organization activity.
Solution mocks
Here are a few solution mocks that more or less made it into production.
^ This is Hugo, one of our full-stack engineers, presenting a demo of the feature after it shipped.
Project 2: Advanced Mapper v2
Problem Statement
The core value proposition of Hightouch is the ability to activate data from a source like a database or warehouse by sending it to a destination where that data is actually visible and useful. The mapper affords users the ability to select what data modeled from a given source to send to their chosen destination app. The original iteration presented a host of usability problems stemming from inefficient use of space and inflexible interaction logic. It also needed to be extended to support more functional requirements which support the platform’s growing capabilities.
Source values (like “email” column value) on the left are mapped to destination fields found in the chosen destination (Asana in this case) on the right.
Version 1.0
We knew that users needed to map more types of source data to their destinations, not just column values.
We achieved this by introducing a popover component that supported 4 types of data values: Column, Static value, Variable value, and Template:
Advanced Mapper Version 2.0
We identified several key pieces of user feedback that we derived problems and pain points from.
1. Optimal order of steps - We found that users often felt more comfortable completing the mappings by selecting DESTINATION fields first, then deciding which source values to map to them afterwards. This is because the mapper will only accept source values whose data types match the destination field types. So we changed the affordances to allow either starting point (source or destination).
After selecting a destination field, the source selection popover will only display values that match the selected destination field data type, to reduce errors and help the users make an acceptable selection faster.
2. Simplifying layout - Users felt overwhelmed by the list of selections that appeared at the point of clicking. It made the mapper feel unnecessarily complex. Often users didn’t know which to choose. It also didn’t scale well to support “subtypes” of certain mapping types (like certain curated columns such as “traits”).
Some of the options once selected required subsequent sub-selections to be displayed in a new column, leaving very little space available for content.
v2 Solution exploration
Our goals were (1) to establish a more scalable pattern in case we needed to add more mapping types in the future and (2) to support display of a lot more metadata that users need to see without cramming the UI making it nearly unusable particularly on smaller displays.
Placing the mapping types across the top made the entire UI simpler, more scalable, and provided enough room for more metadata that users needed to see when choosing data values.
This layout afforded more space to type when interacting with template-based mapping types.
Added support for selecting the “Sync method” and better error validation
Blocking error
Non-blocking error pattern
Drag and drop to re-order mappings
