Wireframing StoryBoard en tant que spécification de conception UX complète (livrables)
Du point de vue d'un concepteur IA/UX, que pensez-vous du storyboard filaire HiFi pour les applications Web, au lieu d'une approche livrable classique?
J'ai lu une très bonne documentation sur les livrables de Mobile Design Information Architecture:
http://www.slideshare.net/bryanrieger/modeling-the-mobile-user-experience
En résumé, il propose des "storyboards filaires" (ou esquisses de storyboards), basés sur des vues, des états et des événements, dans son ensemble un projet livrable, au lieu de classiques, basés sur de nombreuses techniques différentes comme:
- Plans du site (conception de la navigation)
- Processus utilisateur/flux de tâches (conception d'interaction)
- présentation de la description de la page filaire (conception des informations et de l'interface)
- Flux de travail de page d'interface utilisateur (navigation et conception d'interaction)
- Modèle de conception (conception d'interaction)
Pour la conception mobile, cela a vraiment fière allure, car avec une seule technique (storyboard), vous pouvez couvrir toutes les techniques précédentes. Vous n'avez pas besoin de créer, par exemple, une carte de flux de tâches utilisateur, car il vous suffit de suivre le storyboard. Ou un SiteMap, car là encore, le storyboard fournit toutes les informations nécessaires.
Que pensez-vous du storyboard pour les applications Web? Pourrait être utilisé après avoir esquissé une section où les parties prenantes et les concepteurs ont convenu de l'approche? Des outils comme Balsamiq, keynote Kungfu ou UX Prototyping pourraient-ils être utilisés à la place des livrables?
Dans l'ensemble, je pense que les outils individuels sont plus polyvalents.
Je pense que plus vous mélangez en un seul livrable, plus il est difficile de se concentrer sur les aspects individuels. Comme l'exemple des wireframes HiFi que j'ai mentionné dans mes commentaires, les clients sont souvent distraits par les mauvais détails.
L'autre problème est que j'ai l'impression qu'un storyboard correspond davantage à un cas d'utilisation. Comment un storyboard peut-il rendre compte de tous les différents chemins possibles qu'un utilisateur pourrait emprunter? Cela pourrait être un excellent moyen d'illustrer et d'expérience globale, mais pas un moyen efficace d'évaluer ces aspects individuels du projet. Mais il y a un temps et un lieu pour cela. Je pense qu'un storyboard de haute qualité peut en dire long sur les investisseurs.
Pour les décideurs au quotidien, je pense que les outils individuels sont plus efficaces. Il crée une base et un cadre solides où les modifications ne peuvent pas être apportées à la légère. Chaque décision que vous prenez devrait avoir un but et devrait avoir le soutien de ces outils individuels. Il gardera les choses sur la bonne voie.
Respectez les artefacts individuels (objectifs utilisateur, plans du site, wireframes annotés) et assurez-vous qu'ils sont cohérents sur tous, sans être redondants.
La prémisse "juste assez d'informations" maintient vos artefacts concentrés et avec la bonne quantité de faits à l'appui.
Pour les premières idées, je pense que le storyboarding pour mobile, ou tout projet avec des états changeants, est une excellente idée.
Mais ... je ne pense pas qu'il propose du tout des storyboards. Il propose de construire des wireframes avec interactivité en utilisant le langage de traitement.
Ce qui est bien, mais cela semble inutile. Vous pourriez apprendre HTML, CSS et jQuery et faire exactement la même chose, en plus vous auriez du code que vous pourriez utiliser dans le projet final et des compétences utiles pour autre chose que la création de wireframes interactifs.
C'est exactement comme ça que je le fais. Créez un filaire interactif cliquable en HTML5/CSS3/jQuery (jQ Mobile s'il s'agit d'un projet mobile). Fonctionne très bien.
ÉDITER:
Je suis d'accord avec la présentation de Bryan. Les wireframes et les prototypes sont des livrables clients terribles car ils sont gonflés et presque toujours obsolètes/synchronisés.
Je ne sais pas si je suis d'accord pour dire que le système de storyboard basé sur XML est différent. C'est peut-être le cas. J'aurais besoin de plus de détails.
Ma réaction instinctive, cependant, est que si vous allez faire de la hi-fi, allez jusqu'au bout. En fait, fonctionne dans le support, il sera intégré. S'il s'agit d'une application Web, vous avez en fait créé le code HTML CSS et JS requis pour communiquer les interactions.