Est-il préférable de transmettre les maquettes de l'interface utilisateur aux programmeurs uniquement après avoir terminé ou en lots plus petits?
J'ai un projet dans lequel j'ai besoin de faire 80 écrans de maquette d'interface utilisateur.
Dois-je transmettre ces 80 maquettes à l'équipe de développement une fois que je les ai toutes terminées, ou dois-je les lui transmettre par lots, par ex. 10-20?
Je l'emballe normalement en respectant les tâches ou sous-tâches, selon l'ordre de priorité du propriétaire du produit/chef d'équipe (plus urgent d'abord), de sorte que lorsque les développeurs entrent dans le sprint, ils ont tout ce dont ils ont besoin pour la fonctionnalité dont ils parlent pour commencer à travailler.
Normalement, pour moi, c'est 2 à 5 écrans par sprint et par équipe, donc si vous travaillez avec deux équipes au rythme de deux sprints par mois, vous finirez par fournir 15 à 30 écrans, soutenus par des éléments comme les cartes de flux d'utilisateurs.
De plus, lorsque je démarre un projet, je commence par faire des premiers écrans grossiers pour donner au codeur une idée de ce qui se passera dans l'interface utilisateur, pour en quelque sorte établir des directives préliminaires d'interface utilisateur et pour donner au frontend l'idée des éléments qui être utilisé dans l'application, pour établir une sorte de bibliothèque bootstrap.
Ce qui tombe dans la première catégorie, ce sont les polices, la palette de couleurs, les marges et l'espacement, et dans la deuxième catégorie, il y a des éléments typiques comme les formulaires de saisie, les info-bulles, les éléments ajax, les boutons flottants et les composants datavis. Cela aide énormément à tout pousser en deux documents distincts qui seront modifiés et évolutifs au cours du projet. Cependant, cela dépend des préférences de l'équipe, certaines personnes n'aiment pas travailler comme ça et tout cela est un sujet de négociation/discussion.
J'essaie d'éviter quelque chose comme passer 80 pages à une équipe de développement.
Il y a beaucoup de raisons à cela. La théorie cognitive montre qu'il est très difficile pour quiconque d'absorber 80 morceaux d'informations. pratique de conception moderne est itératif ou agile, et se traduit par une bien meilleure collaboration avec les développeurs et le dérisquage de produits que les modèles de style cascade où de gros morceaux d'informations sont transmis de la conception au développement.
En général, j'essaie de faire participer les développeurs au processus de conception dès le début grâce à un storyboard basse fidélité. Cela leur permet de réfléchir à l'architecture et de fournir des commentaires sur les domaines de complexité technique. Cela nous permet également d'établir des flux et des sous-flux clairs dans l'UX, que les développeurs comprennent de manière holistique afin qu'ils soient clairs sur la façon dont les pièces fonctionnent ensemble.
Ensuite, lors de la conception, les gars UX créent des wireframes de haut en bas ... à partir de la page générale des wireframes et des flux bas niveau haut niveau. Ceux-ci sont transmis à l'équipe de développement afin qu'ils puissent continuer à planifier.
Les flux de haut niveau sont ensuite décomposés en sous-flux, qui sont généralement de 1 à 10 pages. Il s'agit d'un bloc d'informations très gérable et chaque sous-flux est transmis à l'équipe de développement au fur et à mesure de sa création.
Le résultat est que les équipes de développement obtiennent des informations dans des blocs de taille de sous-flux, mais comme elles ont tous les storyboards et wireframes de haut niveau, elles comprennent clairement comment chaque sous-flux s'intégrera dans l'application globale, donc nous ne le faisons pas devez attendre que tous les écrans soient conçus et qu'ils puissent commencer à coder immédiatement et également fournir des commentaires immédiatement.
Je termine tout et je le passe ensuite aux programmeurs. Habituellement, le mieux est d'utiliser une sorte de logiciel de maquette (axure, invision, flinto, etc.) afin qu'ils comprennent toute la convivialité.
Ceci est encore plus important dans le travail avec les clients. Ce n'est qu'après que le client a approuvé la conception que nous le transmettons aux programmeurs, puis il revient à la conception pour le contrôle qualité.