Comment apporter des modifications filaires aux membres de l'équipe
Je travaille dans une petite équipe de projet en tant que designer d'interaction. Le produit est en cours de développement et n'est pas encore rendu public.
Au début, toutes les fonctionnalités du produit ont été conçues en filaire dans un seul document. Dans ce cas, PowerPoint. Le document contient suffisamment d'informations pour que toute l'équipe le comprenne.
Tout fonctionne bien. Les développeurs et les concepteurs regardent le document, le conçoivent et le développent.
Si l'application est dans un état où nous pouvons exécuter des tests avec les utilisateurs, nous la testons et bien sûr après le test, certaines interactions doivent être modifiées.
- Parfois, je le change dans le document lui-même et dis aux membres de l'équipe de retirer une nouvelle version du serveur.
- Parfois, je corrige un bug et un développeur est averti.
- Parfois, j'envoie 3 nouvelles diapositives à une seule personne pour y travailler.
- Parfois, je partage un changement en personne.
Je continue de tomber sur cette situation et j'espérais que quelqu'un aurait quelques conseils sur la façon de gérer cela.
Comment vous informez-vous, vous et les membres de votre équipe, des nouveaux changements? Comment communiquez-vous les modifications aux membres de votre équipe. Comment commandez-vous vos documents? Y a-t-il des outils qui peuvent m'aider?
Avoir une place canonique pour les wireframes est le meilleur moyen d'éviter toute confusion. J'ai tendance à diviser les wireframes en fonctionnalités. Je travaille généralement sur une fonctionnalité/section du site à la fois, et cela évite le problème du document maître géant.
Si vous les communiquez aux développeurs, téléchargez le filaire sur l'histoire sur laquelle les développeurs travaillent. Lorsque vous mettez à jour le filaire, mettez à jour l'histoire avec la nouvelle.
Pour le reste de l'équipe, utilisez quelque chose comme un camp de base ou un sac à dos pour les enregistrer et les mettre à jour au même endroit.
Nous sommes allés plus loin et utilisons myBalsamiq, la version hébergée des maquettes balsamiq. Ils suivent les changements dans les versions et ont des commentaires des utilisateurs. Pour moi, c'est la meilleure façon de résoudre ce problème. Vous pouvez joindre une version particulière à une histoire, puis continuer à travailler sur la fonctionnalité.
Mon conseil:
PAS!
Hélas, ce que vous décrivez est un problème presque universel dans toute structure d'équipe qui dépend des wireframes comme document source pour tout le reste.
À mon humble avis, les wireframes sont destinés à mettre des idées sur papier. C'est un croquis approximatif. Facile à modifier rapidement et à intégrer les idées de chacun.
À ce stade, c'est un document de base pour l'équipe UX pour commencer le processus de construction du produit. Je considère maintenant que les structures filaires sont terminées et que tout changement de conception à l'avenir (il y en aura beaucoup) doit être géré en dehors des structures filaires pour la simple raison que la maintenance des structures filaires est une énorme charge de temps et d'organisation.
Dans un monde idéal, votre équipe n'est pas gigantesque et est plutôt une taille gérable et tout le monde peut gérer les mises à jour au fur et à mesure d'un processus Agile.
Je me rends compte que ce n'est pas toujours le cas et qu'il est inévitable que bon nombre d'entre nous soient coincés dans de grandes organisations qui sont déterminées à produire de grandes quantités de documentation papier. Dans ces situations, je suis d'accord avec ce que les autres ont dit ... idéalement, le filaire est une page Web à laquelle tout le monde accède en direct. S'il doit être mis à jour, cet emplacement est mis à jour et par défaut, tout le monde obtient la dernière version. Si ce n'est pas du HTML, vous courez le risque que les gens mettent les versions hors ligne et soient complètement désynchronisés.
Certes, pour que cela fonctionne, vous avez besoin d'une équipe UX avec des compétences en HTML, ce qui est un autre problème dans de nombreuses organisations. : /
Lorsque je crée des wireframes dans Visio, j'utilise un script pour générer automatiquement une table des matières. Je prends alors l'habitude de modifier le nom de la mise en page pour indiquer les changements mineurs/majeurs en suffixant un "-" ou "+". Le script se compare à la table des matières précédente et aux codes de couleur de chaque ligne: les petits changements deviennent verts, les grands changements deviennent bleus et les nouvelles pages deviennent rouges.
Le processus est plus important que l'outil! La communication et la bonne structuration du workflow le feront fonctionner quel que soit l'outil que vous utilisez.
Nous utilisons 4shared.com pour partager des fichiers et configurer les paramètres en fonction de nos besoins.Si quelqu'un met à jour un document, il envoie la notification à toute l'équipe.