Making data consolidation feel safe.

The gap wasn't technical.
It was human.

Enterprise procurement teams deal with supplier data coming in from multiple systems. The result is a bloated database full of duplicates, incorrectly merged records, and tangled relationships with no governed way to fix any of it.

Data stewards were making irreversible decisions with no structure and no safety net.

Platforms existed.
None solved this for humans.

Informatica MDM, SAP MDG, and Reltio exist, but they're built for IT administrators. Their merge workflows are buried in configuration panels with no visual feedback and no explicit relationship handling.

No competitor offered all three. That was the opportunity.

One shared need
across all roles.

The platform serves data stewards, procurement managers, and operations admins. What they share isn't a job title, it's a need for confidence. Every action they take has downstream consequences they may not fully see.

They didn't need faster. They needed trustworthy.

The scope
wasn't in the PRD.

Merge and split weren't scoped initially. The first stakeholder call revealed the real need, there was no governed way to handle supplier consolidation. No competitor had solved this for business users. I designed from scratch with no prior reference, front-loaded the thinking before touching Figma, and iterated on exactly one thing: the relationship assignment logic.

The launchpad
for everything.

Before a user can merge or split a supplier, they need to understand it fully. Tab architecture separates concerns, each tab has one job. The header strip surfaces status and Auto Sync state before any scrolling. Inline editing keeps users in context, no modal, no lost place.

SM-01 · LAUNCHPAD Supplier Details, Attributes tab, full view

Supplier Details, Attributes tab, full view.

SM-02 · INLINE EDIT Edit state, inline form, Cancel/Confirm always visible

Edit state, inline form, Cancel/Confirm always visible.

Four steps. No surprises.
Nothing moves silently.

Merging two supplier records is one of the most consequential actions in the platform. I designed a four-step guided flow that makes every decision visible and every action deliberate. The merge triggers directly from the supplier page, no separate flow, no context switch. The action lives where the data lives.

SM-03 · MERGE TRIGGER Merge triggered from the supplier page, source supplier pre-filled

Merge triggered from the supplier page, source supplier pre-filled.

Know before you commit.

Key identifiers visible on both cards. No blind merges.

SM-04 · MERGE STEP 1 Add Target Supplier, Step 1

Add Target Supplier, Step 1.

Consequences before selection.

Early designs used a dropdown. Users chose without understanding what they were committing to. Cards replaced it, the outcome is visible before any commitment is made.

SM-05 · MERGE STEP 2 Select Merge Strategy, Step 2

Select Merge Strategy, Step 2.

Every attribute. Your decision.

Source left, target right. Every field independently assignable. Custom value option means users aren't forced to pick either.

SM-06 · MERGE STEP 3 Compare and Edit, Step 3

Compare and Edit, Step 3.

Nothing moves silently.

This was the most debated part of the project. When two suppliers merge, what happens to their subsidiaries, affiliates, and parent companies? Auto-assigning relationships felt too risky, one silent move could corrupt an entire supplier hierarchy.

A mandatory confirmation checkbox requires users to acknowledge they've reviewed every assignment. This isn't friction, it's a contract. The user is saying: I have reviewed every decision. I own this.

SM-07 · ASSIGN RECORDS Assign Records, explicit decision per relationship, grouped by type

Assign Records, explicit decision per relationship, grouped by type.

One misclick here corrupts an entire hierarchy. That's why nothing is assumed.

See everything. Change anything.
Then execute.

A complete summary of the merged supplier, all attributes, contacts, locations, and a relationship assignment table showing exactly where every record ended up. Users can navigate back and correct anything before executing.

SM-08 · REVIEW & MERGE Review and Merge, Step 4

Review and Merge, Step 4.

Before you execute, you see everything. That's not a courtesy, it's the design.

The inverse problem.
Same rigour.

The split flow solves the inverse problem, a supplier incorrectly merged needs to be separated. Same entry point, same mental model, no relearning. Every contact, location, and document must be explicitly assigned to one of the new suppliers. One action per item. Nothing assumed. Same confirmation checkbox. Same audit trail.

SM-09 · SPLIT · DISTRIBUTE Split, Distribute Data, one assign action per item

Split, Distribute Data, one assign action per item.

SM-10 · SPLIT · REVIEW Review and Split, three suppliers, one confirmation

Review and Split, three suppliers, one confirmation.

Same rigour as merge. Because the stakes are identical.

What this design
replaces.

* Projected. Phase 1, metrics updated post-launch.

What we didn't
get to solve, yet.

Phase 1 ships. Phase 2 learns. That's how good products are built.