The Same Feature Is Help to One User and Surveillance to Another

On a healthcare platform serving a marginalized community, I designed clinical intake workflows that a clinician reads as thorough and a patient reads as invasive. Both readings are correct. That is not a problem to solve. It is the condition you design inside.

Most products have one dominant user. The friction of designing for two is that you cannot optimize for one without creating pressure on the other. Every decision I made on that platform existed inside that pressure.

A Feature Has No Fixed Meaning

Consider a simple thing: asking a patient for their date of birth during registration. For a clinician, that field is routine data, the foundation of a care record.

For a patient from a community where healthcare has historically been hostile, that same field is one more proof of being catalogued. The field did not change. The context did.

This is not an edge case. It is the normal condition of any platform where one group holds institutional power and another group depends on that power for care. The screen looks the same to both users. It lands differently.

The instinct in product design is to treat ambiguity as a flaw and resolve it. Define the primary user, design for them, then accommodate everyone else. But on this platform there was no primary user.

Both groups were load-bearing. If patients did not trust the platform enough to complete registration, clinical staff had nothing to manage. If clinical workflows were too compromised to meet regulatory standards, the service could not operate. The design had to hold both groups or it would lose both.

Distributing the Load Across the Journey

One concrete place where this tension became visible: we needed roughly thirty required demographic data points per patient to meet a government surveillance reporting requirement. Thirty questions sitting at the front of the experience would look, to most patients, like an interrogation. Presenting the same data to clinical staff as a gap report at the end of a consultation would look, to them, like incomplete records.

Neither reading was wrong. The answer was to stop treating the data as a form and start treating it as a conversation spread across time. I mapped each required data point against the moment in the patient journey when asking for it would feel natural, working through the mapping with the clinical team to make sure the distribution still produced a complete record. Then I divided the collection across three stages: registration, appointment booking, and consultation.

Some questions are reasonable at registration. Some only make sense in the context of booking a specific type of appointment. Others belong in a clinical conversation with a trained provider.

By the time a patient arrived at their consultation, most of the reporting requirement was already satisfied, collected in the moments it was contextually appropriate. The clinician captured the remainder during the visit itself. Nobody faced a wall of questions.

The data captured was identical. The experience of being asked was not.

The Tension Goes All the Way Down

Distributing the collection across the journey solved the structural problem. But the tension persisted at every level below that.

When a patient entered an incorrect date of birth, the error message had to acknowledge the mistake without making the person feel caught. When a clinician reviewed the same field with an inconsistency, the interface had to surface the discrepancy without hiding it. Same field, different message, different moment, different stakes.

I wrote several versions of error messages for fields where the two groups would encounter failure differently. The clinical copy and the patient copy looked nothing alike. They pointed at the same data condition, but they spoke to different people navigating different kinds of risk.

This is where the work becomes genuinely hard. Not the architecture, not the data model. The sentence.

The sentence that a frightened person will read on a screen at 11pm after a health scare, and the sentence that a clinician will read at a busy clinic managing a queue of eight patients. Different people, same product, same event, different words.

What the Two-User Problem Teaches You

Designing inside this tension changes how you think about defaults. A default is a choice made on behalf of a user who has not expressed a preference. On a single-user product, a default is an educated guess. On a dual-user platform, a default is a political act: it expresses which user you trust, which need you weight, whose comfort you prioritize.

The most useful discipline I developed was to ask, for every screen: what is the most charitable reading a patient could make of this, and what is the most charitable reading a clinician could make of it? If the charitable readings were compatible, the design was probably defensible. If they were not, something needed to move.

You cannot hold two opposed readings of the same screen at once unless you have genuinely internalized both. That requires spending real time with both user groups before you pick up Figma. It requires building the kind of clinical knowledge that makes the regulatory logic feel obvious rather than arbitrary. It requires treating community trust not as a soft metric but as a structural dependency the whole system runs on.

The hardest part is not resolving the tension. The hardest part is staying in it long enough to design something neither group will refuse.