11 choses que j'ai apprises au cours de ma première année de travail en tant que concepteur UX/UI dans une maison de logiciels

Cela fait en fait plus d'un an que j'ai commencé mon premier emploi en tant que concepteur UX/UI dans une maison de logiciels. Bien que certaines personnes pensent que ce n'est pas le meilleur endroit pour commencer votre expérience UX/UI en raison de la variété des projets et de l'indépendance requise, je n'ai pas eu beaucoup de problème avec cela. Je travaillais comme assistante d'architecture pour un assez grand studio et « freelance » pour une organisation étudiante en relations publiques et graphisme.

Cependant, ce n'était pas que du soleil et des arcs-en-ciel . Il m'a fallu moins de quatre mois entre la décision de changer de marque et le début de mon premier emploi, et par conséquent, je n'ai pas appris et compris tous les domaines nécessaires pour le poste. En général, on apprend peu aux juniors l'importance de la coopération entre les différentes équipes dans les entreprises, principalement la partie commerciale et commerciale du projet.

Voici quelques problèmes rencontrés lors de ma première année en UX/UI design :

1. MVP et KPI

Ce sont des concepts presque complètement étrangers que j'ai rencontrés en travaillant sur mon premier projet. Certes, il s'agissait d'un projet interne, mais le travail était occasionnel, et j'ai pu interroger chaque participant au projet sur diverses questions. C'est alors que j'ai fait la connaissance des analystes métier et de leur rôle dans le projet. J'ai découvert le côté commercial des produits, qui, en fin de compte, est la partie la plus essentielle d'entre eux dans les éditeurs de logiciels. Ayant de l'expérience dans une industrie précédente, les MVP et les KPI ont peut-être existé cachés sous d'autres noms, mais leur détermination pratique lors d'ateliers avec des clients a été ce que j'ai vécu ici.

2. Besoins commerciaux, recueillir les besoins, les confirmer avec le client, faire des confirmations

À mon avis, c'est la partie la plus essentielle du travail d'un concepteur de produit. Au sein de l'entreprise, j'étais partiellement ou entièrement responsable de recueillir les exigences et de les confirmer avec le client — parfois en partenariat avec un analyste d'affaires qui pénétrait en douceur dans la structure du client et recueillait les exigences d'affaires. À ce stade, il est essentiel de se renseigner sur l'industrie et les processus du client, d'expliquer au client pourquoi nous faisons cela (s'il ne le sait pas) et, en fait, de recueillir systématiquement ces informations sur le produit en cours de conception. Je l'ai fait en écrivant des histoires d'utilisateurs, des critères d'acceptation et des risques potentiels. Pour le client, l'aspect visuel du produit qu'il nous commande est déjà important à ce stade, donc la forme la plus attractive de collecte de ces exigences est de faire des maquettes mid-fi, c'est-à-dire maquettes avec un contenu partiellement proposé. Il est important de se rappeler qu'il s'agit d'une des nombreuses propositions qui peuvent être présentées, il ne vaut donc pas la peine de s'attacher à une telle version du projet. À ce stade, vous devez également garder à l'esprit la clarté du flux d'informations, en établissant comment les exigences sont collectées et confirmées par le client. Sans clôturer cette étape, vous ne pouvez pas avancer dans le développement en raison des risques potentiels - modifier les décisions prises ou ajouter de nouvelles exigences, ce qui affecte le calendrier du projet. Il arrive aussi que nous créons un produit, collectons des exigences, peut-être sommes-nous déjà au stade de l'acceptation de la documentation ou même du développement, et du coup le métier (c'est-à-dire les utilisateurs) déclare qu'il ne comprend pas le processus.

3. Estimation du temps — sous-estimation ou surestimation

Le fait est que la plupart du temps est consacré à la création de maquettes, à la personnalisation de bibliothèques existantes ou à la création de bibliothèques personnalisées et à la rédaction de documentation. Il est souvent très difficile pour les concepteurs novices d'estimer le temps qu'ils y consacreront, et d'une manière ou d'une autre, ils doivent le faire. Plusieurs fois, j'ai sous-estimé le temps passé sur une tâche particulière, et une fois je l'ai même surestimé, mais à mon avis, cette compétence vient avec l'expérience. Il est bon d'avoir une certaine marge de temps dans une telle situation - il est toujours préférable de livrer quelque chose plus rapidement que tard.

4. La barre, la voile et le navire — l'autonomie

Jusqu'à présent, dans mon expérience, je n'ai eu à prendre en charge que de petits aspects de projets, tels que la coordination des installations dans les plafonds des chambres d'hôtel et des couloirs ou les parties dites Back of House. En tant que designer UX/UI après avoir été officiellement affecté à mon premier projet, j'étais beaucoup plus responsable du produit, car j'étais le seul designer de l'équipe de projet. D'une part, c'était ennoblissant pour moi, mais d'autre part, c'était beaucoup de responsabilité et de confiance globale de la part de l'entreprise. Jusqu'à présent, je ne sais pas si cela me convenait, peut-être était-il beaucoup trop tôt pour être entièrement responsable du produit en tant que personne ayant peu d'expérience dans l'industrie. C'était tout un test pour moi, mais pour autant que je sache, le client et l'équipe étaient satisfaits de moi, donc je suppose que j'ai réussi à bien exécuter ces tâches de projet pour ce moment après tout

5. La recherche au stade UX, ou plutôt son absence

Les clients n'ont souvent aucune connaissance de l'intérêt de mener des recherches UX au stade de la conception (et s'ils le font, remerciez votre service commercial pour un client aussi informé !). C'est l'inconvénient général des éditeurs de logiciels. Dans les entreprises de produits, d'après mes conversations lors de rencontres et de conférences, il était clair que malheureusement, ce n'est pas non plus la norme en matière de processus de conception. Néanmoins, il est toujours intéressant de faire la présentation au client sur la recherche UX et de lui présenter pourquoi c'est important et combien cela peut faire gagner du temps. Le premier exemple venu du rivage — je développais un produit dont le processus métier était assez compliqué à comprendre, il s'est avéré — pas seulement pour moi, parce que les utilisateurs ne l'ont pas bien compris. Avec le client, nous avons dû revenir à l'étape de recueil des besoins, rassemblez-les à nouveau après en avoir appris davantage sur le processus, améliorez les maquettes et continuez le développement. Cela aurait pu être évité si nous avions eu un moment pour prototyper les maquettes et mener des tests d'utilisabilité avec de futurs utilisateurs (employés d'une des équipes chez le client). Même alors, nous aurions identifié les problèmes qui sont apparus beaucoup plus tard.

6. Création de documentation

C'est vraiment un travail que le client doit vérifier. Pour créer de la documentation UX, j'ai utilisé l'article détaillé d'Autentika sur la préparation de la documentation (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/en polonais).

Cela m'a été très utile pour le créer, mais ce n'était pas suffisant à 100%. Les diagrammes de processus dans le produit que je créais à l'époque étaient TRÈS compliqués, alors je suis allé voir les analystes pour une raison, et avec leur aide, j'ai créé une spécification de cas d'utilisation et des exigences de processus plus détaillées avec des critères d'acceptation à la place. Bien sûr, maintenant je ferais une telle documentation un peu plus différemment, mais à ce moment-là, j'en étais assez satisfait.

7. Méthodologies ? Existent-ils ? (Non)

La plupart des éditeurs de logiciels essaient de travailler de manière itérative, avec une approche individuelle du client. Il est difficile de planifier des processus de livre dans de telles situations, d'autant plus que la recherche conseil à conseil est rarement effectuée parce que « le temps manque » ou que vous travaillez en tant que concepteur unique. Au final, la méthodologie de conception est basée sur Agile, mais les frameworks sont assez similaires entre eux et peuvent plutôt être divisés en étapes Discover, Define, Design, Develop et Deliver/Deploy (comme un 5D étendu avec une étape de Double Diamond) .

8. Comprendre le client

C'est le cœur de la coopération avec le client au niveau de la conception de l'application. Souvent, les clients (en particulier des industries non informatiques) ne savent pas ce qu'est l'UX, de quoi il s'agit, quels problèmes il peut éliminer aux toutes premières étapes du projet. Un bon exemple de mon expérience serait lorsque je présentais des maquettes lo-fi pour répondre aux besoins de l'entreprise. La réunion comprenait également l'équipe marketing du client, qui était très incertaine… sur la conception des maquettes lo-fi. Comme ils n'étaient pas tous sur la même longueur d'onde, j'ai de nouveau parlé du fait que les maquettes n'étaient que l'occasion de parler des fonctionnalités et du fonctionnement du produit. Malheureusement, cela n'a pas empêché le marketing de commenter les polices de caractères utilisées sur les maquettes, qui n'avaient aucune incidence sur la conception de l'application à ce stade du projet . À la fin, le sujet s'est résolu assez rapidement et a été compris, mais le fait même qu'il ne l'ait pas été tout de suite indique que le sujet de l'UX est complètement inconnu dans les entreprises. Cela vaut la peine de faire une courte présentation au client au tout début de la phase de conception avec une discussion sur la façon dont nous travaillons, ce que nous allons présenter et dans quelle mesure nous avons besoin de la contribution du client. Et, bien sûr, pourquoi cela en vaut la peine pour lui.

9. Travailler avec les développeurs

Souvent, les développeurs ont une très bonne contribution en matière de solutions et posent des questions très techniques et logiques, ce qui m'a souvent donné un bon sujet pour réfléchir à une solution. Cependant, ils proposent parfois des solutions plus simples pour eux et pas nécessairement bonnes du point de vue de l'utilisateur, il faut donc ici bien équilibrer ce qui vaut éventuellement la peine de proposer de changer et où il vaut la peine de les arrêter et d'expliquer les décisions prises.

10. API, JSON, LDAP, orchestrateurs et autres mots étranges

Ce sont des concepts clés pour le développement d'applications que, en tant qu'UX, vous devez connaître car les développeurs et l'ensemble de la communauté informatique les utilisent. Apprenez à les connaître et vous pourrez mieux parler aux ingénieurs. Vous ne savez pas - demandez, de préférence au début, même si pour moi, la compréhension de ces concepts n'est venue qu'après avoir examiné la documentation d'implémentation que les développeurs étaient en train de créer - les schémas de communication interne de l'application permettaient de comprendre beaucoup quand il s'agissait de son fonctionnement.

11. Travail en sprints, projet quotidien, planification de sprint et retro(spec)

Ce sont des réunions précieuses qui donnent un contrôle total sur ce qui se passe dans le projet. Les chefs de projet sont importants ici, intervenant en cas de besoin (par exemple, lorsque le client essaie de modifier les arrangements), ainsi que les Scrum Masters si nous travaillons de manière agile (presque tous les projets).

Comme vous pouvez le voir, c'est beaucoup de choses que j'ai apprises quand j'ai rejoint l'informatique. J'espère que vous les trouverez intéressants et peut-être que cette liste sera utile pour ceux qui envisagent leur carrière UX/UI ou même pour les personnes travaillant dans cette industrie !