Fivetran · 2019–2021
Getting the first sync finished
More than half of the prospects who started Fivetran's onboarding never finished a data sync. I was the first designer on the app, and this is how we rebuilt that flow.
Fivetran's managed connectors handled schema normalization and table structure so that data teams didn't have to. But getting a pipeline running still meant going through IT or a data engineer, which was costly and slow, and it got in the way of Fivetran's growth.
The brief was to build a system that let non-technical users self-serve. The measurable version of that goal was narrower: get more people through setup to a finished first sync.
Synthesized from customer interviews across key personas.
Reorder the steps, and put the documentation inside the step that needs it
I mapped the existing flow in low fidelity first and marked every pain point, so none of them would get lost in the redesign. Then we changed the order of the steps, standardized the visual system, and rebuilt the layout to make room for embedded documentation. The goal was to put education right where someone gets stuck on a technical form.
My PM and I agreed up front to measure the work with metrics our analytics team already tracked: time to value, and dropoff at each key step. That meant we didn't need new instrumentation, and we wouldn't be debating later whether it had worked.
We added a Welcome step and made things worse
The embedded docs did what we hoped and led to more completed syncs during onboarding. The new Welcome step didn't. Asking people to choose a source and a destination before anything else caused more dropoff early in the flow than the version we had replaced.
We shipped a new onboarding flow
We quickly shipped a follow-up that made that first choice non-committal, so you could move on without deciding. Sync rates at onboarding improved 36% overall after that release, and we kept tuning individual steps based on ongoing usage tracking.
The most emotional theme in the interviews was not knowing whether personal data was about to be copied into the warehouse. People hesitated at the schema step, and when they hesitated there, they often didn't finish their first sync.
So we added an explicit review of the schema and its PII risks before syncing. We wrote the goal down as reducing PII anxiety and raising sync rates, in those exact words, so the team understood what we expected to get in exchange for adding a step.
The final flow, from the welcome step to the first sync, brings that work together: the reordered steps and in-place guidance, and the schema review, where people choose what to sync and how future schema changes are handled before any data leaves their source. Every screen is built from Blueprint's components, from the stepper and connection tests to the schema picker and status badges. We planned the work in three phases, and wrote down the goal for each one before it started.
Our research turned up problems across the entire journey, and we couldn't take them all on at once. Enabling self-service meant starting where people's confidence broke down, which was during setup, and phasing in the rest after that.
Redesigning the core dashboard
Setup gets people to their first sync, but the dashboard is where they spend the rest of their time. I redesigned the two pages at its core, the connector list and the connector detail page, around the questions operators actually ask: where is my connector, and is it healthy?
Connector list
- Search by name plus status and source filters, so a list of hundreds of connectors narrows to the one you need in a couple of steps.
- Connectors used to be nested under their source, like "Amplitude (2)", which hid them behind an extra click. Now each connector has its own row.
- Name, source type, status and last sync sit in consistent, sortable columns instead of being stacked under each name.
Connector detail
- The wall of per-minute ticks became one bar per sync for each stage, with warnings in their own color, a "now" marker and timing on hover.
- Sync frequency, average duration, schema changes, last successful sync and open warnings sit in one summary strip at the top.
- Alerts, user actions and stats sit side by side under the chart, so you can see what went wrong, who changed what and how the connector is performing without leaving the page.
Blueprint design system
I didn't treat the design system as a separate project. While the onboarding work moved through its phases, I built Blueprint alongside it. Whenever a pattern repeated across screens, I turned it into a token or a component, documented every state, and used it in the next round of design.
Engineering adopted Blueprint as the shared foundation for the product UI. It came out of the design process itself, built up screen by screen as the onboarding and dashboard work moved along.
Beyond setup, I worked across the roadmap on transformations, the sync chart UI and more, and most of what I learned there was about writing.
I came into data integration new to the domain, so I had to learn it properly before I could write a single useful label, and I had to bring the right stakeholders into copy decisions instead of making them alone. I found that you can't design an educational experience for technical and non-technical users at the same time until you really understand the thing you're explaining.