Quels sont les conseils généraux pour la démonstration de wireframes aux clients?
J'ai travaillé sur une application Web et j'ai obtenu les wireframes assez loin, sur la base des recherches et discussions internes initiales. Les gars biz sont impatients de mettre en place des démos des wireframes à des clients potentiels, et je suis impatient de les utiliser comme une opportunité pour plus de recherche. Avez-vous des conseils généraux sur les questions à poser, les choses à éviter, l'approche, etc.?
TIA
Première loi de Nickster sur le prototypage: Il existe une relation inverse entre l'ancienneté de la partie prenante et sa capacité à visualiser/conceptualiser les interactions à partir d'un prototype de faible fidélité ... c'est-à-dire. plus ils sont âgés, plus il faut de fidélité.
Qu'ils ne puissent pas ou ne veulent pas, c'est un peu discutable, mais l'accepter comme un fait de la vie. Ils deviennent distraits ou détournés par les détails (par exemple une copie d'exemple) et la vision du tunnel qui s'ensuit ne comprend pas ce que vous essayez de transmettre (en général mais pas toujours).
Lisez Marty Kagan "Une lettre ouverte à la communauté du design" car il couvre très bien ce sujet. Lecture obligatoire pour tous à mon humble avis.
Personnellement, j'utilise maintenant des wireframes pour mes propres itérations de conception et Axure pour tout ce qui doit être présenté aux parties prenantes.
Deux obstacles auxquels vous serez probablement confrontés s'ils ne sont pas habitués à voir des wireframes:
- Aucun de l'attrait du trottoir des concepts de design, donc ils pourraient être sous-estimés. Profitez-en pour les engager à participer à la fonctionnalité.
- Ils pourraient avoir des difficultés à considérer les wireframes statiques/plats dans le contexte de l'application entière. Nous contournons cela en fournissant un flux utilisateur à côté des wireframes et en mettant en évidence la partie du processus que le wireframe représente.
Si vous utilisez des wireframes interactifs, souvenez-vous que vous risquez de rencontrer un problème technique ou quelque chose qui n'est pas correctement connecté, etc. sur le code inutile qui est complètement hors de propos vient le temps de construction.
Dans un contexte plus large, essayez de les amener à séparer les besoins de l'entreprise (leur point de vue naturel) des besoins de l'utilisateur. Essayez peut-être de vous construire quelques personnages rapides à l'avance afin de pouvoir fournir des "pseudo preuves" lorsqu'une suggestion d'un client ne fonctionnera évidemment pas pour les utilisateurs finaux.
HTH
J'ai présenté des centaines de wireframes à tout le monde, des clients externes aux cadres internes et le meilleur conseil que je puisse donner est de créer d'abord une histoire centrée sur votre personnage principal et un ou des objectifs qu'ils souhaitent atteindre. Ensuite, décrivez les événements et les flux de travail nécessaires pour raconter l'histoire qui met en valeur votre conception et comment elle améliore la vie de votre personnage.
En fait, la meilleure lecture pour un fil que j'ai jamais fait était d'avoir le client réel à traverser le fil dans un scénario scripté et de montrer comment cela lui a sauvé des milliers d'heures de travail manuel, ce qui s'est terminé par un commentaire "Je veux cela maintenant, quand puis-je l'avoir?"
À mon humble avis, les wireframes sont vraiment un document de conception interne. Ils aident à étoffer et à extraire toutes les exigences métier, mais sont vraiment destinés à l'équipe UX interne plus qu'au client.
Si vous pouvez repousser, la meilleure approche n'est pas de faire des démonstrations de wireframes pour le client final. En gardant une faible fidélité, je recommanderais de construire même un prototype interactif grossier. Toutes les cases et les lignes du monde n'aideront pas les utilisateurs professionnels non avertis à saisir votre conception presque aussi bien que si, lorsque du texte est entré ou que des éléments sont cliqués/survolés/quel que soit un exemple de ce qui est censé se produire ... arrive.
Vous pouvez facilement faire des prototypes low-fi dans Axure ou même quelque chose comme Balsamiq et inclure des interactions qui démontreront le flux et l'état de votre solution de conception proposée.