My Role
I joined Hightouch’s product design team in the Spring of 2021. I took on the position of Lead Product Designer with a goal to create a best-in-class product for our users and implement a cross-platform approach to our product experience.
About Hightouch
Hightouch is a pioneer of what was once called “Reverse ETL”, which helps move data from a central warehouse like Snowflake back to the tools and apps you use everyday.
The term “ETL” (Extract, Transform, Load) 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 be interpreted — a time-consuming process.
Establishing visual rules
The first orders of business was to define a new updated look & feel for both the site and the app. This included updating the color palette and creating style rules where there previously were none. Below is the original iteration of the brand visual design which I later worked with an externally contracted brand designer to develop the current forest green iteration.
Hightouch Sign Up
One of the first pages to take on an update was the delicate Sign Up flow. Which included multiple versions that were A/B tested and optimized to this final version—later applied to the app.
Web 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. Below is an abridged version.
Sample project: 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
There was a lot of iteration I performed in tandem with our engineers where we kept an eye on things like scalability, error scenarios and performance metrics.
^ This is Hugo, one of our full-stack engineers, presenting a demo of the feature after it shipped.
Another project: 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
