Le meilleur type de spécifications d'interface utilisateur pour la conception d'interface utilisateur?
J'ai eu des problèmes pour transmettre des spécifications qui étaient des conceptions filaires + une explication des éléments aux concepteurs/artistes de l'interface utilisateur.
Ce qui avait tendance à se produire était que les premiers écrans créés étaient en effet des interprétations libres de la spécification filaire lâche, mais à mesure que nous nous rapprochions du milieu du projet, les conceptions avaient tendance à refléter les conceptions filaires (qui n'ont jamais été conçues comme des dispositions réelles) , ce qui augmente le nombre d'itérations pour chaque nouvel écran.
Ceci en dépit d'être très clair devant le besoin non seulement d'art mais aussi de design.
Récemment, on m'a suggéré que faire un filaire en premier lieu pourrait être la mauvaise approche. On m'a dit que je devais créer une hiérarchie d'éléments pour chaque écran et laisser le concepteur travailler à partir de cela.
Ma question est la suivante: quel type de spécification est le meilleur afin de donner au concepteur la meilleure aide possible pour créer une bonne interface utilisateur avec une excellente expérience utilisateur?
Existe-t-il des exemples de documents que je pourrais utiliser comme base pour mes spécifications révisées?
ÉDITER:
Clarification, cette question concerne principalement les spécifications d'un indépendant sous contrat. Comme le dit DA01, il est préférable de travailler ensemble dès le début et de continuer à itérer. Cependant, dans le cas où vous embauchez quelqu'un pour la conception de l'interface utilisateur, qui pourrait même être à l'autre bout du monde, les règles ont tendance à être très différentes.
Quel est ton rôle? Architecte de l'information? Analyste d'affaires?
D'après ce que vous avez dit, je pense qu'un ou plusieurs des événements suivants se produisent:
Vous êtes extrêmement doué pour produire des mises en page et des flux de travail optimaux, de sorte que les concepteurs finissent toujours par revenir à votre conception.
Votre spécification (qui, selon vous, contient "wireframes + explication des éléments") ne contient pas suffisamment de documents de cas d'utilisation et d'informations de haut niveau pour que vos concepteurs puissent effectuer leur propre flux de travail et analyse de tâches.
Vos concepteurs ne possèdent pas une solide expertise en analyse de flux de travail et de tâches.
Autres problèmes de gestion de projet. (pas assez de temps, manque de révision, etc.)
Quel que soit le coupable, la réponse n'est pas de refuser les wireframes que vous avez créés aux concepteurs. Vous avez créé ces wireframes, car cela vous a aidé à résoudre les problèmes. Ces wireframes seront tout aussi précieux pour les concepteurs. Le défi est de créer un environnement pour les concepteurs qui leur permettrait de faire leur propre analyse. (voir ci-dessus 4 balles)
Après tout, vous leur demandez de faire plus qu'un simple design visuel et interactif.
Modifier:
S'il s'agit d'un projet de contrat à prix fixe, le concepteur est très incité à minimiser le temps qu'il passe sur votre projet en réutilisant autant que possible ce que vous lui donnez, en particulier sur des choses comme l'analyse qui ne sont pas toujours produire des actifs tangibles à montrer au client.
Vous devez donc demander spécifiquement des wireframes/workflows en tant que livrable séparé. Cela vous permettra également d'évaluer si le concepteur possède cet ensemble de compétences particulier. Et en convenant de structures filaires/workflows qui vous plairont tous les deux avant de passer à la phase de conception visuelle, vous pouvez éviter que le concepteur ne revienne à votre conception.
(Cependant, si votre concepteur laisse passer l'occasion de gagner plus d'argent, le problème # 3 est également une bonne possibilité)
conduisant à des quantités croissantes d'itérations
Je pense que c'est la meilleure façon. Itérer, itérer, itérer.
Pour rendre le processus plus fluide, essayez de faire en sorte que le client/entreprise, UX, la conception de l'interface utilisateur, la conception IX et le développement de l'interface utilisateur fonctionnent tous en parallèle (bonus si vous pouvez également obtenir le développement principal sur la même page).
Lorsque toute l'équipe travaille en parallèle, cela simplifie énormément le processus par rapport au modèle en cascade de wireframes se jetant dans la conception de l'interface utilisateur qui est ensuite jeté vers le développeur de l'interface utilisateur qui est ensuite jeté à l'arrière. Ce dernier processus laisse beaucoup d'inconnues jusqu'à la fin en raison de décisions qui affectent les autres membres de l'équipe sans leurs commentaires et inévitablement, tout le monde se démène vers la fin pour effectuer des ajustements qui ont été manqués tôt.
En fin de compte, ce qui est "meilleur" dépend complètement des structures d'équipe et des processus commerciaux particuliers dont vous disposez. Cela va varier d'un projet à l'autre. Je pense que plus vous pourrez faire travailler les gens en parallèle, plus les choses seront fluides en général.
Existe-t-il des exemples de documents que je pourrais utiliser comme base pour mes spécifications révisées?
En lien avec ce qui précède, un autre défi est que la documentation pendant la phase de conception rationalise rarement le calendrier du projet. L'argument en faveur de l'itération est que tout le monde est réellement concentré sur l'amélioration de l'expérience utilisateur et non sur la nécessité de produire et de maintenir une documentation contraignante.
La documentation est importante, bien sûr, mais gardez-la aussi légère que possible. De nombreuses communications de spécifications peuvent probablement se produire verbalement. Avoir des réunions fréquentes avec les équipes clés énumérées ci-dessus. Supprimer les révisions dans le code plutôt que dans les documents de spécification et les choses se passent généralement beaucoup plus facilement. *
* avec l'énorme mise en garde étant que oui, je réalise aussi complètement que dans certaines organisations ... généralement les plus grandes ... tout ce que j'ai dit ci-dessus peut ne pas être une solution pragmatique. De nombreuses organisations sont toujours embourbées dans le développement en cascade/non itératif et jettent des obstacles supplémentaires dans le mélange, comme le développement externalisé. Dans ces situations, tout ce que je peux offrir, c'est une énorme "bonne chance! ;)
Esquisser pour de meilleures expériences mobiles pourrait être très utile pour vous.
En bref, il y a quelques étapes lors du croquis:
- Esquisse divergente - brainstorming, le résultat est des esquisses lâches
- Esquisse convergente - combinant les idées, polissant la meilleure, esquisse détaillée comme résultat, pourrait être utilisé comme spécification et implémenté comme prototype
- Création de flux d'interface utilisateur , pourrait être utilisé comme spécification et implémenté comme prototype
Les étapes détaillées d'une session de dessin typique peuvent être trouvées dans l'article. Donc, le croquis est un bon outil de spécification, il suffit de le rendre suffisamment détaillé.
Cela dépend des compétences de ceux qui sont impliqués. Il pourrait être utile de se pencher sur Lean UX. Actuellement, il n'y a pas de définition unique, même le livre récent O'reilly apparaît comme très esquisse ( http://shop.oreilly.com/product/0636920021827.do ) mais, en un mot Shell, il s'agit de s'assurer que tous les membres de l'équipe sont impliqués et ont une visibilité sur la génération d'idées et que vous ne dépendez pas des livrables pour communiquer une idée. Les spécifications détaillées prennent beaucoup de temps et, comme vous le rencontrez, sont difficiles à maintenir pour de longues itérations ou des itérations rapides et rapides.
De courtes réunions quotidiennes tous les jours le matin (comme dans Agile) sont un bon moyen d'assurer la communication, tout comme le travail dans une salle de guerre (une idée qui précède le Lean UX d'au moins dix ans) et l'utilisation de tableaux blancs comme origine et lieu de vie pour certains des résultats du processus. J'ai utilisé un mélange d'une feuille de calcul avec l'état de la page, un plan du site sur un tableau blanc et une image filaire HTML pour un projet pour Boots au Royaume-Uni en 2000. Les conceptions étaient attachées aux pages HTML avec un lien et le stratège de contenu pouvait mettre une copie in situ sur les wireframes - les développeurs ont ensuite utilisé tout cela pour créer une version finale du site, bien qu'il y ait à l'époque des interactions moins lourdes par rapport aux sites d'aujourd'hui.
Tout cela dépend de la nature et de l'emplacement des membres de l'équipe. En bref, si la spécification échoue, voyez ce que vous pouvez en retirer et voyez où vous pouvez transformer les communications papier en face à face (ou `` bande passante élevée '' comme je l'ai entendu appeler).