Un design sprint permet de poser une date limite et de tester concrètement une question produit complexe. Plutôt que de prolonger d'interminables débats sur la façon dont les gens pourraient réagir, une petite équipe conçoit une proposition d'expérience et observe de vrais utilisateurs la prendre en main. Résultat : des éléments concrets pour guider la décision suivante, tout en gardant à l'esprit les limites inhérentes au prototype et au test.
Le format en cinq jours popularisé par Jake Knapp et ses collègues est décrit dans l'introduction des auteurs de Sprint. De nombreuses équipes adaptent ce planning, mais raccourcir le calendrier n'enlève rien au travail nécessaire pour cerner le problème, recruter les bons participants ou analyser ce qui s'est passé.
Posez une question à laquelle la semaine peut vraiment répondre
Un sprint donne le meilleur de lui-même lorsqu'une incertitude majeure peut être explorée à travers une expérience concrète. Savoir si les clients comprennent une nouvelle façon de configurer un abonnement est un objectif tout à fait réaliste. Savoir si l'entreprise retiendra ces clients pendant un an ne peut pas être tranché par une semaine de tests sur prototype.
Rassemblez les données de recherche existantes et identifiez les zones d'ombre restantes. Dans le déroulé classique en cinq jours, l'équipe cartographie le défi, esquisse des alternatives, choisit une direction et crée un storyboard, conçoit un prototype, puis le teste. Les décisions deviennent de plus en plus concrètes au fil de l'eau, ce qui rend le cadrage initial primordial : une semaine parfaitement orchestrée peut très bien s'attaquer au mauvais problème.
Le recrutement doit commencer assez tôt pour toucher des personnes ayant l'expérience pertinente. Des questionnaires de sélection permettent de cibler ces profils plutôt que des personnes simplement disponibles. Si le public visé regroupe des profils très différents, prévoyez comment couvrir ces spécificités au lieu de supposer qu'un petit groupe représentera tout le monde.
Créez l'expérience nécessaire pour le test
Le prototype doit permettre de jouer des scénarios d'usage réalistes, en intégrant les informations dont les utilisateurs ont besoin pour prendre leurs décisions. Un bel enchaînement d'écrans qui ne fonctionne que si l'animateur explique chaque étape n'apprendra pas grand-chose sur l'utilisation en toute autonomie.
Pour une étude sur l'abonnement, par exemple, les participants pourraient choisir une formule adaptée à un foyer précis et expliquer les montants auxquels ils s'attendent. Leurs hésitations sur un plafond ou une condition de renouvellement sont bien plus riches d'enseignements qu'une simple question demandant s'ils apprécient le design. Les entretiens en direct de Ballpark facilitent ces sessions où le chercheur a besoin de rebondir sur ces moments précis.
Déterminez ce que ces apprentissages changent
Une petite série de tests qualitatifs permet de mettre en lumière des incompréhensions, des freins ou des signaux très prometteurs. En revanche, elle ne mesure pas un taux d'adhésion global sur le marché, et une session sans accroc ne prouve pas que l'expérience convient à tout le monde.
À la fin du sprint, séparez bien les faits observés des interprétations de l'équipe. Une explication de tarif confuse justifie peut-être un nouveau prototype ; une contrainte d'achat inattendue demandera plutôt une recherche exploratoire plus large. Désignez les responsables de ces prochaines étapes tant que les enseignements sont encore bien frais. Si vous ne prévoyez pas de temps pour exploiter ce qui a été appris, la date de fin du sprint ne sera rien d'autre que le jour où le prototype a été bouclé.