Comment représenter les affichages conditionnels dans les wireframes?
Je travaille sur un assez gros projet. Il existe de nombreux scénarios d'utilisation possibles pour les différents types d'utilisateurs.
J'ai produit des livrables pour le client qui sont essentiellement
- personnage
- benchmark/analyse de la concurrence
- Architecture de l'information (une carte mentale)
- maquettes
J'aurai de nombreux wireframes différents qui couvriront la plupart des pages. Mais pour certaines pages, il existe différents scénarios. Par exemple. le tableau de bord ne sera pas affiché de la même manière si l'utilisateur a connecté un compte social, s'il est prenium ou utilisateur basique, s'il est de type A ou B, etc.
Il y a donc différentes variables qui feront changer un peu la disposition.
Je préfère communiquer ces idées avec des images, ou au moins les inclure dans le wireframe (c'est-à-dire en incluant ces informations sur les wireframes) parce que c'est juste plus facile à comprendre pour toutes les parties (client et développeurs)
Je ne sais pas comment faire cela et si c'est une bonne idée.
Comment représenteriez-vous tous ces cas (diagramme, carte mentale? Annotations)? Concevoir des wireframes pour tous les cas serait trop.
Je ne peux pas me permettre de prendre trop de temps pour cela, alors dites-moi quelle est la solution la plus efficace.
Merci pour votre réponse.
Le parcours utilisateur/scénario/flux ne convient pas à cela, il est trop granulaire.
Les variations de modules sont intéressantes.
J'ai finalement décidé d'écrire des cas d'utilisation sur Info Archi. carte mentale. Pour chaque page que j'ai sur l'IA, j'ai créé un nœud appelé use-case où je spécifie toutes les combinaisons possibles.
De cette façon, je pense que je n'aurai pas besoin de créer des wireframes pour chaque cas, mais créez simplement tous les modules possibles et ensuite les développeurs sauront lequel utiliser à quel moment.
J'espère que cela fonctionnera! Qu'est-ce que tu penses?
Je trouve difficile de donner une recommandation claire car nous n'en savons pas autant que vous. Mais je pouvais imaginer que les options suivantes pourraient aider. Enfin, vous devez décider lequel vous convient le mieux.
Décrivez d'abord la page générale une fois - mettez un espace réservé pour chaque module ou élément qui a des états différents selon le type d'utilisateur. Après avoir décrit la page en général, montrez ces modules: placez les fils des différents états d'un module - modules uniquement/sans la page autour - les uns à côté des autres et spécifiez les états uniques.
Cela a du sens, si seuls des éléments ou des modules d'une seule page changent.
Ecrire des parcours utilisateur pour décrire une séquence d'écrans pour différents utilisateurs Cela a du sens si non seulement une page ou des modules sinlge sur un changement de page mais une séquence de deux pages ou plus.
Donnez un titre clair au voyage, en indiquant le statut/type de l'utilisateur et l'action qu'il entreprend - par ex. "Un utilisateur premium se connecte pour voir son tableau de bord et fait telle ou telle chose pour ..." Utilisez vos fils pour illustrer le voyage - spécifiez tous les modules et éléments des écrans simples.
Cela aide les clients et les développeurs à comprendre le chemin suivi par un certain utilisateur, les actions qu'il entreprend, les réactions et le comportement des modules individuels. Il est facile de suivre le même voyage et de ne pas confondre différents comportements.
La réponse courte à votre question serait des diagrammes de haut niveau avec des annotations faisant référence à des maquettes ou maquettes plus détaillées.
Souvent, les wireframes sont présentés pour un ensemble spécifique de flux/voyages d'utilisateurs, par exemple, le chemin le plus fréquent ou le plus important. Il existe donc généralement un point de référence pour les alternatives basées sur des conditions différentes. Ce sont les différentes conditions auxquelles je peux penser que vous pouvez annoter sur le flux filaire principal et fournir une annexe ou une documentation supplémentaire pour montrer les variations:
- Autre (s) point (s) de départ: ceux-ci pourraient en fait avoir un impact significatif sur le flux/voyage de l'utilisateur et nécessiteraient probablement un diagramme entièrement séparé mais avec des références appropriées.
- Autre (s) point (s) final (s): ils sont le résultat de variations à différentes étapes du flux/voyage de l'utilisateur, mais sont généralement fournis de sorte qu'un instantané des résultats disponibles puisse être facilement déterminé.
- Chemins alternatifs/conditionnels: il peut s'agir d'options ou de sélections qui peuvent ou non affecter le résultat final en fonction de la logique métier réelle et de la sélection de l'utilisateur.
La meilleure façon est d'établir un système (numérique, alphabétique ou alphanumérique) que vous utilisez pour annoter un flux/trajet de référence qui vous permet également de fournir des désignations pour chaque chemin et également des branches à partir du flux principal. Mais il est préférable de cartographier toutes les variantes avant de créer un système afin de ne pas avoir à le changer à mi-chemin et vous pouvez également être sûr qu'il fonctionne pour la plupart des flux/voyages d'utilisateurs que vous devez décrire.