Gesundheitswesen
Web-App
Designsystem

Patient Management System · Case Study

Eine Arbeitsliste für die Klinik, die zeigt, was jetzt zu tun ist.

Ein System für das Personal einer stark ausgelasteten Diagnoseklinik. Unser Team hat die erste Version 2020 gestaltet; 2026 habe ich sie auditiert und neu gestaltet: eine klare Sprache für Priorität und Status, Aufgabenlisten, die zeigen, was jetzt zu tun ist, und Ansichten je nach Rolle. Umgesetzt als funktionierender Prototyp auf einem dokumentierten Designsystem.

Rolle: Product Designer
Zeitraum: 2020 · überarbeitet 2026
Unternehmen: New Malden Diagnostic Centre
Standort: London, Großbritannien
Team: 2 Designer, 1 PM, 1 Frontend- und 1 Backend-Entwickler

Ergebnisse

UX-Audit
User Flows
Prototyp
Designsystem

Live-Demo Designsystem

Das Problem: In unserer Version von 2020 konnte das Personal einer ausgelasteten Diagnostikklinik nicht erkennen, was jetzt zu tun ist. Die Priorität war unsichtbar, der Status wurde nur über Farbe vermittelt, und zwei zentrale Abläufe gab es gar nicht.
Was ich gemacht habe: Ich habe unsere eigene erste Version auditiert, den Behandlungspfad, die Aufgabenstatus und die Rollen definiert, die wichtigsten Abläufe neu gestaltet und einen funktionierenden Prototyp auf einem dokumentierten Designsystem gebaut.
Das Ergebnis: Ein klickbares Produkt, das den Weg von der Überweisung bis zur Abrechnung für drei Rollen abdeckt, in Hell und Dunkel, mit jeder Komponente dokumentiert in Storybook.

Das Dashboard im hellen Theme — Dashboard, hell

Rollen, jede mit eigener Ansicht: 3
Aufgabenstatus mit erlaubten Übergängen: 6
dokumentierte Storybook-Stories: 60+
Textkontrast in beiden Themes: AA

Projektübersicht

Wir haben es 2020 ausgeliefert. Sechs Jahre später sah ich, wo es scheiterte.

Das New Malden Diagnostic Centre ist eine private ambulante Klinik für Diagnostik im Süden Londons: Bildgebung, Facharztsprechstunden und eine Kinderabteilung, sechs Tage die Woche.

Das Personalsystem der Klinik erfasst Patienten, plant Sprechstunden, verfolgt Befunde und meldet Aktivitäten für die Abrechnung. Angebunden sind Myorb für die Radiologie, ein Labor vor Ort und Healthcode für die Versicherer.

2026 habe ich unsere eigene erste Version auditiert und die wichtigsten Teile neu gestaltet.

Ziele

Produktziele aus dem Briefing

01Patienten erfassen und bestehende Akten finden, mit einer neuen Behandlungsepisode statt eines Duplikats
02Termine in Sprechstunden einplanen
03Patienten bei Ankunft einchecken, damit Ärzte sehen, wer da ist
04Aufgaben in Arbeitslisten verwalten, jeweils mit Priorität und vollständigem Protokoll, wer wann was getan hat
05Aktivitäten nach Zeitraum und Kostenträger für die Abrechnung auswerten

Designziele

01Das Personal sieht in Sekunden, was jetzt zu tun ist, ohne eine Tabelle durchsuchen zu müssen
02Priorität und Status lassen sich nie falsch lesen, auch nicht mit einer Farbsehschwäche
03Jede Rolle sieht genau das, worauf sie reagieren darf
04Fehler werden verhindert, statt sie nachträglich zu beheben

Für wen es ist

Hier hat niemand seine Ruhe am System.

Telefone klingeln, Patienten kommen herein, ein Consultant wartet. Die Personas stammen ausschließlich aus den Rollen im Briefing, es gibt keine erfundenen Figuren.

Admin / Empfang
Hält den Tag am Laufen
Patienten erfassen, Sprechstunden ausgebucht halten, Patienten einchecken, Arbeitslisten sauber halten.
Empfang und Backoffice, ständige Unterbrechungen. Manche haben zusätzlich die Finance-Berechtigung.
Consultant
Sieht nur die eigenen Patienten
Die Sprechstunde effizient führen, mitten in der Konsultation eine Untersuchung in einem Schritt anfordern, Befunde mit wenig Verwaltungsaufwand zurückbekommen.
Sprechzimmer oder Untersuchungsraum, Patient anwesend, knappes Zeitfenster.
Consultant Secretary
Arbeitet für einen Consultant
Die Patienten ihres Consultants schnell buchen und verwalten, die Liste sauber halten.
Büro, Arbeit für einen namentlich bekannten Consultant. Sieht keine fremden Aufgaben.

Meine Rolle

01Das Briefing in ein Domänenmodell und den Lebenszyklus einer Buchungsaufgabe übersetzt
02Die bestehenden Screens anhand von Usability-Heuristiken und WCAG auditiert
03Informationsarchitektur und Abläufe für jede Rolle definiert
04Die visuelle Sprache und jeden Screen gestaltet, in Hell und Dunkel
05Das Designsystem aufgebaut: Tokens, Komponenten, Dokumentation in Storybook
06Den klickbaren Prototyp in Code gebaut, damit sich die Abläufe ausprobieren und nicht nur ansehen lassen

Research

Bevor ich irgendetwas neu zeichnete, habe ich geprüft, was wir ausgeliefert hatten.

Quellen: das Angebot des Kunden, das Pfaddiagramm, Überweisungsformulare auf Papier und unsere Screens von 2020, elf für Admins und sechs für Ärzte.

Fünf Screens wurden anhand von Nielsens Heuristiken und WCAG 2.1 AA geprüft, jeder Befund nach Schweregrad bewertet.

01Priorität war unsichtbar
Das Briefing macht Routine, Dringend und Red Flag zum Kern, doch die Buchungsliste hatte keine Prioritätsspalte. Das Personal konnte nicht triagieren.
02Kein Patientenname in den Befunden
Die Befundliste für Admins hatte zwölf Spalten, aber keine verriet, wessen Befund man gerade verfolgt.
03Check-in war versteckt
Einen Patienten als angekommen zu markieren ist eine zentrale tägliche Aufgabe am Empfang, steckte aber nur in einem Zeilenmenü in der Ansicht der Ärzte.
04Kein Online-Überweisungsformular
Die tägliche Aufnahme hing weiterhin am Papier.

Außerdem gefunden

•Status nur über Farbe dargestellt; zwei Zustände wirkten wie fast identisches Grün
•Keine Ansicht „Was braucht mich jetzt“: flache Listen, keine Standardsortierung oder Gruppierung
•Rollenblind: dieselbe Oberfläche für jede Rolle
•Überall Platzhalterinhalte, die echte Randfälle verdeckten

Define

Ich habe den Behandlungspfad der Klinik in einen Ablauf übersetzt, dem das Produkt folgen kann.

Nach dem Check-in verzweigt er sich: Eine Untersuchung wird vom Arzt bestätigt und für die Abrechnung erfasst, eine Konsultation führt direkt zu einer einzigen Frage, nämlich ob eine weitere Untersuchung nötig ist. Bei Ja geht es mit einer neuen Aufgabe in derselben Episode zurück. Die blauen Schritte hat das Audit ergänzt: eine Duplikatprüfung und der Check-in.

Zwei Frames vom Miro-Board, nachgezeichnet nach den Diagrammen des Kunden. Patient Pathway: Überweisung eingegangen, Prüfung auf bestehende Akte, Patientenakte anlegen, Behandlungsepisode, Aufgabe anlegen, Termin einplanen, Patient kommt an, dann die Entscheidung Diagnostiktermin: Eine Untersuchung wird durchgeführt und vom Arzt bestätigt, was für die Abrechnung erfasst wird, oder der Patient sieht einen Consultant; eine Entscheidung über eine weitere Untersuchung führt zurück zu Aufgabe anlegen. Radiology Flow: Swimlanes für Patient Management und Myorb, von der Buchungsaufgabe bis zum Eingang des Befundlinks. — Aus den Diagrammen des Kunden: der Patientenpfad mit der Verzweigung zwischen Diagnostik und Konsultation und der Schleife zurück für eine weitere Untersuchung sowie die Radiologie zwischen unserem System und Myorb.

Flussdiagramm des Patientenpfads. Überweisung eingegangen; hat der Patient keine Akte, wird er mit Duplikatprüfung erfasst, sonst wird die Akte geöffnet; Behandlungsepisode und Buchungsaufgabe anlegen; Termin einplanen; Patient kommt an und wird eingecheckt. Bei einem Diagnostiktermin wird die Untersuchung durchgeführt, vom Arzt bestätigt und für die Abrechnung im Aktivitätsbericht erfasst; andernfalls sieht der Patient einen Consultant. Beide Wege führen zu einer Entscheidung: Ist eine weitere Untersuchung oder ein weiterer Termin nötig, wird in derselben Episode eine neue Buchungsaufgabe angelegt; wenn nicht, endet der Pfad. — Wo das Briefing nur Text enthielt, habe ich den Ablauf selbst gezeichnet: Anbindung des Pathologielabors (nach dem Muster von Myorb), Abrechnung und Aktivitätsbericht, Lebenszyklus der Buchungsaufgabe, Berechtigungen nach Rolle und die Erfassung eines Überweisungsformulars.

Ein Statusmodell hat die meisten Diskussionen beendet, bevor sie begannen.

Jeder Zustand und jeder erlaubte Übergang ist festgehalten, sodass eine Schaltfläche nie etwas anbietet, was der Prozess nicht zulässt.

•Die Priorität (Routine, Dringend, Red Flag) ist vom Status getrennt und erscheint in jeder Liste als Spalte, Sortierung und Filter
•Eine Aufgabe zu deaktivieren erfordert immer eine Begründung; bei „nicht mehr erforderlich“ muss sie schriftlich erfolgen
•Jeder Status und jede Priorität besteht aus Icon, Label und Farbe, nie nur aus Farbe
•Status werden nach Bedeutung gruppiert: Handlungsbedarf, wartend, erledigt, geschlossen. Das löste die beiden ähnlichen Grüntöne aus dem Audit

Jede Rolle sieht nur das, worauf sie reagieren kann.

Eine Navigation, nach Rolle gefiltert: Eine Secretary sieht die Liste ihres Consultants, ein Consultant sieht seine eigenen Patienten.

Bereich	Admin / Empfang	Consultant	Secretary
Dashboard	Triage über alle Listen	Meine Patienten, Ankünfte, erwartete Befunde	Liste und Sprechstunden meines Consultants
Buchungsaufgaben	Alle	Anforderung aus der Sprechstunde	Auf den eigenen Consultant beschränkt
Befunde	Alle	Nur meine Patienten	Beschränkt
Abrechnung und Berichte	Nur mit Finance-Berechtigung	Nein	Nein

Design

Richtung

Ruhig, präzise, unaufgeregt

Das Briefing war ein gut geführter Empfang, kein kaltes Krankenhausportal und keine Consumer-Gesundheits-App. Farbe ist der Bedeutung vorbehalten, sodass der Status das Einzige ist, was laut wird. Eine Regel, an die ich mich hielt: Rot ist Systemfehlern vorbehalten, damit ein klinischer Red Flag nie mit einem Validierungsfehler verwechselt wird.

•Eine erste Richtung mit tiefblauer Seitenleiste wurde im Review als zu schwer verworfen
•Der endgültige Look: eine helle Fläche, ein weißes Arbeitspanel, Tabellen mit Rahmen, Avatare mit Initialen und weiche, getönte Status-Pills mit Icons
•DM Sans, eine Schriftskala von 12 bis 28 px, ein Blau für Aktionen

Prototyp

Ein Produkt, das man benutzen kann

Ich habe das Redesign als klickbaren Prototyp mit Beispieldaten und einem Rollenwechsler statt eines Logins gebaut. Das war ein bewusster Schnitt: Ein Reviewer beurteilt Screens und Abläufe, also floss der Aufwand in die Oberfläche und nicht in eine Datenbank. Zustandsänderungen sind innerhalb einer Sitzung echt: Eine Episode anzulegen erzeugt eine Aufgabe, das Einplanen setzt sie auf Scheduled, die Abrechnung markiert die Episode als bezahlt oder in Rechnung gestellt.

Designsystem

Von Screens zu einem System

Sobald die Screens standen, habe ich sie zu einem System gemacht, damit der nächste Screen schneller und einheitlich entsteht. Drei Token-Ebenen, helle und dunkle Themes aus denselben Tokens und jede Komponente dokumentiert mit Varianten, Zuständen, Do und Don't sowie Hinweisen zur Barrierefreiheit.

Audit-Befunde und das Redesign

Was unsere erste Version falsch machte und was an ihre Stelle trat.

Befund 01

Priorität unsichtbar, Status nur über Farbe, kein „Was braucht mich jetzt“

Ein Prioritäts-Tag und ein Status mit Icon und Label an jeder Aufgabe, Filter nach Priorität und ein Dashboard, das zuerst auflistet, was Aufmerksamkeit braucht.

Unsere Aufgabenliste von 2020, mit markierter Statusspalte und Kopfzeile — Aufgabenliste in Version 1. 1: Status nur über Farbe. 2: keine Prioritätsspalte.

Die neu gestaltete Aufgabenliste mit Prioritäts- und Status-Pills, Suche und Filtern — Aufgabenliste: Priorität, Status mit Icon und Label, Filter

Die neu gestaltete Aufgabenliste, gefiltert auf Red-Flag-Aufgaben — Auf Red Flag gefiltert: ein Klick zum Dringendsten

Befund 02

Erfassung ohne Duplikatprüfung und ein deaktivierter Absenden-Button, der nichts erklärt

Ein Formular, das vor einem möglichen Duplikat warnt und der Klinik trotzdem die Erfassung erlaubt, mit einer Meldung unter jedem fehlerhaften Feld und einem Absenden-Button, der immer funktioniert.

Unsere Patientenerfassung von 2020, mit den eingeklappten Schritten zwei bis fünf und dem ausgegrauten Absenden-Button markiert — Erfassung in Version 1. 1: vier weitere Schritte weiter unten, ohne Gefühl für den Fortschritt. 2: Absenden ausgegraut, ohne Grund.

Der Dialog „Patient erfassen“ mit Fehlern unter drei leeren Pflichtfeldern — Fehler unter den Feldern, die korrigiert werden müssen

Der Dialog „Patient erfassen“ mit einer Warnung vor einem möglichen Duplikat — Ein mögliches Duplikat wird markiert, nicht blockiert

Befund 03

Zwei sich überschneidende Kalender und kein klarer Weg zum Buchen

Die Terminplanung findet in der Aufgabe statt, mit Datum, Uhrzeit und Ort, und die Aufgabe wechselt von selbst auf Scheduled. Eine Terminseite listet alles Gebuchte auf.

Zwei unserer Screens von 2020 nebeneinander: der Kalender der Clinic Page und die Tagesansicht der Appointments, beides ein Raster aus Räumen und Stunden — Version 1. 1: der Kalender der Clinic Page. 2: der Kalender der Appointments. Dasselbe Raster aus Räumen und Stunden, an zwei Orten.

Der Aufgabendialog mit einem gebuchten Termin und den erlaubten nächsten Aktionen — Terminplanung innerhalb der Aufgabe

Die Tabelle der Termine — Alle Termine an einem Ort

Befund 04

Befundliste für Admins mit zwölf Spalten und ohne Patientennamen

Befunde stehen in der Aufgabe neben dem Termin und dem Überweisungsformular, immer unter dem Namen des Patienten, mit einem klaren nächsten Schritt.

Unsere Befundliste von 2020, mit markierter Kopfzeile und Statusspalte — Befundliste in Version 1. 1: zwölf Spalten, keine davon der Patientenname. 2: Status nur über Farbe.

Der Aufgabendialog mit einem eingegangenen Befund und der Aktion „An Überweiser senden“ — Befund, Überweisung und Termin zusammen

Befund 05

Überweisungsformular nie gestaltet; Aufnahme weiterhin auf Papier

Ein Überweisungsformular je Kategorie, aus der Aufgabe heraus hinzugefügt und mit ihr verknüpft, mit strukturierten Feldern statt gescanntem Freitext.

Version 1: Diesen Screen gab es nie; die Aufnahme lief auf Papier.

Der Aufgabendialog mit einem Überweisungsformular, das gerade ausgefüllt wird — Strukturiertes Überweisungsformular, mit der Aufgabe verknüpft

Designentscheidungen

Status ist Farbe, Icon und Label
Lesbar für Menschen mit Farbsehschwäche und in Graustufen.
Eine primäre Aktion pro Screen oder Dialog
Das Personal triagiert, es stöbert nicht.
Hover nur bei klickbaren Elementen
Hover bedeutet immer „Das kannst du anklicken“.
Absenden wird nie deaktiviert, um einen Grund zu verbergen
Ein ausgegrauter Button erklärt nichts; zeige, was zu korrigieren ist.
Bedienelemente, die eine Rolle nicht nutzen kann, fehlen
Niemand stößt nach einem Klick auf einen Fehler.

Zentrale Abläufe

In Code gebaut, damit man sich durchklicken kann, statt nur zuzusehen.

Dashboard: was Aufmerksamkeit braucht

Die primäre Kachel zählt aktive Aufgaben. Eine Liste darunter stellt Red-Flag- und dringende Aufgaben nach oben.

Das Dashboard im dunklen Theme — Dashboard, dunkel

Patienten und Episoden

Patienten suchen, eine Akte öffnen und jede Überweisung als Episode mit ihren Aufgaben und der Abrechnung sehen.

Eine Patientenakte mit Episoden und Aufgaben — Ein Patient, nach Episoden gruppiert

Lebenszyklus einer Aufgabe

Das Personal bewegt eine Aufgabe nur entlang erlaubter Übergänge. Jeder Schritt wird mit Person und Zeitpunkt protokolliert.

Eine ausstehende Aufgabe im Aufgabendialog — Eine Red-Flag-Aufgabe, ausstehend

Das Terminformular mit einer Fehlermeldung für ein fehlendes Datum — Das Terminformular erklärt, was fehlt

Diagnostik oder Konsultation

Jede Aufgabe trägt ihre Terminart. Nach einer Untersuchung bestätigt der Arzt, dass sie durchgeführt wurde, und auf diese Bestätigung wartet die Abrechnung. Nach einer Konsultation beantwortet der Consultant eine Frage: Ist eine weitere Untersuchung nötig? Bei Ja entsteht in einem Schritt eine neue Aufgabe in derselben Episode.

Eine Diagnostikaufgabe nach dem Termin, mit der Bestätigung der Untersuchung durch den Arzt, für die Abrechnung erfasst — Diagnostik: Untersuchung bestätigt, für die Abrechnung erfasst

Eine Konsultationsaufgabe nach dem Termin, mit der Frage, ob eine weitere Untersuchung oder ein weiterer Termin nötig ist — Konsultation: eine Frage nach dem Besuch

Die abgeschlossene Konsultationsaufgabe, mit dem Hinweis, dass eine Radiologieuntersuchung nun eine ausstehende Aufgabe in derselben Episode ist — Eine weitere Untersuchung wird zu einer neuen Aufgabe in derselben Episode

Drei Rollen, drei Ansichten

Ein Rollenwechsler schlüpft in jede Rolle. Ein Consultant sieht nur seine eigenen Aufgaben und keine Abrechnung.

Das Menü des Rollenwechslers mit dem Demo-Personal — Rollenwechsler

Die Aufgabenliste als Consultant, mit nur den zwei Aufgaben dieses Consultants — Ansicht des Consultants

Abrechnung, nur für Admins

Selbstzahler werden als bezahlt markiert, Versicherer als in Rechnung gestellt, und der Bericht summiert beides.

Der Abrechnungsbericht für Admins — Abrechnungsbericht

Dunkles Theme

Gemeinsam mit dem hellen Theme aus denselben Tokens gestaltet und auf Kontrast geprüft.

Die Aufgabenliste im dunklen Theme — Aufgabenliste, dunkel

Der Aufgabendialog im dunklen Theme — Aufgabendialog, dunkel

Designsystem

Ich habe den nächsten Screen günstiger gemacht.

Drei Token-Ebenen: rohe Palette, nach Zweck benannte semantische Tokens, Komponenten-Tokens. Jedes semantische Token hat einen hellen und einen dunklen Wert, und eine Prüfung schlägt bei jeder rohen Farbe fehl.

•Jede Komponente dokumentiert, mit Live-Beispielen, allen Varianten und Zuständen
•Wann man sie einsetzt, mit Do und Don't und echten Beispielen
•Verwendete Tokens und Hinweise zur Barrierefreiheit
•Eine Matrix, die jede interaktive Komponente in jedem Zustand zeigt

Die Einführungsseite des Designsystems in Storybook — Einführung: Ebenen, Prinzipien, wie man beiträgt

Die Seite der semantischen Farb-Tokens in Storybook — Semantische Tokens, je Theme aufgelöst

Die Matrix der Interaktionszustände in Storybook — Jede Komponente in jedem Zustand

Designsystem öffnen

Ergebnis

Was heute existiert.

Screens und 4 Dialoge, die den Pfad von der Überweisung bis zur Abrechnung abdecken

Rollen mit unterschiedlichen Ansichten und Berechtigungen

Aufgabenstatus mit einem expliziten Satz erlaubter Übergänge

60+

Storybook-Stories, mit Dokumentation für jede Komponente

Token-Ebenen, rund 100 Farb-Tokens, helle und dunkle Themes

Textkontrast auf jedem Screen und Dialog in beiden Themes; Feldrahmen liegen noch unter 3:1

Zentrale Erkenntnisse

Drei Dinge, die mir dieses Projekt beigebracht hat.

01
Behandlung ist ein Kreislauf, keine Linie
Eine Konsultation endet oft in einer weiteren Untersuchung. Das System muss in einem Schritt die nächste Aufgabe in derselben Episode anlegen, statt wieder von vorn zu beginnen.
02
Abrechnung folgt dem Nachweis
Die Klinik rechnet durchgeführte Untersuchungen ab, nicht gebuchte. Eine einzige Bestätigung durch den Arzt wurde zum Bindeglied zwischen Klinikalltag und Finanzen.
03
Prüfe zuerst die eigene Arbeit
Sechs Jahre später waren die Probleme unserer ersten Version offensichtlich. Meine eigenen Screens zu auditieren war schwerer, als die eines anderen zu kritisieren, und es entschied, was ich zuerst neu gestalte.

Probieren Sie es selbst aus

Wechseln Sie in der Demo zwischen den Rollen oder lesen Sie das Designsystem.

Live-Demo Designsystem

← Zurück zu den Case Studies