Designing for sensitive data: UX when not everything can be visible
Designing with sensitive data is not just about protecting information, but about deciding what data is displayed, to whom, when and with what level of control, without making the experience a burden for the user.
UX · Sensitive data · Privacy · SSI · Digital health · Trust · Digital product
Privacy as part of the experience
Privacy by design should be a starting point, not an extra layer added at the end of the product development process. But in products that handle sensitive data, the challenge does not end with protecting the information: it also lies in making the experience clear, simple and useful for those who have to use it.
Often, whether from a business or product perspective, there is a temptation to request more data than is strictly necessary. More fields, more forms, more consents, more contextual information, more potential KPIs. Such information may be valuable for analysing, measuring or improving a service, but it does not always provide direct value to the user at the moment it is requested.
This is where UX becomes critical. If the user feels that the product is demanding data without properly explaining why, without providing any benefit in return or without helping them with a specific task, trust is eroded. In sectors such as healthcare, banking, public administration, digital identity or data platforms, the user should not have to bear the burden of the system’s complexity simply so that the organisation can capture more information.
Designing for sensitive data involves striking that balance: protecting, simplifying and adding value. It is not about hiding everything, nor about revealing everything, nor about asking for everything. It is about ensuring that every piece of data makes sense within the flow.
From protecting data to building trust
Having worked on projects relating to digital health, identity, verifiable credentials, data spaces and processes involving sensitive information, it is becoming increasingly clear to me that privacy cannot be understood solely in terms of regulatory compliance.
It is also a matter of user experience, trust and product design. A product may formally comply with data protection requirements and yet still generate mistrust. It may have legal notices, consent forms, permissions and policies that are correctly drafted, but force the user to accept something they do not understand, ask for data they do not perceive as necessary, or display sensitive information without the appropriate context.
The opposite can also happen: trying to protect information so much that the product becomes useless. If a professional cannot access the data they need to make a decision, if an organisation cannot verify an authorisation, or if a user does not understand what they are sharing, privacy becomes poorly resolved friction.
That is why designing for sensitive data is not just about minimising exposure, but about designing proportionate access. What does each user profile need to see? What action must they take? What full data is necessary, and when is a signal, a status, a validation or a summary sufficient? What information should remain hidden by default, and what should be displayed for the process to make sense?
This is particularly important when internal measurement requirements arise. KPIs are necessary, but they should not be used to justify a more cumbersome user experience if the user receives nothing in return. Asking for more data simply because it might be useful later can lead to endless forms, unclear consent requests or processes that seem designed for the organisation rather than the individual.
Trust is built when the user understands why they are being asked for something, what benefit they gain, what control they retain, and what the consequences are of sharing or not sharing certain information. When it comes to sensitive data, a good experience is not just one that provides the best protection, but one that makes that protection understandable and actionable.
The challenge lies in showing just the right amount
Designing with sensitive data requires making very specific decisions. It is not enough simply to apply permissions or hide fields. We need to define which information adds value, which information poses a risk, and how all of this translates into an experience that enables users to take action without revealing more than is necessary.
Minimum required data
Not everything that can be requested should be requested. Collecting only the minimum necessary data is not just good privacy practice; it is also a UX decision. The more information that is requested, the more effort is required and the more doubts arise. The key lies in identifying which information is essential to move the process forward and which can be omitted, inferred, reused or requested only when it is genuinely necessary.
Value over catch
Collecting data to measure, segment or generate KPIs may make sense for the organisation, but the user needs to perceive value in the interaction. If they are asked for sensitive information, they must understand what benefit they will gain: a faster process, a more accurate recommendation, a simpler verification process, a more personalised service or a better-informed decision.
Reasonable leave
Permissions should not be seen as an incomprehensible technical or legal barrier. In products handling sensitive data, users need to know what they are authorising, who will be able to access it, for what purpose, and for how long. The user experience must translate roles, permissions and consents into clear actions, not into layers of text that are accepted without being read.
Context rather than exposition
Sometimes you don’t need to display all the data to make a decision. A status, an alert, a validation, a summary or a confidence indicator may be enough. Good design means knowing when detail adds value and when it merely increases the risk. Showing less isn’t always the same as hiding; sometimes it’s a way of protecting without losing functionality.
Designing decisions, not just screens
When it comes to products involving sensitive data, the experience is not limited to simply displaying information. It involves designing decisions: what is requested, what is shared, what is verified, what is concealed, what is recorded, and what each party involved in the process is permitted to do.
In healthcare, for example, not all user profiles need access to the same level of clinical information. One professional may need to consult a complete set of data to make a clinical decision, whilst another may only need to verify a status, an authorisation or the existence of specific information. Good design involves differentiating between access, purpose and responsibility.
Something similar applies to digital identity and verifiable credentials. An individual should not have to share a complete document if it is sufficient to demonstrate a single attribute. The user experience must help clarify what data is being presented, who is requesting it, which organisation will verify it, and what accepting that presentation entails. The value lies in reducing friction without losing control.
In data ecosystems, sensitivity also extends to the organisational level. It is not just a matter of protecting personal data, but of defining under what conditions an organisation may use a service, process information or access aggregated data. Here, UX must make the rules visible without turning governance into a maze.
In banking or KYC processes, sensitive information is intertwined with compliance, risk and verification. If the workflow is designed solely with the need to collect documentation in mind, the experience can become cumbersome and untrustworthy. If it is designed with usability in mind, it can guide the user, reduce repetition, explain each request and make the process seem more reasonable.
Care must also be taken with artificial intelligence applied to sensitive data. A model can summarise, classify, recommend or detect patterns, but the experience must make it clear what the AI is doing, what data it uses, what a person needs to review, and how reliable the output is. When the data is sensitive, automating without explanation can generate more uncertainty than value.
Therefore, designing for sensitive data requires consideration of architecture, permissions and compliance, but also of language, hierarchy, decision points, errors, exceptions and trust. The interface is where many of these rules become tangible. It is the place where the user understands, hesitates, accepts, rejects or becomes stuck.
Practical privacy, not mere window dressing
Sensitive data does not need any further visible complexity; it needs experiences that make it clear what is being protected, what is being shared and what purpose it serves.
Privacy by design should be a basic requirement, but the product cannot stop there. A solution can be secure and yet still be confusing, cumbersome or difficult to adopt. It can protect data effectively whilst, at the same time, asking for too much information, providing too little explanation or turning every interaction into a burden. In complex products, trust is not achieved simply by hiding information, but by designing the right access at the right time.
For those of us working on digital products, the challenge lies in balancing needs that sometimes compete with one another: protecting data, complying with regulations, measuring impact, generating KPIs, facilitating decisions and delivering value to the user. Designing for sensitive data means not passing on all that complexity to the person using the product. It means turning privacy, permissions and control into a clear, proportionate and useful experience.
Let’s talk about UX, data and trust
I work on digital products where the user experience has to coexist with sensitive data, identity, interoperability and access rules. If you’re exploring solutions where privacy, business and usability need to be balanced, let’s have a chat.