Sujet 3.4 — Phases de découverte

En une phrase : La découverte est l'effort discipliné et limité dans le temps pour comprendre vos utilisateurs et le véritable problème avant d'engager de l'argent, du risque clinique, ou de la réputation à construire une solution.

Pourquoi c'est important dans la santé et l'action sociale#

Dans la plupart des secteurs, construire la mauvaise chose gaspille de l'argent. Dans la santé et l'action sociale, cela peut aussi gaspiller du temps clinique, ancrer les inégalités de santé, et — à l'extrême — nuire aux patients. Un service numérique qui suppose que chaque utilisateur a un smartphone, un haut débit fiable, et un anglais confiant exclut discrètement les fragiles, les pauvres, et les marginalisés numériquement : précisément les personnes que le NHS et l'action sociale existent pour servir. La découverte est là où vous le découvrez pour le prix de quelques semaines de recherche, plutôt qu'après un déploiement national.

Les dépenses de santé et d'action sociale sont de l'argent public détenu en fiducie, et une grande partie circule à travers des obligations statutaires : la NHS Constitution, l'obligation d'égalité du secteur public au titre de l'Equality Act 2010, et les principes Caldicott pour traiter les informations confidentielles des patients. La découverte est la phase où vous testez si un service proposé est nécessaire, légal, sûr, et équitable — avant que ces questions ne deviennent coûteuses à répondre. La sauter ne supprime pas les questions ; elle les reporte simplement à un point où la réponse honnête est politiquement impossible à accepter.

Le NHS Digital Service Standard et le GOV.UK Service Manual font tous deux de la découverte la première phase obligatoire de tout service numérique orienté utilisateur précisément pour cette raison. Ce n'est pas du théâtre bureaucratique. C'est l'assurance la moins chère que vous achèterez jamais.

Concepts fondamentaux#

La découverte, définie. La découverte est une phase courte (typiquement 6 à 10 semaines) dont l'objectif est de comprendre un espace de problème : qui sont les utilisateurs, ce qu'ils essaient de faire, ce qui les arrête, ce qui existe déjà, et s'il y a un problème qui vaut la peine d'être résolu du tout. Son résultat est la compréhension et la preuve, pas un produit. Une bonne découverte peut valablement conclure « ne rien faire » ou « c'est un problème de politique, pas un problème numérique ».

Le double diamant. Le double diamant (2005) du Design Council cadre la conception comme deux diamants liés. Le premier — Découvrir puis Définir — diverge pour explorer largement le problème, puis converge pour le cadrer précisément. Le second — Développer puis Livrer — diverge pour explorer des solutions, puis converge pour en construire une. La découverte, en tant que phase de livraison, vit presque entièrement dans le premier diamant. L'échec récurrent est que les équipes se précipitent dans le second diamant avant que le premier ne soit terminé.

Besoin utilisateur versus souhait de partie prenante. Un besoin utilisateur est quelque chose qu'une personne essaie d'accomplir, exprimé de son point de vue (« j'ai besoin de savoir que mon rendez-vous est confirmé pour ne pas prendre un jour de congé pour rien »). Un souhait de partie prenante est une fonctionnalité ou solution que quelqu'un a déjà décidée (« nous avons besoin d'une application »). La discipline centrale de la découverte est de retraduire les souhaits en besoins, car les besoins sont stables et les solutions sont bon marché et interchangeables une fois le besoin clarifié.

Cadrage du problème. Comment vous énoncez un problème contraint chaque solution que vous considérerez. « Les patients manquent des rendez-vous » invite une application de rappel. « Les patients ne peuvent pas facilement réorganiser des rendez-vous qui ne leur conviennent plus » invite la reréservation en libre-service. Même symptôme, problème différent, service radicalement différent. La découverte gagne sa place largement dans la qualité de l'énoncé de problème qu'elle produit.

Hypothèses, hypothèses de recherche, et preuves. Chaque projet repose sur des hypothèses. La découverte les rend explicites, les classe par risque, et teste les plus risquées avec de vrais utilisateurs. L'objectif n'est pas la certitude — elle est inatteignable — mais une incertitude réduite sur les choses qui couleraient le projet.

Bonnes pratiques#

1. Commencez par un problème, pas une solution. Écrivez l'énoncé du problème avant que quiconque ne nomme une technologie. Si l'offre de financement, le document du conseil d'administration, ou le pitch du fournisseur spécifie déjà « une application » ou « un portail », traitez cela comme une hypothèse à tester, pas une décision à implémenter. Les solutions arrivées avant que le problème ne soit compris sont presque toujours l'habitude de quelqu'un, pas le besoin de l'utilisateur.

2. Menez une véritable recherche utilisateur avec de vrais utilisateurs. Interviewez et observez les personnes réelles qui utiliseront le service — patients, aidants, réceptionnistes, infirmières communautaires, travailleurs sociaux — dans leur contexte réel, pas un atelier de gestionnaires parlant en leur nom. Visez la profondeur plutôt que le volume ; une douzaine d'entretiens contextuels bien choisis révèlent plus qu'une enquête à mille réponses. Recrutez délibérément pour les utilisateurs les plus difficiles à atteindre, car ce sont eux qu'un service échoue le plus souvent.

3. Cartographiez le service entier, pas la tranche numérique. Les utilisateurs vivent un service de bout en bout — une orientation, une évaluation, un traitement, un suivi — dont votre composant numérique est une étape. Cartographiez le parcours actuel à travers chaque canal et organisation, y compris les parties papier, téléphone, et face à face. Les changements numériques échouent régulièrement parce qu'ils optimisent une étape et cassent les deux de chaque côté.

4. Cadrez le problème explicitement et faites-le convenir. Produisez un énoncé de problème écrit et la preuve qui le sous-tend, et obtenez l'accord explicite de votre sponsor senior. Cet artefact est votre contrat : il définit ce que signifie « terminé » pour les phases suivantes et vous donne la position pour dire non à un périmètre qui ne sert pas le problème convenu.

5. Dimensionnez l'opportunité et le risque honnêtement. Estimez combien de personnes sont affectées, à quel point, et ce que cela coûte au système aujourd'hui. Associez cela aux risques qu'une solution introduirait — clinique, gouvernance de l'information, équité, livraison. Les dirigeants financent des découvertes ; ils décident sur la base d'une image défendable d'opportunité et de risque, donc donnez-leur en une.

6. Concevez pour les marges dès le premier jour. Recrutez des participants de recherche à travers le spectre d'inclusion numérique, testez contre les attentes des Web Content Accessibility Guidelines (WCAG 2.2 AA) tôt, et traitez les voies numériques assistées et hors ligne comme de premier ordre, pas des réflexions après coup. Dans la santé et l'action sociale, l'utilisateur exclu est souvent l'utilisateur à besoin élevé ; un service qui ne fonctionne que pour les confiants et connectés élargit l'inégalité.

7. Gardez-le transversal et limité dans le temps. Dotez la découverte d'un chercheur utilisateur, d'un concepteur de services, d'une personne produit, d'un architecte technique, et — pour tout ce qui touche aux soins — d'une contribution clinique et de gouvernance de l'information. Limitez-la strictement dans le temps (semaines, pas trimestres) pour forcer la convergence. Une découverte à durée ouverte est un signal d'alerte que l'équipe évite une décision.

8. Écrivez ce qui vous ferait arrêter. Convenez, au départ, des conditions dans lesquelles la recommandation honnête serait « ne pas procéder » : aucun véritable besoin utilisateur, une barrière de gouvernance de l'information ou de sécurité insurmontable, un meilleur correctif non numérique, ou un problème possédé par une autre équipe. Une découverte qui ne peut pas recommander l'arrêt n'est pas une découverte ; c'est une construction pré-justifiée.

Questions à discuter avec votre équipe#

1. Que devrions-nous voir en découverte pour recommander honnêtement « ne pas procéder », et quelqu'un dans cette pièce a-t-il la position pour le dire ? Les conditions d'arrêt ne valent rien si elles ne peuvent pas être exercées, et dans la santé et l'action sociale, la pression pour ne pas les exercer est intense : un directeur a annoncé l'application, un contrat fournisseur est à moitié signé, ou une fenêtre de financement se ferme si l'équipe hésite. Cette question force une équipe à nommer la preuve spécifique — aucun véritable besoin utilisateur, une barrière de gouvernance de l'information ou de sécurité clinique insurmontable, un meilleur correctif non numérique, un problème possédé par un autre service — qui basculerait la recommandation vers l'arrêt, et à l'écrire avant que la recherche ne commence afin qu'elle ne puisse pas être discrètement redéfinie plus tard. La tension qui vaut la peine d'être débattue est entre la confiance du sponsor et l'indépendance du chercheur : une découverte qui structurellement ne peut pas dire non est une construction pré-justifiée portant les habits de la découverte. Considérez qui protège les conclusions du chercheur de l'édition, si un étranger révise la preuve, et quelle était la dernière découverte que votre organisation a réellement arrêtée — s'il n'y en a pas, c'est en soi une conclusion. Une réponse honnête identifie les véritables raisons pour lesquelles « non » est difficile ici et un mécanisme concret (critères d'arrêt convenus, un défi indépendant, un sponsor qui a publiquement béni la possibilité d'arrêter) qui le rend dicible.

2. Qui sont les utilisateurs que nous sommes le plus susceptibles d'exclure, et comment les intégrerons-nous dans la recherche plutôt que de les reporter à la bêta ? Dans la santé et l'action sociale, l'utilisateur exclu — le fragile, le marginalisé numériquement, la personne à faible confiance en anglais, l'aidant jonglant avec trois systèmes — est de manière disproportionnée l'utilisateur à besoin élevé que le service existe pour servir, donc échantillonner pour la commodité conçoit discrètement l'inégalité dans l'architecture. Le compromis à débattre est la profondeur et l'inclusion contre le calendrier et le coût de recrutement : atteindre les plus difficiles à atteindre prend du temps, des partenaires communautaires, des incitations, et des méthodes de recherche assistées ou hors ligne qu'une découverte précipitée est tentée de sauter « pour l'instant ». Les angles concrets incluent cartographier explicitement le spectre d'inclusion numérique, recruter via des gardiens du secteur bénévole et clinique plutôt qu'une liste de diffusion, et traiter les voies numériques assistées et non numériques comme des conclusions de premier ordre plutôt que des réflexions après coup. Il vaut la peine de nommer l'obligation d'égalité du secteur public et le contexte Caldicott afin que l'inclusion soit comprise comme une obligation légale et éthique, pas une gentillesse. Une bonne réponse produit un plan de recrutement nommé qui sur-échantillonne délibérément les marges, et une déclaration claire de quels utilisateurs l'équipe traitera comme le centre de gravité de la conception.

3. Avons-nous cadré un problème, ou avons-nous glissé une solution en contrebande dans l'énoncé du problème ? Comment un problème est énoncé contraint silencieusement chaque solution que l'équipe considérera — « les patients oublient les rendez-vous » invite une application de rappel, tandis que « les patients ne peuvent pas facilement réorganiser des rendez-vous qui ne leur conviennent plus » invite la reréservation en libre-service et une révision de la politique de créneaux — donc la formulation de l'énoncé du problème est là où la découverte gagne la plupart de sa place. Le débat est de savoir si l'offre de financement, le document du conseil d'administration, ou le pitch du fournisseur a déjà fixé la réponse (« une application », « un portail », « un outil de triage par IA ») et l'a habillée en besoin, et si l'équipe a la discipline de retraduire ce souhait en l'objectif utilisateur sous-jacent. Les angles utiles incluent l'interdiction des noms de solutions dans l'énoncé du problème, la cartographie du service entier de bout en bout à travers chaque canal et organisation afin que la tranche numérique soit vue en contexte, et la vérification que chaque besoin énoncé est exprimé du point de vue de l'utilisateur plutôt que de l'organisation. La preuve compte ici : un cadrage devrait être traçable à ce que de vrais utilisateurs ont dit et fait, pas à une habitude ou une diapositive de stratégie. Une réponse honnête confirme soit que l'énoncé nomme un besoin utilisateur stable avec des preuves derrière, soit admet qu'une solution a été supposée et rouvre le cadrage avant qu'un alpha ne soit cadré.

4. Avons-nous les bonnes disciplines dans la pièce, et la sécurité clinique et la gouvernance de l'information façonnent-elles le travail plutôt que de le valider à la fin ? Une découverte dotée seulement d'un chef de produit et d'un responsable de livraison trouvera des problèmes de produit et de livraison ; les utilisateurs, cliniciens, et obligations légales qu'elle n'invite jamais dans la pièce deviennent les risques qui émergent coûteusement en alpha ou, pire, après la mise en production. La tension est qu'une équipe véritablement transversale — chercheur utilisateur, concepteur de services, architecte technique, responsable de sécurité clinique, expertise en gouvernance de l'information et Caldicott — est rare, disputée, et lente à réunir, donc les équipes sont tentées d' « emprunter » un clinicien pour une heure ou d'ajouter la gouvernance de l'information comme porte finale. Ce séquençage est le piège : la sécurité clinique et la gouvernance de l'information sont bon marché à concevoir pendant le cadrage et ruineusement coûteuses à adapter ultérieurement une fois qu'une architecture suppose que les données circuleront à travers les frontières organisationnelles. Les angles concrets incluent nommer un responsable de sécurité clinique dès la première semaine pour tout ce qui touche aux soins, traiter une évaluation d'impact relative à la protection des données comme un artefact de découverte vivant plutôt qu'une formalité ultérieure, et vérifier si les personnes qui comprennent le flux de travail de première ligne sont des contributeurs ou simplement des consultés. Une réponse honnête nomme qui est réellement dans l'équipe, quelles obligations sont représentées par une personne versus une case à cocher, et où la découverte serait aveugle parce qu'une discipline manque.

5. Comment saurons-nous que la découverte est terminée, et qu'est-ce qui l'empêche de dériver pendant des mois ou d'être coupée après quinze jours ? La découverte a deux modes d'échec opposés et les deux concernent le temps : l'étude illimitée qui cartographie tout et ne décide rien, et la quinzaine tronquée qui se précipite vers une conclusion prédéterminée parce qu'une date de livraison a été fixée avant que la recherche ne commence. La discipline que le double diamant exige est la convergence — savoir quand le problème est assez compris pour prendre une décision défendable, pas quand chaque question a reçu une réponse, car la certitude est inatteignable et l'objectif est une incertitude réduite sur les choses qui couleraient le projet. Le compromis qui vaut la peine d'être débattu est la profondeur contre l'élan : une limite de temps stricte de quelques semaines force l'équipe à prioriser les hypothèses les plus risquées, mais une limite fixée trop serrée affame la recherche inclusive et difficile à atteindre dont ce domaine a le plus besoin. Les angles utiles incluent convenir de la décision que la découverte doit informer et des artefacts dont un sponsor a besoin pour la prendre, classer les hypothèses afin que la limite soit dépensée sur ce qui compte, et nommer un point de décision plutôt que de laisser la phase se prolonger dans un alpha non reconnu. Une réponse honnête énonce combien de temps dure la limite, à quoi ressemble « suffisamment compris » pour ce problème, et qui appelle la fin.

6. Lorsque la découverte se termine, pouvons-nous remettre à un comité de financement une image défendable de l'opportunité et du risque — ou seulement une histoire ? Les dirigeants ne financent pas la compréhension ; ils financent des décisions, et une découverte qui produit un aperçu riche mais aucun compte lisible pour le conseil d'administration sur combien de personnes sont affectées, à quel point, ce que cela coûte au système aujourd'hui, et ce qu'une solution mettrait en péril, laisse la décision à quiconque raconte l'histoire la plus confiante. La tension est entre les conclusions nuancées et mises en garde du chercheur et le besoin du conseil d'administration pour un dossier dimensionné, comparable, et défendable — compressez trop fort et vous perdez les subtilités d'équité et de sécurité qui étaient le point ; refusez de compresser et la preuve n'atteint jamais les personnes qui allouent l'argent. Dans la santé et l'action sociale, l'image doit associer l'opportunité aux risques qu'une solution introduit — clinique, gouvernance de l'information, équité, livraison — car un conseil d'administration qui ne voit que le potentiel positif est en train d'être préparé à faire un mauvais pari. Les angles concrets incluent dimensionner la population affectée à partir de vraies données plutôt qu'une estimation optimiste, rendre les conclusions traçables afin qu'un sceptique puisse les retracer à ce que les utilisateurs ont dit, et cadrer la recommandation (y compris « ne pas procéder » ou « faire un alpha de cette chose plus étroite ») en termes sur lesquels la prochaine phase peut agir. Une réponse honnête montre que l'équipe peut passer de la preuve à une recommandation qu'un comité de financement pourrait scruter en public sans qu'elle ne s'effondre.

En pratique : un exemple de santé et d'action sociale#

Un integrated care system (ICS) est sous pression pour réduire les taux de non-présentation (DNA) aux cliniques de consultations externes. Un fournisseur a proposé une application de rappel alimentée par l'IA, et un directeur est impatient de la financer. Au lieu d'acheter, l'ICS mène une découverte de huit semaines.

Le chercheur utilisateur interviewe dix-huit patients qui ont récemment manqué des rendez-vous, plus des réceptionnistes et deux gestionnaires de clinique. Un schéma émerge que la théorie du rappel a manqué : de nombreuses « non-présentations » avaient essayé de réorganiser mais avaient heurté une ligne téléphonique occupée pendant des jours, ou avaient reçu un rendez-vous pendant les heures de travail qu'elles ne pouvaient pas prendre sans perdre leur salaire. Un sous-ensemble était décédé ou avait été admis ailleurs et était toujours sur la liste. Les rappels ne toucheraient aucune de ces causes.

L'équipe cartographie le parcours de réservation de bout en bout et trouve trois organisations, deux systèmes d'administration des patients, et un fax dans la boucle. Elle recadre le problème de « les patients oublient les rendez-vous » à « les patients ne peuvent pas facilement nous joindre pour réorganiser des rendez-vous qui ne fonctionnent plus pour eux ». Elle le quantifie : environ 40 % des DNA dans les cliniques échantillonnées impliquaient une tentative de contact préalable échouée. Elle signale une question de gouvernance de l'information (un outil de reréservation partagé traverserait les frontières organisationnelles) et une conclusion d'équité (les taux de DNA les plus élevés étaient parmi les patients des codes postaux les plus défavorisés, pour qui le créneau en heures de travail était la barrière).

La découverte recommande contre l'application, et pour un alpha explorant la reréservation en libre-service plus une révision de la politique de planification des créneaux. Le problème recadré est convenu par le sponsor, un responsable de sécurité clinique est nommé pour l'alpha, et une évaluation d'impact relative à la protection des données est commandée. L'ICS a dépensé huit semaines et évité de financer une solution qui aurait échoué de manière mesurable en public.

Angles sectoriels#

Startup#

Une startup de santé numérique mène la découverte avec un budget serré et contre la montre — souvent la « découverte » est la propre expérience vécue des fondateurs plus une quinzaine d'entretiens utilisateurs coincés entre des réunions d'investisseurs. La pression de financement est de montrer une traction, ce qui tente les fondateurs de sauter directement à une démo ; la discipline qui compte le plus est de nommer l'hypothèse la plus risquée et de tuer l'idée à moindre coût si elle échoue, car une startup ne peut pas se permettre de construire la mauvaise chose même une seule fois. La responsabilité s'exerce envers les investisseurs et les adopteurs précoces plutôt qu'un conseil d'administration statutaire, donc les conditions d'arrêt sont commerciales (aucune volonté de payer, aucun marché atteignable) autant que cliniques. L'avantage est la vitesse et la liberté de pivoter ; le risque est de confondre un récit convaincant du fondateur avec une preuve d'un véritable besoin utilisateur.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une agence de soins à domicile, une clinique monosite, ou un petit fournisseur de health-tech ayant dépassé le stade pré-revenu — a de vrais patients et des opérations en cours, mais rarement un chercheur utilisateur ou concepteur de services de réserve pour doter une découverte formelle. Ici, la découverte est légère et opportuniste : la « recherche » est la réceptionniste qui sait déjà pourquoi les patients ne peuvent pas joindre par téléphone, les travailleurs de soins qui voient quotidiennement la duplication de paperasse, et une poignée de conversations délibérées avec les utilisateurs qu'un changement affecterait. Le piège est que les mêmes obligations statutaires — Caldicott, UK GDPR, l'obligation d'égalité, la sécurité clinique — s'appliquent pleinement qu'il y ait ou non quelqu'un en interne qui les possède, donc la discipline qui compte le plus est de cadrer le problème honnêtement et de tester l'hypothèse la plus risquée avant d'engager de l'argent rare dans le produit d'un fournisseur. Parce que les opérations en cours ne peuvent pas s'arrêter, un petit prestataire mène souvent sa découverte autour d'un seul point de douleur concret plutôt qu'un large espace de problème, et sa condition d'arrêt la plus précieuse est de reconnaître quand le correctif est un changement de processus ou une plateforme régionale partagée plutôt qu'un système à acheter.

Entreprise#

Un trust du NHS ou un grand fournisseur de health-tech peut doter une véritable découverte transversale — chercheurs utilisateurs, concepteurs de services, sécurité clinique, gouvernance de l'information — mais doit combattre la gravité organisationnelle : un contrat fournisseur en place, un conseil d'administration qui a déjà annoncé « l'application », ou un dossier commercial qui a prédécidé la solution. Ici, le travail le plus difficile de la découverte est politique — recadrer une solution sanctionnée en un besoin utilisateur sans perdre le soutien du sponsor. Le financement est annuel et lié à un comité, donc les découvertes se disputent des créneaux et doivent produire des artefacts lisibles pour le conseil d'administration. L'appétit pour le risque est faible et la responsabilité large (régulateurs, auditeurs, public), ce qui rend un « ne pas procéder » honnête à la fois plus précieux et plus difficile à dire à voix haute.

Gouvernement#

Un organisme public national ou local — NHS England, DHSC, un gouvernement décentralisé, une autorité locale — mène la découverte sous le poids complet du Service Standard, des portes de contrôle des dépenses, et de l'examen public, où le rapport de découverte lui-même peut être publié et contesté. La base d'utilisateurs est énorme et l'obligation d'inclure les marginalisés est une préoccupation légale, pas optionnelle, donc le recrutement inclusif et les voies numériques assistées sont obligatoires dès la première semaine. La responsabilité s'exerce envers les ministres, le Parlement, et l'électorat, donc une découverte doit être défendable en public et peut être arrêtée par des contrôles de dépenses lorsque la preuve est faible. Le compromis est la rigueur contre le rythme : la découverte gouvernementale est plus lente et plus assurée, ce qui protège l'argent public mais peut frustrer des équipes habituées à aller vite.

Modes d'échec courants#

• Solutionner trop tôt. L'équipe entre en découverte avec la réponse déjà choisie et passe les semaines à construire un dossier commercial pour elle. Antidote : interdire les noms de solutions dans l'énoncé du problème ; faire de l'hypothèse la plus risquée une question de recherche.
• Théâtre de la recherche. Quelques parties prenantes amicales sont consultées, les utilisateurs difficiles à atteindre sont sautés « par manque de temps », et les conclusions confirment commodément le plan. Antidote : recruter pour les marges ; faire contester les conclusions de recherche par quelqu'un en dehors de l'équipe.
• La découverte qui ne peut pas dire non. Le financement, la politique, ou un contrat signé rendent « ne pas procéder » indicible, donc la découverte devient un rituel. Antidote : convenir des conditions d'arrêt en amont et protéger l'indépendance du chercheur.
• Faire bouillir l'océan. Une découverte illimitée dérive pendant des mois, cartographiant tout et ne décidant rien. Antidote : une limite de temps stricte et une décision nommée à la fin.
• Ignorer le service non numérique. L'équipe étudie l'écran et manque la ligne téléphonique, la lettre, et la réceptionniste qui portent réellement le parcours. Antidote : cartographier tous les canaux et organisations de bout en bout.
• Traiter l'accessibilité et l'inclusion comme pour plus tard. Les utilisateurs en marge sont reportés à la bêta, moment auquel l'architecture les exclut. Antidote : recruter de manière inclusive et tester contre WCAG dès le premier prototype.

Modèle de maturité#

Liste de contrôle#

• Il y a un énoncé de problème écrit qui nomme un besoin utilisateur, pas une solution.
• De vrais utilisateurs — y compris les plus difficiles à atteindre — ont été interviewés ou observés en contexte.
• Le service de bout en bout est cartographié à travers tous les canaux et organisations.
• Les hypothèses les plus risquées sont listées, classées, et les plus élevées testées.
• Les risques de sécurité clinique, de gouvernance de l'information (Caldicott, UK GDPR/DPIA), et d'inégalité de santé sont identifiés.
• L'accessibilité (WCAG 2.2 AA) et l'inclusion numérique sont considérées dès le premier prototype.
• Les conditions d'arrêt ont été convenues au départ, et « ne pas procéder » est un résultat réellement possible.
• L'opportunité est dimensionnée et la recommandation est défendable devant un comité de financement.
• Une équipe transversale (incluant une contribution clinique/de gouvernance de l'information) a mené la phase dans une limite de temps fixe.
• Le sponsor a convenu de l'énoncé du problème avant qu'un alpha ne commence.

Sources clés#

• NHS England — NHS Digital Service Manual and NHS Service Standard (service.nhs.uk).
• GOV.UK Service Manual — "How the discovery phase works" and the Government Service Standard (Government Digital Service).
• Design Council — The Double Diamond design process framework.
• NHS England — Digital Technology Assessment Criteria (DTAC): clinical safety, data protection, technical assurance, interoperability, usability and accessibility.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C; and GOV.UK guidance on accessibility and assisted digital.
• UK Caldicott Principles and the Data Protection Act 2018 / UK GDPR (data protection impact assessments).
• Equality Act 2010 — the public sector equality duty (relevant to health-inequality assessment in discovery).

Références#

1. Double Diamond (design process model) — Wikipédia — https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)
2. Design Council — Wikipédia — https://en.wikipedia.org/wiki/Design_Council
3. User research — Wikipédia — https://en.wikipedia.org/wiki/User_research
4. Contextual inquiry — Wikipédia — https://en.wikipedia.org/wiki/Contextual_inquiry
5. Problem statement — Wikipédia — https://en.wikipedia.org/wiki/Problem_statement
6. Web Content Accessibility Guidelines — Wikipédia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
7. Equality Act 2010 — Wikipédia — https://en.wikipedia.org/wiki/Equality_Act_2010
8. NHS Constitution for England — Wikipédia — https://en.wikipedia.org/wiki/NHS_Constitution_for_England
9. Digital divide — Wikipédia — https://en.wikipedia.org/wiki/Digital_divide
10. Privacy impact assessment (data protection impact assessment) — Wikipédia — 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