Par
Mathieu Collet dans
Conception le
17 décembre 2007 |
1 commentaire J’ai déjà évoqué le storyboard dans deux précédents articles :
Dans cet article, je vais vous présenter une méthode complète pour bien concevoir un storyboard Web en précisant :
- Quels outils utiliser ?
- Qui faire participer ?
- Quel degré de granularité associer à un storyboard ?
Quels outils utiliser ?
J’ai évoqué dans les précédents billets les supports électroniques envisageables) pour un storyboard (Visio, PowerPoint, Axure). Cependant ce n’est pas suffisant.
Pour donner sa pleine mesure à un storyboard et entrer le plus possible dans le détail et orienter la maquette vers ce que l’on désire faire, il est nécessaire d’utiliser les outils/ressources suivants :
- Outil de capture : Snag-it (payant), Gadwin System (Freeware), FastStone Capture (Freeware) ou encore FireShot (plugin Firefox)
=> Cela va permettre de récupérer des parties du site existant (photos, logo, etc…) ou d’autres ressources. Cela va habiller et donner vie au storyboard
- Banque de pictogramme : Iconfinder.net ou Challenger.se
=> Toujours dans le but de détailler au maximum le storyboard et de limiter les écarts entre la vision apportée par le concepteur et les développements à suivre.
Qui faire participer ?
Le contexte des applications métiers
La réalisation de storyboard dans le cadre d’une application métier doit se faire dans un premier temps en coopération avec la maîtrise d’ouvrage (MOA) qui connaît les besoins métiers, les premiers besoins des utilisateurs et les objectifs d’utilisabilité recherchés (efficacité, apprentissage, etc…)
Ensuite, il est nécessaire de confronter le storyboard à un panel représentatif d’utilisateurs afin de valider les concepts.
Il convient enfin de confronter les propositions du storyboard à la maîtrise d’oeuvre (MOE) afin de valider la faisabilité technique.
Le contexte des sites web
Dans le cadre d’un site web, e-commerce à fortiori, le storyboard se fait en collaboration avec les responsables marketing/communication. Il est souvent important d’ajouter une dimension éditoriale dans le storyboard afin de renforcer sa valeur ajoutée.
Tout comme pour les applications métiers, il est ensuite recommandé et nécessaire de valider le storyboard d’abord avec les utilisateurs et ensuite avec la technique.
Quel degré de granularité associer à un storyboard ?
J’en ai déjà parlé auparavant, plus le storyboard est détaillé, plus le risque d’écarts est réduit. Le détail se formalise par :
- Une premier niveau d’arboresence de l’application / site
- Du vrai contenu avec un effort particulier sur les dénominations utilisées (d’où un besoin d’assistance d’un expert éditorial)
- Des premiers objets graphiques : photos, logos, pictogrammes. En ce qui concerne l’utilisation de couleurs pour donner des tendances, ce n’est pas recommandé car cela peut influencer la perception de l’ergonomie de l’interface. En effet, un ergonome/concepteur n’est que très très rarement un web designer / directeur artistique accompli. Leur expertise sera en revanche intégrée dans la phase suivante au storyboard qui est la création de l’identité graphique.
- Des commentaires pour justifier le placement, l’existance des différents composants
- Des commentaires pour donner un premier niveau de spécifications fonctionnelles
Poster un commentaire
C’est une trés bonne synthèse mais j’ajouterais deux petites choses…
Tout d’abord, je dirais que le niveau de granularité est trés contextuel, dépendant à la fois de plusieurs facteurs:
- du type de projet (sur des cycles courts en mode Agile, on ne travaille pas de la même manière que dans des cycles trés séquentiels)
- du moment dans le projet et des informations dont on dispose (c’est lié au point précédent)
- du temps dont on dispose pour réaliser les Wireframes
- des destinataires (qui ne réclament pas le même niveau de détail et de commentaires)
- de l’utilisation qu’on en aura (une approche démo, test ou avant vente nécessitera plus de précision, de préparation et de graphisme)
Ensuite, et c’est une remarque plus terminologique… storyboard et wireframe sont souvent utilisés comme des synonymes; or pour moi il n’en est rien.
Il s’agit de deux livrables différents quant à la forme, au niveau de détail et aux objectifs.
La wireframe (ou « zoning détaillé », « blueprint ») est la représentation de l’écran, c’est à dire une représentation plus ou moins évoluée établie essentiellement pour positionner fonctionnalités, contenu et interactions. La granularité et le graphisme sont trés contextuels. C’est un livrable que je fournis à chacune de mes interventions. J’accompagne chaque wireframe des règles ergonomiques.
J’utilise le storyboard un peu moins souvent (en tant que livrable). Il correspond à un enchaînement de plusieurs écrans, représentés sous une forme ultra simplifiée, avec seulement l’interaction principale permettant de passer de l’un à l’autre (un lien / un bouton selon les cas). Il m’est utile pour mettre le focus sur des tâches d’importance et ne représentent qu’un scénario. Je l’utilise par exemple pour décrire les scénario principal d’un use case, sans m’attarder sur les variations ou extensions. En somme, il représente un script ou un scénario majeur; aucun design, c’est seulement une vue schématique.