La méthodologie UCD appliquée à des produits techniques

Ou comment surmonter son syndrome de l’imposteur

Annamaria Boheim
Apr 3 · 8 min read

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.

Think, Make, Check — mon processus UCD (User-centred design)

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 ?

Par exemple : Un constructeur automobile français voulait vérifier si un framework technique est l’outil adéquat pour son équipe

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 :

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.

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 !

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 :

  1. Présentez le problème grâce au scénario
  2. Prenez 10–15min pour imaginer et dessiner les solutions potentielles
  3. Présentez vos idées les uns aux autres
  4. Chacun vote pour ses solutions et détails préférés
  5. Récapitulez ce qui est ressorti du tour de vote
Nous avons utilisé miro (avant RealTimeBoard) pour faire un Design studio en remote

Une fois toutes ces étapes exécutées, discutez avec vos collègues pour choisir la solution que vous voulez tester.

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.

Nous avons utilisé un template pour réfléchir à comment nous pouvons tester notre hypothèse la plus rapide et la moins couteuse possible.

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 !

J’ai simulé une interface en ligne de commande en utilisant un fond noir et une police de caractère monotype.

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.

J’ai mené 5 entretiens en utilisant un guide de discussion et le scénario.

Exemple d’entretien réalisé par vidéo conférence

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.

Voici les slides utilisées pour une conférence que j’ai faite sur ce sujet pour Product Apéro en Mars 2019.

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.

Pivotal Labs Paris

Leader du développement agile depuis plus de 20 ans, nos développeurs, nos designers et nos product managers accompagne les entreprises pour résoudre leurs défis les plus importants.

Annamaria Boheim

Written by

Senior Product Designer at Pivotal Labs Paris. Learning french. Eating all the croissants. Spotting all the cats.

Pivotal Labs Paris

Leader du développement agile depuis plus de 20 ans, nos développeurs, nos designers et nos product managers accompagne les entreprises pour résoudre leurs défis les plus importants.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade