Understanding before simplifying
Digital identity initiative · Self Sovereign Identity (SSI) · UX strategy · Complex systems
I used to believe that good design meant removing friction: fewer decisions, fewer clicks, less complexity.
Working on a national digital identity initiative challenged that belief. The product was shaped by technical architecture, regulation, accessibility, security, political scrutiny and public trust. Usability mattered, but it was never the only goal.
Because the project is confidential, names, interfaces and implementation details have been generalised. The design questions and lessons are authentic.
The shift in my approach
What I brought into the project
01Reduce friction
02Use familiar patterns
03Simplify the experience
What the project taught me
01Question assumptions
02Understand the domain
03Design for the right outcome
One of the first interactions I encountered felt wrong.
Instead of presenting a QR code to identify yourself, you had to scan one first.
I instinctively questioned why. I was used to showing a QR code for identification in many situations, so having to scan first made me stop and think. The explanation was about data sovereignty. Before sharing personal information, users should first know who is asking, what data is being requested, and what they are about to approve.
The interaction was not designed to minimise effort. It was designed to protect informed consent. I understood the reasoning, yet it still felt unfamiliar. That tension exposed a blind spot: I was judging the product through patterns learned in other domains.
A familiar identity pattern
01Present a QR code
02The other party scans it
03Identity data is read
A data-sovereign request pattern
01Scan the request
02Review the requested attributes
03Choose whether to share
I stopped looking for better solutions and started looking for better questions.
Why does this exist? Which problem is it solving? Which principle is being protected? What would be lost if we removed the complexity?
I kept asking until I could explain the processes myself and make decisions based on knowledge rather than assumptions.
Before I could simplify the experience, I first had to understand why it was complex.
Three small interface questions revealed three larger product decisions.
What looked like local interface friction was often protecting something more important: agency, meaning, or the user's mental model of the system.
When simplicity removes control
Should an unregistered but potentially harmful request be blocked automatically, or should users be warned and allowed to decide for themselves?
A shorter flow would block the request. The chosen approach exposed the deviation, warned the user and required deliberate confirmation.
I initially found the additional friction uncomfortable. But blocking would also make the decision on the user's behalf.
We were not discussing a warning dialog. We were deciding whether convenience should outweigh agency.
What story should a history tell?
Should an activity history show everything the system does, or only what the user intentionally did?
The specification proposed showing automatic credential renewals in the activity history. Technically, that was logical: something happened, so it belonged in the list.
I argued that the history should reflect deliberate user actions. A credit-card statement shows my transactions, not every internal process at the bank.
We were not discussing a list item. We were defining the mental model of the product.
Where should the feature live?
Should automatic credential renewal live in global settings, or with the credential itself?
The menu settings was an available container. But the action was not about configuring the application. It was about managing a specific credential.
I argued that users think in terms of objects and tasks, not technical capabilities. Managing a credential belongs where the credential lives.
We were not discussing navigation. We were deciding whether the product should mirror its architecture or the user's mental model.
Before
Reduce friction by default
Prefer familiar interaction patterns
Treat additional steps as usability debt
Simplify before fully understanding the domain
After
Question assumptions before redesigning
Understand which principle a pattern protects
Treat purposeful friction as part of the product logic
Optimise for the right outcome, not only for fewer steps
The project did not teach me a new design method.
It changed the questions I ask before designing. I no longer optimise for simplicity by default. I optimise for understanding. I no longer assume familiar patterns are automatically better. I ask whether they express the product's principles. I no longer treat friction as a defect. I ask what purpose it serves.
Every simplification hides something. Sometimes that is exactly what users need. Sometimes it removes awareness, meaning or control. Good design does not emerge from applying universal patterns. It emerges from understanding the domain, the values behind the system and the outcome the product must protect. I ask why before I ask how.