Dans quelle mesure vos wireframes sont-ils abstraits / spécifiques?
Nous sommes une petite équipe de conception Web qui révise actuellement notre flux de travail et nous nous demandions comment vous travaillez avec les wireframes.
Utilisez-vous des wireframes et si oui, dans quelle mesure sont-ils abstraits ou spécifiques? Essayez-vous d'utiliser du contenu réel (textes, images,…) ou simplement des rectangles et du texte aveugle? Pourquoi choisissez-vous de le faire?
J'ai l'impression que la question est très large mais je vais essayer de l'aborder de la meilleure façon possible.
TL; DR
- Commencez avec des wireframes low-fi pour aplanir les fonctionnalités et les interactions.
- Utilisez un outil prototype comme Adobe XD ou InVision pour créer un filaire/maquette/prototype hi-fi.
- Répétez ici jusqu'à ce que tous les problèmes soient éliminés.
- Évitez d'utiliser des données aléatoires à tout prix. Utilisez toujours le contenu réel (sauf à l'étape 1)
Réponse détaillée:
Comprendre les exigences
Cela va sans dire, mais c'est la partie la plus importante de tout processus. Rassembler les exigences ne devrait pas être juste un moyen de lister les exigences. Il est très important de comprendre les exigences . Déterminez dans quelle mesure le client comprend le domaine, est-il suffisamment compétent pour comprendre les wireframes, qui sont leurs utilisateurs finaux, que veut l'utilisateur final ...
Il n'y a littéralement aucune limite à la quantité d'informations que vous pouvez collecter pendant la première phase. Si vous vous demandez pourquoi cela est pertinent pour la question, alors voici la raison.
Il vous aide à comprendre comment abstrait ou spécifique le filaire doit être.
Définir des objectifs
En fonction de la taille du projet, définissez la taille de chaque étape. Et cela définit ce qui devrait être la première étape.
Pour un petit projet, il vous suffit de préparer une maquette low-fi à l'aide de Balsamiq, de laisser tous les acteurs s'accorder sur les éléments à l'écran et les flux d'interaction puis aller tout de suite pour un prototype avec XD ou un POC avec des données factices (essayez d'obtenir des données du client)
Pour un grand projet, il est logique de commencer avec des wireframes dessinés à la main, puis un wireframe low-fi (en utilisant Basamiq ou quelque chose), puis un wireframe/prototype hi-fi (en utilisant Invision ou Adobe XD) et à la fin, peut-être même un POC fonctionnel.
Itérer rapidement et efficacement
Quelle que soit la méthode et l'outil que vous utilisez pour le wireframing ou les maquettes, assurez-vous qu'il est facile à mettre à jour. Continuez à itérer jusqu'à ce que vous trouviez le bon ajustement et essayez d'éviter de vider trop de modifications sur une seule itération. Et n'oubliez pas de consigner chaque itération dans une version distincte et CONSERVEZ TOUTES LES VERSIONS! Croyez-moi, j'ai appris à la dure.
D'après mon expérience, cela dépend de:
a) Quelle est la taille ou la complexité du projet
b) Combien de personnes travaillent sur le projet ou combien de personnes utiliseront des wireframes
Dans notre cas, il est démontré que:
- Les wireframes dessinés à la main sont bons pour les points de départ, l'organisation des éléments et le lancement du projet (pour communiquer à tous les membres quoi faire)
- Converti en prototypes numériques, il peut servir de source unique de vérité pour les phases ultérieures du projet et la communication
- Converti en prototypes numériques haute fidélité et cliquables, il sert pour les présentations, les réglages et les détails
Sketch, Craft et Invision est une super pile pour travailler ici.
Le processus le plus détaillé auquel je puisse penser serait:
handrawn ⟹ handrawn haute fidélité ⟹ digital low ⟹ digital high ⟹ clickable ⟹ visual design
Deux considérations:
Le principal groupe d'utilisateurs de vos wireframes est probablement les développeurs. Donc, vraiment, vos wireframes devraient fournir tout ce dont ils ont besoin. Dans certaines entreprises, les développeurs ont besoin de spécifications hi-fi car il n'y a pas de documentation de conception pour fournir des mises en page, des tailles, des couleurs, etc. Demandez souvent à vos développeurs si les WF leur fournissent ce dont ils ont besoin.
Présentez-vous vos wireframes à un client? Je trouve qu'un filaire lo-fi fonctionne mieux pour concentrer les clients sur la fonctionnalité. Il est frustrant de voir un client se plaindre des polices ou des couleurs des wireframes lorsque vous essayez de présenter les fonctionnalités et la navigation.
En bref, faites en sorte que vos wireframes servent le but dont ils ont besoin.
Je crée toujours des wireframes. Je ne veux pas investir du temps et des ressources dans la création de design visuel et d'interactivité sans avoir d'abord un haut niveau de confiance dans la structure fondamentale des éléments et le flux dans la solution. Il est beaucoup plus rapide de créer un filaire , testez-le, modifiez et répétez jusqu'à ce que j'aie cette confiance que de tester et de modifier de manière itérative à l'aide d'un prototype conçu et interactif.
En ce qui concerne la fidélité filaire (images vs espaces réservés, etc.), cela change au cours du processus itératif. Généralement, je commence très bas-fi et ajoute des détails jusqu'à ce qu'il soit temps de commencer à ajouter de l'interactivité et de la conception visuelle . Communiquer clairement aux utilisateurs et aux parties prenantes qu'ils voient un concept approximatif et non le produit fini est essentiel pour atténuer toute confusion, en particulier avec les wireframes à faible fi.
La chose la plus importante à propos des wireframes est qu'elles doivent être basées sur des recherches solides. J'ai découvert qu'une fois que je comprends vraiment qui est l'utilisateur, ce qu'il essaie de faire, comment il le font actuellement, et comment cela pourrait être amélioré, l'entonnoir de solutions se rétrécit vraiment et le processus de wireframing se déplace rapidement.
Donc, après quelques années à faire des wireframes, je vous recommande d'essayer de vous en débarrasser (ou de les réduire considérablement) pendant que vous le pouvez. Voici quelques raisons:
Tout le monde pense que les wireframes sont vos principaux livrables. Peu de gens comprennent le travail nécessaire qui se déroule derrière un filaire. La logique, cartographier le contenu, planifier les informations, les intentions, etc.
Les wireframes limitent les concepteurs. J'ai trouvé que les concepteurs n'avaient pas vraiment besoin de wireframes, ce dont ils ont besoin, c'est la logique derrière chacun et leur laissant la liberté d'implémenter l'interface et la conception.
Les clients se retrouvent avec l'étiquetage et le contenu. Souvent perdu beaucoup de temps à discuter de choses qui sont des espaces réservés dans les wireframes.
Peine perdue. En termes simples, compte tenu de tous les inconvénients et du temps dont vous disposez pour exécuter le projet, les wireframes ne valent tout simplement pas le temps.
Ce que je propose:
- Concentrez vos efforts sur les détails, les données sur les viandes et pommes de terre et le contenu du site Web. Concentrez votre temps sur la cartographie du contenu, l'étude des intégrations, la cartographie des trajets, les flux de tâches, la recherche et la meilleure façon d'utiliser les données pour maximiser l'expérience. Nous savons que le contenu est roi, alors pourquoi ne pas partir du contenu? Voici un très bon article qui a touché ces points.
- Ne créez des wireframes que si vous devez exécuter des tests d'utilisabilité. De nombreux projets, en particulier dans les agences, ne peuvent pas se permettre le luxe des tests. De plus, si vous avez beaucoup de temps, je suggérerais d'optimiser le flux de travail du concepteur et de tester les maquettes plutôt que les câbles. Beaucoup de choses peuvent changer dans la maquette, de la couleur aux emplacements des éléments, ce qui invalide directement beaucoup de résultats dans les wireframes. De plus, avoir un vrai contenu permet aux utilisateurs de mieux juger de l'expérience.
J'ai lu brièvement les autres réponses et je ne pense pas que quelqu'un d'autre ait dit ce que je vais faire et je ne suis pas d'accord avec Nicolas.
Dans les entreprises dans lesquelles j'ai travaillé, le niveau des wireframes dépend massivement de la confiance que vous avez en votre équipe de développement et de savoir si vous avez même un concepteur, en tant que tel, ce que vous fournissez pourrait être aussi simple qu'un filaire brut, jusqu'à un design presque complet.
J'ai fait les deux.
De cette façon, ce n'est pas à un million de kilomètres d'Agile.
Pourquoi suis-je en désaccord avec Nicolas, le développement de leads de conception est une façon de travailler tout à fait acceptable.