Thema 3.4 — Discovery-Phasen

In einem Satz: Discovery ist die disziplinierte, zeitlich begrenzte Anstrengung, Ihre Nutzenden und das wirkliche Problem zu verstehen, bevor Sie Geld, klinisches Risiko oder Ansehen auf den Bau einer Lösung setzen.

Warum das in Gesundheit und Pflege wichtig ist#

In den meisten Branchen verschwendet das Bauen des Falschen Geld. In Gesundheit und Pflege kann es auch klinische Zeit verschwenden, gesundheitliche Ungleichheiten verfestigen und – im Extremfall – Patientinnen und Patienten schaden. Ein digitaler Service, der annimmt, dass alle Nutzenden ein Smartphone, zuverlässiges Breitband und selbstsicheres Englisch haben, schließt still die Gebrechlichen, die Armen und die digital Marginalisierten aus: genau die Menschen, denen der NHS und die Sozialfürsorge dienen sollen. In der Discovery finden Sie das zum Preis einiger Wochen Forschung heraus, statt nach einem nationalen Rollout.

Ausgaben für Gesundheit und Pflege sind öffentliches Geld in treuhänderischer Verwahrung, und vieles davon fließt durch gesetzliche Pflichten: die NHS Constitution, die Gleichstellungspflicht des öffentlichen Sektors nach dem Equality Act 2010 und die Caldicott-Prinzipien zum Umgang mit vertraulichen Patienteninformationen. Discovery ist die Phase, in der Sie testen, ob ein vorgeschlagener Service gebraucht, rechtmäßig, sicher und gerecht ist – bevor diese Fragen teuer zu beantworten werden. Sie zu überspringen beseitigt die Fragen nicht; es verschiebt sie nur auf einen Zeitpunkt, an dem die ehrliche Antwort politisch nicht mehr akzeptierbar ist.

Der NHS Digital Service Standard und das GOV.UK Service Manual machen die Discovery aus genau diesem Grund zur verpflichtenden ersten Phase jedes nutzerorientierten digitalen Services. Es ist kein bürokratisches Theater. Es ist die billigste Versicherung, die Sie je kaufen werden.

Kernkonzepte#

Discovery, definiert. Discovery ist eine kurze (typischerweise 6–10 Wochen) Phase, deren Ziel es ist, einen Problemraum zu verstehen: wer die Nutzenden sind, was sie zu tun versuchen, was sie hindert, was bereits existiert und ob es überhaupt ein lohnendes Problem zu lösen gibt. Ihr Ergebnis ist Verständnis und Evidenz, kein Produkt. Eine gute Discovery kann berechtigterweise zu dem Schluss kommen „nichts tun“ oder „das ist ein Politikproblem, kein digitales“.

Der Double Diamond. Der Double Diamond (2005) des Design Council rahmt Design als zwei verbundene Diamanten. Der erste – Discover dann Define – divergiert, um das Problem breit zu erkunden, und konvergiert dann, um es präzise zu fassen. Der zweite – Develop dann Deliver – divergiert, um Lösungen zu erkunden, und konvergiert dann, um eine zu bauen. Discovery als Lieferphase lebt fast vollständig im ersten Diamanten. Das wiederkehrende Versagen ist, dass Teams in den zweiten Diamanten spurten, bevor der erste fertig ist.

Nutzerbedürfnis versus Stakeholder-Wunsch. Ein Nutzerbedürfnis ist etwas, das ein Mensch zu erreichen versucht, aus seiner Sicht ausgedrückt („Ich muss wissen, dass mein Termin bestätigt ist, damit ich mir nicht umsonst einen Tag frei nehme“). Ein Stakeholder-Wunsch ist eine Funktion oder Lösung, auf die sich jemand bereits festgelegt hat („wir brauchen eine App“). Die Kerndisziplin der Discovery ist, Wünsche zurück in Bedürfnisse zu übersetzen, denn Bedürfnisse sind stabil, und Lösungen sind billig und austauschbar, sobald das Bedürfnis klar ist.

Problemrahmung. Wie Sie ein Problem formulieren, begrenzt jede Lösung, die Sie erwägen werden. „Patientinnen und Patienten verpassen Termine“ lädt zu einer Erinnerungs-App ein. „Patientinnen und Patienten können Termine, die nicht mehr passen, nicht leicht verlegen“ lädt zu Self-Service-Umbuchung ein. Dasselbe Symptom, ein anderes Problem, ein radikal anderer Service. Discovery verdient sich ihren Unterhalt weitgehend in der Qualität der Problemstellung, die sie hervorbringt.

Annahmen, Hypothesen und Evidenz. Jedes Vorhaben ruht auf Annahmen. Discovery macht sie explizit, ordnet sie nach Risiko und testet die riskantesten mit echten Nutzenden. Das Ziel ist nicht Gewissheit – die ist unerreichbar –, sondern verringerte Unsicherheit bei den Dingen, die das Vorhaben versenken würden.

Bewährte Praktiken#

1. Beginnen Sie bei einem Problem, nicht bei einer Lösung. Schreiben Sie die Problemstellung, bevor irgendjemand eine Technologie nennt. Wenn der Finanzierungsantrag, das Vorstandspapier oder der Lieferanten-Pitch bereits „eine App“ oder „ein Portal“ festlegt, behandeln Sie das als zu testende Annahme, nicht als umzusetzende Entscheidung. Lösungen, die vor dem Verstehen des Problems entstehen, sind fast immer die Gewohnheit von jemandem, nicht das Bedürfnis der Nutzenden.

2. Führen Sie echte Nutzerforschung mit echten Nutzenden durch. Befragen und beobachten Sie die tatsächlichen Menschen, die den Service nutzen werden – Patientinnen, Patienten, Angehörige, Empfangskräfte, Gemeindepflegekräfte, Sozialarbeitende – in ihrem realen Kontext, nicht in einem Workshop von Führungskräften, die in ihrem Namen sprechen. Zielen Sie auf Tiefe statt Menge; ein Dutzend gut gewählter Kontext-Interviews offenbaren mehr als eine Umfrage mit tausend Antworten. Rekrutieren Sie gezielt für die am schwersten erreichbaren Nutzenden, denn ihnen wird ein Service am häufigsten nicht gerecht.

3. Kartieren Sie den ganzen Service, nicht die digitale Scheibe. Nutzende erleben einen durchgängigen Service – eine Überweisung, eine Beurteilung, eine Behandlung, eine Nachsorge –, dessen digitale Komponente einen Schritt darstellt. Kartieren Sie die aktuelle Reise über jeden Kanal und jede Organisation, einschließlich der Papier-, Telefon- und persönlichen Teile. Digitale Änderungen scheitern routinemäßig, weil sie einen Schritt optimieren und die zwei daneben brechen.

4. Rahmen Sie das Problem explizit und lassen Sie es zustimmen. Erstellen Sie eine schriftliche Problemstellung und die Evidenz dahinter und sichern Sie sich die ausdrückliche Zustimmung Ihrer leitenden Förderin. Dieses Artefakt ist Ihr Vertrag: Es definiert, was „fertig“ für die nächsten Phasen bedeutet, und gibt Ihnen das Standing, zu Umfang Nein zu sagen, der dem vereinbarten Problem nicht dient.

5. Bemessen Sie Chance und Risiko ehrlich. Schätzen Sie, wie viele Menschen betroffen sind, wie stark und was es das System heute kostet. Paaren Sie das mit den Risiken, die eine Lösung einführen würde – klinisch, Informationsgovernance, Gerechtigkeit, Lieferung. Führungskräfte finanzieren Discoveries; sie entscheiden auf Grundlage eines vertretbaren Bildes von Chance und Risiko, also geben Sie ihnen eines.

6. Gestalten Sie von Tag eins für die Ränder. Rekrutieren Sie Forschungsteilnehmende über das gesamte Spektrum digitaler Inklusion, testen Sie früh gegen die Erwartungen der Web Content Accessibility Guidelines (WCAG 2.2 AA) und behandeln Sie assistierte digitale und Offline-Wege als erstklassig, nicht als Nachgedanken. In Gesundheit und Pflege ist der ausgeschlossene Nutzende oft der Nutzende mit hohem Bedarf; ein Service, der nur für die Selbstsicheren und Vernetzten funktioniert, vergrößert Ungleichheit.

7. Halten Sie sie multidisziplinär und zeitlich begrenzt. Besetzen Sie die Discovery mit einer Nutzerforscherin, einem Servicedesigner, einer Produktperson, einem technischen Architekten und – bei allem, was Versorgung berührt – klinischem und Informationsgovernance-Input. Begrenzen Sie sie hart (Wochen, nicht Quartale), um Konvergenz zu erzwingen. Eine offene Discovery ist ein Warnzeichen, dass das Team einer Entscheidung ausweicht.

8. Schreiben Sie auf, was Sie stoppen ließe. Vereinbaren Sie zu Beginn die Bedingungen, unter denen die ehrliche Empfehlung „nicht fortfahren“ wäre: kein echtes Nutzerbedürfnis, eine unüberwindliche Hürde bei IG oder Sicherheit, eine bessere nichtdigitale Lösung oder ein Problem, das einem anderen Team gehört. Eine Discovery, die nicht empfehlen kann, zu stoppen, ist keine Discovery; sie ist ein vorab gerechtfertigter Bau.

Fragen zur Diskussion im Team#

1. Was müssten wir in der Discovery sehen, um ehrlich „nicht fortfahren“ zu empfehlen, und hat jemand in diesem Raum das Standing, es zu sagen? Stoppbedingungen sind wertlos, wenn sie nicht ausgeübt werden können, und in Gesundheit und Pflege ist der Druck, sie nicht auszuüben, intensiv: Ein Direktor hat die App angekündigt, ein Lieferantenvertrag ist halb unterschrieben, oder ein Finanzierungsfenster schließt sich, wenn das Team zögert. Diese Frage zwingt ein Team, die konkrete Evidenz zu benennen – kein echtes Nutzerbedürfnis, eine unüberwindliche Hürde bei Informationsgovernance oder klinischer Sicherheit, eine bessere nichtdigitale Lösung, ein Problem, das einem anderen Service gehört –, die die Empfehlung zum Stoppen kippen würde, und sie aufzuschreiben, bevor die Forschung beginnt, damit sie später nicht still umdefiniert werden kann. Die Spannung, die zu debattieren lohnt, liegt zwischen der Zuversicht der Förderin und der Unabhängigkeit der Forscherin: Eine Discovery, die strukturell nicht Nein sagen kann, ist ein vorab gerechtfertigter Bau in den Kleidern der Discovery. Überlegen Sie, wer die Befunde der Forscherin vor Bearbeitung schützt, ob eine Außenstehende die Evidenz prüft und welche die letzte Discovery war, die Ihre Organisation tatsächlich gestoppt hat – gibt es keine, ist das selbst ein Befund. Eine ehrliche Antwort benennt die wirklichen Gründe, warum „Nein“ hier schwer ist, und einen konkreten Mechanismus (vereinbarte Stoppkriterien, eine unabhängige Herausforderung, eine Förderin, die die Möglichkeit des Stoppens öffentlich gesegnet hat), der es sagbar macht.

2. Wen unter den Nutzenden schließen wir am wahrscheinlichsten aus, und wie holen wir sie in die Forschung, statt sie auf die Beta zu verschieben? In Gesundheit und Pflege ist der ausgeschlossene Nutzende – der Gebrechliche, der digital Marginalisierte, die Person mit geringem Vertrauen in ihr Englisch, die Betreuende, die drei Systeme jongliert – überproportional der Nutzende mit hohem Bedarf, dem der Service dienen soll; Stichproben nach Bequemlichkeit gestalten daher still Ungleichheit in die Architektur ein. Der zu debattierende Zielkonflikt ist Tiefe und Inklusion versus Zeitplan und Rekrutierungskosten: Die am schwersten Erreichbaren zu erreichen braucht Zeit, Gemeinschaftspartner, Anreize und assistierte oder Offline-Forschungsmethoden, die eine gehetzte Discovery „vorerst“ überspringen möchte. Konkrete Ansätze umfassen, das Spektrum digitaler Inklusion ausdrücklich zu kartieren, über Gatekeeper aus Freiwilligensektor und Klinik statt über einen Verteiler zu rekrutieren und assistierte digitale und nichtdigitale Wege als erstklassige Befunde statt als Nachgedanken zu behandeln. Es lohnt, die Gleichstellungspflicht des öffentlichen Sektors und den Caldicott-Kontext zu nennen, damit Inklusion als rechtliche und ethische Verpflichtung verstanden wird, nicht als Nettigkeit. Eine gute Antwort ergibt einen benannten Rekrutierungsplan, der die Ränder bewusst überrepräsentiert, und eine klare Aussage, welche Nutzenden das Team als Schwerpunkt des Designs behandelt.

3. Haben wir ein Problem gerahmt, oder haben wir eine Lösung in die Problemstellung geschmuggelt? Wie ein Problem formuliert wird, begrenzt still jede Lösung, die das Team erwägen wird – „Patientinnen und Patienten vergessen Termine“ lädt zu einer Erinnerungs-App ein, während „Patientinnen und Patienten können Termine, die nicht mehr passen, nicht leicht verlegen“ zu Self-Service-Umbuchung und einer Überprüfung der Slot-Politik einlädt –, sodass die Formulierung der Problemstellung der Ort ist, an dem Discovery den größten Teil ihres Unterhalts verdient. Die Debatte ist, ob der Finanzierungsantrag, das Vorstandspapier oder der Lieferanten-Pitch die Antwort („eine App“, „ein Portal“, „ein KI-Triage-Werkzeug“) bereits festgelegt und als Bedürfnis verkleidet hat und ob das Team die Disziplin hat, diesen Wunsch zurück in das zugrunde liegende Nutzerziel zu übersetzen. Nützliche Ansätze umfassen, Lösungssubstantive aus der Problemstellung zu verbannen, den ganzen durchgängigen Service über jeden Kanal und jede Organisation zu kartieren, damit die digitale Scheibe im Kontext gesehen wird, und zu prüfen, dass jedes genannte Bedürfnis aus der Sicht der Nutzenden statt der der Organisation ausgedrückt ist. Evidenz zählt hier: Eine Rahmung sollte auf das zurückführbar sein, was echte Nutzende sagten und taten, nicht auf eine Gewohnheit oder eine Strategiefolie. Eine ehrliche Antwort bestätigt entweder, dass die Aussage ein stabiles Nutzerbedürfnis mit Evidenz dahinter benennt, oder räumt ein, dass eine Lösung angenommen wurde, und öffnet die Rahmung erneut, bevor irgendeine Alpha umrissen wird.

4. Haben wir die richtigen Disziplinen im Raum, und formen klinische Sicherheit und Informationsgovernance die Arbeit, statt sie am Ende freizugeben? Eine nur mit einer Produktmanagerin und einem Lieferleiter besetzte Discovery wird Produkt- und Lieferprobleme finden; die Nutzenden, das Klinikpersonal und die rechtlichen Pflichten, die sie nie in den Raum einlädt, werden zu den Risiken, die in der Alpha teuer auftauchen oder, schlimmer, nach dem Go-live. Die Spannung: Ein wirklich multidisziplinäres Team – Nutzerforscherin, Servicedesigner, technische Architektin, Clinical Safety Officer, Expertise in Informationsgovernance und Caldicott – ist knapp, umkämpft und langsam zusammenzubringen, sodass Teams versucht sind, ein Klinikmitglied für eine Stunde zu „leihen“ oder IG als letztes Tor anzuflanschen. Diese Sequenzierung ist die Falle: Klinische Sicherheit und IG sind bei der Rahmung billig einzuplanen und ruinös teuer nachzurüsten, sobald eine Architektur annimmt, dass Daten Organisationsgrenzen überqueren. Konkrete Ansätze umfassen, bei allem, was Versorgung berührt, ab Woche eins einen Clinical Safety Officer zu benennen, eine Datenschutz-Folgenabschätzung als lebendiges Discovery-Artefakt statt als spätere Formalität zu behandeln und zu prüfen, ob die Menschen, die den Arbeitsablauf an der Front verstehen, Mitwirkende oder bloß Konsultierte sind. Eine ehrliche Antwort benennt, wer tatsächlich im Team ist, welche Pflichten durch eine Person statt durch ein Kästchen vertreten sind, und wo die Discovery blind wäre, weil eine Disziplin fehlt.

5. Woran erkennen wir, dass die Discovery abgeschlossen ist, und was verhindert, dass sie Monate driftet oder nach zwei Wochen abgebrochen wird? Discovery hat zwei gegenläufige Fehlerbilder, und beide betreffen Zeit: die unbegrenzte Studie, die alles kartiert und nichts entscheidet, und die verkürzte Zwei-Wochen-Runde, die zu einem vorab feststehenden Schluss hetzt, weil ein Liefertermin vor Beginn der Forschung festgelegt wurde. Die vom Double Diamond verlangte Disziplin ist Konvergenz – zu wissen, wann das Problem gut genug verstanden ist, um eine vertretbare Entscheidung zu treffen, nicht wann jede Frage beantwortet ist, denn Gewissheit ist unerreichbar und das Ziel ist verringerte Unsicherheit bei den Dingen, die das Vorhaben versenken würden. Der zu debattierende Zielkonflikt ist Tiefe versus Schwung: Ein harter Zeitrahmen von Wochen zwingt das Team, die riskantesten Annahmen zu priorisieren, doch ein zu eng gesetzter Rahmen hungert die inklusive, schwer erreichbare Forschung aus, die dieser Bereich am meisten braucht. Nützliche Ansätze umfassen, die Entscheidung zu vereinbaren, die die Discovery informieren muss, und die Artefakte, die eine Förderin dafür braucht, Annahmen zu ranken, damit der Rahmen auf das Wichtige verwendet wird, und einen Entscheidungspunkt zu benennen, statt die Phase in eine unerklärte Alpha rieseln zu lassen. Eine ehrliche Antwort sagt, wie lang der Rahmen ist, wie „gut genug verstanden“ für dieses Problem aussieht und wer das Ende ausruft.

6. Wenn die Discovery endet, können wir einem Finanzierungsgremium ein vertretbares Bild von Chance und Risiko vorlegen – oder nur eine Geschichte? Führungskräfte finanzieren nicht Verständnis; sie finanzieren Entscheidungen, und eine Discovery, die reiche Erkenntnisse, aber keine für ein Gremium lesbare Darstellung liefert, wie viele Menschen betroffen sind, wie stark, was es das System heute kostet und was eine Lösung gefährden würde, überlässt die Entscheidung dem, der die selbstsicherste Geschichte erzählt. Die Spannung liegt zwischen den nuancierten, mit Vorbehalten versehenen Befunden der Forscherin und dem Bedürfnis des Gremiums nach einem bemessenen, vergleichbaren, vertretbaren Fall – komprimieren Sie zu stark, verlieren Sie die Gerechtigkeits- und Sicherheitsnuancen, die der Sinn waren; weigern Sie sich zu komprimieren, erreicht die Evidenz nie die Menschen, die Geld zuweisen. In Gesundheit und Pflege muss das Bild Chance mit den Risiken paaren, die eine Lösung einführt – klinisch, Informationsgovernance, Gerechtigkeit, Lieferung –, denn ein Gremium, das nur Vorteile sieht, wird zu einer schlechten Wette angestiftet. Konkrete Ansätze umfassen, die betroffene Population aus echten Daten statt einer hoffnungsvollen Schätzung zu bemessen, Befunde rückverfolgbar zu machen, damit ein Skeptiker sie auf das zurückführen kann, was Nutzende sagten, und die Empfehlung (einschließlich „nicht fortfahren“ oder „diese engere Sache in die Alpha“) in Begriffen zu rahmen, auf die die nächste Phase reagieren kann. Eine ehrliche Antwort zeigt, dass das Team von Evidenz zu einer Empfehlung kommen kann, die ein Finanzierungsgremium offen prüfen könnte, ohne dass sie auseinanderfällt.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) steht unter Druck, die Raten des Nichterscheinens (Did Not Attend, DNA) in Ambulanzen zu senken. Ein Lieferant hat eine KI-gestützte Erinnerungs-App angeboten, und ein Direktor will sie unbedingt finanzieren. Statt zu kaufen, führt das ICS eine achtwöchige Discovery durch.

Die Nutzerforscherin befragt achtzehn Patientinnen und Patienten, die kürzlich Termine verpasst haben, sowie Empfangskräfte und zwei Ambulanzmanagerinnen. Es zeigt sich ein Muster, das die Erinnerungstheorie übersah: Viele „Nichterscheinende“ hatten versucht, umzubuchen, waren aber tagelang auf eine besetzte Telefonleitung gestoßen oder hatten einen Termin zu Arbeitszeiten bekommen, den sie ohne Lohnverlust nicht wahrnehmen konnten. Eine Teilgruppe war verstorben oder anderswo aufgenommen worden und stand noch auf der Liste. Erinnerungen würden keine dieser Ursachen berühren.

Das Team kartiert die durchgängige Buchungsreise und findet drei Organisationen, zwei Patientenverwaltungssysteme und ein Faxgerät in der Schleife. Sie formulieren das Problem von „Patientinnen und Patienten vergessen Termine“ um zu „Patientinnen und Patienten können uns nicht leicht erreichen, um Termine umzubuchen, die für sie nicht mehr passen“. Sie beziffern es: Etwa 40 % der DNAs an den erfassten Ambulanzen betrafen einen gescheiterten früheren Kontaktversuch. Sie markieren eine Frage der Informationsgovernance (ein gemeinsames Umbuchungswerkzeug würde Organisationsgrenzen überqueren) und einen Gerechtigkeitsbefund (die höchsten DNA-Raten lagen bei Patientinnen und Patienten in den am stärksten deprivierten Postleitzahlgebieten, für die der Termin zu Arbeitszeiten die Barriere war).

Die Discovery empfiehlt gegen die App und für eine Alpha, die Self-Service-Umbuchung plus eine Überprüfung der Slot-Planungspolitik erkundet. Das umformulierte Problem wird von der Förderin vereinbart, ein Clinical Safety Officer wird für die Alpha benannt, und eine Datenschutz-Folgenabschätzung wird beauftragt. Das ICS hat acht Wochen ausgegeben und vermieden, eine Lösung zu finanzieren, die öffentlich messbar gescheitert wäre.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit führt Discovery auf Sparflamme und gegen die Uhr durch – oft ist die „Discovery“ die eigene gelebte Erfahrung der Gründenden plus zwei Wochen Nutzerinterviews, zwischen Investorentermine gequetscht. Der Finanzierungsdruck ist, Traktion zu zeigen, was Gründende verleitet, direkt zu einer Demo zu springen; die wichtigste Disziplin ist, die riskanteste Annahme zu benennen und die Idee billig zu töten, wenn sie scheitert, denn ein Startup kann es sich nicht leisten, auch nur einmal das Falsche zu bauen. Die Rechenschaft gilt gegenüber Investoren und frühen Anwendern statt einem gesetzlichen Gremium; Stoppbedingungen sind daher ebenso kommerziell (keine Zahlungsbereitschaft, kein erreichbarer Markt) wie klinisch. Der Vorteil ist Geschwindigkeit und die Freiheit zu pivotieren; das Risiko ist, eine überzeugende Gründererzählung mit Evidenz für ein echtes Nutzerbedürfnis zu verwechseln.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, ein ambulanter Pflegedienst, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Phase ohne Umsatz – hat echte Patientinnen und Patienten und laufenden Betrieb, aber selten eine übrige Nutzerforscherin oder einen Servicedesigner, um eine formale Discovery zu besetzen. Discovery ist hier schlank und gelegenheitsgetrieben: Die „Forschung“ ist die Empfangskraft, die bereits weiß, warum Patientinnen und Patienten am Telefon nicht durchkommen, die Pflegekräfte, die täglich die Papierdoppelung sehen, und eine Handvoll bewusster Gespräche mit den Nutzenden, die eine Änderung beträfe. Die Falle ist, dass dieselben gesetzlichen Pflichten – Caldicott, UK GDPR, Gleichstellungspflicht, klinische Sicherheit – in vollem Umfang gelten, ob es jemanden im Haus gibt, der sie verantwortet, oder nicht; die wichtigste Disziplin ist daher, das Problem ehrlich zu rahmen und die riskanteste Annahme zu testen, bevor man knappes Geld auf das Produkt eines Lieferanten setzt. Weil der laufende Betrieb nicht pausieren kann, führt ein kleiner Anbieter seine Discovery oft um einen einzelnen konkreten Schmerzpunkt statt um einen breiten Problemraum, und seine wertvollste Stoppbedingung ist zu erkennen, wann die Lösung eine Prozessänderung oder eine gemeinsame regionale Plattform statt eines zu kaufenden Systems ist.

Großunternehmen#

Ein NHS Trust oder großer Health-Tech-Lieferant kann eine ordentliche multidisziplinäre Discovery besetzen – Nutzerforschende, Servicedesigner, klinische Sicherheit, Informationsgovernance –, muss aber gegen organisatorische Schwerkraft kämpfen: einen bestehenden Lieferantenvertrag, einen Vorstand, der „die App“ bereits angekündigt hat, oder einen Business Case, der die Lösung vorab entschieden hat. Hier ist die schwerste Arbeit der Discovery politisch – eine genehmigte Lösung zurück in ein Nutzerbedürfnis umzurahmen, ohne die Unterstützung der Förderin zu verlieren. Die Finanzierung ist jährlich und gremiengebunden, sodass Discoveries um Slots konkurrieren und für ein Gremium lesbare Artefakte liefern müssen. Die Risikobereitschaft ist gering und die Rechenschaft breit (Aufsichten, Prüfende, Öffentlichkeit), was ein ehrliches „nicht fortfahren“ wertvoller und schwerer auszusprechen macht.

Regierung#

Eine nationale oder lokale öffentliche Stelle – NHS England, DHSC, eine dezentrale Regierung, eine Kommunalverwaltung – führt Discovery unter dem vollen Gewicht des Service Standard, von Ausgabenkontroll-Toren und öffentlicher Kontrolle durch, wo der Discovery-Bericht selbst veröffentlicht und angefochten werden kann. Die Nutzerbasis ist enorm, und die Pflicht, die Marginalisierten einzubeziehen, ist eine rechtliche, keine optionale; inklusive Rekrutierung und assistierte digitale Wege sind daher ab der ersten Woche verpflichtend. Die Rechenschaft gilt gegenüber Ministern, Parlament und Wählerschaft, sodass eine Discovery offen vertretbar sein muss und von Ausgabenkontrollen gestoppt werden kann, wenn die Evidenz schwach ist. Der Zielkonflikt ist Strenge versus Tempo: Discovery der Regierung ist langsamer und stärker abgesichert, was öffentliches Geld schützt, aber Teams frustrieren kann, die schnelles Vorgehen gewohnt sind.

Häufige Fehlermuster#

• Zu frühes Lösen. Das Team tritt mit bereits gewählter Antwort in die Discovery ein und verbringt die Wochen damit, einen Business Case dafür zu bauen. Gegenmittel: Lösungssubstantive aus der Problemstellung verbannen; die riskanteste Annahme zur Forschungsfrage machen.
• Forschungstheater. Einige freundliche Stakeholder werden konsultiert, schwer erreichbare Nutzende „aus Zeitgründen“ übersprungen, und die Befunde bestätigen bequem den Plan. Gegenmittel: für die Ränder rekrutieren; Forschungsbefunde von jemandem außerhalb des Teams anfechten lassen.
• Die Discovery, die nicht Nein sagen kann. Finanzierung, Politik oder ein unterschriebener Vertrag machen „nicht fortfahren“ unsagbar, sodass die Discovery zum Ritual wird. Gegenmittel: Stoppbedingungen vorab vereinbaren und die Unabhängigkeit der Forscherin schützen.
• Den Ozean zum Kochen bringen. Eine unbegrenzte Discovery driftet Monate, kartiert alles und entscheidet nichts. Gegenmittel: ein harter Zeitrahmen und eine benannte Entscheidung am Ende.
• Den nichtdigitalen Service ignorieren. Das Team studiert den Bildschirm und übersieht die Telefonleitung, den Brief und die Empfangskraft, die die Reise tatsächlich tragen. Gegenmittel: alle Kanäle und Organisationen durchgängig kartieren.
• Barrierefreiheit und Inklusion auf später verschieben. Randnutzende werden auf die Beta verschoben, wo die Architektur sie bereits ausschließt. Gegenmittel: inklusiv rekrutieren und ab dem ersten Prototyp gegen WCAG testen.

Reifegradmodell#

Checkliste#

• Es gibt eine schriftliche Problemstellung, die ein Nutzerbedürfnis benennt, keine Lösung.
• Echte Nutzende – einschließlich der am schwersten Erreichbaren – wurden im Kontext befragt oder beobachtet.
• Der durchgängige Service ist über alle Kanäle und Organisationen kartiert.
• Die riskantesten Annahmen sind aufgelistet, geordnet und die obersten getestet.
• Risiken bei klinischer Sicherheit, Informationsgovernance (Caldicott, UK GDPR/DPIA) und gesundheitlicher Ungleichheit sind identifiziert.
• Barrierefreiheit (WCAG 2.2 AA) und digitale Inklusion werden ab dem ersten Prototyp bedacht.
• Stoppbedingungen wurden zu Beginn vereinbart, und „nicht fortfahren“ ist ein echtes mögliches Ergebnis.
• Die Chance ist bemessen und die Empfehlung gegenüber einem Finanzierungsgremium vertretbar.
• Ein multidisziplinäres Team (einschließlich klinischem/IG-Input) hat die Phase in einem festen Zeitrahmen durchgeführt.
• Die Förderin hat die Problemstellung vor Beginn jeder Alpha vereinbart.

Zentrale Quellen#

• NHS England — NHS Digital Service Manual und NHS Service Standard (service.nhs.uk).
• GOV.UK Service Manual — „How the discovery phase works“ und der Government Service Standard (Government Digital Service).
• Design Council — das Designprozess-Rahmenwerk The Double Diamond.
• NHS England — Digital Technology Assessment Criteria (DTAC): klinische Sicherheit, Datenschutz, technische Absicherung, Interoperabilität, Nutzbarkeit und Barrierefreiheit.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C; und GOV.UK-Leitlinien zu Barrierefreiheit und Assisted Digital.
• Die britischen Caldicott-Prinzipien und der Data Protection Act 2018 / UK GDPR (Datenschutz-Folgenabschätzungen).
• Equality Act 2010 — die Gleichstellungspflicht des öffentlichen Sektors (relevant für die Bewertung gesundheitlicher Ungleichheit in der Discovery).

Referenzen#

1. Double Diamond (design process model) — Wikipedia — https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)
2. Design Council — Wikipedia — https://en.wikipedia.org/wiki/Design_Council
3. User research — Wikipedia — https://en.wikipedia.org/wiki/User_research
4. Contextual inquiry — Wikipedia — https://en.wikipedia.org/wiki/Contextual_inquiry
5. Problem statement — Wikipedia — https://en.wikipedia.org/wiki/Problem_statement
6. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
7. Equality Act 2010 — Wikipedia — https://en.wikipedia.org/wiki/Equality_Act_2010
8. NHS Constitution for England — Wikipedia — https://en.wikipedia.org/wiki/NHS_Constitution_for_England
9. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
10. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
11. How the discovery phase works — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
12. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
13. The Double Diamond — Design Council — https://www.designcouncil.org.uk/our-resources/the-double-diamond/
14. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — https://www.w3.org/TR/WCAG22/
15. Equality Act 2010 — UK legislation (legislation.gov.uk) — https://www.legislation.gov.uk/ukpga/2010/15/contents
16. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
17. The Caldicott Principles — National Data Guardian, GOV.UK — https://www.gov.uk/government/publications/the-caldicott-principles
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health