Trois choses que les équipes produit ont besoin des designers

Cet article est écrit par Chris Hill-Scott. Cet article a été publié pour la première fois en mars de cette année sur le Design in Government GOV.UK Blog****. Vous pouvez lire l'article original ici* .*

Cet article contient des informations du secteur public sous licence Open Government License v3.0.


Cartographier les choix que GOV.UK Notify offre aux équipes pour la marque de leurs e-mails (Crédit : Design in Government)

Je pense que les équipes produit ont besoin de 3 choses de la part des designers. Et, en tant que designer, votre vie sera plus facile si vous pouvez identifier les 3 choses dont une équipe a besoin à tout moment.

Les 3 choses sont :

• rendre les choses visibles
• faire de vraies choses
• donner du sens aux choses

Lorsque je parle d'« équipes », j'entends des équipes de produits multidisciplinaires qui créent, exploitent et réitèrent leurs services. J'ai travaillé dans quelques-unes de ces équipes au Service numérique du gouvernement (GDS), et j'ai un aperçu de bien d'autres choses en tant qu'évaluateur de services.

**• Tu veux écrire pour nous? Jetez un œil au guide pour les contributeurs

Quand je dis "concepteurs", je veux dire contenu, graphisme, interaction et concepteurs de services. Mais j'espère que ce conseil est utile à toute personne impliquée dans la création de choses au sein d'une équipe.

Rendre les choses visibles

C'est à ce moment que quelqu'un, peut-être vous, a une idée de la façon dont l'avenir devrait être différent. Vous rendez cette idée visible et compréhensible afin que l'équipe puisse décider de la construire pour de vrai.

Vous pouvez faire des croquis, des prototypes, des maquettes, des diagrammes, des cartes ou des présentations - tout ce qui aide l'équipe à comprendre en quoi consiste le concept ou l'idée sera comme pour la personne qui doit l'utiliser. Vous pouvez tester ce que vous avez fait avec les utilisateurs pour voir si vos hypothèses sont correctes.

Ce travail peut aussi consister à rendre le présent visible. Vous pouvez analyser certaines données ou aider à communiquer les résultats de la recherche afin que l'équipe ait une meilleure compréhension du contexte dans lequel ils sont travail.

Ce travail est précieux à 2 niveaux :

• S'assurer que tous les membres de l'équipe ont une compréhension commune de l'idée
• Développer la compréhension du problème par l'équipe : si votre idée ne résout pas le problème, cela indique quelque chose sur la façon dont vous comprenez le problème

Mais ce travail est aussi risqué. Il peut soulever plus de questions qu'il n'apporte de réponses. Pour les équipes qui exploitent un service, il peut être frustrant d'avoir quelqu'un qui leur dit de prendre du recul et de leur demander quel problème ils essaient « réellement » de résoudre alors qu'ils ont déjà l'impression d'avoir beaucoup de problèmes.

Vous devez faire attention à ne pas passer trop de temps à travailler de cette façon. Plus vous ajoutez de détails à ce stade, plus la conception peut diverger de la livraison.

J'essaie d'ajouter juste assez de détails pour comprendre en quoi je me trompe, puis je recommence. Si je répète ce processus suffisamment de fois, je m'attache à une idée. C'est à ce moment-là que je sais qu'il est temps d'arrêter de travailler dessus et de le partager avec les autres.

Faire un bon croquis peut prendre quelques minutes, mais il faut des mois d'efforts d'équipe pour développer un vrai produit. Rendre les choses visibles fait partie de ce processus, pas un livrable en soi.

Faire de vraies choses

Le design doit être impliqué dans la production, car un produit de haute qualité est obsédé par des centaines de petits détails.

C'est pourquoi il est utile d'apprendre un peu de codage et de savoir comment lancer une pull request.

Il est difficile de justifier de donner la priorité à une histoire sur certains arriérés pour rendre les apostrophes bouclées, pas droites, ou faire des éléments de la ligne d'interface up. Mais si vous allez réparer ces choses vous-même, cela indique que vous vous souciez de la qualité du produit. Les équipes s'en rendent compte, alors le souci des détails finit par faire partie des valeurs de l'équipe.

Si vous avez une équipe qui se soucie de la qualité du produit, elle viendra probablement vous demander quand elle ne sait pas quelque chose. Ils commenceront à utiliser leur expertise pour poser des questions réfléchies sur votre travail qui amélioreront sa qualité et votre pratique.

Donc, la contribution la plus difficile, mais la plus importante qu'un designer puisse apporter est de garder le produit cohérent.

Cela ne se produit que si vous prenez le temps et si vous êtes disponible pour répondre aux questions qui se posent pendant que les développeurs construisent des choses. Il y aura toujours des décisions de conception que vous ne pouvez pas anticiper. Vous ne voulez pas que ces décisions soient prises uniquement sur la base de ce qui est technologiquement simple.

Lorsque vous devenez bon dans ce domaine, vous pouvez apporter de petites améliorations qui sont expédiées à la production le même jour. Il est difficile d'exagérer la valeur de petites améliorations fréquentes et réelles. Avec le temps, cela conduit à un produit radicalement meilleur.

Surtout, apporter de petites améliorations fréquentes permet de gagner la confiance de l'équipe. Vous devez avoir la confiance de l'équipe avant de pouvoir effectuer les autres types de travail de conception dont le produit a besoin.

Le risque d'être obsédé par les détails est que le design devienne un bloqueur. C'est à ce moment-là que la seule façon de réaliser une bonne conception est d'empêcher la mauvaise conception de l'expédition. Cela a l'air génial - vous avez le contrôle - mais cela incitera les gens à faire le moins possible pour vous dépasser, plutôt que le mieux possible pour le produit et l'utilisateur.

Donner du sens aux choses

Quelque chose que vous apprenez lorsque vous étudiez le design est la façon dont votre réflexion est façonnée par votre choix d'outil. En art, c'est direct : un croquis au crayon exprime une qualité différente de celle d'une sculpture. Au travail, il y a une différence entre penser en paragraphes, penser en Powerpoint, et penser en Post-it. Ce sont des outils, et choisir le bon est important.

Le processus que vous utilisez façonne également votre réflexion : une réunion a un résultat différent d'un atelier, qui a un résultat différent d'une conversation en tête-à-tête.

Lorsqu'il s'agit de créer un logiciel, nous n'avons pas – à un niveau fondamental – le choix des outils ou des processus. Nous avons du code, et nous avons une certaine forme d'agilité.

Agile est une bonne chose. Mais il est important d'être conscient du type de produit que vous obtenez d'une méthode de travail itérative et incrémentielle.

Si tout ce que vous faites est d'ajouter des fonctionnalités, le produit n'aura finalement plus de sens dans son ensemble. Même si les fonctionnalités sont utiles et sensées, le produit sera déroutant à utiliser.

Ainsi, la contribution la plus difficile, mais la plus importante, qu'un designer puisse apporter est de garder le produit cohérent. Ian Bogost explique que le rôle du designer est de « [rendre les choses encore plus ce qu'elles sont déjà](https://web.archive.org/web/2090017013728/https://design.blog/2016/09/29/ian -bogost-jouer-n'importe quoi/)".

Ce travail pourrait consister à s'assurer qu'un élément apparaisse au même endroit d'une page à l'autre. Il pourrait s'agir de vérifier que les choses sont nommées de manière cohérente d'un endroit à l'autre. Il peut s'agir de supprimer une case à cocher une fois que la raison de son existence a changé.

Il est particulièrement difficile de maintenir la cohérence lorsqu'une nouvelle fonctionnalité arrive, mais c'est aussi à ce moment-là que la cohérence peut en souffrir le plus. Pour éviter de tels points de pincement, l'équipe doit se sentir habilitée à faire ce travail en continu, en prévision des nouvelles fonctionnalités et en réponse à celles-ci.

Vous ne pouvez pas tout faire en même temps

Il y a beaucoup de choses dans le post ci-dessus. Ce serait écrasant de tout faire en même temps. La seule façon de le faire est de déterminer quel travail faire quand.

Cela peut aussi sembler sans fin, ainsi qu'écrasant. J'ai suivi une formation de graphiste. À l'université, il y avait toujours une date limite pour remettre le travail. Plus tard, en travaillant pour des agences, le travail était remis ou livré au client à la fin d'un projet. Travailler dans des équipes de produits et travailler au gouvernement est un peu différent. Développer différentes approches prend du temps.

Mais j'espère que les choses deviendront plus simples une fois que vous pourrez déterminer quelle approche convient à une situation. — Chris Hill-Scott

Nous voulons savoir ce que vous pensez de cet article. Pitch an article à nous ou envoyez vos commentaires à hello@aphysical.co

(Crédit photo : Unsplash)