Privacy in Aleris Digital Interfaces — Jobs to Be Done Analysis

Status

Desk research-based JTBD analysis. Derived from academic literature, practitioner sources, and Aleris's own Privacy by Design development principles. Not validated through user research — to be treated as a structured hypothesis for design decisions.

Two Domains, Different Jobs

Privacy in Aleris interfaces serves two fundamentally different user groups with different needs. A patient managing their own data and a clinician managing data about others have jobs that sometimes directly conflict. The design system must serve both without forcing one domain's logic onto the other.

Domain 1: The Private Individual (Patient / Customer)

Primary Job

I want to manage my healthcare without having to think about whether my information could end up in the wrong place.

The functional job is booking, preparing, following up. The emotional job — what privacy touches — is about not having to be vigilant. Research consistently shows that most patients express concern about health data protection but few know who actually has access. The driver is not GDPR knowledge but a diffuse feeling of not being in control.

Job 1.1 — Hand over sensitive information without it lingering visibly

Functional: Enter national ID, health data, contact information. Emotional: It should feel like dropping a letter in a mailbox — it disappears from my world after I confirm. Social: If someone glances at my screen, they should not see my details.

Pains:

National ID visible on screen after input is complete
Health details displayed in plaintext in an overview I didn't ask for
Sensitive diagnoses visible in notifications or preview text

Gains:

Masking logic: data visible during editing, hidden after confirmation
Confirmation that data was received without re-exposing it
The system "closes the door" behind me

Design system implication: Masked input field component. Shows cleartext during active editing, transitions to masked state (last four digits or fully hidden) on blur/confirmation. Toggleable "show" interaction for re-verification.

Job 1.2 — Know my information is safe without understanding how

Functional: See that the system has security measures. Emotional: Trust without having to validate. Social: Be able to tell family "it's safe" without explaining the technology.

Pains:

Hospitalized patients express particular concern about unauthorized third-party access, given that health apps are often free and easily downloadable
Yet most patients accept the risk of data misuse once they've adopted a technology (the privacy paradox) — concern exists but rarely converts to action

Gains:

Subtle visual cues communicating security without requiring reading (icons, layout patterns, consistent treatment of sensitive fields)
Transparency that is experienced, not studied
The absence of anxiety signals — no jarring security warnings that imply something might be wrong

Design system implication: A consistent visual language for "this is protected." Not a padlock icon on every field, but a recognisable pattern: sensitive data fields share a visual treatment (consistent component, consistent placement) that builds trust through familiarity rather than explicit security messaging.

Job 1.3 — My diagnosis should not define how I'm perceived

Functional: Manage my care. Emotional: Not be reduced to a diagnosis. Social: Control who knows what about my health.

Pains:

Cancer patients and psychiatric patients are notably more hesitant to share via national digital platforms, driven by fear of stigma or causing worry among family
Patients worry about health information being used by employers or insurance companies to discriminate against them
Some conditions carry heavier social weight than others — mental health, sexual health, substance use

Gains:

Graduated visibility — I control what is shown to whom
Diagnosis information never exposed in contexts where it's not clinically necessary (booking confirmations, SMS reminders, sharing links, notification previews)
A clear distinction between "administrative information about my visit" and "clinical information about my condition"

Design system implication: Notification and messaging components that default to generalized content ("You have a new message from Aleris" — not "Your PSA test result is available"). Content classification at the data layer that distinguishes administrative from clinical, surfaced as component behaviour.

Job 1.4 — See who has viewed my information

Functional: Review access log. Emotional: The feeling of control and transparency — knowing the system monitors itself. Social: Trust in the healthcare system as an institution.

Pains:

Access logs that are unreadable or inaccessible
No confirmation that logging occurs
The uncertainty itself creates distrust

Gains:

A simple, accessible view: "These people have viewed your records"
Not hidden behind three clicks
Presented in plain language, not system terminology (staff name + role + date, not internal IDs)

Design system implication: Access log component designed for patient comprehension: human-readable, chronological, with role context. This is progressive disclosure inverted — transparency about others' access should be easy to find, not hidden.

Job 1.5 — Use the service on my phone in a public setting

Functional: Book appointments, read information, check results. Emotional: Not feel exposed. Social: The person sitting next to me on the bus should not be able to read my diagnosis.

Pains:

Large heading styles with diagnosis names
Push notifications with health data in preview
Screens that don't account for shoulder surfing

Gains:

Generalized notifications: "New message from Aleris" not "Your obesity consultation is confirmed"
Sensitive data hidden behind interaction (tap to reveal)
Option for a "discreet mode" for public use

Design system implication: A "discreet mode" token set or component state that reduces visible sensitive content. Notification content templates that default to non-clinical language. Tap-to-reveal interaction pattern for sensitive data in mobile contexts.

Domain 2: Healthcare Staff (Clinician, Administrator, Coordinator)

Primary Job

I want to provide safe care without the system slowing me down.

The functional job is identifying the right patient, documenting correctly, communicating with colleagues. Emotionally, it's about not making mistakes. Patient safety overrides data minimisation in the operational context.

Job 2.1 — Quickly and safely identify the correct patient

Functional: Confirm I'm working with the right person. Emotional: Security that I'm not making a mix-up. Social: Professional standard — colleagues should be able to verify.

Pains:

Screen displays with confusing layouts and extraneous information making identifying data hard to find
Patient lists where names look similar without distinguishing attributes
National ID displayed in contexts where it's not needed (administrative views)

Gains:

Patient identity consistently placed (always same position on screen)
Name + one secondary attribute (date of birth or last four digits of national ID) sufficient for identification
Additional ID information accessible on explicit need — not absent, just not default

Design system implication: Patient identification component with fixed placement pattern. Consistent layout: name prominent, secondary identifier visible, full national ID expandable. This component is safety-critical — its placement and hierarchy should be invariant across all clinical views.

Job 2.2 — Document without the system creating unnecessary steps

Functional: Record clinical observation or action. Emotional: Flow in work, not friction. Social: Show colleagues the work is documented.

Pains:

Clinicians average 1.4 task switches per minute; documentation duplication (bedside paper notes later entered into EHR) compounds the burden
Every extra click required for privacy purposes (confirmation dialogs, identity verification) is experienced as friction in an already overloaded workday
Privacy controls that interrupt clinical flow create workarounds that are worse than no control

Gains:

Access logging that happens invisibly — the system records that I viewed something without requiring confirmation from me
Privacy controls that don't interrupt clinical flow
Documentation that automatically carries provenance (who, where, when) without extra form fields

Design system implication: Provenance metadata captured automatically by the system, not through visible UI fields. The clinician writes the clinical note; the system attaches who wrote it, where, when, and under whose responsibility. No extra inputs.

Job 2.3 — Discuss a patient with a colleague without security steps every time

Functional: Share information within a treatment team. Emotional: Collaboration should be easy, not administrative. Social: A professional culture of information sharing for the patient's benefit.

Pains:

Role explosion in access systems — staff requiring multiple role assignments and spending time on access request tickets or switching roles to perform tasks
Systems that treat internal team collaboration with the same security level as external sharing
Legitimate information needs blocked by overly rigid access controls

Gains:

Team-based access where the treatment team's permissions are already configured
Sharing functions that distinguish "share within team" (low friction) from "share outside team" (higher verification)
The system knows who I work with and adapts access accordingly

Design system implication: Share/handoff components with contextual friction levels. Within-team actions are fluid. Cross-team or cross-unit actions introduce proportional verification. The UI makes the boundary visible without making the within-team experience feel restricted.

Job 2.4 — Know I'm not breaking rules without knowing the rules

Functional: Stay within legal boundaries. Emotional: Not worry about consequences of actions taken in good faith. Social: Not be singled out as the one who "violated GDPR."

Pains:

Awareness that access is logged without understanding of what's permitted
Fear of looking up a patient not on one's own list
Ambiguity about what triggers a flag

Gains:

The system guides by making the right action easy and the wrong action harder (but not impossible when there's legitimate need)
Context-aware access: if I search for a patient not on my schedule, the system asks me to state purpose — without it feeling like an accusation
Clear, non-punitive language in access prompts

Design system implication: Purpose-request component for out-of-context access. Tone: helpful, not accusatory ("This patient isn't on your current schedule. What brings you here?" — not "ACCESS DENIED: Unauthorized patient"). Escalation-aware: this is an "important" moment in the escalation framework, not an "urgent" one.

Job 2.5 — Export or print patient data without feeling like I'm doing something wrong

Functional: Bring a printout to a meeting, send a referral. Emotional: It should not feel like I'm committing a violation. Social: Demonstrate professionalism in data handling.

Pains:

Export dialogs that treat every printout as a potential data breach
Warnings that become trivialized through repetition (alert fatigue — same phenomenon as with clinical alerts)
One-size-fits-all confirmation regardless of export sensitivity

Gains:

Differentiated export levels: anonymous summary (no confirmation), individual data (brief confirmation + logging), bulk/registry data (formal confirmation + stated purpose)
Confirmation proportional to risk
The system trusts the professional while maintaining accountability

Design system implication: Tiered export dialog component. Three levels of friction mapped to three levels of data sensitivity. Default: anonymized export with no barrier. Individual: single confirmation with automatic logging. Bulk: confirmation + purpose statement + logging. The escalation framework applies: export of anonymous aggregates is "business as usual"; individual patient export is "important."

Tensions Between Domains

The most productive insight in this analysis is where the two domains pull in opposite directions:

Patient wants to hide; clinician wants to see. The same national ID should be masked in the patient's view and readily accessible in the clinician's. This is not a token question — it is a role-based component question.

Patient wants control; clinician wants flow. Every layer of patient control (consent, opt-out, review rights) adds an administrative step to the clinician's workday. The design challenge: give the patient control without creating friction for the clinician.

Both want to trust the system, for different reasons. The patient wants to trust that data is protected. The clinician wants to trust that the system won't punish them for legitimate work. Same system integrity, experienced from two directions.

Shoulder surfing vs clinical identification. The patient in the waiting room wants their screen to be private. The nurse at the bedside needs the patient's name and date of birth large and clear to avoid mix-ups. Same data, diametrically opposite requirements — resolved through context, not through policy.

Alert fatigue vs genuine vigilance. Privacy confirmations that fire on every action teach the user to click through without reading. Privacy confirmations that fire only when the situation warrants it maintain their meaning. The escalation framework is the tool here: business as usual requires no confirmation; important moments require proportional confirmation; urgent situations are self-identifying.

What This Gives the Design System

This JTBD analysis points toward component patterns rather than tokens. Tokens govern visual register, spacing, colour. Privacy in the interface is about what is shown to whom in which context — that is component logic, role-based views, and interaction patterns.

The design system needs to deliver:

Components:

Masked input field (cleartext during edit, masked after)
Patient identification component (fixed placement, role-dependent detail level)
Tiered export dialog (friction proportional to sensitivity)
Purpose-request dialog (for out-of-context access)
Access log viewer (patient-readable format)
Notification content templates (administrative vs clinical language defaults)
Tap-to-reveal interaction for mobile sensitive data

Patterns:

Self-data pattern: minimize lingering exposure of the individual's own information
Work-data pattern: maximize operational access with invisible logging
Progressive disclosure of identity: default to contextual identifiers, expand to full identity on interaction
Proportional confirmation: friction scales with consequence (mapped to the escalation framework)
Visual separation of identity region and clinical content region in mixed-data views

Principles:

The system does the privacy work, not the user (aligns with PbD principle 2: privacy as default)
Clinical safety overrides data minimization when patient identification is a safety requirement
Confirmation dialogs that fire on every action teach users to ignore them — reserve for genuinely consequential moments
The same data can require opposite treatment depending on who is viewing it and why

Design Decision Record

Decision: Privacy is implemented as role-based component behaviour, not as a design token dimension. Why: Privacy requirements differ by viewer role, not by visual register. The same data field needs opposite treatment for patients (mask by default) and clinicians (show for safety). Tokens govern how things look; components govern what is shown. Privacy lives in the component layer.

Decision: Two distinct component pattern families — self-data and work-data. Why: A patient handling their own national ID and a clinician handling a patient's national ID have different jobs, different emotional contexts, and different safety requirements. One pattern cannot serve both. Attempting to unify them creates either unsafe clinical interfaces (too much hidden) or privacy-violating patient interfaces (too much visible).

Decision: Proportional confirmation — friction scales with consequence. Why: Uniform confirmation dialogs create alert fatigue, which is a documented safety risk in clinical systems. The escalation framework (business as usual → important → urgent) provides the structure: routine actions require no confirmation; consequential actions require proportional confirmation. This preserves both privacy and workflow.

Open Questions

How does "discreet mode" for patient mobile use interact with surface temperature? Is it a third surface mode, or a modifier on the existing two?
Should the patient access log show staff names, or only roles? (Swedish patients can currently see who accessed their records via national portals — but Aleris may have latitude in how granular its own interface is.)
How do we handle the case where a patient is also a staff member at Aleris? Their self-data and work-data patterns collide in the same system.
What is the right default for notification content — fully generalized ("message from Aleris") or category-indicated ("appointment reminder from Aleris")? Where is the line between useful and exposing?

Evidence Base

This analysis draws on:

Systematic review of patient perspectives on mHealth data privacy (JMIR 2024, Alhammad et al.)
AMA patient survey on health data privacy concerns (2022)
Scoping review of barriers to sharing patient-generated health data (Frontiers in Public Health, 2021)
Qualitative study of privacy concerns with mHealth apps and smart speakers (PMC, 2022)
Systematic review of health data sharing attitudes (eClinicalMedicine/Lancet, 2024)
EHR usability and safety multi-center study (PMC, 2020)
AMA analysis of 7 EHR usability and safety challenges (2023)
Scoping review of EHR usability impact on documentation burden (PMC, 2025)
Guidehouse analysis of role-based access control challenges in EHRs (2022)
Aleris Privacy by Design — Principle Inventory (internal, 2026)
Aleris Privacy by Design — Development Principles (internal, 2026)