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.