La plupart du travail de design produit repose sur un ensemble d'hypothèses si fondamentales qu'elles sont rarement examinées : les utilisateurs ont choisi d'utiliser votre produit, ils peuvent arrêter de l'utiliser s'il les frustre, et leur engagement ou leur départ vous dit quelque chose de significatif sur la qualité de votre design. Quand on conçoit pour une population d'utilisateurs captifs, aucune de ces hypothèses ne tient.
SQOOL a été déployé dans 465 lycées d'Île-de-France dans le cadre d'une initiative de la collectivité régionale. 300 000 appareils. Les élèves ont reçu des tablettes qu'ils n'avaient pas demandées, faisant tourner des logiciels qu'ils n'avaient pas choisis, dans un contexte (l'école) où leur capacité à se désengager de l'un ou l'autre était limitée. Les données d'engagement que nous collections ne nous apprenaient presque rien d'utile. Une utilisation élevée d'une fonctionnalité pouvait signifier que les élèves la trouvaient utile ou que leur enseignant l'exigeait. Une faible utilisation pouvait signifier que la fonctionnalité était inutile ou simplement qu'elle ne faisait pas partie du flux de travail curriculaire de la semaine.
L'échec des boucles de rétroaction conventionnelles
Les mécanismes de rétroaction UX standards se désintègrent dans les contextes d'utilisateurs captifs. Les enquêtes NPS produisent des résultats qui reflètent l'attitude générale envers l'institution plutôt que le produit. « Dans quelle mesure recommanderiez-vous SQOOL à un ami ? » est une question à laquelle un élève qui en veut d'avoir une tablette scolaire imposée répondra sur la base de ce ressentiment, pas sur la base de son expérience avec une fonctionnalité particulière. Les retours volontaires dans l'application faussent vers les plus frustrés et les plus enthousiastes, deux populations non représentatives.
Les analytics étaient tout aussi peu fiables. Nous pouvions voir que les élèves passaient beaucoup de temps dans certaines applications. Nous ne pouvions pas déduire des données si ce temps était productif, frustrant ou simplement obligatoire. Un élève qui met vingt minutes à accomplir une tâche parce que l'interface est mal conçue et un élève qui met vingt minutes parce qu'il est genuinement impliqué dans le contenu produisent des signaux comportementaux identiques dans les analytics.
L'observation en classe comme méthode de recherche principale
L'approche de recherche sur laquelle j'ai convergé était l'observation en classe, associée à des conversations structurées avec les enseignants. Pas de tests d'utilisabilité en environnement contrôlé. Des séances de cours réelles, avec des élèves travaillant sur leurs tâches assignées et moi assis au fond de la salle avec un carnet.
Ce que l'observation en classe révèle qu'aucune autre méthode ne capture : les contournements. Les élèves qui ne peuvent pas accomplir une tâche de la manière prévue en trouvent une autre. Ils partagent des écrans, ils dictent à un camarade, ils photographient le contenu avec un téléphone personnel. Chaque contournement est un échec de design rendu visible. L'élève qui photographie l'écran parce que la fonction copier-coller est enfouie à trois niveaux dans un menu vous dit quelque chose sur l'architecture de l'information qu'un test d'utilisabilité ne révélerait que si vous testiez spécifiquement cette tâche.
Les enseignants étaient un type d'informateur différent. Ils observaient des patterns d'utilisation sur une classe de trente élèves, cinq jours par semaine, pendant des mois. Ils savaient quelles applications perdaient systématiquement l'attention d'une classe et lesquelles la retenaient. Ils avaient accumulé une connaissance opérationnelle des modes d'échec qu'aucun tableau de bord analytics ne pouvait répliquer. Le défi consistait à structurer les conversations pour que les enseignants partagent des spécificités opérationnelles plutôt que des impressions générales. « Les élèves ont du mal avec ça » est moins utile que « quand les élèves essaient de soumettre un devoir et que la connexion se coupe, ils ne savent pas si la soumission est passée, donc ils soumettent à nouveau et ont ensuite des doublons qui échouent ».
La fiabilité au premier essai comme contrainte de design principale
Dans le design de produit grand public, l'onboarding est une préoccupation de premier ordre. On investit dans l'expérience initiale parce que la décision de l'utilisateur de continuer à utiliser le produit ou de l'abandonner se joue dans les premières sessions. Dans un contexte scolaire, il n'y a pas de moment d'onboarding au sens grand public. La sonnerie retentit, l'enseignant donne une instruction, et les élèves sont censés exécuter immédiatement. Si l'interface nécessite une découverte, le temps de cours disparaît dans la confusion. Si un message d'erreur apparaît et que les élèves ne savent pas comment le résoudre, l'enseignant doit arrêter le cours.
Cette contrainte change considérablement le vocabulaire de design. La divulgation progressive, qui fonctionne bien dans les contextes grand public parce qu'elle réduit la charge cognitive initiale, devient un passif quand la fiabilité au premier essai est la contrainte principale. Chaque action importante doit être accessible sans connaissance préalable de la structure de l'interface. Les états d'erreur doivent être auto-résolutifs ou expliquer clairement ce que l'élève doit faire, car il n'y a pas de canal d'assistance dans une salle de classe.
Concevoir avec dignité quand le choix est retiré
La dimension éthique du design pour des utilisateurs captifs est réelle et mérite d'être explicitée. Les élèves qui utilisent SQOOL ne l'ont pas choisi. Ils sont dans un contexte coercitif (l'école) utilisant un produit mandaté par une institution (la collectivité régionale). Le design a l'obligation d'être respectueux de cette position : ne pas utiliser la relation captive pour collecter des données, surnotifier, ou créer des patterns d'engagement qui servent des métriques institutionnelles plutôt que les besoins des élèves.
En pratique, cela signifiait résister aux demandes d'ajout de suivi d'utilisation suffisamment granulaire pour constituer une surveillance, refuser d'implémenter des patterns de notification conçus pour maximiser les taux d'ouverture, et cadrer systématiquement le brief de design autour de ce qui facilitait le travail de l'élève plutôt que de ce qui rendait le reporting de l'administrateur plus propre. Ces conversations avec des parties prenantes soumises à des pressions de redevabilité institutionnelle n'étaient pas toujours faciles. Mais c'étaient les bonnes à tenir, et les ancrer dans la contrainte spécifique (utilisateurs captifs, pas de désengagement possible) les rendait plus abordables que des arguments abstraits sur l'éthique.