Context
Designing data merge workflows for Master Data Management
Designing data merge workflows for Master Data Management
Designing data merge workflows for Master Data Management
Designing data merge workflows for Master Data Management
I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.
I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.
I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.
Designing data merge workflows for Master Data Management
Designing data merge workflows for Master Data Management
I designed a core workflow within an enterprise Master Data Management product to help Data Stewards merge duplicate records into a single trusted Golden Record.
Senior Experience Designer
This project was part of a larger Master Data Management (MDM) transformation initiative for a Fortune 500 B2B SaaS client. The organisation brought us in to build a new, internal MDM tool on the ServiceNow Platform.
The project involved reviewing and modifying several existing workflows for the primary users, known as Data Stewards. We were developing this new experience on the ServiceNow platform, so most of the new workflows were designed to leverage the capabilities of ServiceNow Workspace. All but one.
This project was part of a larger Master Data Management (MDM) transformation initiative for a Fortune 500 B2B SaaS client. The organisation brought us in to build a new, internal MDM tool on the ServiceNow Platform.
The project involved reviewing and modifying several existing workflows for the primary users, known as Data Stewards. We were developing this new experience on the ServiceNow platform, so most of the new workflows were designed to leverage the capabilities of ServiceNow Workspace. All but one.
This project was part of a larger Master Data Management (MDM) transformation initiative for a Fortune 500 B2B SaaS client. The organisation brought us in to build a new, internal MDM tool on the ServiceNow Platform.
The project involved reviewing and modifying several existing workflows for the primary users, known as Data Stewards. We were developing this new experience on the ServiceNow platform, so most of the new workflows were designed to leverage the capabilities of ServiceNow Workspace. All but one.
4+
Systems Replaced
4+
Systems Replaced
30%
Improvement in data quality
30%
Improvement in data quality
25%
Reduction in duplicate record conflicts
25%
Reduction in duplicate record conflicts
Role
Lead Designer
Lead Designer
Lead Designer
Industry
Enterprise SaaS
Enterprise SaaS
Enterprise SaaS
Topic
Data Management
Data Management
Data Management
Services
UX Strategy,
UX Research,
Workflow Design
Stakeholder Facilitation
UX Strategy,
UX Research,
Workflow Design
Stakeholder Facilitation
UX Strategy,
UX Research,
Workflow Design
Stakeholder Facilitation
The Problem
Three problems resulted in one broken experience.
Three problems resulted in one broken experience.
The data stewards worked with two main systems when merging records - ServiceNow and IDD. There were no proactive alerts for duplicates or mergers sent by the system, instead, they were usually reported through sales requests, and stewards validated the information using external tools, like Dun & Bradstreet (D&B) and the company's website.
The data stewards worked with two main systems when merging records - ServiceNow and IDD. There were no proactive alerts for duplicates or mergers sent by the system, instead, they were usually reported through sales requests, and stewards validated the information using external tools, like Dun & Bradstreet (D&B) and the company's website.
01 · Legacy tooling
Legacy tooling
01 · Legacy tooling
Scattered across too many systems
Scattered across too many systems
Stewards toggled between the legacy MDM tool, ServiceNow Workspace, external sources to evaluate a single merge. Each switch broke focus and cost time.
Stewards toggled between the legacy MDM tool, ServiceNow Workspace, external sources to evaluate a single merge. Each switch broke focus and cost time.
02 · Platform ceiling
Platform ceiling
ServiceNow couldn't support the logic
ServiceNow couldn't support the logic
The rest of the MDM system would live in ServiceNow Workspace, but it was only able for for simple, single-field merges. We had to design for a new multi-relational data model.
The rest of the MDM system would live in ServiceNow Workspace, but it was only able for for simple, single-field merges. We had to design for a new multi-relational data model.
03 · A new data model
A new data model
The schema was changing underneath us
The schema was changing underneath us
We were replacing the flat schema with a new layered model, introducing parent-child relationships between records. A merge now meant reconciling entire hierarchies of connected data across related tables.
We were replacing the flat schema with a new layered model, introducing parent-child relationships between records. A merge now meant reconciling entire hierarchies of connected data across related tables.
The pre-existing merge workflow required switching between at least three separate systems
The pre-existing merge workflow required switching between at least three separate systems
Understanding the Data
How the data would affect our proposed solution
How the data would affect our proposed solution
How the data would affect our proposed solution
The move from a flat schema to a layered one fundamentally altered what a merge involved and what the interface needed to do. Understanding this shift was foundational to every design decision that followed.
The move from a flat schema to a layered one fundamentally altered what a merge involved and what the interface needed to do. Understanding this shift was foundational to every design decision that followed.
Before - Flat model
Before - Flat model
Pick one full record as the "winner" with no field-level selection
Pick one full record as the "winner" with no field-level selection
Pick one full record as the "winner" with no field-level selection
Every record was a peer to every other
Every record was a peer to every other
Every record was a peer to every other
Data stored as plain text strings, no references or linkable IDs
Data stored as plain text strings, no references or linkable IDs
Data stored as plain text strings, no references or linkable IDs
No visibility into survivorship scoring
No visibility into survivorship scoring
No visibility into survivorship scoring
No data lineage
No data lineage
No data lineage
After - Multi-layered model
After - Multi-layered model
Merges operate at the field level so each attribute can be sourced from any record
Merges operate at the field level so each attribute can be sourced from any record
Merges operate at the field level so each attribute can be sourced from any record
Merges must account for all child records
Merges must account for all child records
Merges must account for all child records
Parent and child records linked via typed references
Parent and child records linked via typed references
Parent and child records linked via typed references
Every field carries a survivorship score
Every field carries a survivorship score
Every field carries a survivorship score
Full data lineage
Full data lineage
Full data lineage
A transition from flat merges to a layered data model, introducing new decision points around related records.
A transition from flat merges to a layered data model, introducing new decision points around related records.
Discovery
04 · Discovery
Understanding the foundations of the problem
Understanding the foundations of the problem
MDM is a specialist domain with its own logic, language, and constraints. Before touching the design, I needed to understand how the existing workflow worked, how stewards made decisions, what the platform could and couldn't support, and what the data architects were building.
MDM is a specialist domain with its own logic, language, and constraints. Before touching the design, I needed to understand how the existing workflow worked, how stewards made decisions, what the platform could and couldn't support, and what the data architects were building.
1
ContextUAL INQUIRIES - DATA STEWARDS
Process walkthrough sessions with data stewards
Process walkthrough sessions with data stewards
Approach
I ran one-to-one walkthrough sessions with data stewards, asking them to talk me through how they completed a merge from start to finish using the existing tools.
These were observational, so I could see the workflow as it actually happened.
I ran one-to-one walkthrough sessions with data stewards, asking them to talk me through how they completed a merge from start to finish using the existing tools.
These were observational, so I could see the workflow as it actually happened.
Reasoning
Before designing a new workflow, I wanted to map the existing one to identify where the real problems were, find natural points to introduce the new merge flow, and understand steward sentiment so I could spot any quick wins along the way.
Before designing a new workflow, I wanted to map the existing one to identify where the real problems were, find natural points to introduce the new merge flow, and understand steward sentiment so I could spot any quick wins along the way.
What I learned
Stewards were navigating between three separate systems to evaluate a single merge, with no shared context carried between them. There was also a consistent lack of confidence in the outcomes, as stewards had to consult external sources to verify information.
Stewards were navigating between three separate systems to evaluate a single merge, with no shared context carried between them. There was also a consistent lack of confidence in the outcomes, as stewards had to consult external sources to verify information.
Outcome
Existing merge journey map
Existing merge journey map
Stewards managed merges across multiple systems, using manual and external lookups to decide which record to keep.
Stewards managed merges across multiple systems, using manual and external lookups to decide which record to keep.
2
TECHNICAL DISCOVERY – DATA ARCHITECTS
Understanding the data model and merge logic
Understanding the data model and merge logic
Approach
I met with the data architects to walk through the new data model, focusing on how entities were structured and related during a merge.
These were collaborative sessions where we mapped out relationships, dependencies, and how child records would behave in different merge scenarios.
I met with the data architects to walk through the new data model, focusing on how entities were structured and related during a merge.
These were collaborative sessions where we mapped out relationships, dependencies, and how child records would behave in different merge scenarios.
Reasoning
Before designing the interface, I needed to understand how the shift from a flat to a layered data model would impact decision-making.
This helped me identify which data points were critical and what stewards would need to see to confidently make merge decisions.
Before designing the interface, I needed to understand how the shift from a flat to a layered data model would impact decision-making.
This helped me identify which data points were critical and what stewards would need to see to confidently make merge decisions.
What I learned
The new model introduced multiple layers of related records that needed to be considered during a merge, not just the parent entity.
This meant stewards were choosing which records to merge, as well as which related child records and attributes to carry forward.
The new model introduced multiple layers of related records that needed to be considered during a merge, not just the parent entity.
This meant stewards were choosing which records to merge, as well as which related child records and attributes to carry forward.
Outcome
Outcome
New merge journey map
New merge journey map
The new journey lets stewards see the full merge process in one place, so they can make confident decisions without switching systems.
The new journey lets stewards see the full merge process in one place, so they can make confident decisions without switching systems.
The new journey lets stewards see the full merge process in one place, so they can make confident decisions without switching systems.
3
DESK RESEARCH & UPSKILLING
Building domain knowledge in MDM and data governance
Building domain knowledge in MDM and data governance
Approach
I invested time in self-guided learning by completing an MDM certification and reviewing documentation, data models, and industry case studies.
I focused specifically on understanding concepts like survivorship logic, data lineage, and how enterprise systems handle conflicting data based on my conversations with the Data Architects.
I invested time in self-guided learning by completing an MDM certification and reviewing documentation, data models, and industry case studies.
I focused specifically on understanding concepts like survivorship logic, data lineage, and how enterprise systems handle conflicting data based on my conversations with the Data Architects.
Reasoning
The domain was very technical, and I needed a strong foundational understanding to design a data-aligned solution.
Building this knowledge allowed me to work alongside the architects and engineers, and it meant my design decisions were grounded in how the system and data model worked.
The domain was very technical, and I needed a strong foundational understanding to design a data-aligned solution.
Building this knowledge allowed me to work alongside the architects and engineers, and it meant my design decisions were grounded in how the system and data model worked.
What I learned
MDM is driven by complex rules and logic that aren’t always visible to users, especially around how “correct” data is chosen.
This meant the interface needed to show key signals like confidence scores and survivorship scores, and put everything in front of them in a digestible way.
MDM is driven by complex rules and logic that aren’t always visible to users, especially around how “correct” data is chosen.
This meant the interface needed to show key signals like confidence scores and survivorship scores, and put everything in front of them in a digestible way.
4
CO-CREATION SESSIONS – STAKEHOLDERS & DATA STEWARDS
Weekly design reviews and collaborative iteration
Weekly design reviews and collaborative iteration
Approach
I ran weekly co-creation sessions with both stakeholders and data stewards, using design walkthroughs to gather feedback and validate decisions in real time.
These sessions were hands-on, allowing us to review flows, test ideas, and iterate quickly together.
I ran weekly co-creation sessions with both stakeholders and data stewards, using design walkthroughs to gather feedback and validate decisions in real time.
These sessions were hands-on, allowing us to review flows, test ideas, and iterate quickly together.
Reasoning
With the wider MDM programme constantly shifting, it was important to keep alignment across both business and end users.
Bringing everyone into the same conversation meant we were all aligned, and decisions were made with full context.
With the wider MDM programme constantly shifting, it was important to keep alignment across both business and end users.
Bringing everyone into the same conversation meant we were all aligned, and decisions were made with full context.
What I learned
Keeping stakeholders and stewards in the same room meant faster feedback and a smoother sign-off.
It also created a more collaborative process, where decisions were understood, challenged, and agreed on together.
Keeping stakeholders and stewards in the same room meant faster feedback and a smoother sign-off.
It also created a more collaborative process, where decisions were understood, challenged, and agreed on together.
The People
Some steward thoughts
Some steward thoughts
Some steward thoughts
“We do jump around quite a bit. I’m used to it now but it could definitely be more straightforward. The worst part is how long it takes to complete a single task”
“We do jump around quite a bit. I’m used to it now but it could definitely be more straightforward. The worst part is how long it takes to complete a single task”
“I keep everything open at once because I know I’ll need to reference it again, probably more than once”
“I keep everything open at once because I know I’ll need to reference it again, probably more than once”
“I know a request is wrong when DUNS returns nothing, but then I have to figure out where the requester went wrong or what they meant”
“I know a request is wrong when DUNS returns nothing, but then I have to figure out where the requester went wrong or what they meant”
“There is a LOT of copying and pasting. It is probably the thing we spend most time doing”
“There is a LOT of copying and pasting. It is probably the thing we spend most time doing”
The data steward persona built from walkthrough sessions and used across the full MDM programme.
The data steward persona built from walkthrough sessions and used across the full MDM programme.
Design Principles
Taking my learnings and creating a strategy
Taking my learnings and creating a strategy
Based on my discovery phase, watching stewards work and spending time with architects, I came up with the following principles to follow, so I addressed the stewards' concerns while sticking to the requirements.
Based on my discovery phase, watching stewards work and spending time with architects, I came up with the following principles to follow, so I addressed the stewards' concerns while sticking to the requirements.
Principle 01
Bring the right decision forward
Bring the right decision forward
Stewards don’t need to review every field—only the ones that actually differ. Everything else is noise.
Principle 02
Make the system's logic visible
Make the system's logic visible
Stewards should understand why the system recommends a value so they can make confident decisions.
Principle 03
Keep them informed, not overwhelmed
Keep them informed, not overwhelmed
Clear structure, visible progress, and simple navigation help stewards stay in control of complex decisions.
Principle 04
Steward override is always the final word
Steward override is always the final word
Automation supports decisions, but stewards bring the context. The design had to keep them in control.
The Solution
A custom experience but built for complex merges.
The decision to build a separate portal rather than extending ServiceNow's native capabilities was one of the most significant calls on the project. It was the right call, but it came with real constraints. The portal had to feel like a natural extension of the ServiceNow workflow where the stewards arrive from a task in Workspace, complete the merge, and return when done.
The decision to build a separate portal rather than extending ServiceNow's native capabilities was one of the most significant calls on the project. It was the right call, but it came with real constraints. The portal had to feel like a natural extension of the ServiceNow workflow where the stewards arrive from a task in Workspace, complete the merge, and return when done.
Step 01
Present the recommended record up front
Present the recommended record up front
Present the recommended record up front
The MDM engine has already calculated a survivorship score for every record and recommended the strongest candidate as the Surviving Record, this is the base from which the Golden Record will be built. The steward's job here is to verify that the right records are included before anything else begins.
The MDM engine has already calculated a survivorship score for every record and recommended the strongest candidate as the Surviving Record, this is the base from which the Golden Record will be built. The steward's job here is to verify that the right records are included before anything else begins.
Step 02
Building the Golden Record, attribute by attribute.
Building the Golden Record, attribute by attribute.
Building the Golden Record, attribute by attribute.
This is the core of the merge and the step that took the most design iterations. All records sit side by side, with the MDM engine pre-selecting a value for each field based on survivorship scoring. The steward reviews, confirms, or overrides each one.
This is the core of the merge and the step that took the most design iterations. All records sit side by side, with the MDM engine pre-selecting a value for each field based on survivorship scoring. The steward reviews, confirms, or overrides each one.
Step 03
Reviewing and selecting related child records.
Reviewing and selecting related child records.
Reviewing and selecting related child records.
This is where the new data schema had the most influence. Stewards had to actively choose which child records to come across. The related tables sidebar shows every child dataset in the merge. Stewards move between them, reviewing records from each source and deciding what to include in the Golden Record.
This is where the new data schema had the most influence. Stewards had to actively choose which child records to come across. The related tables sidebar shows every child dataset in the merge. Stewards move between them, reviewing records from each source and deciding what to include in the Golden Record.
This is where the new data schema had the most influence. Stewards had to actively choose which child records to come across. The related tables sidebar shows every child dataset in the merge. Stewards move between them, reviewing records from each source and deciding what to include in the Golden Record.
Step 04
Confirming the merge and creating the Golden Record.
Confirming the merge and creating the Golden Record.
Confirming the merge and creating the Golden Record.
Everything the steward has decided is laid out in one place before anything is committed. The master record, the selected attributes with their survivorship scores, the child records across every dataset, and a breakdown of system defaults versus steward overrides. If anything needs changing, they can step back without losing their other selections. When they're satisfied, they submit, and the Golden Record is created.
Everything the steward has decided is laid out in one place before anything is committed. The master record, the selected attributes with their survivorship scores, the child records across every dataset, and a breakdown of system defaults versus steward overrides. If anything needs changing, they can step back without losing their other selections. When they're satisfied, they submit, and the Golden Record is created.
Everything the steward has decided is laid out in one place before anything is committed. The master record, the selected attributes with their survivorship scores, the child records across every dataset, and a breakdown of system defaults versus steward overrides. If anything needs changing, they can step back without losing their other selections. When they're satisfied, they submit, and the Golden Record is created.
