L'histoire d'une refonte qui a changé l'approche de développement chez ISPsystem.
J'ai rejoint ISPsystem en avril 2016. A cette époque, la situation avec la conception de produits était la suivante: les décisions concernant les produits étaient prises par la direction et les programmeurs, il n'y avait pas de concepteurs ou de concepteurs. La situation du marché nécessitait des produits avec «d'autres interfaces», la direction a donc décidé de repenser la partie client de
BILLmanager . C'était censé être un ballon d'essai, la première tentative de faire quelque chose avec un nouveau design.
J'étais le seul designer UX de l'entreprise: j'ai étudié un produit existant, je me suis engagé dans la recherche d'utilisateurs, j'ai pris connaissance des retours d'expérience des partenaires et de leurs marketeurs. Ce sont les pratiques habituelles de conception de produits, en tenant compte des spécificités d'un produit complexe. Une grande aide m'a été apportée par le chef de produit, car il connaissait le mieux le produit.
Chaque semaine, je montrais le résultat sous forme de prototypes, de circuits, etc. à la direction de l'entreprise. Cela ressemble à la façon dont les concepteurs clients travaillent avec les clients, avec tous les avantages et les inconvénients: vous pouvez vous décharger de la responsabilité des décisions, l'essentiel est de les «vendre» à la direction. Mais comme j'avais déjà de l'expérience dans une entreprise de produits et que la direction me faisait confiance dans ces domaines, nous avons rapidement travaillé ensemble sur des solutions que j'ai développées et transformées en prototype.
Les développeurs rencontrent le prototype
En août 2016, les prototypes du client BILLmanager étaient prêts sous leur forme conceptuelle. La fonctionnalité de l'ancienne version du produit a été complètement transférée à la nouvelle interface, avec quelques améliorations. Les prototypes étaient bien développés d'un point de vue visuel, mais je voulais plus, j'ai donc commandé un design visuel à une société tierce. Cependant, nous avons rapidement réalisé que cette tentative était infructueuse, un travail itératif constant était requis sur le composant visuel, et nous avions besoin d'un concepteur visuel dans le personnel. En quelques mois, nous avons développé notre propre langage visuel. En fait, à ce moment-là, nous avions plusieurs parties du futur système de conception: un langage visuel, des éléments et des modèles.
En parallèle, à partir d'août 2016 environ, les développeurs ont commencé à implémenter une nouvelle interface. Les gars considéraient le prototype comme une alternative à la tâche technique. Comme cela se produit à de tels moments, des questions ont commencé à apparaître à grande échelle, ce qui se résume à une chose: faisons-nous ce que les programmeurs mettent en œuvre rapidement et simplement ou ce qui a été inventé et conçu par un designer? Pour résoudre rapidement ces problèmes et simplifier la communication, nous avons créé une équipe de designers et front-end.
Département UX en équipe de designers et de front-renderers
Au milieu de l'automne 2016, un département UX a été formé dans l'entreprise sous ma direction, qui était composé de concepteurs UX, d'un concepteur visuel, d'appels d'offres frontaux et de testeurs. Notre tâche immédiate était de lancer le compte personnel ISPsystem avec une nouvelle interface (nous utilisons BILLmanager chez nous) d'ici fin mars 2017 et nous avons eu deux groupes de problèmes. Les développeurs ont mal prédit le calendrier de leur travail, et nous n'avons pas tout à fait compris comment créer une interaction entre les développeurs et les concepteurs.
Ce que nous donnons aux développeurs
Lorsque vous utilisez Sketch et Zeplin, l'interaction entre les concepteurs et les développeurs est très simple. Mais nous avions plus de 150 pages dans un prototype interactif, que nous avons appris à utiliser comme alternative aux savoirs traditionnels pour les programmeurs et comme spécification pour les testeurs. Nous ne voulions pas rendre les 150+ pages avec différents états dans Sketch et nous sommes arrivés à la conclusion que nous ne le ferions que pour des pages uniques. De plus, tous les éléments auraient dû apparaître dans Zeplin: boutons, champs de formulaire, etc. Après un certain temps, nous avons appris le nom d'une telle approche - il s'agit d'un
système de conception basé sur la conception atomique . Il est toujours en cours de développement, mais les concepteurs et les développeurs l'utilisent déjà. Le dernier dans l'entreprise pour le système de conception est le concepteur visuel.
En conséquence, nous fournissons aux développeurs deux types d'artefacts:
- des schémas de ce qui deviendra un système de conception dans Zeplin (ou plutôt déjà dans Figma),
- prototypes de produits, alternative aux savoirs traditionnels sous forme de code HTML généré par Axure.
Dans le même temps, le concepteur UX est toujours prêt à dire aux développeurs et aux testeurs quoi et comment cela devrait fonctionner et ressembler.
Scrum avec les designers
En février 2017, nous avons décidé d'améliorer la précision des délais de prévision et avons essayé de mettre en œuvre Scrum. La complexité de notre Scrum est que les membres de l'équipe sont très différents en termes de compétences et de culture. Les concepteurs ne sont pas comme les programmeurs: nous planifions nos tâches différemment, nous avons des attitudes différentes envers ce qui est considéré comme un bon résultat.
Voici comment nous avons construit le processus:
- les concepteurs courent en avant;
- Il existe un prototype de backlog, élaboré en termes généraux, dans lequel vous pouvez voir à quoi devrait ressembler l'ensemble du produit;
- au moment de la planification du sprint, les concepteurs fournissent des prototypes et des maquettes de la partie du produit qui doit être réalisée dans le sprint. Ces prototypes sont détaillés et décrits par le concepteur UX au point où les développeurs peuvent définir et décomposer leurs tâches;
- au moment de la planification, le concepteur UX conseille activement les développeurs et les testeurs sur ce qui devrait fonctionner et comment;
- au moment de la planification, le chef de produit doit indiquer au concepteur UX quelle partie du produit doit être effectuée au prochain sprint afin que le concepteur UX puisse planifier son travail.
Les développeurs ont rapidement compris la valeur d'un concepteur UX, qui peut être rapidement abordée quand il n'est pas clair ce qui devrait fonctionner et comment. Les conflits se produisent toujours, mais les pratiques Scrum, le travail d'équipe et les objectifs communs aident à les surmonter.
Qu'est-ce que le testeur a à voir avec ça?
Le rôle du testeur dans les processus était très important. C'est la personne qui connaît le mieux la fonctionnalité du produit. Le testeur a été la première personne à examiner les prototypes d'un concepteur UX et à fournir rapidement des commentaires en termes de conformité et de fonctionnalité des prototypes. Les prototypes approuvés deviennent une source de connaissances pour le testeur sur le fonctionnement du produit. Les deux parties souhaitaient une coopération étroite.
En conséquence, l'équipe a publié à temps la nouvelle interface du compte personnel ISPsystem. Nous avons appris à travailler sur Scrum, à prédire le travail du département UX en équipe de front-end et de designers. Et à l'été 2017, ils ont été confrontés à un nouveau problème.
BILLmanager est un produit flexible. Et c'est un problème pour le designer
Lorsqu'un designer dessine une affiche, compose un livre ou fait la couverture d'un magazine, il travaille avec des informations statiques. Il contient du texte spécifique, certaines images et d'autres contenus.
Lorsqu'un concepteur conçoit une application ou une interface de site, les informations ne sont pas statiques. Il existe des informations sur ce que peuvent être les données, mais les données elles-mêmes ne le sont pas. Supposons qu'il existe un blog, chaque entrée de blog a un titre, une annotation, une date de publication, une image, etc. Il n'y a pas de titre spécifique, mais il est entendu qu'il y aura toujours un titre et que la date aura toujours un format de date. La tâche est devenue plus compliquée, nous avons des types de données, mais il n'y a pas de données: nous devons réfléchir à ce que peut être le contenu, quelles restrictions peuvent et doivent lui être imposées. Très probablement, il y aura moins de valeur artistique que l'affiche, mais le concepteur veut obtenir un résultat qui sera beau, pratique et compréhensible.
Dans le cas de BILLmanager, l'administrateur de l'hébergeur peut modifier les paramètres pour que, par exemple, pour le bon de commande d'un serveur dédié, l'ensemble des champs puisse être différent. Dans un cas, nous aurons certainement un processeur, un disque et une mémoire, et dans l'autre, ce ne sera pas (ou le sera, mais, par exemple, un seul champ), et cela ne peut pas être prévu. Dans ce cas, le concepteur n'a même pas un ensemble de données fixe, nous ne connaissons pas seulement des données spécifiques, nous ne connaissons pas les types de ces données ... et cela complique le travail.
Lorsque nous avons commencé à créer la version en boîte, les testeurs ont commencé à vérifier tous les paramètres possibles dans BILLmanager. Ensuite, il est devenu clair que, d'une part, les prototypes ne sont pas suffisamment complets pour couvrir les possibilités de réglages flexibles de BILLmanager. D'un autre côté, l'architecture de l'ancien produit n'était pas suffisamment flexible pour mettre en œuvre un grand nombre d'idées de conception. De l'automne 2017 au printemps 2018, nous avons repensé les prototypes et recherché des compromis afin de résoudre ce problème. Et avec quelques restrictions sur les paramètres, ils ont publié une
version en boîte de la partie client de BILLmanager 6 Beta en mai 2018.
Département UX de designers
Alors que le département UX résolvait les problèmes avec la flexibilité de BILLmanager, la direction a décidé de traiter les interfaces des autres produits de l'entreprise et de mettre en œuvre Scrum et les processus de conception dans d'autres équipes. Nous avons commencé avec VMmanager 6, réuni une équipe de produits à part entière composée de participants de différentes compétences, autonomes pour créer un produit: back-end, front-end, testeurs, UX-designer, chefs de produit et de projet. Il est devenu clair que tous les autres produits seront progressivement développés par les mêmes équipes, et nous avons entamé une transition progressive vers une structure matricielle de gestion du développement produit.
Dans ce contexte, le département UX aurait dû cesser de faire partie des équipes produits. Après la sortie de la partie client de BILLmanager 6 Beta, la plupart du département UX est devenu une partie de l'équipe BILLmanager et est maintenant engagé dans la résolution de problèmes architecturaux et la version mobile de la partie client. Dans le même temps, nous avons commencé à travailler sur la formation d'un département UX qui pourrait travailler avec tous les produits simultanément.
Designer UX pour chaque équipe produit. Design Competency Center
ISPsystem propose quatre produits complexes. Nous nous sommes assurés que chaque équipe possède son propre concepteur UX. Il s'agit de la personne responsable de la conception de son produit. Ses responsabilités incluent la préparation de prototypes pour la planification de sprint et le contrôle que tout ce qui est nécessaire pour les développeurs est dans la version pixelperfect. Il est le chef de file de la politique de conception de l'entreprise pour son équipe. L'une de ses tâches consiste à s'assurer que le résultat du développement est un produit qui correspond à la conception.
Nous avons également plusieurs personnes qui forment le centre des compétences de conception de l'entreprise. Il comprend un concepteur visuel. Ce centre forme la politique de conception des produits de l'entreprise, travaille sur le système de conception. Elle enseigne également aux concepteurs UX en équipe, résout les problèmes de conception les plus complexes, enseigne aux développeurs, aux chefs de produit et de projet comment travailler avec les concepteurs UX et met en œuvre les processus de conception dans les équipes Scrum.