Designing for five roles without building five products

The telehealth platform we built serves five distinct roles. Each one arrives with a different job, a different vocabulary and a different tolerance for complexity. The design problem is not building five interfaces. It is building one system that can present five honest views of itself.

Start from the job, not the data model

A provider and a patient can look at the same consultation record and need almost nothing in common from it. The provider needs history, prescribing and documentation. The patient needs to know what was decided and what happens next.

When you design outward from the shared data model, everyone gets a slightly wrong screen. When you design inward from each role's actual task, the shared model does its job quietly underneath — which is where it belongs.

Scope is a design decision before it is a permission

Role-based access is usually treated as a security control bolted on at the end. It is more useful as a design constraint at the start. A manager who only ever sees their own team does not need a filter for everyone else. Removing that filter makes the screen simpler and the permission model easier to reason about at the same time.

The five things this person needs, not the forty they do not — that is the whole brief.

The seams are where products fail

Most of the pain in multi-role systems lives at the handovers: the prescription passing to a pharmacy, the lab order returning a result, the leave request reaching an approver. Those transitions deserve more design attention than any single screen, because that is where users currently fall back on phone calls and email.

If a handover inside your product is slower than a WhatsApp message, people will use WhatsApp — and your system stops being the record.