En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies pour vous proposer des offres adaptées à vos centres d'intérêt, recueillir des données de statistiques et permettre le partage de pages sur les réseaux sociaux.
  • Accueil
  • Blog
  • Le Design Sprint: 5 jours de l’idée à l’utilisateur.

Le Design Sprint: 5 jours de l’idée à l’utilisateur.

0%
Temps de lecture : 4 minutes

Le design sprint est un processus de 5 jours qui permet de répondre aux questions les plus critiques au travers le prototypage et l’itération avec les utilisateurs. Il permet de tester une idée en évitant de passer par les étapes chronophages de construction et mise en ligne d’un produit sur un marché.

Il ne s’agit pas de faire un tutoriel complet sur la méthode, mais bien de partager notre rétrospective; les avantages et inconvénients auxquels nos équipes ont pu être confrontés.

Contexte

D’après Wikipedia, la charge mentale, est un principe de sociologie traitant de la charge cognitive que représente, généralement, la gestion du foyer au quotidien pour la femme ou l’homme. Pixy, notre client souhaite s’attaquer à ce problème en développant une application collaborative qui aide les familles à mieux s’organiser, communiquer et se responsabiliser, pour libérer du temps de qualité à passer ensemble.

Problème

Nos clients avaient une liste importante de fonctionnalités à réaliser. Le développement de celles-ci allait prendre du temps et coûter cher. Nous ne savions pas quelle fonctionnalité serait la plus importante aux yeux des utilisateurs finaux. Aussi, avons nous décidé de réaliser un design sprint de 5 jours pour confronter nos hypothèses à un panel d’utilisateurs.

Les participants

Pour nos besoins, nous avons réuni avec notre client un UX Designer, un UI Designer, un ingénieur développeur, un business manager et un sprinter (pour piloter les étapes). Il nous semblait important d’avoir une équipe complémentaire dès le début afin de prétendre au juste niveau de transparence recherché.

Organisation

Le design sprint requiert une organisation assez stricte:

Lundi: Détermination d’une liste de questions auxquelles le sprint devra répondre. Identifications un panel d’individus qui testeront le prototype en fin de sprint

Mardi: Chacun des participants présente les solutions retenues la veille et esquisse les parcours permettant d’y aboutir.

  

Mercredi: Tous les parcours sont collés au mur et chaque participant crée sa carte thermique en venant placer des gommettes à côté des éléments qu’il préfère. Sur la base des meilleurs votes, un storyboard est crée.

 

Jeudi: En utilisant des outils comme Marvel ou Invision, les écrans du prototype sont réalisés. En parallèle, le guide d’entretien est réalisé et partagé à toute l’équipe.

Vendredi: Toute la matinée est consacrée au test des prototypes. Dans notre cas, nous les avons effectué sur un panel de 10 individus. Le prototype leur a été remis et chaque parcours était enregistré en vidéo.

Le vendredi après midi a été pour notre part consacré à une rétrospective de sprint afin d’identifier les éléments positifs et ceux requérant des améliorations. Nous les listons ci dessous:

Avantages:

En confrontant nos hypothèses au public cible, nous avons obtenu des réponses rapides aux interrogations et hypothèses de conception sans avoir à constituer un quelconque cahier des charges. Une simple idée a suffit.

Elle permet aussi d’éviter de se tromper: Nous avons pu constater, lors des tests auprès du panel que certains éléments de nos interfaces étaient pas ou peu compris par les individus interrogés. Dans une phase de conception traditionnelle, nous nous serions certainement rendu compte de cela bien plus tard.

En réunissant tous les intervenants (UX, UI, Technique, Business et client) et en leur permettant de co-concevoir un produit, nous avons pu mettre tout le monde en phase sur la conception et ainsi éviter tous les points de frustration qui peuvent émaner lorsqu’un ingénieur reçoit un brief.

En intégrant notre client dans le cycle de production, cela nous a permis de nous imprégner de ses enjeux business mais aussi de le sensibiliser aux problématiques liées à la navigation, l’ergonomie et la technique, et éviter l’éternelle « Mais rajouter un bouton ça ne prend quelques minutes ».

 

Inconvénients:

Cinq jours c’est peu lorsqu’on crée un produit digital de grande consommation avec autant d’inconnues liées au marché. Nous n’avons pas de doute sur le fait que les résultats obtenus nous ont permis de réduire les risques de nous tromper, néanmoins, nous n’avons pas la prétention de penser qu’un seul Design Sprint peut servir à créer la prochaine killer app. Un seul Design Sprint ne peut donc pas permettre de définir toute la roadmap d’un produit de grande consommation. Il faut plusieurs itérations à différentes périodes clés pour pouvoir aboutir à un produit amenant une vraie valeur ajoutée.

Une certaine frustration à la fin du sprint peut émaner. En effet, le cadre du design sprint étant très stricte, il impose une cadence intense, suivie et soutenue. Nous aurions apprécié pouvoir passer plus de temps pour améliorer tel ou tel écran mais en se faisant, aurions certainement mis en péril l’objectif fatidique du vendredi, et la qualité du prototype final.

En résumé:

Cette méthode de conception s’inscrivant totalement dans une pratique Agile offre l’exact niveau de transparence et de collaboration qui doit être amené à chaque client. En testant rapidement son idée, notre product owner sait exactement sur quelle(s) fonctionnalité(s) se concentrer. Ce qui réduit grandement le gaspillage des phases exploratoires et le time to market.

Néanmoins, le cadre du Design Sprint étant stricte, nous pensons qu’il ne peut être respecté stricto sensu. En effet, une flexibilité doit pouvoir être amenée tant sur le profil des intervenants en perspective des enjeux business ou sur la durée des étapes au regard du niveau de connaissance dont bénéficie déjà notre client.

1 commentaire

  • Himmer04 décembre 2018 / 06:12

    Je ne connaissais pas cette méthode. Elle me semble intéressante à développer. Est il possible voire souhaitable d’intégrer des exigences dans ce processus? Cdt

Laisser un commentaire