Deduplication flow
Discovery of the users’ fears
Role:
Lead Product Designer (hands-on)
Product:
Maxo (B2B CRM platform)
Scope:
UX strategy, flow design, usability testing, interaction design
Impact area:
Data integrity, trust, critical user decisions
Outcome (high level):
Redesigned the deduplication flow to reduce user fear and confusion by making outcomes explicit before confirmation, aligning stakeholder assumptions with real user behaviour.
Why it could be interesting for you:
This case demonstrates my approach as a hands-on Lead Product Designer: making high-stakes decisions under ambiguity, challenging assumptions with research, and designing for trust in complex systems.
What?
The problem
Deduplication is a high-risk action:
- Users fear losing or corrupting data
- Mistakes feel irreversible
- Confidence matters more than speed
- The system needed to stay efficient
- Stakeholders pushed for fewer clicks and faster resolution
- Edge cases made the flow increasingly complex
- The feature technically worked, but users hesitated, double-checked, or abandoned the action.
So what?
The real problem
On the surface, the problem was UX clarity.
In reality, user interviews showed that the problem was user anxiety. Users weren’t asking:
“How do I deduplicate?”
They were asking:
“Am I about to break something?
Will I lose relations of merging records?”
When an action is irreversible, uncertainty becomes friction—users prioritize understanding the outcome over completing the task quickly.
The existing flow focused on efficiency, not reassurance.
In reality, user interviews showed that the problem was user anxiety. Users weren’t asking:
“How do I deduplicate?”
They were asking:
“Am I about to break something?
Will I lose relations of merging records?”
When an action is irreversible, uncertainty becomes friction—users prioritize understanding the outcome over completing the task quickly.
The existing flow focused on efficiency, not reassurance.
Strategic tension
There were two strong, opposing beliefs:
Stakeholders: fewer clicks = less friction
Users: fewer clicks = less certainty
This created a classic bias trap: Internal logic vs real user perception. Efficiency vs trust.
As a lead, my role was to surface this tension, not smooth it over.
Stakeholders: fewer clicks = less friction
Users: fewer clicks = less certainty
This created a classic bias trap: Internal logic vs real user perception. Efficiency vs trust.
As a lead, my role was to surface this tension, not smooth it over.
Key insights that changed direction
Initial usability tests revealed unexpected findings:
Users feared invisible consequences.
They couldn’t clearly predict what would happen after merging.
These insights directly contradicted internal assumptions.
Users feared invisible consequences.
They couldn’t clearly predict what would happen after merging.
- Less interaction increased stress
- Faster flows felt riskier, not better
- Missed clear “before/after” effect
- Users lost confidence when records weren’t clearly similar or when they were asked to evaluate too many possible duplicates at once
- The risk of overwriting values triggered anxiety around irreversible mistakes and the loss of important relationships.
- didn’t want more options, just clarity and confidence in the action they were taking.
These insights directly contradicted internal assumptions.
Now what?
Design strategy — test the assumptions
Instead of defending one direction, I intentionally designed two contrasting solutions:
Option A: Original assumption of PM and designer, legacy grid structure, presenting help on demand on the screen, reviewing changes step
Option B: Informed by the first round of testing: a reversed data grid, a clear explanation of what happens to relationships, and a new field type that collects values from multiple records.
The goal wasn’t aesthetics—it was to test bias vs reality.
Option A: Original assumption of PM and designer, legacy grid structure, presenting help on demand on the screen, reviewing changes step
Option B: Informed by the first round of testing: a reversed data grid, a clear explanation of what happens to relationships, and a new field type that collects values from multiple records.
The goal wasn’t aesthetics—it was to test bias vs reality.
What I designed
Designed two competing solutions to test bias vs reality
Shifted the flow toward guided, outcome-focused confirmation
Made edge cases and results explicit before irreversible actions
Shifted the flow toward guided, outcome-focused confirmation
Made edge cases and results explicit before irreversible actions
I was responsible for:
- Framing the problem beyond usability
- Designing and testing alternative solutions
- Using evidence to challenge stakeholder bias
- Making a recommendation under uncertainty
I was also hands-on:
- Flow mapping
- Interaction and confirmation design
- Usability test planning and synthesis
Key decisions
Decision 1:
Make outcomes explicit before confirmation
Why:
Fear came from not knowing the result.
Trade-off:
More UI upfront.
Outcome:
Users could clearly see:
- what would be merged
- what would remain
- what could not be undone
Decision 2:
Embrace guidance over minimalism
Why:
Users wanted reassurance, not speed.
Trade-off:
Increased interaction steps.
Outcome:
Users felt confident proceeding instead of hesitating or cancelling.
Impact
- Version preference in testing — guided version preferred by 9 of 11 participants (source: usability sessions)
- Task abandonment / cancellation rate — 34% → 21% (source: event tracking data)
- Support tickets about accidental merges / data loss — directional reduction
- Better alignment between stakeholders and user needs
- Shared internal understanding that speed ≠ trust
- Most importantly: Decisions moved from opinion-based to evidence-based.
Gallery