UX et spécifications de conception
Je travaille sur un grand projet de m-commerce et j'essaie d'appliquer les principes du lean UX au sein de mon équipe. Malheureusement, je suis limité par le fait que l'équipe de développement n'est pas colocalisée avec les concepteurs et autant que j'essaie de créer des interactions hebdomadaires, ils ont exprimé une préférence pour recevoir une spécification à la fin de chaque sprint pour travailler.
J'ai cherché des moyens de créer une spécification qui minimise la quantité de travail qui va dans ce document sans compromettre la réussite du projet.
Nous utilisons actuellement Axure pour créer des wireframes, des conceptions et des annotations sur les interactions et tout. Nous créons ensuite un PDF que nous imprimons pour les développeurs. Nous trouvons que cela prend vraiment beaucoup de temps et est inefficace car chaque fois qu'il y a un changement de conception ou d'UX, nous devons recréer ce document, imprimer et etc.
Quelqu'un a-t-il essayé une autre façon de procéder? Idéalement, nous aimerions pouvoir avoir un Wiki en ligne avec la spécification qui est un document vivant accessible à tous, modifié en temps réel et distribué facilement aux équipes non colocalisées.
Quelqu'un a vécu la même situation et a des idées?
Pour la partie "Lean" de ceci: diviser la documentation de conception en:
- Guide de style - Toujours à jour
- Dessins individuels - Pas mis à jour après avoir atteint leur objectif.
Wiki ou Confluence est idéal pour la documentation car vous pouvez lier des conceptions au Guide de style (et également dans le cas de l'utilisation de Confluence et Jira, lier directement les tickets de développement aux conceptions)
Si l'équipe de développement organise une réunion Scrum quotidienne, peut-être en appelant via Skype, si cela fonctionne pour l'équipe.
Si vous utilisez Axure, vous avez déjà accès à la publication sur Axure Share . Les annotations et les notes sont toujours facilement disponibles sur la page et tout le monde peut y accéder à tout moment. Lorsque vous mettez à jour les fils et republiez, il utilise la même URL - donc un peu comme un document vivant.
J'utilise cela tout le temps et c'est incroyablement utile pour partager des idées/spécifications entre les équipes. Notez que vous devez être très clair sur ce que vous changez de publication en publication. Vous pouvez l'inclure dans les notes de page ou de la meilleure façon pour la communication entre vos groupes.
wiki en ligne avec la spécification
Cherchez à utiliser une "bibliothèque de composants". Ils prennent du temps à mettre en place au départ, mais peuvent rationaliser les projets sur la route. L'idée est de documenter des éléments individuels. Par exemple, vous pouvez avoir un modèle de conception pour un champ de recherche. Vous décririez ce modèle dans la bibliothèque de composants, ajouteriez des visuels et, idéalement, vous auriez peut-être même un exemple de code de couche de présentation. Vous nommez/numérotez ensuite cet élément, puis vous le référencez dans vos wireframes.
Quelqu'un a vécu la même situation et a des idées?
Oui. Tout le temps. C'est (malheureusement) la "norme" dans la vie des entreprises. La gestion et le développement de projets d'entreprise sont encore profondément enchevêtrés dans les méthodologies de la cascade. Pour eux, "agile" signifie simplement "cascade plus rapide" et en tant que tel, il devient un système lourd de documents. En partie à CYA, mais en partie juste à cause de l'entêtement.
Je n'ai pas d'autre solution magique que de repousser. Poussez, poussez, poussez et continuez à pousser. Certaines choses que nous avons faites:
- utilisez le mode "sommaire" dans Axure et montrez-le très tôt aux développeurs. Insistez pour qu'ils viennent aux révisions afin qu'ils puissent aider à formuler la solution pendant sa création. Cela leur impose plus de responsabilité plus tôt que tard.
- Annoter dans Axure (il suffit d'ajouter directement des notes à la page). Insistez sur le fait que c'est là que vous mettrez des notes de projet et que vous ne ferez pas des tas d'autres documents.
- Évitez les processus d'approbation. C'est une autre prise en charge des jours de la cascade où l'on croyait que le design était `` fait '' à un certain moment et ensuite il était construit. Ce n'est jamais vrai et, en tant que tel, le concept de "signature" est dépassé.
- Insistez pour que les utilisateurs UX/UI examinent les progrès avec les développeurs. Avoir une personne chargée de l'interface utilisateur pour signaler les problèmes d'interface utilisateur avant les tests réels peut économiser une tonne de temps et des maux de tête (d'autant plus que les équipes de test ont rarement un œil sur l'interface utilisateur)
- Travailler sur la bibliothèque de composants.
Je te souhaite bonne chance. ;)
Un projet d'essai récent sur lequel j'ai travaillé a été créé des prototypes de fidélité de niveau moyen à l'aide d'Axure puis partagés via Axshare. Cela m'a permis d'aller assez loin dans la spécification sans avoir besoin de beaucoup écrit. Ceci est aidé par des stand-ups quotidiens. Ensuite, lorsque nous approchons de la fin, je reçois les conceptions créées (dans les PSD, pas idéal, mais c'est ainsi que l'équipe fonctionne), puis je crée un PDF avec des annotations minimales pour chacun des Comme quelqu'un qui a créé des spécifications très détaillées dans le passé, il se sent ad hoc mais, bizarrement, cela fonctionne. Tout cela est partagé via une boîte de dépôt (le camp de base serait mieux à mon avis).
Il y a un système avec des histoires dessus, mais d'après mon expérience, les wikis etc. ont tendance à ne pas être lus. Les quelques mots et documents les plus probables que quelque chose soit construit de la bonne manière. Les réunions quotidiennes sont également essentielles pour suivre le rythme d'un projet. Les développeurs travaillent en utilisant Agile et je fais une sorte de version de Lean. UX se situe en dehors du processus agile et alimente le sprint (complétant efficacement l'arriéré). N'essayez pas de lancer UX en sprint - de cette façon, c'est la folie.
Cette méthode vous permettra également de découvrir des lacunes car les spécifications ne sont pas exhaustives, c'est très bien car elles peuvent être résolues de manière `` juste à temps '' à condition que l'histoire globale soit solide et que les principales parties des fonctionnalités aient été bien pensées.
Il s'agit vraiment de fournir la bonne quantité d'informations au bon moment et de ne pas avoir peur de commencer à construire sans avoir couvert très peu de détails.
"créer PDF que nous imprimons pour les développeurs ..."
Pourquoi utiliser alors Axure? C'est comme utiliser une mitrailleuse pour tuer des fourmis. Axure est bon pour démontrer les interactions qui ne peuvent pas être réalisées avec un PDF ou impression.
En regardant comment les développeurs travaillent, il devient clair qu'il y a bien plus que simplement dessiner l'interface utilisateur, du moins si ce n'est pas un site ou une application relativement statique qu'on leur demande de développer.
Certains problèmes liés à l'utilisation d'un prototype cliquable sont
- flux d'utilisateurs non clair (ou cas de coin faciles à manquer)
- une interaction/fonctionnalité importante est facile à ignorer
- peu de sentiment d'avoir "terminé" la tâche
- compliqué et long à démontrer la gestion des erreurs d'entrée/sortie de données
Cela dit, l'ensemble minimum qui devrait être fourni pour vous assurer d'obtenir ce que vous demandez est
- un organigramme du flux utilisateur, y compris l'interaction principale/l'objectif de chaque écran (donnera également un bon aperçu de la portée du projet)
- description détaillée des interactions sur chaque écran
- wireframes, ou, mieux encore, un prototype cliquable
- détails de conception et actifs (PSD, CSS, logos, etc.)
L'outil pour cela est presque secondaire. Cela aide si c'est un outil qui fonctionne dans tous les environnements (c'est-à-dire basé sur le Web) et peut prendre en charge les connexions existantes (connexion Google pour les documents Google à titre d'exemple). Plus la barrière est basse, utiliser l'outil le pari
"un document vivant accessible à tous, modifié en temps réel et diffusé ..."
Il faut une certaine stabilité pour le développement. Vous ne voulez pas changer les choses tout le temps parce que cela gaspillera le plus souvent beaucoup de temps de développement et conduira à la frustration. Mais c'est peut-être leur expérience ou c'est ce dont ils ont peur et c'est peut-être pourquoi ils (pensent) qu'ils aiment les spécifications.
Souvent, une conversation ouverte et honnête sur les raisons de la demande de spécification ou de format spécifique aide à comprendre, à résoudre les problèmes et à trouver des solutions alternatives.