Envoyer des wireframes avant une démonstration?
Je suis un concepteur UX interne pour une entreprise de taille moyenne, et une grande partie de mon travail consiste à créer des wireframes à inclure dans des documents techniques. Habituellement, le flux de travail ressemble à ceci - le chef de produit proposera la nouvelle fonctionnalité/amélioration, je travaillerai sur les maquettes et nous nous réunirons pour discuter avec le service informatique avant la finalisation des spécifications. Les wireframes sont généralement de faible fidélité dans quelque chose comme Balsamiq Mockups, mais parfois ils sont complets sur des prototypes interactifs de style Axure ou Justinmind.
Sur la question - lors de la présentation d'un ensemble de wireframes, dois-je envoyer les wireframes à l'avance ou non? En tant que destinataire des demandes de réunion, j'apprécie toujours autant d'informations à l'avance que possible. Mais en tant que donneur de démonstrations, je comprends que les wireframes n'ont pas toujours beaucoup de sens sans la présentation.
Alors, quelles sont les situations où vous souhaitez envoyer des wireframes à l'avance?
Cette réponse s'applique à la plupart des présentations, pas seulement à celles UX.
Une bonne présentation est comme une histoire, où vous emmenez votre public dans le voyage que vous voulez qu'il vive. Si vous leur envoyez la présentation à l'avance, vous perdez la possibilité de les emmener dans ce voyage.
Il existe également d'autres points négatifs potentiels en ce sens que votre public peut commencer par des idées préconçues sur ce que vous voulez leur dire, et qu'il interprètera donc souvent tout ce que vous dites à cette lumière. Rendre votre travail encore plus difficile.
La seule fois où je peux voir que cela est pertinent, c'est quand il doit y avoir un examen technique objectif au préalable, mais c'est assez rare.
En résumé, si vous pouvez l'éviter, ne l'envoyez pas à l'avance.
D'après ma propre expérience, les maquettes basse fidélité sont rarement claires pour les personnes qui ne sont pas familières avec les wireframes même si elles sont accompagnées d'une description complète ou de commentaires, donc je ne pense pas que vous devriez les envoyer avant votre démonstration car cela peut introduire des hypothèses et des attentes erronées (comme cela a déjà été mentionné par @JohnGB).
Mais, en tenant compte de cette chose difficile à comprendre, vous pouvez améliorer votre démonstration, en
Démontrez-le à quelqu'un (en particulier au propriétaire de la fonctionnalité, etc.) à l'avance, de sorte que vous comprendrez clairement que la démonstration se déroulera sans heurt, et la plupart des choses sont claires pour les participants. En conséquence, vous pourrez réparer votre station de démonstration et préparer des réponses aux questions possibles.
Envoyez une note de bienvenue qui contiendra une description du (des) problème (s) que vous essayez de résoudre et l'ordre du jour de la prochaine démonstration, afin que les gens puissent décider de tout ce dont ils ont besoin pour assister à cette démonstration ou non.
Compte tenu du fait que les wireframes sont difficiles à comprendre, je préfère discuter des wireframes avec un nombre limité de personnes pour réduire le nombre de solutions appropriées et préparer des prototypes haute fidélité, qui sont beaucoup plus faciles à présenter devant un large public.
Je suis tout à fait présentateur de wireframes et d'autres concepts.
Rien de mieux que de voir la réaction à première vue et de traiter les conceptions erronées dès que possible.
Cela dit - il y aura toujours des moments où cela sera impossible. Peut-être qu'un cadre n'était pas présent à une réunion ou que vous devez expliquer les concepts à un tiers.
Dans cette situation, je recommanderais d'envoyer une vidéo de l'interaction avec le filaire accompagnée d'une voix off. Cela vous permet d'expliquer les tenants et aboutissants. Je voudrais également envoyer un e-mail lors d'un raccordement téléphonique ou mieux encore un appel Skype.
Si vous laissez un vide - le destinataire ajoutera sa propre interprétation.
Certains livres, comme Lire ceci avant notre prochaine réunion, suggèrent d'envoyer du matériel à l'avance. Bien sûr, cela n'a de sens que s'ils peuvent donner un sens à tout ce que vous leur envoyez.
S'il s'agit de choses qu'ils sont censés lire avant la réunion ou s'il s'agit de matériel connexe (comme des articles de recherche que vous avez trouvés sur la fonctionnalité en question), laissez-les lire, mais si vous ressassissez simplement des choses que vous allez dire les dans la réunion de toute façon, vous perdrez votre temps.
Lors des réunions de conception, une partie de mon processus avec les clients consiste à m'assurer de leur montrer tous mes wireframes. En d'autres termes, je leur montre les idées clés que j'ai rejetées ainsi que mes solutions les plus finales. Je trouve que cela aide vraiment à créer une bonne discussion ouverte sur les options. Et cela m'oblige à expliquer ma logique de conception.
J'ai tendance à utiliser des méthodes de prototypage très rapides, par exemple balsamiq. Je trouve que l'aspect sommaire aide à encourager la discussion.
Si je vais les envoyer à l'avance, je les mets dans PowerPoint avec quelques notes jointes. Cependant, dans l'ensemble, j'essaie de garder l'annotation au minimum. Les gens ne les lisent tout simplement pas.
Parce que j'ai partagé beaucoup d'options - dans l'ensemble, je ne trouve pas que mes collègues aient émis des opinions fixes avant la réunion. Nous avons généralement des discussions très saines. Je pense que ma propre volonté d'exposer les impasses ainsi que ma meilleure pensée y contribuent.
Peut-être que ma réponse est que cela dépend où vous en êtes dans le processus de conception. Au début, la valeur d'une réunion est le déploiement initial de nouveaux matériaux/directions parce que je peux évaluer les réponses à chaque idée.
Plus tard dans le processus, lorsque nous peaufinons la conception, le temps réel est moins important. J'aime l'idée d'envoyer une vidéo. Je pense que les gens seraient plus disposés à voir cela que de lire de longues notes.