Les wireframes sont-ils appropriés pour la documentation des exigences?
Les responsables de la conception, du développement et des tests discutent actuellement des exigences.
Une partie de la conversation porte sur le but et l'utilisation des wireframes. Notre analyste du changement est fermement opposé à l'utilisation de wireframes dans le cadre des exigences de développement ou de test. Ils doivent être utilisés pour des "informations supplémentaires" uniquement lorsque cela est nécessaire - "quelque chose à laquelle se référer" pour plus de clarté.
En bref: utilisez des exigences écrites, pas visuelles.
Les wireframes doivent-ils être utilisés dans le cadre du processus de collecte des exigences et de documentation?
L'un de vous a-t-il déjà travaillé dans une équipe où les wireframes étaient le document principal des exigences de développement et/ou de test?
Edit: J'ai un parti pris en faveur de l'utilisation de wireframes comme documentation des exigences formelles. J'ai passé quelques années dans un environnement où elles étaient la seule forme de documentation des exigences - le développement n'a commencé que lorsque les propriétaires de produits (environnement agile) ont approuvé les wireframes. Très efficace dans ce cadre.
Je pense que vous risquez ici le débat exigences vs conception. Les wireframes sont assez importants mais je pense que cela dépend de la façon dont vous les conceptualisez. Ce qui suit est mon propre avis, mais soutenu par des processus industriels assez standard selon mon expérience.
- Les exigences doivent généralement être écrites uniquement parce que vous décrivez ce qu'une solution doit faire. Ils doivent être suffisamment détaillés pour décrire clairement toutes les étapes qui doivent se produire et doivent être décomposés en compartiments logiques, selon le type de produit auquel ils sont destinés.
- Les wireframes font partie du processus de conception car ils décrivent comment la solution doit se comporter pour répondre aux exigences. Parfois, vous devrez peut-être développer une carte mentale ou un diagramme de nœuds, ou dessiner quelque chose pour qu'un client décrive plus clairement ses besoins, mais ce n'est pas le but d'un filaire.
- Dans les projets où quelqu'un a tracé le déroulement d'une application et/ou construit des wireframes (qui commencent essentiellement à placer des éléments sur une interface utilisateur) dès le départ, cela biaise invariablement le processus de conception et à mon humble avis, il finit généralement par être substantiellement modifié ou complètement supprimé.
Les exigences sont généralement (pas toujours bien sûr) écrites par un analyste d'entreprise ou PM et non par un concepteur centré sur l'utilisateur. Parfois, ces rôles se chevauchent et les gens peuvent bien faire les deux, mais où les rôles sont selon mon expérience, les wireframes différenciés ne fonctionnent généralement pas. Par nécessité, ils viennent par la suite, lorsque le client a approuvé ce que le produit doit faire, pas comment il doit le faire.
J'utilise Storyboards dans PowerPoint en semi-haute fidélité. Je trouve que la documentation écrite présente des défauts majeurs.
Les gens ne peuvent pas réagir émotionnellement à l'interactivité en l'imaginant à partir du texte. Vous ne pouvez pas écrire un paragraphe sur le fonctionnement de quelque chose et faire comprendre aux gens la nuance de la conception de l'interaction. C'est comme écrire "Le graphisme sera beau avec beaucoup de violet". Qu'est-ce que ça veut dire? Comment pouvez-vous le définir sans le montrer?
La langue craint . J'ai beaucoup moins d'arguments en personne que par e-mail. Le courrier électronique (communication textuelle) a beaucoup trop de chances d'être mal interprété. Lorsque vous êtes ensemble et que vous regardez quelque chose de visuel, les choses se passent mieux. De plus, de nombreux ingénieurs que je connais ne parlent pas l'anglais comme première langue. Le texte est très souvent mal interprété.
Vous ne pouvez pas tester le texte . Vous pouvez tester un storyboard et le mettre devant les gens pour obtenir des réactions. Le texte ne fonctionne pas de cette façon.
CAVEAT: Toutes les entreprises ont des bizarreries et des circonstances spéciales. Vous devez trouver ce qui fonctionne pour vous. Ne laissez pas les gens vous dire quelque chose qui ne va pas. Si vous le devez, faites les deux et donnez secrètement les storyboards aux ingénieurs.
Ma frustration en tant que BA est le manque de clarté entre les "exigences" qui sont des unités testables et la "conception" qui, une fois créées dans le cadre des exigences, DEVIENNENT en fait des exigences. Lorsque l'entreprise se connecte sur un filaire low-fi ou high-fi, ils ont fait de ce visuel leur exigence. Maintenant, j'écris des scripts de test pour m'assurer que le filaire génère exactement comme indiqué dans l'image. Parlez de granularité !! Les exigences doivent concerner la FONCTION de l'application, pas la conception visuelle, sauf si la conception a un besoin commercial légitime à couvrir - comme l'ADA, les normes de marketing ou les améliorations de productivité identifiées.
Plus souvent qu'autrement, les entreprises et les développeurs s'appuient sur le visuel car ils ne peuvent pas conceptualiser leur produit final sans lui. C'est la différence entre lire un livre et regarder la vidéo de ces exigences. C'est une pente glissante de se marier avec un design et l'entreprise commence à dicter "comment" ce design doit agir (boutons de sauvegarde, messagerie d'erreur, collecte de données, navigation, etc.) Autant les développeurs ne doivent pas dicter l'UX, ni le l'entreprise, à moins qu'ils ne soient dans le domaine de l'UX et du design et je me demande alors pourquoi ils n'écrivent pas eux-mêmes du code.
Le gros gémissement est souvent de rassembler et de documenter les exigences plus rapidement afin que le développement puisse commencer, ce qui pose la question de savoir pourquoi les écrire du tout? Si les développeurs ne peuvent pas lire les exigences et commencer à structurer le développement sans conception, il semble probable qu'ils ne se soucient pas de retravailler les données et que le remaniement de la conception est beaucoup plus inconfortable à changer. Être agnostique à la collecte des exigences signifie une opportunité ouverte pour la conception agnostique - la conception n'est pas liée à une plate-forme et à ses contraintes. En créant le processus de signature sur les wireframes, vous configurez l'entreprise pour accepter ce que vous êtes prêt à leur donner au lieu de leur donner ce dont ils ont besoin. Ensuite, le processus se termine sur les jolies images et non sur la fonction de l'application.
Certainement ... Je pense qu'il est essentiel pour votre équipe d'interface utilisateur d'avoir un filaire pour voir toutes les différentes interactions que vous devez afficher sur le projet.
Certaines personnes disent qu'il devrait être suffisant d'avoir une description écrite du projet, mais vous ne pouvez parfois pas obtenir l'image complète d'un projet avec juste des mots.
Surtout avec les wireframes dynamiques, il est plus facile pour le concepteur, par exemple, d'avoir une idée de ce qu'un menu devrait faire.
Il est également agréable de travailler avec les clients, car ils ont une idée claire de ce que votre équipe a l'intention de programmer pour leur projet.
Cela vous fera gagner beaucoup de temps sur le plan de la programmation et des interactions avec l'interface utilisateur. Pour moi, un bon filaire est la représentation graphique d'un bon document écrit.
Il n'y a aucun doute dans mon esprit la valeur d'un bon filaire interactif détaillé.
Les wireframes ne sont pas des documents d'exigences. Les documents d'exigences ne sont pas des représentations filaires. Cependant, ils dépendent et s'influencent mutuellement.
Je trouve qu'ils fonctionnent mieux ensemble en parallèle. En d'autres termes, les deux évoluent ensemble (au lieu que l'un soit terminé avant que l'autre ne commence).
Vous mentionnez que vous utilisez des wireframes comme exigences dans un environnement agile. Je pense que c'est probablement l'exception. Idéalement, tout se ferait dans un environnement agile.
Dans ce scénario, les wireframes sont vraiment des croquis de serviette. Ils sont un document interne pour communiquer une idée afin qu'elle puisse se construire immédiatement.
La grande chose à propos d'Agile est que (à mon humble avis) une fois bien fait, il réduit considérablement le besoin de documentation en général et, d'une certaine manière, rend cette question particulière moins pertinente.
J'ai trouvé que les idées trouvées dans le livre "Prototyping: A Practitioners Guide" sont un bon exemple de la façon dont parfois un MRD écrit n'est plus aussi utile qu'avant, basé sur l'idée que parfois montrer, vaut mieux que raconter. Étant donné que les spécificités des livres portent sur le prototypage, j'ai l'impression que les mêmes idées peuvent également passer au filaire.
- Le prototypage est génératif: ce qui signifie que, au fur et à mesure de votre processus de prototypage (ou filaire), vous parcourez des centaines d'idées. Certains brillants et d'autres moins brillants. Mais les idées les moins brillantes peuvent être le catalyseur de solutions brillantes.
- Le prototypage communique à travers le show and tell.
- Le prototypage réduit les erreurs d'interprétation. Prenez un document d'exigences de 60 pages. Amenez 15 personnes dans une pièce. Remettez-le. Laissez-les tous le lire. Maintenant, demandez-leur ce que vous construisez. Vous allez obtenir 15 réponses différentes. Imaginez maintenant essayer la même chose avec un MRD de 200 pages - c'est encore pire ...
- Le prototypage crée une boucle de rétroaction rapide, ce qui économise finalement du temps, des efforts, de l'argent et réduit les risques.
Avec tout cela à l'esprit, l'argument contre cela serait, parfois le prototypage/wireframing peut également être exagéré pour certains projets, donc vraiment, tout dépend vraiment du projet.
Absolument pas - les wireframes ne font pas partie des exigences.
Les wireframes sont un excellent moyen de:
- Générer des exigences
- Concevoir des solutions aux exigences
Mais les mettre dans les exigences est un cauchemar, qui mènera à une réflexion et à une documentation confuses et confuses (souvent confondant forme et fonction).
C'est particulièrement un problème dans les environnements réglementés ou les contrats - regardez de cette façon, si l'interface utilisateur change une liste déroulante en vue liste:
- L'exigence n'est plus satisfaite et constitue par défaut une défaillance réglementaire ou contractuelle. Le produit fonctionne toujours bien mais la paperasse est désormais une responsabilité légale.
- La documentation doit être refaite à chaque fois que l'interface utilisateur change - c'est fou.
- J'ai travaillé pour une entreprise avant, c'était assez fou non seulement pour mettre des wireframes dans les exigences mais aussi dans les tests correspondants! Cette folie signifiait que lorsque l'interface utilisateur était révisée avec de nouveaux designs et boîtes à outils, toute la documentation devait être refaite (qu'ils n'avaient pas prise en compte dans leurs estimations de projet).
Je suppose que vous voulez juste dire des wireframes d'interface utilisateur. Les schémas fonctionnels, les organigrammes, etc. sont essentiels.
Le produit final que vous créez est une application Web.
Les treillis métalliques peuvent vous amener à mi-chemin avec peu d'effort, il est donc logique d'utiliser des treillis métalliques comme exigences tant qu'ils contiennent une granularité adéquate entre les étapes.
Sinon, j'ai trouvé que les filaires mal réalisés peuvent être mal interprétés presque aussi facilement que les exigences écrites.
Mais, les exigences écrites sont toujours essentielles pour documenter tous les flux. Sans eux, il devient difficile de faire des tests d'acceptation utilisateur et des tests d'assurance qualité structurés.
C'est là que je crois que vos besoins peuvent devenir ingénieux - des diagrammes et des organigrammes de construction.
http://www.leacock.com/deliverables/block_diagram_ex2.pdf
Ici, il explique le processus dans un organigramme, ce qui est encore mieux mieux que la simple documentation. L'utilisation de Wireframes nécessite du temps et du budget pour fonctionner, mais l'utilisation de diagrammes et d'organigrammes est plus significative et aide les autres développeurs et les membres de l'équipe à s'engager avec la documentation.
La plupart du temps, les gens n'aiment pas regarder des informations textuelles qui, d'après mon expérience, n'incitent personne à les regarder plus de 10 minutes. Nous avons réalisé un projet face au Client dont il a largement bénéficié en montrant des wireframes en parallèle aux données textuelles. Les gens ont commencé à comprendre dans quoi nous essayons de documenter. Mais cela demande beaucoup d'efforts. Le moyen idéal pour garder les ressources intactes est donc d'utiliser des organigrammes et des diagrammes pour les rendre intéressants.