How this works: A real example

I once led research for a Federal Data Migration project.
On the surface, it was technical: move legacy contracts to a modern platform. But the real challenge was hidden.
 

Federal employees were drowning in:

• Four to six months to complete approvals (mostly waiting, not working)

• Multiple systems they had to juggle between, constantly

• Fear that one mistake meant redoing everything from scratch

• A new system that, no matter how well-designed, terrified them
   

The client was ready to blame users for "resisting change" and blame engineers for designing poor. But that wasn't the problem.
 

I conducted several interviews across eight stakeholder groups - not just users, but the teams supporting them, vendors, managers, architects. I shadowed workflows. I analyzed what actually happened versus what people thought happened. Then I mapped it all: the current journeys, the broken handoffs, where fear lived, where information scattered.​

​

What emerged wasn't a list of feature improvements. It was a service blueprint showing how the migration itself needed to be redesigned. Users weren't resisting the new platform - they were overwhelmed by fragmented processes they had no control over. The system was the problem, not the people.

That insight changed everything about how the project was approached.