Human-centred design sounds straightforward until you try to practise it inside a Canadian insurance company while a FINTRAC deadline is two months away and the steering committee wants a demo by Thursday.
I have led HCD programs at two major Canadian insurers. Both were in regulated environments. Both had compliance requirements that could not be compromised. Both had business stakeholders who were, at various times, certain that we were spending too much time talking to users and not enough time building things.
What nobody tells you is that HCD in a regulated environment is not harder because of the regulation. It is harder because of the organizational dynamics that regulation creates.
In a regulated environment, there is a persistent temptation to treat compliance requirements as a proxy for user needs. The logic goes like this: the regulator requires this disclosure, therefore we must show it to the user, therefore showing it to the user is the design. This is almost always wrong.
What the regulator requires and what the user needs to understand are related but not the same thing. A FINTRAC identity verification requirement tells you what information you must collect. It does not tell you how to collect it in a way that makes sense to someone filling out an insurance application on their phone for the first time.
On the electronic insurance application I led at Equitable Life, we went through seven rounds of user testing on the identity verification flow alone. The regulatory requirement never changed. What changed was how we presented it, how we sequenced the questions, and what we did when something went wrong. Each round of testing produced improvements. The seventh round produced a flow that advisors and clients could complete without calling our support line.
This is the real problem. Not the research methodology. Not the synthesis. Not even finding users to talk to. The problem is organizational permission to spend time on research when there is always something more urgent to do instead.
The answer I have found is to make the research visible and useful to the people who control the timeline. A user testing session that produces a ten-page report no one reads does nothing for your political capital. A user testing session where you invite the product sponsor to watch someone struggle with the current design for twenty minutes does quite a lot.
Observation is more persuasive than reporting. Put the people who control the timeline in the room when users are struggling. You will not have to argue for research time after that.
The reframe I have found most useful is treating regulatory constraints not as barriers to good design but as design inputs. Every constraint defines a boundary. Good design works within boundaries.
When the AML requirement says you must verify identity before a transaction can proceed, that is a design constraint. The design question becomes: where in the user journey does identity verification feel least disruptive? When does the user have context to understand why you are asking? What happens if verification fails? These are design questions, not compliance questions. The answer to them makes both the user experience and the compliance outcome better.
The things that get cut when HCD is under time pressure are almost always the things that matter most: the edge cases, the error states, and the recovery flows. The happy path gets tested. The unhappy paths get deferred.
In insurance specifically, the unhappy paths are where the experience lives. An advisor whose client fails identity verification at 4pm on a Friday before a policy needs to be in force is not on a happy path. How that experience is handled determines whether that advisor ever uses the platform again.
I have seen applications go live with excellent happy-path flows and unusable error states. The support call volumes after launch told the story. We went back and fixed them. It would have been much cheaper to have tested them in the first place.
HCD in a regulated environment is possible. I have done it, and the platforms are still running. The key is not to treat regulation and user experience as opposing forces. They are both trying to accomplish the same thing: a transaction that works, that the user understands, and that stands up to scrutiny afterward.