Designing a new workflow for merging data in a MDM system

A purpose-built data merge tool designed to help data stewards easily review records and create a single, reliable source of truth called a “Golden Record”

ROLE

Lead Product Designer

CLIENT

B2B SaaS (Fortune 500)

INDUSTRY

Enterprise Software

TOPICS

Product Design

Master Data Management

/

CONTEXT AND BACKGROUND

As part of designing an internal MDM system, I worked on one of the most complex parts of the experience, helping data stewards merge duplicate company records into a single, reliable source of truth known as the “Golden Record.”

This project sat inside a larger Master Data Management (MDM) program to create a single, trusted Golden Record for every all the data records this client held across numerous domains.

While designing the new MDM system, we needed to create a bespoke merge experience to support one of the key use cases, merging records within a new layered data model replacing their old flat structure.

This project sat inside a larger Master Data Management (MDM) program to create a single, trusted Golden Record for every all the data records this client held across numerous domains.

In this case study

Project Goal

The Objective

Design Discovery

Data Foundations

Data Meets Design

The Final Experience

Lessons Learned

/

PROJECT GOAL

Our goal was to take a complex, manual merge process and turn it into an experience that felt clear, intuitive, and gave data stewards the confidence and control to create one trusted source of truth for their data.

/

THE objective

Designing a merge experience for a new data model

We were building the rest of the MDM system within ServiceNow Workspace, and while most use cases fit within the platform, one didn't - merging company records.

To solve this, we needed to design a custom merge portal that worked with ServiceNow but gave stewards the visibility and control they needed. Instead of jumping between disconnected systems to complete a single merge, everything would now happen in one place

/

THE CHALLENGE

→

Stewards were using legacy tools that were slow and forced constant switching between systems, making merges time-consuming.

→

ServiceNow Workspace couldn’t handle the detailed logic needed for comparing and merging records.

→

The new layered data model introduced parent and child records, which made merges even more complex to review and validate.

/

Our solution

→

Build a unified, purpose-built merge experience to replace fragmented legacy tools.

→

Design a custom merge portal connected to the ServiceNow Workspace.

→

Design a clear and transparent workflow that allowed stewards to review and choose what was included in the merge from all records and their children.

The merge workflow before redesign

Stewards managed merges across disconnected systems, relying on manual checks and external lookups to decide which record to keep.

/

DESIGN DISCOVERY

Learning from the stewards and the experts

To design an experience that truly supported data stewards, I needed to understand both how they worked and how the data itself was going to be structured by the architects.

Who I was working with

My discovery strtaegy

(1)

Understanding the current process

We began by asking Data Stewards to walk us through how they navigated between systems when merging records, explaining each step and its purpose.

This helped us understand

We began by asking Data Stewards to walk us through how they navigated between systems when merging records, explaining each step and its purpose.

This helped us understand

→

What they did and why they did it

→

Where the main pain points were

→

How they wanted the new experience to work

Since we were changing the way they would be doing this in the future, it quickly became clear that this would need to be a “show a draft first, then we’ll tell you” approach for the client.

Map of the process stewards had to go through when merging data before

(2)

Working closely with data architects

To design an experience that reflected how data actually worked, I collaborated closely with the data architects and engineers.

They showed me how

→

Records connected across the new layered schema.

→

Survivorship rules determined the “Golden Record.”

→

These relationships should surface in the UI so being merged in a more detailed way.

These deep dives helped me design according to the new data structure so that the final experience aligned with how the system actually processed and linked records.

Early data architecture explorations used to understand survivorship logic and inform UI design

(3)

Desk research and upskilling

Because the project had a lot of technical depth, I spent extra time learning about data management and MDM systems.

I took short courses, read documentation, used AI tools to quickly explore schema relationships and merge logic.

Because the project had a lot of technical depth, I spent extra time learning about data management and MDM systems.

I took short courses, read documentation, used AI tools to quickly explore schema relationships and merge logic. This helped me to

This helped me to

Because the project had a lot of technical depth, I spent extra time learning about data management and MDM systems.

I took short courses, read documentation, used AI tools to quickly explore schema relationships and merge logic. This helped me to

→

Understand how data flows and relationships actually worked behind the scenes.

→

Learn how technical backend logic might affect the user experience design.

→

Understand what Master Data Management is. Period.

Completed MDM certification to strengthen understanding of data structures and merge logic.

(4)

Defining the new model

I worked closely with the data architects as they introduced a new layered data schema, connecting the parent-child relationship.

This related to my design work because

I worked closely with the data architects as they introduced a new layered data schema, connecting the parent-child relationship.

This related to my design work because

→

I needed to understand how these new relationships interacted during a merge.

→

The UI had to mirror the logic of the data model, so stewards could see how records were connected.

→

Our goal was to give stewards visibility into every layer while keeping the interface clear and manageable.

Working with architects to visualise relationships and understand the new data model.

/

DATA FOUNDATIONS

Understanding the merge process and data model

I next needed to understand how the data itself was structured and how the new model would change the way stewards interacted with it. The data architects helped me make sense of it all at every step.

BEFORE

A flat data schema

When we joined the project, company data lived in a flat schema, meaning

→

All company information sat in a single table, with no linked hierarchies.

→

There were no parent–child relationships between records.

→

Data was stored as plain text instead of as references.

→

This worked for simpler use cases, but it made the data less accurate and harder to maintain.

Stewards managed merges across disconnected systems, relying on manual checks and external lookups to decide which record to keep.

The old merge experience

The old UI reflected this flat setup, which meant

→

Stewards had to manually review records and pick one “winning” version to keep.

→

Stewards had to cross-check details in external tools like D&B or company websites to make sure there were no more duplicates.

→

This led to slower cleanup and merges, not to mention the old system was also painfully slow to load.

Stewards managed merges across disconnected systems, relying on manual checks and external lookups to decide which record to keep.

AFTER

Moving to a layered data schema

The layered schema introduced a more connected way of representing company data. Each layer captured specific relationships and attributes, all linked back to a single core company record.

The layered schema introduced a more connected way of representing company data.

Each layer captured specific relationships and attributes, all linked back to a single core company record.

For stewards, this meant

Seeing how records were related across layers without losing context.

Tracing data lineage to understand where information came from.

Reviewing and validating data in one place instead of switching systems.

Snapshot of how company data connects across layers to create a more enriched data source

/

Data Meets Design

Making the merge process clear and manageable

When it came to the design, I focused on making the new, more complex data model easy to follow while giving stewards the clarity and control to navigate it confidently and make the decisions they needed to make.

I wanted stewards to

feel confident in what they were seeingIn this case study

to understand system suggestions at a glance

step in and override the system when needed

always feel in control of the process.

step in and override the system when needed

always feel in control of the process.

The new merge workflow

The new workflow introduced more complexity as stewards now needed to review and merge data across multiple layers instead of a single flat view. My role was to make that depth manageable.

The new journey lets stewards see the full merge process in one place, so they can make confident decisions without switching systems.

/

the FINAL EXPERIENCE

The Final Experience

/

the FINAL EXPERIENCE

The Final Experience

STEP ONE

Moving to a layered data schema

When stewards open a merge task from Workspace, they’re brought to the Merge Portal on a new tab. Here, they review the system-suggested Surviving Record, see all records included in the merge, and can add or remove any before moving forward.

System-suggested "Surviving Record"

Adding or removing records

Content

STEP TWO

Selecting attributes for Golden Record

Stewards review all records side by side and select which attributes should form the Golden Record. The system preselects attributes from the suggested record based on survivorship scores, but stewards can override any value with a single click

Filtering for conflicting attributes

To reduce visual noise and speed up decision-making, stewards can toggle “Show only conflicting attributes” to display only fields where record values differ.

STEP THREE

Reviewing related data / child records

Next, stewards need to review child or related records that are connected to the parent records being merged. This step reflects the new layered data schema, where company data is linked across multiple related tables.

STEP THREE

Confirm and submit the merge

Once stewards have reviewed attributes and related records, they submit the merge and move to the final confirmation step where the modal simply asks them to verify accuracy and confirm submission. If they want to double check any details, they can navigate back through previous steps before submitting.

/

LESSONS LEARNED

What this project taught me about designing for data

The MDM project as a whole taught me a lot about designing for data, but the merge experience in particular opened up my eyes to how the data architecture and schema really shapes the experience. It showed me how crucial it is to design with the data model, not just design for what users want/need, but still be able to translate the tech logic into something that feels natural for them.

Some things I learned

Design WITH the data schema

Understanding the schema and its relationships early meant the design could align with how the system actually behaved, reducing friction later.

Collaborating across disciplines is paramount

It was such a joy to work alongside the data architects and learn more about data and how it’s structured from them. It proved the importance of collaborating across disciplines.

Next project.

Orovia

Packaging and product design for a premium gourmet chocolate brand.

Designer

2023

Next project.

Orovia

Packaging and product design for a premium gourmet chocolate brand.

Designer

2023

Next project.

Orovia

Packaging and product design for a premium gourmet chocolate brand.

Designer

2023