Thema 3.2 — Designsysteme und Prototyping

Ein Designsystem macht gute Designentscheidungen zu gemeinsamer, wiederverwendbarer Infrastruktur – damit Barrierefreiheit, klinische Sicherheit und Konsistenz einmal eingebaut und überall geerbt werden, statt auf jedem Bildschirm neu verhandelt und neu gebrochen zu werden.

Warum das in Gesundheit und Pflege wichtig ist#

In Gesundheit und Pflege sind die Oberflächen oft die letzten Zentimeter zwischen einer klinischen Entscheidung und einer Patientin. Ein verwirrendes Medikationsfeld, ein nicht barrierefreier Datumswähler, eine Schaltfläche, die in einem Service „Termin absagen“ und in einem anderen „abbrechen und Ihre Daten verlieren“ bedeutet – das sind keine kosmetischen Probleme. Es sind Patientensicherheitsprobleme, Gerechtigkeitsprobleme und Vertrauensprobleme. Wenn jedes Team seine eigenen Komponenten von Grund auf entwirft, vervielfachen sich Mängel, und Sicherheitsgarantien lassen sich über ein Portfolio hinweg nicht mehr nachvollziehen.

Ein Designsystem ist die Art, nicht wiederholt für dieselben Fehler zu zahlen. Wenn eine barrierefreie, gut getestete Komponente einmal gebaut und über Dutzende Services wiederverwendet wird, beheben Sie einen Barrierefreiheitsmangel oder eine Sicherheitsmehrdeutigkeit an einer Stelle, und jeder Service erbt die Korrektur. Die Alternative – überall maßgeschneiderte Front-Ends – bedeutet unbekannte, ungleiche Qualität: Manche Services erfüllen die Web Content Accessibility Guidelines (WCAG), und manche schließen still genau die Menschen aus, die am meisten auf öffentliche Gesundheitsservices angewiesen sind.

Konsistenz ist auch eine Verständlichkeitsfrage. Patientinnen, Patienten und Personal wechseln zwischen Services – einer App des National Health Service (NHS), dem Ambulanzportal eines Trusts, einem Buchungswerkzeug einer Hausarztpraxis –, und jedes ungewohnte Muster erzeugt kognitive Last. In einer Bevölkerung, die kranke, ängstliche, ältere, digital ausgeschlossene oder assistive Technologie nutzende Menschen einschließt, ist diese Last nicht gleich verteilt. Gemeinsame Muster senken sie für alle. Dieses Thema handelt von der Maschinerie – Komponenten, Muster, Tokens, Prototypen und Design Operations –, die sicheres, barrierefreies, konsistentes Design zum Weg des geringsten Widerstands statt zu einem Akt der Heldenhaftigkeit macht.

Kernkonzepte#

Ein Designsystem ist eine einzige Wahrheitsquelle für die wiederverwendbaren Komponenten, Muster, Stile und Anleitungen, die zum Bau einer Reihe digitaler Services genutzt werden. Es ist mehr als ein Styleguide: Es paart funktionierende, kodierte Komponenten mit der Designbegründung, Barrierefreiheitshinweisen und Nutzungsanleitung, die Ihnen sagen, wann und wie jede zu verwenden ist. Die zwei relevantesten öffentlichen Beispiele sind das NHS-Designsystem (gepflegt von NHS England, auf dem NHS.UK-Front-End gebaut) und das GOV.UK Design System, gepflegt vom Government Digital Service (GDS). Beide sind offen, frei verfügbar und über Millionen Interaktionen erprobt.

Eine Komponentenbibliothek hält die einzelnen Bausteine – Schaltflächen, Formulareingaben, Kopfbereiche, Fehlerzusammenfassungen –, während eine Musterbibliothek die übergeordneten Lösungen für wiederkehrende Probleme hält: wie man ein Geburtsdatum abfragt, wie man eine Seite mit Fragen strukturiert, wie man einen Fehler meldet, wie man Nutzende nach ihrer NHS-Nummer fragt. Komponenten sind das Vokabular; Muster sind die Sätze. Beide stützen sich auf komponentenbasiertes Software-Engineering, bei dem Systeme aus lose gekoppelten, unabhängig testbaren, wiederverwendbaren Teilen zusammengesetzt werden.

Design Tokens sind die kleinsten gemeinsamen Entscheidungen, als benannte Variablen ausgedrückt – eine Farbe, eine Abstandseinheit, eine Schriftgröße, eine Fokus-Umrandung. Weil Tokens namentlich referenziert statt fest kodiert werden, verbreitet sich eine Änderung an einem Token (etwa die Erhöhung der Mindestgröße von Touch-Zielen oder des Kontrasts) einheitlich auf jede Komponente, die es nutzt. Tokens sind der Mechanismus, der ein System beim Skalieren kohärent hält und es möglich macht, ein gemeinsames System für lokale Nutzung zu themen, ohne es zu forken.

Eine einzige Wahrheitsquelle (Single Source of Truth) ist die leitende Idee: Jede Designentscheidung wird an genau einem Ort geführt und kann daher über Services hinweg nicht aus dem Takt geraten. Wenn Design, Code und Anleitung einer Komponente alle in einer maßgeblichen Bibliothek leben, beseitigen Sie die Fehlerklasse, bei der Bild und Produkt einander widersprechen.

Software-Prototyping ist die Praxis, bewusst unvollständige Versionen eines Services zu bauen, um etwas zu lernen, bevor Sie sich auf den Bau des echten festlegen. Prototypen reichen von niedriger Detailtreue (Papierskizzen, Graustufen-Wireframes) bis hoher Detailtreue (interaktiv, realistisch, oft in Code gebaut). Das GDS-Prinzip lautet prototypen, um zu lernen, nicht um zu behalten: Die Aufgabe eines Prototyps ist, durch Usability-Tests mit echten Nutzenden eine Frage zu beantworten, wonach er weggeworfen wird – das ist Wegwerf- (oder „Rapid“-)Prototyping, unterschieden von einem evolutionären Prototyp, den man zur Produktion härten will.

DesignOps (Design Operations) ist die Disziplin, Design im großen Maßstab zu betreiben – die Menschen, Arbeitsabläufe, Governance, das Beitragsmodell und die Werkzeuge, die ein gemeinsames Designsystem in einer Organisation oder einem Integrated Care System (ICS) gesund, finanziert und vertrauenswürdig halten. Es verhält sich zu Design wie Plattform-Engineering zu Code: meist unsichtbar, wenn es funktioniert, schmerzhaft offensichtlich, wenn nicht. Prototyping geschieht in Designwerkzeugen wie Figma oder direkt in Code mit dem Front-End eines Designsystems, was uns zur Front-End-Webentwicklung führt – der HTML-, CSS- und JavaScript-Schicht, in der Wiederverwendung Duplizierung, Kosten und Risiko tatsächlich verringert.

Dieses Thema deckt bewusst nicht erneut ab, was Nutzende brauchen (siehe Thema 3.0 — Nutzerforschung und Servicedesign) oder wie Worte geschrieben werden (siehe Thema 3.1 — Content-Design und Gesundheitskompetenz). Diese Disziplinen speisen das Designsystem; dieses Thema handelt von der wiederverwendbaren Maschinerie, die ihre Schlussfolgerungen sicher in die Produktion trägt.

Bewährte Praktiken#

1. Übernehmen Sie, bevor Sie bauen. Beginnen Sie beim NHS-Designsystem und dem GOV.UK Design System, statt ein eigenes zu erfinden. Sie kodieren bereits Jahre an Barrierefreiheitstests, Content-Design und realer Nutzung über Gesundheits- und Regierungsservices. Einen Datumswähler oder eine Fehlerzusammenfassung neu zu erfinden ist keine gute Verwendung knapper, teurer Design- und Entwicklungskapazität, und eine hausgemachte Version wird fast immer weniger barrierefrei sein. Erweitern und themen Sie diese Systeme für lokale Bedürfnisse; forken Sie sie nicht ohne bewussten, dokumentierten Grund.

2. Bauen Sie Barrierefreiheit und klinische Sicherheit in die gemeinsamen Komponenten ein, nicht in die einzelnen Bildschirme. Der gesamte wirtschaftliche und Sicherheitsfall eines Designsystems ist, dass Sie etwas einmal beheben und überall erben. Eine barrierefreie, tastaturbedienbare, mit Screenreadern getestete Geburtsdatum-Komponente, einmal gebaut und abgesichert, schützt jeden Service, der sie nutzt. Bauen Sie WCAG-Konformität, sinnvolle Fehlerbehandlung und sicherheitsrelevantes Verhalten (klare Bestätigung destruktiver Aktionen, eindeutige Einheiten für Dosen und Messwerte) in die Komponente selbst ein, damit Teams sie nicht leicht falsch machen können (siehe Thema 1.9 — Digitale Inklusion und Barrierefreiheit und Thema 1.6 — Klinische Sicherheit und Risikomanagement).

3. Prototypen Sie, um zu lernen, nicht um zu behalten. Behandeln Sie Prototypen als Wegwerf-Experimente, die eine bestimmte Frage – „kann eine Patientin mit geringer Gesundheitskompetenz diese Überweisung abschließen?“ – billig und schnell beantworten. Stimmen Sie die Detailtreue auf die Frage ab: Nutzen Sie Skizzen niedriger Detailtreue, um Ablauf und Verständnis früh zu testen, und kodierte Prototypen hoher Detailtreue, um später realistische Interaktion, Barrierefreiheit und Randfälle zu testen. Widerstehen Sie dem Sog, einen Prototyp direkt in die Produktion zu befördern; Prototypen-Code, optimiert auf Lerngeschwindigkeit, ist selten sicher, geschützt oder wartbar genug für einen klinischen Live-Service.

4. Prototypen Sie im echten Front-End, wenn Interaktion und Barrierefreiheit die Frage sind. Prototypen in Designwerkzeugen (Figma und ähnliche) eignen sich hervorragend, Layout, Ablauf und Inhalt schnell und gemeinsam zu erkunden. Sie können aber Tastaturnavigation, Screenreader-Verhalten, Fokusverwaltung oder Leistung auf alter NHS-Hardware nicht getreu testen. Wenn das die Risiken sind, prototypen Sie in Code mit dem Front-End des Designsystems, damit Sie etwas testen, das dem nahekommt, was echte Nutzende mit echter assistiver Technologie tatsächlich erleben werden.

5. Testen Sie Prototypen vor dem Bau mit echten Nutzenden. Ein Prototyp, der nie repräsentativen Nutzenden vorgelegt wird, ist nur eine teure Meinung. Testen Sie mit Menschen, die Ihre tatsächliche Population widerspiegeln – einschließlich älterer Menschen, Menschen mit Behinderungen, Menschen mit geringem digitalem Selbstvertrauen und Personal unter Zeitdruck. Selbst fünf Teilnehmende decken die meisten ernsten Usability- und Verständnisprobleme auf, und sie in einem Prototyp zu finden ist um Größenordnungen billiger, als sie in der Produktion zu finden (siehe Thema 3.7 — Testen und Qualitätssicherung).

6. Steuern Sie Tokens als Vertrag für Konsistenz. Drücken Sie Farben, Abstände, Typografie und Interaktionszustände als benannte Design Tokens aus und behandeln Sie Änderungen daran mit dem Ernst einer Änderung an einer gemeinsamen Abhängigkeit. Tokens lassen Sie Mindestkontrast, Touch-Zielgröße und Fokussichtbarkeit systemweit durchsetzen und lassen ein lokales Team für seine Marke neu themen, ohne die zugrunde liegenden Barrierefreiheitsgarantien zu brechen. Wenn sich ein nationaler Standard verschiebt, wollen Sie ein Token ändern, nicht zehntausend Bildschirme prüfen.

7. Betreiben Sie ein Beitragsmodell, keinen ummauerten Garten. Ein Designsystem, das nur Input eines zentralen Teams akzeptiert, wird immer hinter den realen Servicebedürfnissen herhinken und von Lieferteams übelgenommen. Veröffentlichen Sie einen klaren Weg für Teams, neue Komponenten und Muster vorzuschlagen, mit Kriterien dafür, was akzeptiert wird, wer prüft und wie Barrierefreiheit und Sicherheit abgesichert werden, bevor irgendetwas in die gemeinsame Bibliothek befördert wird. Das ist Kernarbeit von DesignOps: Sie gleicht die Spannung zwischen lokaler Flexibilität und gemeinsamer Konsistenz aus, ohne das System verrotten oder zersplittern zu lassen.

8. Versionieren, dokumentieren und kommunizieren Sie Änderungen. Behandeln Sie das Designsystem als Produkt mit Nutzenden (Ihren Lieferteams), einer Roadmap, Release Notes und einem Supportkanal. Semantische Versionierung, Changelogs und klare Hinweise zur Abkündigung lassen Teams Verbesserungen sicher und im eigenen Takt übernehmen. Undokumentierte Breaking Changes zerstören das Vertrauen, das Teams das gemeinsame System dem Eigenbau vorziehen lässt.

9. Messen Sie Annahme und Qualität, nicht nur Existenz. Ein Designsystem liefert nur Wert, wenn es genutzt wird. Verfolgen Sie, welche Services die gemeinsamen Komponenten nutzen, wo Teams maßgeschneiderte Alternativen bauen mussten (und warum) und ob sich die Barrierefreiheitskonformität mit steigender Annahme verbessert. Hohe Raten lokaler Umgehungen sind ein Signal, dass dem System etwas Echtes fehlt – behandeln Sie sie als Backlog, nicht als Ungehorsam.

Fragen zur Diskussion im Team#

1. Wo sollte die Linie zwischen gemeinsamer Konsistenz und lokaler Flexibilität verlaufen, und wer entscheidet? Das ist die zentrale Governance-Spannung jedes Designsystems. Zu starr, und Lieferteams fühlen sich blockiert, bauen Schattenkomponenten und umgehen das System – und zersplittern die Konsistenz, die Sie schützen wollten. Zu locker, und das „System“ wird zu einem lose verwandten Haufen Einzelstücke ohne gemeinsame Sicherheits- oder Barrierefreiheitsgarantien. In Gesundheit und Pflege ist der Einsatz spezifisch: Manche Variation ist legitim (ein psychiatrischer Krisenservice hat wirklich andere Bedürfnisse als ein Routine-Terminbucher), manche Variation ist gefährlich (uneinheitliche Wege, eine destruktive klinische Aktion zu bestätigen). Eine gute Antwort benennt, welche Entscheidungen nicht verhandelbar sind (Barrierefreiheit, sicherheitskritische Muster, zentrale Interaktionsverhalten) und welche für lokales Theming offen sind, und definiert einen expliziten, humanen Prozess, mit dem ein Team eine Ausnahme beantragen oder ein neues Muster beisteuern kann, statt Abweichung einfach zu verbieten.

2. Wie werden Barrierefreiheit und klinische Sicherheit in unseren Komponenten tatsächlich abgesichert – und wer gibt sie frei? Es ist leicht zu behaupten, Barrierefreiheit und Sicherheit seien „eingebaut“; es ist schwer, es zu garantieren. Diese Frage zwingt Sie, die Absicherungspipeline konkret zu machen: Wer testet jede Komponente gegen WCAG, mit welchen assistiven Technologien und mit welchen Nutzenden mit Behinderungen; wie werden sicherheitsrelevante Verhaltensweisen gegen Ihren Prozess der klinischen Sicherheit (DCB0129/DCB0160) geprüft; und welche Nachweise sind an eine Komponente gehängt, bevor sie als „sicher zur Wiederverwendung“ veröffentlicht wird. Die Debatte sollte ehrliche Lücken offenlegen – vielleicht haben Sie automatisierte Kontrastprüfungen, aber nie mit einer echten Screenreader-Nutzerin getestet, oder Ihr Clinical Safety Officer hat die gemeinsame Komponentenbibliothek nie geprüft. Eine starke Antwort ergibt eine benannte Verantwortliche, ein definiertes Testregime und eine Regel, dass keine Komponente ohne dokumentierte Nachweise zu Barrierefreiheit und Sicherheit in die gemeinsame Bibliothek gelangt, denn ein von fünfzig Services geerbter Mangel ist fünfzigfacher Schaden.

3. Wer finanziert, besetzt und pflegt das Designsystem, wenn die anfängliche Begeisterung verfliegt? Designsysteme werden häufig in einem Energieschub geschaffen und dann still aufgegeben, wenn das Gründungsteam weiterzieht, und hinterlassen eine veraltete Bibliothek, der Teams nicht mehr vertrauen. Das ist im Kern eine DesignOps- und Finanzierungsfrage, keine Designfrage. Debattieren Sie ehrlich, ob Sie ein ständiges, finanziertes Team haben, das das System als laufendes Produkt verantwortet – mit Kapazität für Support, Beitragsprüfung, Versionierung und das Schritthalten mit den vorgelagerten NHS- und GOV.UK-Systemen – oder ob Sie sich auf Goodwill verlassen, der verdunsten wird. In einem ICS ist es noch schärfer: Gehört das System einer dominanten Organisation, wird es gemeinsam gesteuert oder ist es zwischen ihnen verwaist? Eine gute Antwort behandelt das Designsystem als langlebige Infrastruktur mit benannter Verantwortlicher, laufendem Budget und einer klaren Beziehung zu den nationalen Systemen, auf denen es aufbaut, statt als Projekt, das „endet“.

4. Wie ist unser Verhältnis zu den vorgelagerten NHS- und GOV.UK-Systemen – und wie bleiben wir im Gleichschritt, wenn sie sich ändern? Ein nationales Designsystem zu übernehmen ist kein einmaliger Download; es ist eine fortlaufende Abhängigkeit von Infrastruktur, die Sie nicht kontrollieren. Diese Frage zwingt Sie zu entscheiden, wo Sie auf dem Spektrum von „leicht themen und vorgelagert eng verfolgen“ bis „forken und abweichen“ stehen. Jede Wahl hat einen Preis: Nah zu bleiben heißt, vorgelagerte Änderungen (eine neue Barrierefreiheitskorrektur, ein überarbeitetes Muster) im Takt eines anderen aufzunehmen und gelegentlich lokale Anpassungen umzuarbeiten; zu forken heißt, dass Ihnen jede künftige Barrierefreiheits- und Sicherheitskorrektur gehört, die das nationale Team Ihnen sonst gratis gegeben hätte. In Gesundheit und Pflege ist der Sog zur Abweichung real – klinische Arbeitsabläufe und lokales Branding erzeugen echten Druck –, doch jede Abweichung ist eine stehende Verbindlichkeit. Eine gute Antwort benennt, wer die Release Notes des Vorgelagerten beobachtet, wie lokale Erweiterungen strukturiert sind, damit sie ein vorgelagertes Update überleben, und den expliziten Test, den eine vorgeschlagene Abweichung bestehen muss, bevor sie erlaubt wird, damit „wir brauchten es anders aussehend“ nie still zu „wir pflegen nun einen veralteten, weniger barrierefreien Fork des NHS-Datumswählers“ wird.

5. Wie halten wir tatsächlich die Linie zwischen „prototypen, um zu lernen“ und „bauen, um zu behalten“? Alle stimmen im Prinzip zu, dass Wegwerf-Prototypen nicht zu Produktionsservices werden sollten; das Versagen geschieht unter Termindruck, wenn ein überzeugender Prototyp mit hoher Detailtreue direkt vorliegt und ihn auszuliefern wie eine Abkürzung aussieht. Diese Frage macht die Grenze konkret statt aspirativ. Debattieren Sie, was praktisch verhindert, dass Prototypen-Code – auf Lerngeschwindigkeit optimiert, nicht auf Sicherheit, Resilienz oder Wartbarkeit – in einen klinischen Live-Service befördert wird: eine technische Trennung (Prototypen in einer Sandbox gebaut, die die Produktion nicht erreichen kann), ein Governance-Tor (keine Freigabe der klinischen Sicherheit, kein Go-live) oder bloß eine geteilte gute Absicht, die verdunstet, sobald ein Liefertermin rutscht? Der Einsatz in Gesundheit und Pflege ist spezifisch, denn nicht abgesicherter Code in einem klinischen Pfad ist ein Patientensicherheitsrisiko, nicht nur technische Schuld. Eine ehrliche Antwort räumt ein, woher der Druck kommen wird, benennt, wer befugt ist, Nein zu sagen, und definiert, was „für die Produktion aus abgesicherten Komponenten neu bauen“ tatsächlich erfordert, damit die Grenze hält, wenn sie getestet wird.

6. Woran erkennen wir, ob das Designsystem tatsächlich funktioniert – und was tun wir, wenn die Kennzahlen unbequem sind? Ein Designsystem kann existieren, wunderschön dokumentiert sein und dennoch wenig Wert liefern, wenn Teams es still umgehen. Diese Frage drängt über „wir haben ein Designsystem“ hinaus zu „verdient es sich seinen Unterhalt“. Entscheiden Sie, was Sie messen: Annahme über Services hinweg, Rate und Gründe für maßgeschneiderte Umgehungen, ob sich die Barrierefreiheitskonformität mit steigender Annahme tatsächlich verbessert und wie viel Zeit Teams durch Wiederverwendung statt Neubau sparen. Das Schwere ist nicht, die Zahlen zu erheben, sondern im Voraus zu vereinbaren, wie Sie sie lesen – denn eine hohe Rate lokaler Umgehungen ist ein Signal, dass dem gemeinsamen System etwas Echtes fehlt, kein Beleg dafür, dass Lieferteams ungehorsam sind. Eine gute Antwort verpflichtet sich, unbequeme Annahmedaten als Backlog- und Roadmap-Input zu behandeln, definiert, wer sie wie oft prüft, und widersteht der Versuchung, nur das Schmeichelhafte zu messen (Existenz, Download-Zahlen) statt dessen, was zählt (sicherere, barrierefreiere, konsistentere Services, die tatsächlich ausgeliefert wurden).

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System, das drei Akut-Trusts, einen psychiatrischen Trust und einen Gemeindeanbieter umfasst, beschließt, seine patientenorientierte digitale Landschaft zu konsolidieren. Heute betreibt jede Organisation ihr eigenes Ambulanzportal; zusammen haben sie vier inkompatible Datumswähler, drei verschiedene Arten, nach einer NHS-Nummer zu fragen, und stark schwankende Barrierefreiheitskonformität. Ein interner Audit findet, dass nur eines der vier Portale einen einfachen Screenreader-Test seines Terminbuchungsablaufs besteht – ein klares Gerechtigkeits- und Sicherheitsrisiko.

Das ICS stellt ein kleines, gemeinsam finanziertes Designsystem-Team auf. Statt von Grund auf zu bauen, übernehmen sie das NHS-Designsystem als Fundament und definieren eine dünne lokale Schicht von Design Tokens für ICS-spezifisches Branding, plus eine Handvoll wirklich lokaler Muster (zum Beispiel ein gemeinsames Muster zur Buchung von Dolmetscherunterstützung, das keines der nationalen Systeme abdeckt). Jede gemeinsame Komponente trägt dokumentierte WCAG-Nachweise und eine Freigabe des ICS-Clinical-Safety-Officers nach dem DCB0129-Prozess, bevor sie veröffentlicht wird.

Bevor sie den Ambulanz-Buchungsablauf neu bauen, prototypen sie. Sie beginnen mit niedriger Detailtreue und testen eine Papier-und-Graustufen-Version des neuen Ablaufs mit zwölf Teilnehmenden, die so rekrutiert wurden, dass sie die lokale Population widerspiegeln – darunter zwei Screenreader-Nutzende, drei Menschen über 75 und einige mit geringem digitalem Selbstvertrauen. Der Prototyp legt ein ernstes Verständnisproblem offen: Patientinnen und Patienten können eine „Umbuchen“-Aktion nicht von einer „Absagen“-Aktion unterscheiden. Das Team behebt das Muster, baut dann einen kodierten Prototyp hoher Detailtreue mit dem Front-End des Designsystems und testet erneut, diesmal mit Bestätigung von Tastatur- und Screenreader-Verhalten auf der tatsächlichen Hardware, die in den Ambulanzen eines Partner-Trusts genutzt wird.

Erst dann bauen sie echt und setzen den Produktionsservice weitgehend aus abgesicherten, wiederverwendbaren Komponenten zusammen. Achtzehn Monate später verschärft ein WCAG-Update die Anforderungen an die Fokussichtbarkeit. Weil das Fokus-Styling in einem einzigen Design Token lebt, liefert das Team eine Änderung aus, und jeder ICS-Service erbt sie im nächsten Release – eine Korrektur, die in der alten fragmentierten Landschaft fünf getrennte Sanierungsprojekte bedeutet hätte und realistisch mindestens einen kaputt gelassenen Service.

Sektorperspektiven#

Startup#

Ein kleines Startup der digitalen Gesundheit sollte fast nie ein eigenes Designsystem von null bauen – es kann sich den Aufwand der Barrierefreiheitstests nicht leisten, und Investoren zahlen für klinische Validierung, nicht für maßgeschneiderte Schaltflächen. Übernehmen Sie das Front-End von NHS oder GOV.UK, wo Sie für NHS-Nutzende bauen, und behandeln Sie Prototyping als Ihren zentralen Wettbewerbsvorteil: billige, schnelle Wegwerf-Prototypen, mit echten Patientinnen und Patienten getestet, lassen Sie schneller lernen als besser finanzierte Platzhirsche. Das Risiko ist das umgekehrte – einen schicken Prototyp mit hoher Detailtreue direkt in die Produktion zu befördern, um eine Investorendemo zu treffen, und unabgesicherten, unsicheren Code in einen klinischen Live-Service zu tragen. Halten Sie selbst unter Finanzierungsdruck eine harte Linie zwischen „prototypen, um zu lernen“ und „bauen, um zu behalten“.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim oder eine Einzelstandort-Klinik, die ein patientenorientiertes Werkzeug beauftragt – hat Live-Patientinnen und -Patienten, aber keine eigene Design- oder Front-End-Fähigkeit und kann die Kosten maßgeschneiderter Komponenten nicht auffangen. Sein wirksamster Zug ist, darauf zu bestehen, dass jeder Lieferant auf dem Front-End von NHS oder GOV.UK baut, sodass die Garantien zu Barrierefreiheit und Sicherheit geerbt statt versprochen sind, und dies zur schriftlichen Vertragsbedingung statt zur Hoffnung zu machen. Er braucht selten ein eigenes Designsystem; er muss eines gut konsumieren und erkennen, dass eine schicke Demo eines Lieferanten kein Beleg für einen barrierefreien, abgesicherten Live-Service ist. Wo er prototypt – ein neues Online-Buchungsablauf mit seinen tatsächlichen, oft älteren oder digital weniger selbstsicheren Patientinnen und Patienten testet –, decken einige Sitzungen mit echten Nutzenden weit mehr auf, als ein polierter Entwurf je offenbart. Es gelten dieselben gesetzlichen Pflichten zu Barrierefreiheit und klinischer Sicherheit wie für einen großen Trust; die ehrliche Frage ist also nicht, ob man konform ist, sondern wie man geerbte Konformität billig aus gemeinsamer nationaler Infrastruktur bekommt.

Großunternehmen#

Ein großer NHS Trust oder ein Health-Tech-Unternehmen hat bereits mehrere Teams, die überlappende Oberflächen bauen; sein Problem ist daher Fragmentierung und doppelte Kosten. Der Wertfall ist ein finanziertes, ständiges Designsystem-Team mit einem echten Beitragsmodell, mit an die Führung berichteten Annahmekennzahlen und einer klaren Governance-Linie zu klinischer Sicherheit und Barrierefreiheitsabsicherung. Die zentrale Spannung ist politisch: Mächtige Lieferteams widersetzen sich der Abgabe von Kontrolle, und ein schwerfälliges zentrales Team erzeugt Schattenkomponenten. Großunternehmen haben Erfolg, indem sie das gemeinsame System zur wirklich leichteren Wahl machen – gut dokumentiert, gut unterstützt und nachweislich höherwertig – statt es vorzuschreiben und zu hoffen.

Regierung#

Eine nationale Stelle wie NHS England oder GDS betreibt das Designsystem als öffentliche Infrastruktur, die von Organisationen genutzt wird, die sie nicht kontrolliert; Offenheit, Stabilität und Abwärtskompatibilität zählen daher enorm. Ihre Pflichten sind die stärksten: gesetzliche Barrierefreiheitsverordnungen, Gleichstellungspflichten und die Realität, dass sich ein Mangel in einer gemeinsamen nationalen Komponente zu Millionen Bürgerinnen und Bürgern fortpflanzt. Die Arbeit ist weniger Erfindung als Verwalterschaft – klare Versionierung, Abkündigungspolitik, erschöpfende Barrierefreiheitsnachweise und Reaktionsfähigkeit gegenüber den Hunderten Teams nachgelagert. Das NHS-Designsystem und das GOV.UK Design System sind die Referenzbeispiele gerade, weil sie das System als langlebiges öffentliches Gut behandeln, nicht als Projekt.

Häufige Fehlermuster#

• Das aufgegebene System. Ein Designsystem wird mit Fanfare gebaut und dann ungepflegt gelassen, wenn sich das Gründungsteam zerstreut; Teams verlieren Vertrauen und driften zurück zu maßgeschneiderter Arbeit. Vermeiden Sie es, indem Sie ein ständiges Produktteam statt eines einmaligen Projekts finanzieren.
• Das Bild, das lügt. Designdateien und Produktionscode widersprechen einander, weil es keine einzige Wahrheitsquelle gibt, sodass „das Designsystem“ etwas beschreibt, das das Produkt nicht mehr tut. Halten Sie kodierte Komponenten und ihre Dokumentation maßgeblich und gemeinsam versioniert.
• Barrierefreiheit als Nachgedanke. Komponenten werden ohne echtes Testen mit assistiver Technologie ausgeliefert, sodass ein nicht barrierefreies Muster überall geerbt wird – Schaden wird vervielfacht statt verringert. Verlangen Sie dokumentierte WCAG- und Screenreader-Nachweise, bevor eine Komponente veröffentlicht wird.
• Prototyp-zu-Produktion. Ein Prototyp mit hoher Detailtreue wird direkt in einen Live-Service befördert, um Zeit zu sparen, und trägt unsicheren, nicht wartbaren, nicht abgesicherten Code in ein klinisches Umfeld. Setzen Sie die Wegwerf-Grenze durch; bauen Sie für die Produktion aus abgesicherten Komponenten neu.
• Der ummauerte Garten. Ein zentrales Team lehnt alle Beiträge ab, sodass das System nie reale Servicebedürfnisse trifft und Lieferteams es umgehen. Veröffentlichen Sie einen Beitrags- und Ausnahmeprozess und behandeln Sie lokale Umgehungen als Backlog-Signal.
• Konsistenztheater. Starre Einheitlichkeit wird dort durchgesetzt, wo echte lokale Variation gerechtfertigt ist (Krisenservices, Pädiatrie), und verschlechtert Sicherheit und Nutzbarkeit im Namen der Ordentlichkeit. Unterscheiden Sie nicht verhandelbare Entscheidungen von legitim lokalen.
• Die falsche Detailtreue testen. Interaktions- und Barrierefreiheitsrisiken werden nur in einem statischen Designwerkzeug „getestet“, das Tastatur- oder Screenreader-Verhalten nicht ausüben kann, und geben falsche Zuversicht. Prototypen Sie in Code, wenn Interaktion die Frage ist.

Reifegradmodell#

Checkliste#

• Sie haben das NHS-Designsystem und/oder das GOV.UK Design System als Fundament übernommen, statt von null zu bauen.
• Gemeinsame Komponenten tragen dokumentierte Nachweise zur WCAG-Konformität, getestet mit echter assistiver Technologie und Nutzenden mit Behinderungen.
• Sicherheitsrelevante Komponenten wurden unter Ihrem Prozess der klinischen Sicherheit geprüft, bevor sie zur Wiederverwendung veröffentlicht wurden.
• Design Tokens steuern Farbe, Abstand, Typografie und Interaktionszustände und ermöglichen systemweite Änderungen von einem Ort aus.
• Es gibt eine einzige Wahrheitsquelle, in der kodierte Komponenten und ihre Anleitung leben und gemeinsam versioniert werden.
• Prototypen sind in der Detailtreue auf die Frage abgestimmt, mit einer repräsentativen Nutzerstichprobe getestet und werden als Wegwerfprodukte behandelt.
• Interaktions- und barrierefreiheitskritische Abläufe werden in Code prototypt, nicht nur in einem Designwerkzeug.
• Ein finanziertes, benanntes Team verantwortet das Designsystem als laufendes Produkt, mit Roadmap und Supportkanal.
• Ein veröffentlichter Beitrags- und Ausnahmeprozess lässt Lieferteams neue Komponenten und Muster vorschlagen.
• Annahme und Qualität werden gemessen, und hohe Raten lokaler Umgehungen werden als Backlog behandelt, nicht als Ungehorsam.

Zentrale Quellen#

• NHS-Designsystem — NHS England: Komponenten, Muster, Stile und Barrierefreiheitsanleitung für digitale NHS-Services.
• GOV.UK Design System — Government Digital Service: Stile, Komponenten und Muster für britische Regierungsservices.
• GOV.UK Service Manual — Prototyping und „make a prototype“ — Government Digital Service: Anleitung zum Prototypen, um zu lernen, und zum Testen mit Nutzenden.
• NHS Digital Service Standard — NHS England: der Standard, an dem gemeinsame und konsistente Services bewertet werden.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: der Standard zur Barrierefreiheitskonformität.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — britische Regierung: die gesetzliche Barrierefreiheitspflicht für Services des öffentlichen Sektors.
• DCB0129 / DCB0160 Standards zum klinischen Risikomanagement — NHS England: Standards zur klinischen Sicherheit für Herstellung und Einsatz von Gesundheits-IT-Systemen.
• Design Council Double Diamond — Design Council: das Modell Discover–Define–Develop–Deliver, das Discovery und Design zugrunde liegt.

Referenzen#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards