Discovery Activity 1 - Contextual Inquiries with Data Stewards
Designing a clearer merge workflow for master data management
Context
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.
What is Match and Merge
Overall MDM architecture with the Match & Merge workflow sat within the wider data transformation programme.
The Problem
The new data model required a workflow that went beyond Workspace’s native capabilities.
Match & Merge became the outlier within the MDM programme. Most workflows could be handled using standard ServiceNow Workspace, but stakeholders had a more ambitious vision for merge management.
They wanted a workflow where the system could assist decision-making, but Data Stewards remained responsible for the final outcome.
The pre-existing merge workflow required switching between at least three separate systems
What stakeholders wanted
The system would
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.
A transition from flat merges to a layered data model, introducing new decision points around related records.
Before
Flat Model
Discovery
Learning about what I needed to design and why
MDM is a specialist domain with its own logic, language, and constraints, so I needed to understand how the existing workflow worked and how stewards made decisions.
Stewards managed merges across multiple systems, using manual and external lookups to decide which record to keep.
Approach
Discovery Activity 2 - Technical Workshops with Data Architects
Understanding the data model and merge logic
Working documents from the technical discovery sessions with the data architects.
Approach
•
•
•
Key insights
•
•
•
The Users
Stewards were frustrated and defeated
Discovery sessions showed that stewards were very frustrated with the current experience and the didn't have much hope for any future improvements/
Observational findings from steward workflow sessions
Design Principles
Four principles to design against
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
Surface the decisions that matter
The experience should prioritise high-impact decisions and reduce noise during the merge process.
Principle 02
Make system logic transparent
Recommendations should explain why the decisions are being suggested;
Principle 03
Reduce cognitive overhead
Complex workflows should be structured into manageable steps that maintain context without overwhelming users.
Principle 04
Keep stewards in control
Automation shouldn't replace decision-making, it's there to support.
The Solution
Shaped by the data model, designed around the steward experience.
The merge experience stayed within the ServiceNow ecosystem, extending Workspace capabilities into the Portal experience to create a more seamless workflow.
By combining platform capabilities with SME collaboration, we designed a connected experience that better supported the new data model.
Step 1 - Review Records
Present the recommended record up front
The MDM engine calculates a survivorship score for every record and recommends the strongest candidate as the Surviving Record that will be the base of the Golden Record.
Feature 01
Merging records table
Design Decision (Principle 04)
If the system has missed anything, stewards can add more records
Feature 02
Suggested "Surviving Record"
Design Decision (Principle 01)
Creating a clear baseline early helps reduce decision fatigue and makes the merge process feel more guided
Step 2 - Select Attributes
Giving stewards control over every field to build the Golden Record
This is the core of the merge. 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 attribute.
Feature 03
Attribute-level selection
Design Decision (Principle 04)
This reflects the new layered data model, where the golden record needs to be built, not chosen.
Feature 04
Survivorship scores per field
Design Decision (Principle 03)
This makes the system's logic visible, giving stewards the confidence to either follow the recommendation or override it.
Step 03 · Review Related Data
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 by moving between them, reviewing records from each source and deciding what to include in the Golden Record.
Feature 05
Related tables navigation
Design Decision (Principle 03)
Grouping by table type mirrors how stewards think about data tables and also organises the interface logically.
Feature 06
Keeping Surviving Records' children
Design Decision (Principle 02)
These linked records have a downstream impact, so stewards should review them and choose what to bring along
Step 04 · Confirm Merge
One final review before anything is committed.
Everything the steward has decided is laid out in one place before anything is committed. If something needs changing, they can step back without losing their other selections.
Feature 07
Reviewing selections against the master
Design Decision (Principle 04)
Stewards need to be able to see what was selected to review
Feature 08
Data confidence score key
Design Decision (Principle 02)
We introduced threshold bands to give the numbers meaning so stewards know if it's worth a second look.
Test and Validation
Measuring the impact after launch
Once the new workflow was live, I returned to the same stewards and the same tasks to see what had actually changed.
Method 01
Task-based benchmarking
We benchmarked the merge workflow during early contextual inquiry sessions and repeated the same scenarios after implementation.
Results
37% reduction in average merge completion time
42% fewer validation checks against external systems
Method 02
Recommendation accuracy testing
We tested duplicate detection and suggested surviving records against real steward decisions and historical merge outcomes.
Results
89% alignment between system recommendations and steward-selected
72% reduced manual comparison effort
Method 03
Golden record quality reviews
A sample set of completed Golden Records was reviewed to assess data quality and attribute accuracy after merges.
Results