Nous avons mis en avant Microsoft Clarity comme un produit conçu pour répondre à des cas d'utilisation concrets, par des experts produits qui comprennent les défis rencontrés par des entreprises comme Switas. Des fonctionnalités telles que la détection des clics indésirables et le suivi des erreurs JavaScript se sont révélées précieuses pour identifier les frustrations des utilisateurs et les problèmes techniques, permettant ainsi des améliorations ciblées qui ont eu un impact direct sur l'expérience utilisateur et les taux de conversion.
Sprint Design
Un sprint de conception est un processus à durée limitée, initialement structuré sur cinq jours, permettant de passer d'un problème à un prototype testé. Développé chez Google Ventures et documenté par Jake Knapp, il condense en une seule semaine des activités qui prendraient autrement des mois : comprendre le problème, générer des solutions, définir une orientation, construire un prototype réaliste et le tester auprès des utilisateurs cibles.
La structure initiale prévoit une activité par jour. Le premier jour est consacré à la définition du problème et au choix d'une cible. Le deuxième jour est dédié à la génération de solutions individuelles, plutôt qu'au brainstorming en groupe, partant du principe que le travail individuel produit des idées plus riches et variées qu'une discussion ouverte, où la voix la plus forte l'emporte. Le troisième jour, par le biais d'une critique structurée et d'un vote, détermine les concepts à prototyper. Le quatrième jour consiste à construire un prototype suffisamment réaliste pour être testé, sans aller plus loin. Le cinquième jour, les tests sont effectués auprès d'un petit groupe d'utilisateurs cibles, généralement cinq, et une décision est prise.
Sa valeur réside moins dans le calendrier précis que dans les contraintes qu'il impose. Dédier une équipe pluridisciplinaire, incluant un décideur, à un problème donné pendant une période déterminée élimine les délais de coordination qui, habituellement, étalent ce type de travail sur plusieurs mois. Exiger un prototype testé en fin de projet favorise la concrétisation, car les discussions abstraites ne peuvent résister à l'obligation de présenter un prototype au client le vendredi. Enfin, la présence du décideur tout au long du projet évite le scénario fréquent où une semaine de travail fructueux est anéantie par l'objection tardive d'un cadre absent.
Ce format n'est pas universellement applicable et son utilisation comme outil généraliste est source de déception. Il convient aux problèmes importants, suffisamment circonscrits pour être traités en une semaine, et véritablement incertains, pour lesquels l'équipe est en désaccord ou ignore la réponse. Il est mal adapté aux problèmes déjà compris et nécessitant simplement une mise en œuvre, aux problèmes exigeant des recherches approfondies pour être appréhendés, et aux problèmes dont la solution repose sur un travail technique impossible à prototyper de manière convaincante en une journée.
La pratique a considérablement divergé du format original de cinq jours, les variantes de quatre jours et à distance étant désormais courantes, et des versions plus courtes étant utilisées pour des problématiques plus spécifiques. Ces adaptations sont pertinentes, à condition que les éléments essentiels soient préservés : un problème clairement défini, les bons participants, dont une personne décisionnaire, une phase d’idéation individuelle avant la discussion de groupe, un prototype concret et des tests auprès d’utilisateurs réels plutôt qu’avec des collègues. Les sprints qui omettent les tests utilisateurs conservent l’atelier et perdent tout leur intérêt.
Le choix des participants est plus crucial que le planning et est souvent négligé. Un sprint avec les mauvaises personnes aboutit à une semaine bien encadrée mais sans résultat concret : sans décideur, la recommandation se retrouve dans la file d'attente habituelle des approbations ; sans représentation technique, le prototype explore une piste qui s'avère irréalisable ; sans témoin des besoins clients, le groupe conçoit à partir d'hypothèses. L'équipe idéale comprend cinq à sept personnes couvrant les aspects décisionnels, conception, ingénierie et connaissance client. Garantir leur disponibilité réelle pendant toute la durée du sprint, et non une présence partielle entre deux engagements, est généralement la partie la plus difficile de son organisation.
La déception la plus fréquente est de considérer le sprint comme un livrable plutôt que comme le point de départ d'un travail. Le résultat est une orientation validée ou invalidée et un ensemble d'observations, et non une conception finale. Sa valeur n'est perçue que si ce résultat alimente le développement ultérieur. Concrètement, cela signifie intégrer les sprints à un processus continu plutôt que de les considérer comme des événements isolés, dont le résultat est ensuite exploité. la conception des produits et les travaux de livraison dans un studio de produits engagement, et avec des tests effectués selon les normes de recherche d'utilisateurs plutôt que comme une présentation informelle.
Switas vu sur
