C’est quoi un storyboard ?

Définition du storyboard

Le storyboard est le pilier central d’un projet. Rédigé par le chef de projet, il s’agit du document qui va décrire chaque fonctionnalité que va contenir l’application mobile. La description sera toujours fonctionnelle, et non pas technique.

Initialement, le storyboard est utilisé dans le secteur du cinéma. Cependant, de part son impact visuel et sa facilité d’utilisation, il vient de plus en plus remplacer le cahier des charges dans la gestion de projet.

 

Objectifs et enjeux

L’objectif d’un storyboard est d’avoir un déroulé exhaustif de tout ce que l’utilisateur va pouvoir faire dans l’application, tant dans les cas d’utilisation normale de l’application, que dans les cas où l’utilisateur se trompe, et ce, afin qu’il n’arrive jamais dans une impasse, et qu’il soit toujours guidé dans sa navigation.

Avoir un storyboard qui décrit en profondeur toutes ces gestions de cas est donc un enjeu crucial car il va permettre au client d’avoir une véritable vision d’ensemble de son application et de la définir pour le développement. Quand le client est satisfait du storyboard, ce dernier est validé, puis il sert de document de référence aux équipes de développement.

Comment construire un storyboard ?

Le storyboard doit donc être un document très facile à comprendre pour le client. Pour ce faire, chaque page est structurée de la même manière : une maquette visuelle représente une fonctionnalité accompagnée d’un texte explicatif, qui va décrire cette fonctionnalité et ses gestions de cas.

Exemple : le chef de projet décrit la fonction de connexion à une application. Il explique ce qui se passe quand l’utilisateur se connecte avec son login et son mot de passe, mais également ce qui se passe s’il entre un mauvais login, ou un mauvais mot de passe.

 

La différence entre un cahier des charges et un storyboard ?

A première vue, un storyboard et un cahier des charges semblent donc identiques, car ils servent tous les deux à décrire en profondeur un projet. Les deux principales différences, viennent du fait qu’un cahier des charges sera rédigé selon un angle technique, car il est principalement destiné aux développeurs, et qu’il n’intègre pas les maquettes en vis à vis des fonctionnalités. Il y a donc un double risque d’avoir un document rébarbatif à lire. Le premier étant que le client ne comprenne pas tous les enjeux de son application, et le second, que les équipes de développement ne lisent pas tout le document. C’est pourquoi chez Beapp, nous réalisons uniquement des storyboards.