Unito · 2024
Reinventing the Sync Conditions to Expand Use Cases and Drive Growth
Under what conditions should cards start syncing?
At a Glance
Recap
Sync conditions decide which items Unito syncs. Users could only say “is” or “is not”, which blocked real use cases. The page itself was difficult to read, which made the sync behavior difficult to predict.
My Role
User researcher and product designer, working fully remote.
Timeline
July – December 2024
Team
- Graham ↗ (opens in a new tab), Product Manager
- Max ↗ (opens in a new tab), Tech Lead
- Nilovna ↗ (opens in a new tab), Developer Manager (cross-squad)
- Jodi ↗ (opens in a new tab), Tech Lead (connector squad)
- Adrien ↗ (opens in a new tab), Tech Lead (sync engine squad)
Outcome
New operators tested on 7,330 workspaces with no regression, despite major backend changes, and a slight lift in activation and conversion.
- 9users tested the prototype before implementation.
- 8new operators. We moved from 2 options, “is / is not”, to 10 operators.
- 7,330workspaces in the test, Dec 18 to Feb 14, half of new users.
01Context
The Rules Behind Every Sync
Unito connects people’s favorite work tools with two-way sync. Users set up each connection in the flow builder, Unito’s core journey.
One step decides which items sync: only validated deals, only high-priority tasks, only one person’s cards. If users can’t express that rule, the flow syncs too much or not at all.
02Problem
Only 2 Operators to Support a Growing Number of Connectors and Use Cases
Picture a sales ops manager. She syncs her sales funnel sheet to the product team’s board, and only wants big, validated deals to go through. Status is “Validated”, fine. Then she opens the budget operator.
Select the tasks you want to sync
Which became our problem statement
How might we unlock more use cases and make conditions easier to set, so more flows activate and convert?
03Process
Four Phases, from Audit to Rollout
Two goals ran side by side: more operators for more use cases, and a simpler page for better usability.
- Jul 2024
Understand the Needs
- Find gaps through quantitative, qualitative and internal audits
- See how current filters limit workflows
- UX audit of the page
- Jul – Aug 2024
Diverge and Explore
- Revisit past explorations
- Generate new concepts
- Align the vision with stakeholders
- Aug – Sep 2024
Converge and Test
- Build a testable prototype
- Test UX and tech feasibility
- Agree on a technical approach
- Sep → Dec 2024
Implement and Evaluate
- Support v1 development
- Run QA
- Measure, plan next iterations
Phase 1 · Understand the needs
1.Main Findings
- Critical
Limited Functionality
Users were restricted by binary conditions, preventing them from fine-tuning filters.
- Medium
Lack of Clarity
The UI didn’t clearly communicate what users were expected to do.
- Medium
No Predictability
Users couldn’t accurately anticipate what items would be included or excluded from sync.
Where the insights came from
- Pricing survey
- Customer conversation analysis
- Feedback loops with customer-facing teams
- Previous research
2.Audit: Four Reasons the Page Felt Heavy
I annotated the existing page against what users told us.
Phase 3 · Converge and test
| Criticality | Finding | What we did |
|---|---|---|
| Critical | Limited functionality | New operators for each data type: text, URL, list values, numbers and dates. |
| Medium | Lack of clarity | Stopped using the natural-language form, which forced a counterintuitive pattern. |
| Medium | No predictability | A live count of matching items, with a preview. |
| Medium | Visual noise | A lighter layout, built from design system components. |
Focus on New Operators for Each Data Type
Our logic was already flexible: [field, operator, value]. So the question became which operators each type of field needed.
Methods
- Functional benchmark
- PM + design sessions to list operators
- Review of real customer scenarios
- Weekly trifecta: PM, dev, design
Deliverables
- Operators per data type matrix
- Fields × design system components matrix
- Functional spec per field type
- Updated design system components
The operators matrix, simplified
The underlying complexity of the sync engine
New operators were simple to add to a menu. But they broke core automation logic, three layers down.
We had 3 main challenges:
- Incoming automation stopped working. How do we keep syncing the relevant items?
- Stop-syncing logic changed. Unito used to deduce it. Now users needed explicit rules.
- Legacy connectors didn’t support the new operators. How do we stay compatible?
My part: I didn’t stop at the UI. I took part in the technical decisions, in PM + design + dev sessions and through the RFC, so each trade-off was weighed against what users would see.
Our answer: stick to two design principles, and design for real scenarios.
04Solution
More Power, Less Noise
A focus on the 4 main UX and UI changes on the page. Pick one to see where it lives.
Under what conditions should cards start syncing?
05Implementation and evaluation
How Did We Scope and Implement It
- MVPDecember 2024
Operators
Add new operators on new connectors while minimizing UI disruption. The sync is the core of the experience: without a clean sync, there’s no point going further.
- v1January 2025
Gradual UI Changes
Apply best practices incrementally.
- Later
Previews for Predictability
Improve visibility into sync behavior.
- Later
Scale It
Deploy operators on older connectors, increase the share of users on this version (only 50% initially), and migrate enterprise accounts to the new system.
I left Unito in December 2024, right after the MVP.
06Retrospective
What I’d Do Differently
Bring Design into the Early Discussions
Even on a highly technical topic, the impact on the experience could have been really bad, adding tons of complexity to a feature aimed at more advanced users.