Hightouch · 2021–2024
Patterns for data activation
I joined as the founding designer on a product that an engineer had built for other engineers. By the time I left, it had a design system, a way to monitor sync health, and workflows that a marketer could complete on their own.
Hightouch was a working reverse ETL product, which means it moves data out of the warehouse and back into the tools business teams use every day. The front-end engineer who designed it had solved the hard integration problems for developers.
My job was to help it hold up as the audience widened, first to data engineers and then to marketers, whose workflows in the product were slow and unforgiving. That meant scaling the patterns we had rather than adding more screens.
These are the three principles we designed around.
I spent the first weeks cataloguing design debt
I went through every flow in the app against standard usability heuristics and wrote down what was actually wrong. Color was used inconsistently, a horizontal stepper had been stretched well past the three steps it worked for, and a "Preview" query button sat as a primary action next to "Save", so users stalled trying to decide which one came first.
Cataloguing all of this was how I got the whole product into my head at once. Once I had that picture, I could fix problems at the level of the system instead of one screen at a time, which is the only way I've found for a single designer to keep up with a startup.
The app landing page ended up becoming a list of syncs
Customer interviews kept pointing to the same problems: too many clicks to reach error information, no sense of what needed attention, status badges that were hard to read, filters that were hard to build and harder to maintain, and no way to get an overview of the workspace. Taken together, they came down to one job: finding recent errors and debugging them quickly.
The existing landing page listed every active sync, and folders hadn't kept it from getting noisy as usage grew. I ran a design jam with the PM and founding engineer on what a monitoring-first home screen should show, prioritized the ideas against customer feedback, and shipped a dashboard that opens on a set of recent sync runs across syncs and destinations. This reduced the amount of time the average user spent hunting for a failing sync.
Shipping a new design
We started with design jams to explore high-level concepts for what a monitoring-first home screen should show. I then took the strongest ideas into lo-fi wireframes to work out the structure and interaction details, and from there into high fidelity.
Extending status patterns to resource pages
While I was working on the dashboard, I also explored how the same status colors could show a single sync's health over time, and what a hover should reveal about why its status changed. I tried several treatments for the history bar, the change log and the tooltips before settling on tints for past states, with the hovered moment shown at full strength.
Once the patterns held up on the dashboard, I carried them into resource pages. On a sync's Monitoring tab, the history bar uses the same scale, and the monitor settings below it use the warning and unhealthy colors to separate the two thresholds each monitor can trigger, so people can see what will change a sync's status before it happens.
What the foundation made possible
Once the design debt in the core experience was under control, I moved on to enterprise features first, like RBAC and deployments, and then to marketer-facing features like Journeys and the Audience builder.
Journeys was the clearest test of whether the foundation held up. A canvas of triggers, destinations and delays is a very different interface from a sync list, but it's built entirely from the components we standardized for the core product, which I cover further down: the same tables, drawers, status colors and empty states. A marketer reading a live journey and a data engineer reading a failed sync are reading the same visual language.
Journey overview: canvas and per-tile performance
Standardizing components
As I redesigned the core workflows and the dashboard, I kept running into the inconsistencies the audit had surfaced, so I standardized components alongside the screen work instead of treating it as a separate project. That work turned into a set of clear, consistent styles and, just as importantly, rules for how to use them. Each component got one job and a defined set of states. For example, there's one primary action per view, destructive actions stay outlined until they're confirmed, badges are for status and pills are for metadata, and alerts escalate based on their intent.
Because the rules were written down, they held up across every core workflow. Setting up a sync, monitoring its runs and building an audience all felt like the same product, and new screens could start from decisions we'd already made.
I learned that teams serving data engineers don't buy through self-serve alone. They read the docs, watch the explainer videos, sit through a demo, and come back to the product once their questions have been answered.
So the product's job was narrower than it first looked: be as simple as possible, add guardrails and governance where the risk is, and always leave a clear path to help. Designing for how people actually evaluated the product worked better than designing for a fully self-serve experience that didn't match reality.
Marketing design
Alongside the product work, I designed marketing collateral: blog thumbnails, signup pages and email campaigns.
Working on both marketing and product helped keep the story consistent, from the first campaign someone saw to the product they signed into.
