Comment documentez-vous vos flux d'interaction?
Depuis de nombreuses années, j'utilise une version évoluée de Jesse James Garrett style de diagramme Visvocab pour documenter l'architecture de l'information et les concepts de conception d'interaction.
Aujourd'hui, bien que nous fassions beaucoup plus de transformations sur la page au lieu de naviguer vers des pages individuelles: des choses comme des vues en accordéon, des boîtes à lumière, des superpositions, AJAX inclusions à la demande, etc. Visvocab de JJG a maintenant 10 ans et n'a donc pas été conçu pour répondre à tous les nouveaux modes d'interaction que nous avons aujourd'hui.
Quel style de diagramme ou notation utilisez-vous pour cartographier vos flux d'interaction?
Pour commencer, je recommande de regarder t son excellent article de UX Matters qui explique comment étendre le vocabulaire visuel de Jesse James Garret pour refléter de riches applications interactives qui recommande de mettre en évidence les interactions comme synchrones (nécessitant un chargement de page) et asynchrone (se produit dans la page). Pour citer l'article
Pour les interactions utilisateur qui ne nécessitent pas de rechargement de page, les interactions asynchrones, qu'elles soient implémentées en JavaScript, CSS, Ajax ou une autre technologie RIA, utilisent une flèche avec une ligne pointillée comme celle illustrée à la figure 3.
Figure 3 - Flèche représentant un changement d'état asynchrone
Changements d'état synchrones Pour les interactions utilisateur qui nécessitent le rechargement d'une page entière, les interactions synchrones, utilisez une flèche sur une seule ligne, comme illustré dans la figure 4. Ceci est la flèche standard que Jesse James Garrett utilise dans son vocabulaire visuel.
L'article donne en outre un exemple de la façon dont le vocabulaire visuel pourrait être étendu et utilisé pour montrer un processus de connexion pour un site.
Cela dit, je trouve généralement utile de créer des prototypes interactifs en utilisant axure qui permettent aux utilisateurs de parcourir les différentes interactions et j'utilise un diagramme de flux d'interaction pour mettre en évidence les interactions clés dans la page qui sera d'intérêt pour l'équipe de développement. Les autres options que nous avons explorées sont
- Création d'une vidéo à travers les interactions pour montrer aux clients les différentes fonctionnalités
- Faire une démo de produit en direct pour montrer les différents cas d'utilisation et documenter les flux de travail importants
- Création de story-boards pour les flux d'utilisateurs importants pour montrer les différentes interactions
- Le traiter comme une conception de flux où j'utilise des organigrammes pour cartographier les flux.
Voici quelques articles qui pourraient vous intéresser
Wireframes interactifs: documentation des RIA
Arrêtez de concevoir des pages et commencez à concevoir des flux
C'est une bonne question. Je me suis demandé s'il y avait un meilleur moyen de documenter les interactions depuis plus d'un an maintenant et j'ai essayé plusieurs choses différentes. Je me suis inspiré de beaucoup d'endroits différents et voici les différents types de méthodes que j'ai créées/testées dans le passé avec un certain succès. Les images ci-dessous montrent l'interaction avec une galerie d'images pour une application pour tablette au détail.
Diagrammes abstraits
Les panneaux gris représentent un état (ne faisant pas la différence entre un rechargement de page et un chargement asynchrone.) Seuls les éléments impliqués dans cette interaction sont illustrés et chaque interaction est représentée avec un symbole pour expliquer quelle entrée est utilisée ou dans ce cas, un geste.
Diagrammes d'état
Une autre tentative consistait à s'inspirer des diagrammes d'état.
J'aime cette méthode parce qu'elle est plus méthodique, donc plus rapide à créer, mais l'inconvénient est qu'elle prend plus de temps à digérer. Je dois encore l'essayer avec plus d'éléments, pour le moment, il se concentre uniquement sur l'interaction avec un élément.
Je me demande maintenant s'il est possible de s'inspirer de la façon dont les critères d'acceptation sont rédigés au sein d'une équipe agile. En utilisant le même exemple que le zoom de l'image, cela ressemblerait un peu à:
DONNÉ, QUAND, ALORS
Scenario 1: Opening image gallery
GIVEN that product page is open
WHEN user taps on product image
THEN resize image to viewport
AND show thumbnails and close button
Scenario 2: Swiping between images
GIVEN that the image gallery is open
AND zoomed out
WHEN the user swipes left or right
THEN the next image slide into the viewport
AND the selected thumbnail will update to the image in view
Scenario 3: Zooming in and out of an image
GIVEN that the image gallery is open
AND zoomed out
WHEN the user double taps on an image
OR pinches out
THEN the image zooms in
AND the thumbnails disappear
WHEN the user pinches in
THEN the image zooms out
AND the thumbnails reappear
Je trouve que l'écriture comme celle-ci est plus facile à lire et à écrire, mais vous devez créer beaucoup de scénarios pour couvrir toutes les interactions et vous commencez bientôt à vous répéter.
Quoi qu'il en soit, je ne pense pas que l'une de ces méthodes soit un substitut pour parler avec les membres de votre équipe et accompagner des prototypes ou des vidéos de certaines interactions.
Cela dépend du projet, mais j'ai tendance à fusionner le flux d'utilisateurs avec n'importe quelle étape de conception où j'en suis. Par exemple, si je décroche les cas d'utilisation, je les mets dans un flux. Si je détermine la séquence des écrans, je les utilise pour représenter le flux. Si je suis en filaire, j'assemble les filaires en un flux. Cette approche nécessite généralement que j'escorte l'équipe à travers le flux une fois, mais après cela, les documents constituent un guichet unique pour avoir une idée de ce qui doit être construit et de la façon dont il s'intègre.
Après deux ans, je suis sûr que vous avez trouvé votre système. Mais je voudrais quand même mentionner ce lien sur lequel j'ai trébuché il y a quelques semaines.
L'auteur utilise un modèle spacieux, intégrant des wireframes et des workflows. Chaque transition est annotée d'un lien vers une vidéo décrivant en détail la transition entre les images.
Balsamiq et Axure disposent d'outils pour schématiser les interactions ajax. Cependant, j'écris simplement des spécifications fonctionnelles et des états statiques de diagrammes.
Je ne pense pas que la conception de l'interaction change. Exactement comme c'est implémenté. Ajax peut vous aider à concevoir quelque chose qui n'a pas besoin d'une nouvelle page, mais vous devez toujours comprendre le contexte de ce que fait l'utilisateur.
Maintenant, cela ne vous facilite pas la tâche, mais plus d'options sur la façon de mettre en œuvre un besoin d'interaction, vous avez plus de façons de fournir une solution.
Balsamiq pour les wireframes simples.
Pour les flux d'interface utilisateur avancés, je préfère utiliser un flux d'interface utilisateur construit à partir de conceptions/captures d'écran réelles (voir ci-joint). Cela réduit considérablement toute mauvaise communication avec les développeurs, car ils sont très clairs sur la façon de coder l'application.
Cette technique a aidé mon entreprise à créer un document de flux d'interface utilisateur qui est:
Rapide à faire, rapide à lire, pleine fidélité.
Il permet de faire rapidement une analyse de l'interface utilisateur du concurrent dans laquelle les écrans peuvent être référencés précisément par le numéro de page pdf.
Il y a une augmentation à cela en utilisant PowerPoint, qui permet l'interconnexion dans le document de flux d'interface utilisateur, mais nous n'avons pas encore fait de vidéo pour le moyen rapide de le faire!
Je pense que cela dépend du projet particulier.
Ces jours-ci, j'ai tendance à esquisser les flux avec l'équipe UX et les développeurs et à répéter le processus de construction. Lorsque nous sommes satisfaits d'une solution, nous la faisons ensuite documenter comme cas de test pour nos équipes Q&A.