Quand les mock-up ne disent pas tout : pensez à documenter ses designs
Lors de la conception d’une fonctionnalité, de nombreuses décisions sont prises au fil des itérations, certaines sont conservées, d’autres non et il devient souvent compliqué de garder une trace claire et fiable.
C’est encore plus vrai pour un stakeholder qui n’a pas suivi au jour le jour les évolutions apportées.
Par manque de rigueur, ou de méthode, on peut perdre un temps précieux à devoir expliquer à plusieurs reprises le comportement attendu d’une partie de l’expérience et/ou les choix qui ont été validés.
Afin de s’éviter cette tâche fastidieuse, mais aussi pour pérenniser l’information, il peut être judicieux de compléter ses maquettes par une documentation design. Ce livrable fera office de référence lorsqu’une question se posera sur un comportement attendu de la fonctionnalité.
Parmi les avantages d’une documentation design complète et détaillée, on retrouve :
- Un onboarding plus rapide des stakeholders
- Une référence pour l’intégration technique par les développeurs
- La réduction des différences entre les intentions de design et l’implémentation technique
- La simplification du travail du PM lors de la catégorisation et planification des tâches
Il est important de noter que la responsabilité de ce process est variable en fonction des structures dans lesquelles vous serez amenés à travailler. Elle peut aussi bien tomber dans le périmètre du Product Manager que du Product Designer.
Dans tous les cas, bien savoir documenter ses designs reste une compétence importante à développer pour un Product Designer, que ce soit lors de la rédaction d’un livrable ou simplement pour gagner en méthodologie et en qualité de travail.
Entrer dans le détails des maquettes grâce aux User Stories
Afin de rendre la documentation plus systématique et de mieux la prévoir dans vos étapes de conception, il peut être judicieux de se baser sur le framework des Users Stories.
Elle représente le dernier niveau de granularité de votre fonctionnalité et ne peut pas être scindée en d’autres éléments plus petits. Elle doit être dans la mesure du possible indépendante et compréhensible sans informations additionnelles.
Pour rédiger efficacement une user story, on peut utiliser la formulation suivante :
Si on prend deux exemples sur notre application bancaire :
- En tant que particulier, je veux pouvoir cliquer sur mes bénéficiaires, pour pouvoir leur faire un virement.
On voit alors que les user stories entrent dans les détails de la conception pour donner du contexte à l’équipe et ainsi simplifier l’UI et les interactions proposées.
Attention tout de même à ne pas tomber dans l’extrême, et tenter de documenter l’intégralité de votre fonctionnalité, au risque d’y passer beaucoup trop de temps sans pour autant générer de la valeur pour votre projet.
L’important est de toujours faire preuve de discernement et de se demander :
Si la réponse est oui, alors il est judicieux de rédiger les users stories associés dans votre documentation design.
Tout n’est pas toujours visible dans les maquettes
Bien souvent, lorsque l’on design des maquettes, on a tendance à ne faire figurer que la partie visible de l’iceberg, celle qui décrit l’intention derrière la fonctionnalité.
Mais à côté de ce cas nominal, il existe tous les cas secondaires (ou edge cases) qui seront une matière très riche pour les développeurs. Ils comprennent entre autres :
- Les statuts d’erreur
- Le contenu contextuel (tooltip, modales…)
- Les empty states
Il est essentiel de bien anticiper et de répertorier ces modificateurs puis de les lister dans la documentation pour avoir une couverture fonctionnelle maximale des cas d’usage.
Bien entendu, si cette modification doit être représentée visuellement, on peut venir y associer un nouveau composant conçu spécifiquement à cet effet. Mais d’ailleurs, comment faire efficacement le lien entre sa documentation fonctionnelle et ses maquettes ?
Les GIF sont vos amis
Il n’y a rien de plus frustrant pour un designer que de passer du temps à concevoir des interactions poussées dans un prototype, pour qu’au final votre travail ne soit pas consulté, le format n’étant pas toujours adapté à la création des tâches pour l’intégration.
Soyez prévoyant lorsque vous rédigez votre documentation et utilisez un outil pour capturer des courtes boucles vidéos au format GIF qui viennent illustrer le comportement que vous avez décrit.
Ainsi, vous faites le lien entre vos maquettes et votre documentation et vous vous assurez que l’interaction sera bien comprise par vos stakeholders et développeurs.
A ce propos, LICEcap est une solution gratuite et open source sous Windows et macOS pour capturer des GIF en un clic.
Documentation animée en GIF présentant les micros interactions de la feature.
Partagez votre documentation régulièrement
Lorsque vous concevez une maquette, vous avez sûrement l’habitude de réaliser des design reviews ou critics avec d’autres designers.
Il en va de même pour la documentation en la partageant au Product Manager et au développeur associé à votre projet. Ces deux stakeholders pourront vous remonter des feedbacks sur des enjeux cruciaux qui pourraient à terme avoir de l’impact sur la solution proposée :
- Faisabilité technique
- Enjeux business
- Comportement inhabituel et recommandation d’alternatives
- Réutilisation de composants existants
Faites attention à bien garder une référence précise et à jour avec les dernières itérations pour faciliter le travail pendant le développement.
Les développeurs vous remercieront
En travaillant sur la documentation en parallèle de vos maquettes, vous assurez une cohérence maximale à la fonctionnalité que vous cherchez à produire. Bien souvent, les développeurs se servent de ce livrable en complément de vos maquettes pour en dériver une spécification technique.
C’est un gain de temps incroyable pour les équipes et le point bonus, c’est que vous pourrez vous servir de cette documentation comme d’une grille de lecture pour effectuer la Q&A avec les développeurs et ainsi créer une relation de confiance en partageant un langage commun.
Faites preuve de bon sens
Toutes les fonctionnalités sur lesquelles vous allez travailler ne nécessitent pas une documentation détaillée aussi poussée que ce que nous avons pu voir. Il est important de faire la part des choses pour ne pas complexifier outre mesure un projet avec un périmètre réduit.
En remplacement de ce livrable, il peut être judicieux d’organiser une session avec le développeur chargé de l’implémentation pour lever les quelques doutes sur la faisabilité technique en amont.
Ainsi, vous évitez le process parfois long et fastidieux de la rédaction et gardez la valeur de partager vos intentions de design avec les équipes.
À vous de positionner le curseur selon la complexité du projet. L’objectif à terme étant d’assurer une cohérence maximale entre les intentions de design et la réalisation technique, peu importe la méthode mise en œuvre.
