Dernière phase de notre réponse à l’ami Jean-Bernard (troisième et dernière question) que je cite:

Finalement pouvez-vous m’indiquer si le stroyboard est d’un réel utilité pour le designer ou plutôt une contrainte. Un post sur les storyboard, zoning et autres seraient les bienvenues.

Comme a son habitude, le [perfide] Jean-Bernard cache deux questions dans une seule phrase:
- qu’est ce qu’un storyboard?
- le story board est-il utile (pour le designer)?
C’est une question ô combien intéressante pour toutes les personnes qui travaillent ou voudraient travailler un jour ou l’autre dans le web…

1. Storyboard – définition
Qu’est ce qu’un storyboard? Question délicate à expliquer sans illustration… Pour faire simple, un storyboard vous permet de poser sur le papier les différentes fonctionnalités de votre site, en représentant votre écran sous la forme d’une feuille A4 format paysage.
Mmmm l’explication devient un poil foirreuse, le mieux serait encore de vous illustrer ça. En même temps faire un storyboard c’est long et chiant (mais on y reviendra dans la deuxième partie), alors je vais vous illustrer ça avec un storyboard pour ce blog (TravailleursDuWeb), juste une page, mais pour vous donner une idée de ce que ça veut dire.
(cliquez sur l’image pour télécharger le ppt)

Vous voyez donc, que le storyboard est une représentation approximative mais exhaustive de votre site web ou service web.
Dans votre storyboard vous devez indiquez toutes les fonctionnalités du site web, les liens vers les différentes pages, les règles de gestion éventuelles, les images, etc…
Le storyboard peut avoir trois formes différentes:
- storyboard rough: c’est la version la plus épurée, juste quelques pages et pas trop de détail
- storyboard standard: c’est la version standard qui couvre la majorité des fonctionnalités
- storyboard détaillé: c’est la version barbare, qui couvre toutes les pages, toutes les fonctionnalités et tous les cas de figures (le document monte très vite même pour un site de taille raisonnable au delà des 100 slides)

2. De l’utilité du storyboard
Le but du storyboard est de servir de base de travail, d’outil de communication entre des groupes de personnes ou corps de métiers qui bien souvent ne parlent pas la même langue (tout le monde parle bien le français… mais) ou ne se comprennent pas bien. Par exemple, prenez un commercial, un directeur artistique, un chef de projet fonctionnel, un marketteux, un développeur et vous verrez que tous ces gens parlent mais ne se comprennent pas à 100%.
Le rôle du storyboard est donc de poser sur le papier toutes les fonctionnalités et voir si tout le monde comprend bien la même chose, est ce la chose que le commercial à vendu au client, cela donne-t-il des idées au DA, est ce que le marketteux à des remarques, etc…
Le storyboard est une phase fastidieuse (je traduis : chiant) et longue, mais elle a plusieurs avantages:
- s’assurer que le site que l’on est sur le point de mettre en production est bien celui que le client veut (oui je sais ça parait idiot, pourtant…)
- s’assurer que toutes les fonctionnalités sont bien présentes (qu’on n’a pas oublié de fonctionnalité majeure – ou mineure)
- s’assurer de la cohérence du projet (qu’il n’y a pas de trou dans la navigation, que l’enchainement des pages est harmonieux, etc…)
- évaluer de façon plus précise l’ampleur du projet et son temps de développement / coût
- faire valider sur le papier des fonctionnalités à un client (c’est idiot, mais un client qui a validé un story ne peut guère -ou alors à ses frais- revenir 25 fois sur telle ou telle fonctionnalité)

A la question existentielle “Quel est l’intérêt du storyboard?” je repondrais pour résumer ceci: passer du temps sur la phase de conception et le storyboard en particulier n’est jamais du temps de perdu… modifier en amont le projet est un acte salvateur qui vous fera économiser un temps précieux en production (et en développement en particulier, qui est sans doute le poste le plus couteux). Modifier un storyboard peut prendre quelques heures maximum, transformer un site web en cours de réalisation peut demander des jours, voir des semaines de modification. Le calcul est simple.
Donc storyboardez… sinon vous risquez d’aller dans le mur.
Reste deux écueils:
- faire comprendre à votre client que non son site ne sera pas des gros carrés bleus et verts sans image et moche, mais que ce n’est qu’une représentation et non le rendu final. Beaucoup de clients ont du mal avec les storyboard, il faut donc expliquer, éduquer, ré-expliquer…
- choisir le bon mode de storyboard: si vous avez une équipe soudée qui avance vite et communique bien, choisissez le draft, pour un client chiant (par expérience) et tatillon optez pour le modèle détaillé, pour le reste un storyboard classique devrait faire l’affaire.

Personnellement j’appuie toujours beaucoup pour avoir des storyboard de la part des fonctionnels avec lesquels je travail, on oublie les mails d’explication, les gribouillis, les listes de fonctionnalités, je veux avoir une vue globale et détaillée de ce dans quoi je me lance. Beaucoup râlent (énormément “Oh la la avec tes story t’es chiant!”) mais ils n’ont pas le choix. Souvent (très souvent) cela leur permet de voir des pans entiers de leur site qu’ils n’avaient pas (ou mal) conçu ou juste oublié. Pour moi cela me permet d’évaluer plus précisément les délais et surtout le coût de développement d’un projet.
Par expérience j’ai rarement vu de projet se dérouler correctement sans storyboard, même avec une très bonne équipe, pour justement ce principe de communication difficile… pour les fonctionnels cela paraît un “petit module” alors que les conséquences techniques peuvent être importantes, donc plutôt que de tentez le diable, je storyboard (même si je vous l’avoue je DETESTE faire ça, il n’y a rien de plus chiant).

Voilà, j’espère avoir été suffisamment clair (bien que un tel sujet mériterait beaucoup plus) et comme d’habitude si vous avez des commentaires…
Je vous rappelle aussi que si vous avez des questions, remarques, suggestions divers et variées, etc… il vous est possible de m’envoyer un petit mail (je réponds à tous mes mails, dès que j’ai un peu de temps), alors n’hésitez pas!

Cet article a été posté le Thursday 16 August 2007 à 12:54 am et a été classé dans la catégorie Développement, Gestion de projet, Graphisme, Lexique, Outils.