Si vous avez lu le whitepaper IHM d'OCTO vous êtes certainement familier avec la notion de story-board, un des livrables des chantiers Ergonomie de nos projets. Le story-board, outil de travail de l'ergonome pour proposer des idées et concepts est un livrable qui se place en entrée de la création graphique (habillage des écrans).
Si nous en restons là le stoy-board est sous-exploité. Or il peut être bien plus important et structurant dans nos projets jusqu'à être un référentiel projet à part entière.
Comment ? Pourquoi ? Des exemples ? C'est tout l'objet de cet article, partager les usages détournés, prolongés des story-boards et en particuliers sur nos projets mobiles où la part d'ergonomie est cruciale et où le story-board est essentiel.
Combien de fois vous êtes vous demandé de quelle fonctionnalité votre interlocuteur vous parlait ? Combien de fois avez-vous eu du mal à situer ou à exprimer une demande sur un projet ?
Le problème vient du fait que chaque type d'interlocuteur a une vision différente du même projet, une vision dans laquelle il navigue facilement et sait se repérer rapidement
Cette multiplicité des langages et leur complexité intrinsèque rend conséquent l'effort que doit faire chaque interlocuteur pour se placer dans un mode où il comprend et où il est compris de tous.
Ainsi, le DAT est trop complexe pour un responsable produit, le cahier des charges trop conceptuel, et le projet dans l'IDE ... c'est le projet dans l'IDE.
Il manque le langage universel, celui que tout le monde connait et dans lequel chacun saura naviguer. Le story-board est probablement ce langage.
Tout le monde sait lire et comprends un story-board, tout le monde l'a sous la main, il n'est pas ambigüe et on y navigue facilement (sinon c'est qu'il y a un vrai problème d'ergonomie). On peut ainsi référencer chaque écran ce qui facilitera grandement la communication. On peut également référencer chaque composant de l'interface comme les textes affichés et ainsi recevoir des demandes de ce style :
Changer le texte 3 de l'écran 5 par : Saisir votre mot de passe
Plutôt que
A la place de saisir votre code je voudrais "Saisir votre mot de passe" dans l'écran d'authentification
Pour exploiter au mieux le story-board comme outil de communication il faut
Le storyboard peut également être un réel input à l'architecture et en particuliers dans les projets mobiles (iPhone, Android, ...). On l'a déjà évoqué à plusieurs reprises, la latence des réseaux mobiles (parfois plusieurs secondes par appel) poussent à développer des services orientés écrans. Dans ce cas là l'ergonomie est un entrant dans la définition de ces services.
On va en extraire les données nécessaires pour définir les services. Une fois ces services définis vous pouvez annoter le story-board avec les identifiants des services appelés par chaque écran et avoir ainsi une vision claire et synthétique de l'usage de chacun. Ces annotations seront utiles autant à l'architecte qu'aux développeurs.
Pour que le story-board serve au mieux l'architecture il faut
Dans les pratiques agiles, le management visuel est largement encouragé avec l'usage de Post-Its décrivant les histoires à implémenter, que l'on passe d'un état à l'autre.
Lorsque l'on dispose des maquettes des écrans, pourquoi ne pas les utiliser pour remplacer ou compléter les histoires ?
Je l'ai fait récemment sur un projet lors de la phase de réalisation des écrans. Les Posts-Its iPhone se déplaçaient sur le scrum board. Le management visuel est poussé à l'extrême, la recette est généralement plus pertinente car lorsqu'il bouge le Post-It le développeur peut le comparer directement à ce qu'il a développé.
Pour que les maquettes puissent être utilisées comme des User Stories il faut :
L'un des objectifs d'une documentation de développement est de rendre l'existant accessible à un nouveau développeur, l'aider à se faufiler dans les méandres des classes, des packages, ...
Lorsque l'on travaille sur une application Web, mobile, ... les écrans sont ce que la MOA va le plus vouloir modifier et ce qu'il faut pouvoir retoucher facilement 2, 3 ou 6 mois après.
Dans le prolongement de ce que j'évoquais dans le premier paragraphe sur l'outil de communication, le story-board peut servir de documentation des développements en l'annotant des noms de classes, packages, ...
Un nouveau développeur pourra ainsi se repérer plus rapidement et visualiser plus facilement ce que prends en charge une classe ou un package.
Cet article montre quelques cas d'usages détournés du story-board et a la vocation de lui donner plus d'importance qu'il n'en a sur nos projets aujourd'hui (quand il existe). Lorsque chacun s'approprie le document il peut réellement améliorer la compréhension, la productivité et la qualité de toute une équipe à moindre frais.
Ce document nécessite tout de même d'être mis à jour très régulièrement pour ne pas souffrir d'écarts avec la réalité. Le document doit donc être partagé (Dropbox par exemple), et chacun a la responsabilité d'y mettre les informations qu'il veut partager :
Et vous quel usage en faites-vous ? Allez-vous essayer ces pratiques ? Répondez en commentant ce post.