Regulated sectors
Designing a music app and designing an insurer's claims process are not the same problem. When the error has real consequences for the user, the design works with other rules. This is what we have learned in more than a decade in banking, energy and insurance.
What changes when you design in sectors where making mistakes has real consequences
There is a difference between designing a music app and designing a claims process. Between designing an e-commerce and designing the access control system of an industrial plant. Between designing a content platform and designing the procedures portal of a public administration.
The difference is not only technical complexity. It's what's at stake.
When the user gets lost in an e-commerce, they abandon the cart and leave. When the user gets lost in managing their life insurance, they make the wrong decision about something that matters a lot to them. When an employee makes a mistake in a plant's control interface, the consequences can be operational and costly.
Having been designing primarily in those contexts for more than a decade has changed how we think about design. These are the things we have learned.
The user is not always the protagonist of the story
In user-centered design, there is an often-unnamed tension: the immediate user of a system is not always the person whose well-being most depends on that system working well.
In a claims process, the user who fills out the form is the call center manager. But the person whose experience matters is the customer who is waiting to hear about their claim and doesn't know what status it is in.
In an industrial machinery management app, the user who operates the interface is the technician. But if the interface does not allow you to detect an anomaly in time, the consequences are felt by other people and other processes.
Designing well in complex contexts means understanding that entire chain of impact — not just the direct user of the system, but everyone who depends on that user using it well.
Research has to go beyond user interviews
User research is the starting point, not the finishing point.
In regulated sectors, the user experience is conditioned by regulatory frameworks that the designer has to understand before proposing solutions. A banking onboarding flow cannot be designed without understanding what KYC regulations require. An AI assistant in insurance cannot be designed without understanding what the AI Act mandates in terms of transparency and explainability.
That means that the design team has to talk to the legal team, to the compliance team, to the risk team. Not to be told what you can and can't do — but to understand the full context of the problem before you start solving it.
In many of the projects we work on, the most valuable learnings have not come from user interviews. They have come from understanding the business, regulation and operation restrictions that surround the user.
Simplicity is more difficult when the problem is complex
There's an idea in design that sounds good but is often misunderstood: that the good experience is the simple one.
In complex sectors, simplicity for the user is the result of absorbing complexity in the system. Not to ignore it.
A claims form that asks the customer for the minimum necessary is not simple because the process is simple — it is simple because someone has decided how much of the complexity of the internal process is for the customer to manage and how much the system can resolve internally.
That decision is not made by the designer alone. The designer takes it with the operations team, with the legal team, with the product team. And it requires understanding the entire process before knowing what can be simplified without breaking anything.
Delivery is not the end of the work
In design projects for complex industries, design delivery is the beginning of implementation — not the end of the work.
What we design has to be buildable, with existing technology, within business deadlines, and by development teams that have not always been in the design process from the beginning.
That means that the specification work — documenting system behavior, error states, edge cases, accessibility rules — is part of the design, not an addendum to be added at the end when there is time.
And it means that monitoring during implementation is part of the value we bring. Not to police, but to resolve the questions that inevitably arise when design meets the reality of development.
Why this matters when choosing who to work with
If your organization operates in banking, energy, insurance, transportation or the public sector, the criteria for choosing a design team should not just be the visual portfolio. It should include whether that team understands the contexts in which it works — the regulation, the operational complexity, the risks of getting it wrong.
Not because design is difficult — it's that design in those contexts requires a specific type of accumulated experience that is not built in a few projects.
We have been accumulating it for more than a decade. And each project teaches us something new about what it means to design when consequences matter.