Workato · 2024–2025
Helping you customize your data schema
Workato could move data between systems in real time, but it couldn't replicate data at volume. I led design on the features that closed that gap, on a product that had already shipped and had been designed by someone else.
Workato's integration platform let different systems talk to each other in real time, but it couldn't move large volumes of data for analysis or storage. Enterprises kept a second vendor for that part of the job, usually Fivetran or Informatica.
A first version of data pipelines had already shipped, and the designer who worked on it had moved on to other projects. I joined to take the team through a roadmap of more sources and destinations and deeper replication capabilities, on top of a core experience that was already in users' hands. Because of that, I needed to propose patterns that would scale to features that weren't specified yet, without introducing changes users hadn't asked for.
Every feature on the roadmap landed on one of these four, and where it landed decided which existing pattern it should extend.
Put PII control on the field, not in a settings page
Sensitive fields need to be protected before they're replicated, and that decision is made per field. The PM and I wrote the copy for a field-level control that lets a user either hash a value or replicate it as is, and I placed it in the right margin of the schema row, next to the field it applies to.
I explored a range of hash icons so the mark would fit with the surrounding copy and still be understood on its own, without a label.
Reuse the margin affordance one level up
Users needed to trigger a one-time sync on an individual object, so that moving data wasn't tied to the schedule. That meant object-level actions and settings needed to live somewhere the schema view already showed.
Instead of opening a new surface, I extended the right-margin control we'd introduced for hashing to the object row. Users only had to learn one interaction, and it worked at two levels. It also meant the next feature could use the same pattern without a redesign.
Three kinds of sync now had to be legible in one chart
Adding object re-syncs meant the dashboard was suddenly reporting three kinds of runs at once: initial syncs, incremental syncs and re-syncs. Looking at the chart no longer told you which kind of run you were looking at.
We added indicator icons to the chart views and carried them into the tooltips, so the sync type is visible at a glance and explained on hover. It was a small addition, and it let us keep the existing dashboard instead of replacing it.
The pipeline pages reported on runs, not on objects. If one table out of eleven was stale, the only way to find it was to read through the run history and work it out. We added an Objects tab that lists the active schema with the last status of each object, filterable by state, so people can check whether their data is current at a glance.
Alongside it, we shipped the capability users had requested most in product feedback: a manual re-sync button for each object. Sync schedules exist for good reasons, but a data engineer who has just fixed a mapping or a permission shouldn't have to wait for the next scheduled run to confirm it worked. The button appears when you hover a row and in the object drawer, and each manual run is labelled as an object re-sync in the run history, so scheduled and on-demand runs can still be told apart afterwards.
Each release added components and patterns back to the shared library, so the next feature had something to start from. A later file-connector pipeline needed more metadata shown in each row, and the icon-and-tooltip pattern we already had was able to handle it without a new layout.
Working on an inherited product limited what I could change, but it also meant users already knew its patterns. I tried to respect the work that came before me and extend those patterns instead of replacing them, which is what allowed three features to ship in a row without users having to relearn the screens.