Onderwerp 3.4 — Discoveryfasen

In één zin: Discovery is de gedisciplineerde, in tijd begrensde inspanning om uw gebruikers en het werkelijke probleem te begrijpen voordat u geld, klinisch risico of reputatie vastlegt in het bouwen van een oplossing.

Waarom dit ertoe doet in gezondheid en zorg#

In de meeste sectoren verspilt het bouwen van het verkeerde geld. In gezondheid en zorg kan het ook klinische tijd verspillen, gezondheidsongelijkheid verankeren en — in het uiterste geval — patiënten schaden. Een digitale dienst die ervan uitgaat dat elke gebruiker een smartphone, betrouwbaar breedband en zelfverzekerd Engels heeft, sluit stilletjes de kwetsbaren, de armen en de digitaal gemarginaliseerden uit: precies de mensen die de NHS en de sociale zorg moeten dienen. Discovery is waar u dat ontdekt voor de prijs van enkele weken onderzoek, in plaats van na een landelijke uitrol.

Uitgaven voor gezondheid en zorg zijn publiek geld in bewaring, en veel ervan loopt via wettelijke plichten: de NHS Constitution, de publieke gelijkheidsplicht onder de Equality Act 2010 en de Caldicott-beginselen voor het omgaan met vertrouwelijke patiëntinformatie. Discovery is de fase waarin u toetst of een voorgestelde dienst nodig, rechtmatig, veilig en billijk is — voordat die vragen duur zijn om te beantwoorden. Overslaan neemt de vragen niet weg; het stelt ze uit tot een punt waarop het eerlijke antwoord politiek onmogelijk te aanvaarden is.

De NHS Digital Service Standard en de GOV.UK Service Manual maken discovery beide de verplichte eerste fase van elke gebruikersgerichte digitale dienst, juist om deze reden. Het is geen bureaucratisch theater. Het is de goedkoopste verzekering die u ooit zult kopen.

Kernbegrippen#

Discovery, gedefinieerd. Discovery is een korte (doorgaans 6–10 weken) fase met als doel een probleemruimte te begrijpen: wie de gebruikers zijn, wat zij proberen te doen, wat hen tegenhoudt, wat er al bestaat en of er überhaupt een probleem is dat het oplossen waard is. Haar uitkomst is begrip en bewijs, geen product. Een goede discovery kan geldig concluderen “doe niets” of “dit is een beleidsprobleem, geen digitaal probleem.”

De Double Diamond. De Double Diamond (2005) van de Design Council kadert ontwerp als twee gekoppelde diamanten. De eerste — Ontdekken (Discover) en dan Definiëren (Define) — divergeert om het probleem breed te verkennen en convergeert dan om het precies te kaderen. De tweede — Ontwikkelen (Develop) en dan Opleveren (Deliver) — divergeert om oplossingen te verkennen en convergeert dan om er een te bouwen. Discovery, als leveringsfase, leeft bijna geheel in de eerste diamant. Het terugkerende falen is dat teams de tweede diamant in sprinten voordat de eerste klaar is.

Gebruikersbehoefte versus wens van een belanghebbende. Een gebruikersbehoefte is iets wat iemand probeert te bereiken, uitgedrukt vanuit zijn of haar gezichtspunt (“ik moet weten dat mijn afspraak bevestigd is zodat ik geen dag vrij neem voor niets”). Een wens van een belanghebbende is een functie of oplossing waarover iemand al heeft beslist (“wij hebben een app nodig”). De kerndiscipline van discovery is wensen terug te vertalen naar behoeften, omdat behoeften stabiel zijn en oplossingen goedkoop en uitwisselbaar zodra de behoefte duidelijk is.

Probleemkadering. Hoe u een probleem formuleert beperkt elke oplossing die u zult overwegen. “Patiënten missen afspraken” nodigt uit tot een herinneringsapp. “Patiënten kunnen afspraken die niet meer passen niet gemakkelijk verzetten” nodigt uit tot zelfbediening bij opnieuw boeken. Hetzelfde symptoom, een ander probleem, een radicaal andere dienst. Discovery verdient haar bestaan grotendeels in de kwaliteit van de probleemstelling die zij oplevert.

Aannames, hypothesen en bewijs. Elk project rust op aannames. Discovery maakt ze expliciet, rangschikt ze naar risico en toetst de riskantste met echte gebruikers. Het doel is geen zekerheid — die is onbereikbaar — maar verminderde onzekerheid over de dingen die het project zouden doen zinken.

Beste praktijken#

1. Begin bij een probleem, niet bij een oplossing. Schrijf de probleemstelling voordat iemand een technologie noemt. Als het financieringsvoorstel, het bestuursstuk of de pitch van de leverancier al “een app” of “een portaal” specificeert, behandel dat dan als aanname om te toetsen, niet als beslissing om uit te voeren. Oplossingen die zijn bereikt voordat het probleem is begrepen zijn bijna altijd iemands gewoonte, niet de behoefte van de gebruiker.

2. Doe echt gebruikersonderzoek met echte gebruikers. Interview en observeer de werkelijke mensen die de dienst zullen gebruiken — patiënten, mantelzorgers, baliemedewerkers, wijkverpleegkundigen, maatschappelijk werkers — in hun echte context, niet een workshop van managers die namens hen spreken. Streef naar diepte boven volume; een dozijn zorgvuldig gekozen contextuele interviews onthult meer dan een enquête met duizend reacties. Werf bewust de gebruikers die het moeilijkst te bereiken zijn, omdat zij degenen zijn die een dienst het vaakst in de steek laat.

3. Breng de hele dienst in kaart, niet het digitale schilfertje. Gebruikers ervaren een dienst van begin tot eind — een verwijzing, een beoordeling, een behandeling, een nazorg — waarvan uw digitale component één stap is. Breng het huidige traject in kaart over elk kanaal en elke organisatie, inclusief de papieren, telefonische en persoonlijke delen. Digitale veranderingen falen routinematig omdat ze één stap optimaliseren en de twee aan weerszijden breken.

4. Kader het probleem expliciet en laat het overeenkomen. Produceer een schriftelijke probleemstelling en het bewijs erachter en verkrijg expliciete instemming van uw senior sponsor. Dit artefact is uw contract: het definieert wat “klaar” betekent voor de volgende fasen en geeft u de positie om nee te zeggen tegen reikwijdte die het overeengekomen probleem niet dient.

5. Schat de kans en het risico eerlijk in. Raam hoeveel mensen worden getroffen, hoe ernstig en wat het het stelsel vandaag kost. Koppel dit aan de risico’s die een oplossing zou introduceren — klinisch, informatiebeheer, billijkheid, levering. Leiders financieren discoveries; zij beslissen op grond van een verdedigbaar beeld van kans en risico, dus geef hun er een.

6. Ontwerp vanaf dag één voor de randen. Werf onderzoeksdeelnemers over het hele spectrum van digitale inclusie, test vroeg tegen verwachtingen van de Web Content Accessibility Guidelines (WCAG 2.2 AA) en behandel begeleide digitale en offlineroutes als eersteklas, niet als bijzaak. In gezondheid en zorg is de uitgesloten gebruiker vaak de gebruiker met hoge behoefte; een dienst die alleen werkt voor de zelfverzekerden en verbondenen vergroot ongelijkheid.

7. Houd het multidisciplinair en in tijd begrensd. Bemens discovery met een gebruikersonderzoeker, een servicedesigner, een productpersoon, een technisch architect en — voor alles wat zorg raakt — klinische en informatiebeheerinbreng. Begrens haar hard in tijd (weken, geen kwartalen) om convergentie af te dwingen. Een open einde discovery is een waarschuwingssignaal dat het team een beslissing vermijdt.

8. Schrijf op wat u zou laten stoppen. Spreek aan het begin de voorwaarden af waaronder de eerlijke aanbeveling “niet doorgaan” zou zijn: geen echte gebruikersbehoefte, een onoverkomelijke barrière van informatiebeheer of veiligheid, een betere niet-digitale oplossing of een probleem dat een ander team bezit. Een discovery die niet kan aanbevelen te stoppen is geen discovery; het is een vooraf gerechtvaardigde bouw.

Vragen om met uw team te bespreken#

1. Wat zouden wij in discovery moeten zien om eerlijk “niet doorgaan” aan te bevelen, en heeft iemand in deze kamer de positie het te zeggen? Stopvoorwaarden zijn waardeloos als ze niet kunnen worden uitgeoefend, en in gezondheid en zorg is de druk om dat niet te doen intens: een directeur heeft de app aangekondigd, een leverancierscontract is half getekend of een financieringsvenster sluit als het team aarzelt. Deze vraag dwingt een team het specifieke bewijs te noemen — geen echte gebruikersbehoefte, een onoverkomelijke barrière van informatiebeheer of klinische veiligheid, een betere niet-digitale oplossing, een probleem dat een andere dienst bezit — dat de aanbeveling naar stoppen zou kantelen, en het op te schrijven voordat het onderzoek begint zodat het later niet stilletjes kan worden geherdefinieerd. De spanning die het bespreken waard is, is die tussen vertrouwen van de sponsor en onafhankelijkheid van de onderzoeker: een discovery die structureel geen nee kan zeggen is een vooraf gerechtvaardigde bouw in de kleren van discovery. Overweeg wie de bevindingen van de onderzoeker tegen bewerking beschermt, of een buitenstaander het bewijs toetst en wat de laatste discovery was die uw organisatie werkelijk stopte — als er geen is, is dat zelf een bevinding. Een eerlijk antwoord identificeert de echte redenen waarom “nee” hier moeilijk is en een concreet mechanisme (overeengekomen stopcriteria, een onafhankelijke uitdaging, een sponsor die de mogelijkheid van stoppen openlijk heeft gezegend) dat het zegbaar maakt.

2. Wie zijn de gebruikers die wij het waarschijnlijkst uitsluiten, en hoe krijgen wij hen in het onderzoek in plaats van hen naar bèta uit te stellen? In gezondheid en zorg is de uitgesloten gebruiker — de kwetsbare, de digitaal gemarginaliseerde, de persoon met laag vertrouwen in Engels, de mantelzorger die drie systemen jongleert — onevenredig de gebruiker met hoge behoefte die de dienst moet dienen, dus steekproeftrekking voor het gemak ontwerpt ongelijkheid stilletjes in de architectuur. De afweging om te bespreken is diepte en inclusie versus planning en wervingskosten: de moeilijkst bereikbaren bereiken kost tijd, gemeenschapspartners, vergoedingen en begeleide of offline onderzoeksmethoden die een gehaaste discovery “voor nu” wil overslaan. Concrete invalshoeken zijn het spectrum van digitale inclusie expliciet in kaart brengen, werven via organisaties uit de vrijwilligerssector en klinische poortwachters in plaats van een mailinglijst en begeleide digitale en niet-digitale routes behandelen als eersteklas bevindingen en niet als bijzaak. Het is de moeite waard de publieke gelijkheidsplicht en de Caldicott-context te noemen zodat inclusie wordt begrepen als wettelijke en ethische verplichting, geen netheid. Een goed antwoord levert een benoemd wervingsplan op dat de randen bewust oversampelt, en een duidelijke verklaring van welke gebruikers het team als zwaartepunt van het ontwerp zal behandelen.

3. Hebben wij een probleem gekaderd, of hebben wij een oplossing in de probleemstelling gesmokkeld? Hoe een probleem wordt gesteld beperkt stilletjes elke oplossing die het team zal overwegen — “patiënten vergeten afspraken” nodigt uit tot een herinneringsapp, terwijl “patiënten kunnen afspraken die niet meer passen niet gemakkelijk verzetten” uitnodigt tot zelfbediening bij opnieuw boeken en een toetsing van het tijdslotbeleid — dus de formulering van de probleemstelling is waar discovery het grootste deel van haar bestaan verdient. Het debat is of het financieringsvoorstel, bestuursstuk of de pitch van de leverancier het antwoord al heeft vastgelegd (“een app”, “een portaal”, “een AI-triagehulpmiddel”) en als behoefte heeft aangekleed, en of het team de discipline heeft die wens terug te vertalen naar het onderliggende gebruikersdoel. Nuttige invalshoeken zijn oplossingsnamen uit de probleemstelling verbannen, de hele dienst van begin tot eind over elk kanaal en elke organisatie in kaart brengen zodat het digitale schilfertje in context wordt gezien en controleren dat elke genoemde behoefte vanuit het gezichtspunt van de gebruiker is verwoord en niet dat van de organisatie. Bewijs doet hier ertoe: een kadering moet herleidbaar zijn tot wat echte gebruikers zeiden en deden, niet tot een gewoonte of een strategiedia. Een eerlijk antwoord bevestigt ofwel dat de verklaring een stabiele gebruikersbehoefte met bewijs erachter noemt, of erkent dat een oplossing is aangenomen en heropent de kadering voordat enige alfa wordt afgebakend.

4. Hebben wij de juiste disciplines in de kamer, en vormen klinische veiligheid en informatiebeheer het werk in plaats van het aan het eind goed te keuren? Een discovery bemand met alleen een productmanager en een leveringsleider zal product- en leveringsproblemen vinden; de gebruikers, clinici en wettelijke plichten die zij nooit in de kamer uitnodigt worden de risico’s die duur opduiken in alfa of, erger, na go-live. De spanning is dat een werkelijk multidisciplinair team — gebruikersonderzoeker, servicedesigner, technisch architect, klinischeveiligheidsfunctionaris, expertise in informatiebeheer en Caldicott — schaars, gewild en traag bijeen te brengen is, dus teams worden verleid een clinicus een uur te “lenen” of informatiebeheer als laatste poort erop te schroeven. Die volgorde is de valkuil: klinische veiligheid en informatiebeheer zijn goedkoop in te ontwerpen tijdens de kadering en ruïnerend duur te retrofitten zodra een architectuur ervan uitgaat dat data over organisatiegrenzen zullen stromen. Concrete invalshoeken zijn vanaf week één een klinischeveiligheidsfunctionaris benoemen voor alles wat zorg raakt, een gegevensbeschermingseffectbeoordeling behandelen als levend discoveryartefact en niet als latere formaliteit en controleren of de mensen die de werkstroom in de frontlinie begrijpen bijdragers zijn of slechts geraadpleegden. Een eerlijk antwoord noemt wie er werkelijk in het team zit, welke plichten door een persoon versus een vakje worden vertegenwoordigd en waar de discovery blind zou zijn omdat een discipline ontbreekt.

5. Hoe zullen wij weten dat discovery klaar is, en wat voorkomt dat zij maandenlang wegdrijft of na twee weken wordt afgekapt? Discovery heeft twee tegengestelde faalwijzen en beide gaan over tijd: de onbegrensde studie die alles in kaart brengt en niets beslist, en de afgekapte twee weken die naar een uitgemaakte conclusie rennen omdat een leveringsdatum werd vastgelegd voordat het onderzoek begon. De discipline die de Double Diamond eist is convergentie — weten wanneer het probleem goed genoeg is begrepen om een verdedigbare beslissing te nemen, niet wanneer elke vraag is beantwoord, omdat zekerheid onbereikbaar is en het doel verminderde onzekerheid is over de dingen die het project zouden doen zinken. De afweging die het bespreken waard is, is diepte versus momentum: een harde tijdbegrenzing van weken dwingt het team de riskantste aannames te prioriteren, maar een te strakke begrenzing verhongert het inclusieve, moeilijk bereikbare onderzoek dat dit domein het meest nodig heeft. Nuttige invalshoeken zijn de beslissing afspreken die de discovery moet informeren en de artefacten die een sponsor nodig heeft om haar te nemen, aannames rangschikken zodat de begrenzing wordt besteed aan wat ertoe doet en een beslismoment noemen in plaats van de fase te laten verlopen in een niet-erkende alfa. Een eerlijk antwoord noemt hoe lang de begrenzing is, hoe “genoeg begrepen” eruitziet voor dit probleem en wie het einde afroept.

6. Wanneer discovery eindigt, kunnen wij een financieringsbestuur een verdedigbaar beeld van kans en risico overhandigen — of alleen een verhaal? Leiders financieren geen begrip; zij financieren beslissingen, en een discovery die rijk inzicht oplevert maar geen voor het bestuur leesbaar verslag van hoeveel mensen worden getroffen, hoe ernstig, wat het het stelsel vandaag kost en wat een oplossing zou riskeren laat de beslissing over aan wie het meest zelfverzekerde verhaal vertelt. De spanning is tussen de genuanceerde, voorbehouden bevindingen van de onderzoeker en de behoefte van het bestuur aan een afgebakende, vergelijkbare, verdedigbare case — comprimeer te hard en u verliest de nuances van billijkheid en veiligheid die het punt waren; weiger te comprimeren en het bewijs bereikt de mensen die geld toewijzen nooit. In gezondheid en zorg moet het beeld kans koppelen aan de risico’s die een oplossing introduceert — klinisch, informatiebeheer, billijkheid, levering — omdat een bestuur dat alleen voordeel ziet wordt klaargestoomd voor een slechte gok. Concrete invalshoeken zijn de getroffen populatie afbakenen op echte data in plaats van een hoopvolle schatting, bevindingen herleidbaar maken zodat een scepticus ze kan volgen tot wat gebruikers zeiden en de aanbeveling (inclusief “niet doorgaan” of “alfa dit smallere ding”) kaderen in termen waarop de volgende fase kan handelen. Een eerlijk antwoord toont dat het team van bewijs kan gaan naar een aanbeveling die een financieringsbestuur openlijk kan toetsen zonder dat zij uiteenvalt.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Een geïntegreerd zorgsysteem (ICS) staat onder druk om het percentage niet-verschenen patiënten (did-not-attend, DNA) bij poliklinieken te verlagen. Een leverancier heeft een door AI gedreven herinneringsapp gepitcht en een directeur wil haar graag financieren. In plaats van te kopen voert het ICS een discovery van acht weken uit.

De gebruikersonderzoeker interviewt achttien patiënten die recent afspraken misten, plus baliemedewerkers en twee polikliniekmanagers. Een patroon dat de herinneringstheorie miste komt naar voren: veel “no-shows” hadden geprobeerd te verzetten maar dagenlang een bezette telefoonlijn getroffen, of hadden een afspraak gekregen tijdens werkuren die zij niet konden nemen zonder loon te verliezen. Een deel was overleden of elders opgenomen en stond nog op de lijst. Herinneringen zouden geen van deze oorzaken raken.

Het team brengt het boekingstraject van begin tot eind in kaart en vindt drie organisaties, twee patiëntenadministratiesystemen en een faxapparaat in de lus. Zij kaderen het probleem van “patiënten vergeten afspraken” naar “patiënten kunnen ons niet gemakkelijk bereiken om afspraken te verzetten die niet meer voor hen werken.” Zij kwantificeren het: ruwweg 40% van de DNA’s bij de bemonsterde poliklinieken betrof een mislukte eerdere contactpoging. Zij markeren een vraag van informatiebeheer (een gedeeld hulpmiddel voor opnieuw boeken zou organisatiegrenzen overschrijden) en een bevinding over billijkheid (de hoogste DNA-percentages lagen bij patiënten in de meest achtergestelde postcodes, voor wie het tijdslot in werkuren de barrière was).

De discovery adviseert tegen de app, en voor een alfa die zelfbediening bij opnieuw boeken onderzoekt plus een toetsing van het beleid voor tijdsloten. Het herkaderde probleem wordt door de sponsor overeengekomen, een klinischeveiligheidsfunctionaris wordt benoemd voor de alfa en een gegevensbeschermingseffectbeoordeling wordt opgedragen. Het ICS heeft acht weken besteed en vermeed een oplossing te financieren die in het openbaar meetbaar zou hebben gefaald.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid voert discovery uit met kleine middelen en tegen de klok — vaak is de “discovery” de eigen geleefde ervaring van de oprichters plus twee weken gebruikersinterviews geperst tussen investeerdersvergaderingen. De financieringsdruk is tractie te tonen, wat oprichters verleidt rechtstreeks naar een demo te springen; de discipline die het meest telt is de riskantste aanname te noemen en het idee goedkoop te doden als zij faalt, omdat een startup het zich niet kan veroorloven zelfs eenmaal het verkeerde te bouwen. Verantwoording loopt naar investeerders en early adopters in plaats van een wettelijk bestuur, dus stopvoorwaarden zijn commercieel (geen betalingsbereidheid, geen bereikbare markt) evenzeer als klinisch. Het voordeel is snelheid en de vrijheid om te pivoteren; het risico is een overtuigend verhaal van een oprichter aan te zien voor bewijs van een echte gebruikersbehoefte.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis, een thuiszorgorganisatie, een kliniek met één vestiging of een kleine leverancier van gezondheidstechnologie voorbij het stadium zonder omzet — heeft echte patiënten en lopende operaties, maar zelden een reserve gebruikersonderzoeker of servicedesigner om een formele discovery te bemensen. Discovery is hier licht en opportunistisch: het “onderzoek” is de baliemedewerker die al weet waarom patiënten niet door kunnen komen aan de telefoon, de zorgmedewerkers die dagelijks de dubbele administratie zien en een handvol bewuste gesprekken met de gebruikers die een verandering zou raken. De valkuil is dat dezelfde wettelijke plichten — Caldicott, UK GDPR, de gelijkheidsplicht, klinische veiligheid — in volle omvang gelden ongeacht of er intern iemand is die ze bezit, dus de discipline die het meest telt is het probleem eerlijk te kaderen en de riskantste aanname te toetsen voordat schaarse middelen worden vastgelegd in het product van een leverancier. Omdat de lopende operatie niet kan pauzeren, voert een kleine aanbieder haar discovery vaak uit rond één concreet pijnpunt in plaats van een brede probleemruimte, en haar waardevolste stopvoorwaarde is herkennen wanneer de oplossing een procesverandering of een gedeeld regionaal platform is en geen systeem om te kopen.

Grote onderneming#

Een NHS-ziekenhuis of grote leverancier van gezondheidstechnologie kan een echte multidisciplinaire discovery bemensen — gebruikersonderzoekers, servicedesigners, klinische veiligheid, informatiebeheer — maar moet vechten tegen organisatorische zwaartekracht: een zittend leverancierscontract, een bestuur dat “de app” al heeft aangekondigd of een businesscase die de oplossing vooraf bepaalde. Hier is het zwaarste werk van discovery politiek — een goedgekeurde oplossing terugkaderen tot een gebruikersbehoefte zonder de steun van de sponsor te verliezen. Financiering is jaarlijks en aan commissies gebonden, dus discoveries concurreren om plekken en moeten artefacten opleveren die voor het bestuur leesbaar zijn. De risicobereidheid is laag en de verantwoording breed (toezichthouders, auditors, het publiek), wat een eerlijk “niet doorgaan” zowel waardevoller als moeilijker hardop te zeggen maakt.

Overheid#

Een nationaal of lokaal publiek orgaan — NHS England, DHSC, een gedecentraliseerde overheid, een lokale overheid — voert discovery uit onder het volle gewicht van de Service Standard, poorten voor uitgavenbeheersing en publieke toetsing, waar het discoveryrapport zelf kan worden gepubliceerd en betwist. De gebruikersbasis is enorm en de plicht de gemarginaliseerden te includeren is een wettelijke, geen optionele kwestie, dus inclusieve werving en begeleide digitale routes zijn vanaf de eerste week verplicht. Verantwoording loopt naar ministers, het Parlement en het electoraat, dus een discovery moet in het openbaar verdedigbaar zijn en kan door uitgavenbeheersing worden stopgezet wanneer het bewijs zwak is. De afweging is strengheid versus tempo: discovery bij de overheid is trager en meer geborgd, wat publiek geld beschermt maar teams kan frustreren die gewend zijn snel te bewegen.

Veelvoorkomende faalpatronen#

• Te vroeg oplossen. Het team begint discovery met het antwoord al gekozen en besteedt de weken aan het bouwen van een businesscase ervoor. Tegengif: verban oplossingsnamen uit de probleemstelling; maak de riskantste aanname een onderzoeksvraag.
• Onderzoekstheater. Enkele vriendelijke belanghebbenden worden geraadpleegd, moeilijk bereikbare gebruikers worden “vanwege tijd” overgeslagen en de bevindingen bevestigen gemakshalve het plan. Tegengif: werf voor de randen; laat onderzoeksbevindingen door iemand buiten het team betwisten.
• De discovery die geen nee kan zeggen. Financiering, politiek of een getekend contract maken “niet doorgaan” onzegbaar, zodat discovery ritueel wordt. Tegengif: spreek vooraf stopvoorwaarden af en bescherm de onafhankelijkheid van de onderzoeker.
• De oceaan koken. Een onbegrensde discovery drijft maandenlang rond, brengt alles in kaart en beslist niets. Tegengif: een harde tijdbegrenzing en een benoemde beslissing aan het eind.
• De niet-digitale dienst negeren. Het team bestudeert het scherm en mist de telefoonlijn, de brief en de baliemedewerker die het traject werkelijk dragen. Tegengif: breng alle kanalen en organisaties van begin tot eind in kaart.
• Toegankelijkheid en inclusie als later behandelen. Randgebruikers worden uitgesteld tot bèta, wanneer de architectuur hen al uitsluit. Tegengif: werf inclusief en test vanaf het eerste prototype tegen WCAG.

Volwassenheidsmodel#

Checklist#

• Er is een schriftelijke probleemstelling die een gebruikersbehoefte noemt, geen oplossing.
• Echte gebruikers — inclusief de moeilijkst bereikbaren — zijn in context geïnterviewd of geobserveerd.
• De dienst van begin tot eind is in kaart gebracht over alle kanalen en organisaties.
• De riskantste aannames zijn opgesomd, gerangschikt en de belangrijkste getoetst.
• Risico’s voor klinische veiligheid, informatiebeheer (Caldicott, UK GDPR/DPIA) en gezondheidsongelijkheid zijn geïdentificeerd.
• Toegankelijkheid (WCAG 2.2 AA) en digitale inclusie worden vanaf het eerste prototype overwogen.
• Stopvoorwaarden zijn aan het begin overeengekomen, en “niet doorgaan” is een echte mogelijke uitkomst.
• De kans is afgebakend en de aanbeveling is verdedigbaar tegenover een financieringsbestuur.
• Een multidisciplinair team (inclusief inbreng van klinische zijde/informatiebeheer) voerde de fase uit binnen een vaste tijdbegrenzing.
• De sponsor is akkoord gegaan met de probleemstelling voordat enige alfa begint.

Belangrijkste bronnen#

• NHS England — NHS Digital Service Manual en NHS Service Standard (service.nhs.uk).
• GOV.UK Service Manual — “How the discovery phase works” en de Government Service Standard (Government Digital Service).
• Design Council — het ontwerpprocesraamwerk The Double Diamond.
• NHS England — Digital Technology Assessment Criteria (DTAC): klinische veiligheid, gegevensbescherming, technische borging, interoperabiliteit, bruikbaarheid en toegankelijkheid.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C; en GOV.UK-richtlijnen over toegankelijkheid en begeleid digitaal.
• Britse Caldicott-beginselen en de Data Protection Act 2018 / UK GDPR (gegevensbeschermingseffectbeoordelingen).
• Equality Act 2010 — de publieke gelijkheidsplicht (relevant voor beoordeling van gezondheidsongelijkheid in discovery).

Referenties#

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