Mieux traduire les besoins utilisateurs à l’équipe de développement

Comprendre les besoins des utilisateurs est indispensable pour la réussite d’un projet. Les analyser et les décrire n’est pas une tâche aisée, exprimer un concept capable de satisfaire à ces attentes l’est encore moins.

Une illustration adaptée facilite la compréhension d’un concept et aide les équipes en charge de l’implémentation et les utilisateurs à se projeter dans l’utilisation du produit. Cependant elle n’est pas suffisante. Pour être efficace, il faut également des descriptions détaillées des interactions nécessaires.

Faites du maquettage fonctionnel

Le maquettage fonctionnel (des termes très variés sont utilisés pour décrire cette activité, tel que zoning, wireframing, paper prototyping ou maquettage papier, storyboarding, mockup design, croquis etc.) permet de traduire les besoins des utilisateurs en premier jet d’écrans statiques.

Les maquettes fonctionnelles illustrent de décrire :

  • les informations qui répondent aux besoins, aux attentes et aux usages des utilisateurs ;
  • l’endroit adéquat pour les afficher ;
  • sous quelle forme les proposer pour respecter la logique des utilisateurs ;
  • les différents niveaux d’interaction ;
  • les fonctionnalités sous-jacentes nécessaires ;
  • la gestion des cas d’exception et des erreurs.

Les maquettes fonctionnelles présentent l’énorme avantage de pouvoir tester vos premières idées de conception directement avec les utilisateurs.

A ce stade, on laisse de côté tous les aspects de design graphique et de développement technique. On s’attache essentiellement au fond (on parle de « low fidelity mockup ») et on laisse de côté la forme (« high fidelity mockup »).

Wireframes annotés

Même si les maquettes fonctionnelles ont une apparence singulière, les informations proposées et leurs positions doivent être au plus proches des écrans finaux. Elles doivent notamment proposer des contenus réels (la longueur des titres est par exemple importante pour un designer graphique, sous peine de devoir revoir sa copie et de perdre du temps plus tard) et explicites.

Il est possible d’enrichir les maquettes fonctionnelles d’interactions de base (par exemple des liens, des boutons d’action) mais veillez à ne pas vous laisser envahir par les possibilités techniques ! A ce stade l’objectif n’est pas de relever des challenges techniques, il est définitivement fonctionnel.

Les maquettes fonctionnelles permettent de mettre à plat certains concepts mais elles ne sont pas suffisantes. Elles doivent impérativement être enrichies d’une cinématique d‘écrans.

Proposez une cinématique d’écrans

Les maquettes fonctionnelles statiques décrivent les écrans principaux de manière individuelle et indépendante. Malgré tout, dans votre esprit (sur base de votre analyse orientée utilisateur), chaque écran est suivi d’un autre, vos scénarios sont rodés et bien établis. Pour communiquer ces différents cas d’utilisation et séquences de pages, utilisez des cinématiques d’écrans.

Story telling

La cinématique d’écran permet aux équipes :

  • de comprendre visuellement comment les maquettes s’agencent entre elles ;
  • de se forger plus simplement une représentation mentale du fonctionnement attendu ;
  • de comprendre la tâche de l’utilisateur (ses objectifs) et comment il les atteint ;
  • d’avoir une représentation globale des développements à réaliser ;
  • de cerner plus directement les choix importants en matière d’interface.

Analyse de la tâche

Tout comme les maquettes fonctionnelles, la cinématique est guidée par l’analyse de la tâche. Cette analyse, faite auprès des utilisateurs cibles sur base d’entretiens, offre la possibilité de savoir quels sont leurs objectifs, comment ils souhaitent les atteindre (quelle séquence de page adopter) et comment organiser les informations sur chaque écran.

Racontez des histoires

La cinématique d’écrans doit avant tout correspondre à des situations d’utilisation et s’intégrer dans un processus concret. Pour illustrer cette correspondance, vous pouvez faire du storytelling.

Le storytelling vous aidera à projeter vos maquettes dans un contexte réel d’utilisation, avec un utilisateur ayant une histoire et des envies.

Bien évidemment, vous ne devez pas faire preuve uniquement d’originalité. Votre storytelling doit se baser sur ce que vous a appris votre analyse orientée utilisateurs (les profils détaillés de vos utilisateurs, l’analyse de la tâche, le contexte précis dans lequel ils vont utiliser le produit).

Vous pouvez par exemple utiliser les personas (technique permettant de décrire les caractéristiques et les attentes des utilisateurs).

Exemple de persona

Un persona peut être présenté comme suit : « Je vous présente Robert Vanstad, 40 ans. Robert est très peu habitué aux nouvelles technologies mais a décidé de s’y mettre récemment. Il souhaite faire un cadeau à sa femme, un bijou dernier cri. Pour cela il prospecte pour s’abonner aux newsletters des sites références en la matière. Dont celle que vous allez développer. Votre mission si vous l’acceptez… etc. ».

Les histoires permettront à l’équipe de mieux comprendre les besoins utilisateurs et de s’approprier plus facilement le projet. Ainsi vous inciterez vos interlocuteurs à s’imprégner du contexte et identifier des particularités ou des exceptions dans l’utilisation du produit.

Documentez les fonctionnalités

Les maquettes fonctionnelles et les cinématiques d’écrans illustrent les principes d’utilisation. Elles permettent de se projeter facilement dans l’usage d’un produit mais ne sont pas suffisantes pour développer les fonctionnalités attendues.

Pour mettre toutes les chances de votre côté, vous devrez les accompagner de descriptions détaillées notamment en indiquant les conditions d’affichage de certaines informations, les règles de validation, de traitement, etc. Les plus fines particularités des différents cas d’utilisation doivent être documentées.

A ce stade, vous serez tentés de décrire les fonctionnalités directement dans les maquettes sous la forme de commentaires. Prenez garde, vous risquez rapidement de masquer une grande partie de l’écran et de nuire à leur compréhension. Ainsi, certaines données ponctuelles pourront être mentionnées sur les maquettes mais pour tout le reste, nous vous conseillons vivement d’enrichir vos livrables d’une documentation fonctionnelle.

Cette documentation peut être organisée de manière très différente. Parfois vous choisirez de la séquencer écran par écran, d’autres fois de la structurer en cas d’utilisation ou encore en fonction des processus métier.

Votre document devra décrire entre autres :

  • les conditions et formats d’affichage des informations ;
  • les traitements déclenchés lors de l’activation de chaque action ;
  • les messages de confirmation nécessaires ;
  • les comportements d’affichage lorsque certaines données ne sont pas renseignées ;
  • le comportement lorsqu’une technologie n’est pas disponible ;

En parallèle, voici typiquement des informations que vous pourriez faire apparaître directement sur vos maquettes :

  • les niveaux de titre ;
  • les rafraîchissements de données ;
  • l’emplacement des messages d’erreurs ;
  • la conséquence des actions utilisateur (par exemple « cliquer sur un bouton d’action ») ;
  • les références vers la description fonctionnelle détaillée.

Rassurez-vous, vous ne pourrez pas tout spécifier et vous devrez de
toute façon accompagner les équipes lors de la réalisation, en
aiguillant les différents choix encore ouverts par des évaluations heuristiques et des retours utilisateurs.

Conclusion

Vous l’avez compris, le maquettage fonctionnel ne se limite pas à des compétences techniques et à l’utilisation d’un outil. Il doit découler de l’analyse orientée utilisateur, analyse au cœur du métier UX.

Cependant quel que soit le niveau de qualité de cette analyse, une mauvaise communication est cause d’échec. Ne laissez pas de place aux interprétations et soyez le plus précis possible lors de la présentation de cas d’utilisation et des maquettes d’écran.

Enfin, quel que soit les livrables que vous proposez, ne laissez surtout pas l’impression qu’ils sont figés. Engagez vos interlocuteurs et demandez leurs des conseils pour améliorer ce que vous proposez. Sollicitez-les pour traduire votre langage fonctionnel en langage technique et ainsi améliorer la compréhension de votre analyse.