La méthodologie UCD appliquée à des produits techniques
Ou comment surmonter son syndrome de l’imposteur
En tant que Product Designer j’ai un processus de travail centré utilisateur bien établi. Je commence mes projets avec une phase exploratoire d’entretiens utilisateur pour comprendre les besoins et les problèmes d’un produit ou d’un service. Ensuite, vient la phase d’idéation. Pendant celle ci je pense aux solutions et à la meilleure manière m’assurer que je suis sur le bon chemin.
Chez Pivotal Labs j’ai travaillé sur beaucoup de projets différents. Au début c’est normal de ne pas connaître le domaine/industrie de mes clients. Avec ma boîte à outil par contre je découvre au fur et à mesure le domaine et les implications, les problèmes, et les besoins des utilisateurs.
Récemment, je me suis trouvée confrontée a des projets très techniques. Par technique j’entends qu’ils étaient soit à destination de développeurs, soit qu’il y avait beaucoup d’intégrations avec des systèmes techniques, ou enfin qu’il n’y avait même pas de UI à concevoir. Ou pire … les trois en même temps !
Ainsi pour moi, la différence entre un “projet normal” et un projet technique est qu’il y a un brouillard d’incertitude encore plus épais. Des termes techniques, des acronymes partout, des systèmes et frameworks que je ne connais pas. Cela rend le sujet encore plus flou et obscur et j’en deviens anxieuse.
Ma réaction : comment puis-je aider l’équipe a expliciter le domaine alors que c’est du chinois pour moi ?
Le Syndrome de l’imposteur
Chez moi le syndrome de l’imposteur se manifeste par une petite voix dans ma tête qui me parle et qui me dit des choses comme “Ce n’est qu’une question de temps avant qu’ils se rendent compte que tu n’as rien de significatif à apporter !” ou “Je n’arrive toujours pas à croire qu’ils te laissent faire ça !“
En gros, je me suis persuadée que : Je n’en suis pas capable. Je n’ai pas de talent. Je ne suis pas légitime.
Cet état d’esprit a eu de nombreux effets négatifs sur mon quotidien. Par exemple, je ne pose plus des questions et m’autocensure parce que je veux pas que les autres se rendent compte que je ne maitrise pas le sujet. Cela a eu pour effet d’avoir laisse un développeur de mon équipe mener les entretiens utilisateurs parce que je ne croyais pas que j’en étais capable; ou bien d’avoir demandé à mon manager de me faire remplacer parce que je ne voyais pas la valeur que j’ajoutais sur le projet.
Aujourd’hui je vois les choses différemment, je me juge autrement, mais à l’époque je n’étais pas vraiment sûre de moi. Le déclic, je l’ai eu grâce à un de mes collègues qui m’a montré qu’un designer avait tout à fait sa place dans une équipe technique. Il m’a aidée à réaliser que le syndrome de l’imposteur est un phénomène qui arrive à beaucoup des personnes dans des domaines différents, et que c’est tout à fait surmontable.
La riposte
Les développeurs sont aussi des utilisateurs ! Ils apprécient une bonne ergonomie et ils souffrent d’un mauvais design. Les API, comme les interfaces utilisateur graphiques, doivent être faciles à utiliser.
Du coup, je me suis rendue compte qu’en tant que designer c’est ma responsabilité de guider une équipe produit à créer une bonne expérience pour tous les utilisateurs, techniques ou pas.
Étape numéro 1 :
Parler avec des gens qui travaillent déjà dans un domaine technique et apprendre comment ils gèrent cette problématique.
J’ai parlé avec Kevin Gates, un collègue de Londres, Designer pour Pivotal Cloud Foundry. Il m’a montré beaucoup d’exemples de comment il applique son expertise de designer pour concevoir des projets d’API ou d’interface en ligne de commande.
Cela m’a encouragée à réessayer à travailler sur un projet technique, mais cette fois ci avec la certitude que c’était possible.
Étape numéro 2 :
Trouver une opportunité pour un autre projet technique
J’ai décidé de travailler avec une équipe de Pivotal Cloud Foundry pour une mission de deux semaines. J’ai tout d’abord rencontré l’équipe pour qui travailler avec un designer était une grande première. Après quelques jours d’introduction au sujet, de découverte des problématiques, je me suis demandée comment puis-je faire au mieux avec un délai si court et montrer la valeur d’une approche centrée utilisateur. La réponse pour moi était claire : On va faire un Design Sprint !
Design Sprint
Ce processus permet à l’équipe, en définissant clairement les objectifs, de valider ou d’invalider des hypothèses et des solutions.
Les principes fondamentaux de ce processus: unité de temps et de lieu (dans notre cas s’est passé en remote), équipes pluridisciplinaires, prototypage rapide, et tests utilisateurs.
Le but du Design Sprint est de générer le meilleur retour sur investissement possible, en explorant le maximum d’idées et en ne prototypant que les meilleures, qui seront testées sur de vrais utilisateurs lors du dernier jour.
Je vais résumer les activités que nous avons fait pendant 5 jours :
Comprendre et choisir le problème à traiter en premier
Dans un autre article j’ai parlé de comment vous pouvez identifier les problèmes prioritaires. Dans ce projet, cette étape était déjà faite et nous avons pu passer directement à la priorisation.
Prioriser les problèmes et choisir le plus important à attaquer en premier aide votre équipe à se focaliser. Il y a des exercises collaboratives que vous pouvez animer comme par exemple le 2x2.
Ecriture de scénarios
Pour rendre votre problème plus concret il faut rajouter du contexte, une persona, un résultat attendu par cette persona. Avec un scénario préparé vous êtes prêts pour les activities suivantes !
Design Studio
Le but de cet exercice est d’imaginer plusieurs idées qui peuvent résoudre le problème d’une manière visuelle. Équipez vous de papier, stylos et du scénario que vous avez fait. Ensuite, suivez les étapes suivantes :
- Présentez le problème grâce au scénario
- Prenez 10–15min pour imaginer et dessiner les solutions potentielles
- Présentez vos idées les uns aux autres
- Chacun vote pour ses solutions et détails préférés
- Récapitulez ce qui est ressorti du tour de vote
Une fois toutes ces étapes exécutées, discutez avec vos collègues pour choisir la solution que vous voulez tester.
Expérimentations Lean
Les expérimentations Lean sont un excellent moyen d’éviter de partir dans la mauvaise direction. Elles nous aident à savoir rapidement quelles idées valent la peine d’être creusées ou non.
Prototypage
Pendant notre experimentation nous avons testé une fonctionnalité dans l’interface en ligne de commande.
Du coup, peu importe l’outil, Sketch, Invision ou ici Google Doc !
Il n’y a pas de bouton, mais il y a quand même beaucoup de décisions design à faire : Afficher les informations le plus clairement possible, éviter de mettre des éléments superflus et penser aux commandes intuitives et faciles à comprendre etc.
Après avoir eu un mockup, j’ai travaillé en binôme avec un développeur pour rendre le mockup Google Doc utilisable dans le terminal pour que cela puisse être utilisé pendant des entretiens et tests utilisateur.
Entretiens utilisateur
J’ai mené 5 entretiens en utilisant un guide de discussion et le scénario.
Au début de chaque entretien, j’ai dit que je n’étais pas une personne technique et que j’allais probablement poser des questions naïves et demander de m’expliquer les termes techniques et les acronymes. Comme ça, l’utilisateur est déjà préparé à adapter son langage.
Après chaque entretien, nous avons analysé les notes des autres membres de l’équipe qui observaient les entretiens. Nous avons groupé les notes par sujet, puis par problème et enfin par apprentissage.
D’ailleurs, nous avons validé ou invalidé les sub-hypothèses après chaque entretien pour avoir un vue plus claire sur ce que nous voulions tester.
Conclusion
En seulement deux semaines j’ai apporté une vraie valeur ajoutée à une équipe qui n’était pas habituée à travailler avec un designer. La bonne nouvelle, c’est qu’ils ont continué à faire des iterations avec des hypothèses, des entretiens de validation etc.
Soyons honnêtes, les domaines techniques ne seront jamais ma passion, mais heureusement j’ai réalisé qu’il ne faut pas en avoir peur et paniquer. Les développeurs sont des utilisateurs comme les autres !
Comme dans n’importe quel projet je n’ai pas besoin de tout comprendre, peu importe si le domaine est technique ou pas.
Créer une bonne expérience d’utilisateur est la responsabilité de toute l’équipe. Du coup, impliquez vos collègues dans le processus de design. C’est enrichissant pour tout le monde car c’est un échange de perspective et en plus, la plupart du temps les meilleures idées viennent des développeurs.
Suivez votre processus habituel ! La boîte à outils d’un designer est tout aussi importante pour les projets techniques, il y a un grand potentiel pour les designer de conquérir ce monde des produits technique si nous nous disons que : Nous en sommes capables. Nous avons du talent. Nous sommes légitimes.
Pivotal Labs
Pivotal Labs, leader du développement agile depuis plus de 20 ans, accompagne les entreprises pour résoudre leurs défis les plus importants. Au-delà d’écrire du code en binôme, nos développeurs, nos designers et nos product managers font partie intégrante de votre équipe. Grâce à notre approche collaborative, votre équipe se forme aux meilleures pratiques et technologies innovantes pour acquérir des connaissances tout aussi précieuses que les produits eux-mêmes.
Contactez-nous
Si vous avez envie de savoir plus sur les sujets de Agile Software Development, Lean ou User-Centered Design n’hésitez pas à nous contacter : Twitter, Linkedin ou laissez-nous un message.
Vous souhaitez faire un workshop gratuit et sans engagement avec nous ? Discuter de la problématique design ou produit que vous rencontrez en ce moment ? Participez à nos “Product Office Hours”
Nous organisons le meetup Product Apéro — inscrivez-vous sur Meetup pour rester dans la boucle pour la prochaine soirée.
