Les structures filaires ou les exigences fonctionnelles doivent-elles être créées en premier?
Quand devez-vous créer un document d'exigences fonctionnelles pour un projet de refonte de site Web? Y a-t-il des cas où un FRD informerait les wireframes? Je suis habitué à ce que les exigences fonctionnelles soient écrites après la création et l'approbation des wireframes, mais récemment, quelqu'un a mentionné le contraire.
N'est-il pas logique que les wireframes informent les exigences fonctionnelles plutôt que l'inverse?
Des termes comme "document d'exigences fonctionnelles" sont notoirement ambigus et souvent mal compris, en particulier lorsque des documents sont transmis entre des équipes de conception et de développement, il est donc souvent préférable de définir l'objectif et la portée du document que vous produisez.
- Avant de commencer, pour obtenir un accord sur le contenu et le format
- Dans le document lui-même, pour éviter les erreurs d'interprétation et les retours tangentiels
Pour qui est-ce? Qu'est-ce qui est documenté?
L'ambiguïté vient du terme "exigences" - essentiellement, si les exigences documentées sont
- contraintes métier sur le comportement de toute solution valide au problème de conception
- contraintes sur la mise en œuvre d'une solution de conception particulière
Dans le premier cas, les exigences doivent être documentées avant toute tentative de solution de conception et doivent donc être finalisées avant l'achèvement des wireframes.
Dans le second, le FRD ne peut pas être démarré tant qu'il n'y a pas de solution de conception à documenter, il ne peut donc pas être démarré tant que la conception de l'interface n'est pas stable, c'est-à-dire à la fin du processus de filaire.
Le premier type de document contraint la conception .
Le deuxième type de document contraint l'implémentation de la conception en tant que code .
Exigences de gestion de conten
C'est une autre ambiguïté à laquelle vous devez faire attention.
Pour de nombreux développeurs Web, un document d'exigences fonctionnelles doit contenir toutes les règles métier qui doivent être implémentées dans le cadre de l'application. Cela peut inclure par exemple les processus de gestion de contenu et la gouvernance, que la plupart des UX ne considèrent pas normalement comme quelque chose qu'ils doivent spécifier dans le cadre de leurs wireframes.
Compréhension partagée
Si vous gardez ces ambiguïtés à l'esprit et que vous travaillez avec vos parties prenantes et développeurs pour vous mettre d'accord sur une compréhension commune de la documentation requise, vous vous mettrez en bonne position pour éviter de faire beaucoup de choses inutiles et inutiles (et engourdissantes). ) Documentation.
Mon illustration préférée sur les processus de conception est la suivante:
Peu importe d'où cela vient, c'est la conception de logiciels à l'ancienne oublié depuis longtemps (quand il n'y avait pas de conception UX et technique distincte, il y avait de l'ingénierie logicielle et des processus d'ingénierie), mais il détient toujours la clé .
Comme vous le voyez, tout commence à peu près au début, mais leur intensité change. Ce sont des itérations d'environ 2 à 4 semaines.
Il n'y a ni premier ni dernier : on pourrait dire: commencé en premier ou terminé en premier.
Personnellement, je pense que vous devriez commencer par la fonctionnalité, car elle définit à quoi le système est utilisé.
Mais d'un autre côté, les utilisateurs parlent la langue de l'utilisateur, c'est-à-dire l'interface utilisateur. Ils ne peuvent l'expliquer que dans un environnement familier, et c'est généralement une interface graphique. En termes de demandes de changement, il s'agit toujours soit de modifications de l'interface utilisateur, soit d'un modèle étrange d'implémentation mentale, le modèle utilisateur de l'implémentation perçue du système.
De toute façon, il s'agit de s'en tenir aux besoins, pas aux boutons : vos utilisateurs n'ont pas besoin d'un autre bouton (même s'ils le disent), ils ont un nouveau problème qu'ils veulent résoudre avec le bouton. Assurez-vous de enregistrer cette information, le plus tôt possible.
Parce que les boutons vont et viennent, les problèmes restent les mêmes. Les applications concernent des problèmes. Ils expliquent comment résoudre les besoins non liés à l'ordinateur, comment atteindre des objectifs non liés à l'ordinateur.
Votre spécification doit être un enregistrement systématique clair du système de ces besoins, juste comment Linné a essayé de décrire le système des êtres vivants : votre monde à décrire est un monde plein de besoins et de pulsions.
Une solution élégante est celle qui correspond à son homologue, le problème efficacement, de la manière la plus simple mais la plus ingénieuse. L'élégance est le minimalisme dans la beauté.
Les concepteurs doivent viser l'élégance, en particulier en ce qui concerne les applications, qui doivent répondre aux besoins des utilisateurs. Tout ce qui ne règle pas le problème ne fait qu'ajouter au problème.
L'interface utilisateur est le système pour vos utilisateurs. C'est la métaphore du système.
Comment pouvez-vous vous attendre à concevoir un système de solution élégant au problème, si vous n'avez pas d'abord une description claire du problème?
Faites tout ce dont vous avez besoin pour comprendre le problème (si vous avez besoin de maquettes d'interface utilisateur pour aider les utilisateurs à communiquer à propos de ces besoins, utilisez-les, si c'est mieux avec des diagrammes ou du texte, utilisez-les), et faites ce que vous voulez vous devez avoir une solution à ce problème, qui ne veut rien résoudre d'autre.
Pour cela, je pense qu'un artefact clé est un document d'exigences qui ne détaille pas la solution, sur lequel repose la conception réelle du système de solution (qui est généralement spécifiée en termes d'interface utilisateur). Si vous concevez d'abord des wireframes complets, ils sont suspendus dans l'air.
Mais bien sûr, c'est un problème de poulet ou d'oeuf. Assurez-vous d'avoir les deux dans votre cour en même temps.
L'équipe avec laquelle je travaille a une seule personne qui gère à la fois l'analyse et la conception de l'entreprise (qui se trouve être moi). Je varie entre commencer par les exigences et commencer par les maquettes/wireframes approximatives, principalement en fonction de quelques facteurs:
- Complexité de la tâche: si c'est quelque chose de simple, je vais probablement passer à un filaire
- Examen en personne ou à distance: si je vais distribuer à des personnes géographiquement distinctes, je vais commencer par des exigences écrites, puis passer à une structure filaire
- Technique contre non technique: si la demande concerne quelque chose de technique/complexe, je commencerai par des exigences écrites
La bonne chose à propos des exigences écrites est qu'elles peuvent être utilisées pour éviter l'ambiguïté inhérente à une maquette; Cela dit, lorsque les utilisateurs voient à quoi ressemblera réellement leur demande, ils présentent souvent plus d'exigences.
Et, parfois, je commence juste par une maquette parce que je suis un mec visuel, et cela m'aide à comprendre exactement comment les exigences doivent être écrites/communiquées. Mes maquettes Balsamiq ultra-rugueuses aident souvent à informer les exigences. Avec cette approche, je suis vraiment prêt à lancer mes conceptions et à recommencer une fois les exigences finalisées/finalisées.
Lorsque vous filaire en premier, vous définissez une solution avant de savoir ce que vous essayez de résoudre. Vous devez définir le problème avant de savoir comment concevoir la solution. Par conséquent, les exigences indiquent ce dont un produit a besoin, pas la solution.
Vos wireframes sont-ils aussi littéralement des éléments d'idées pour la discussion, ou vous efforcez-vous d'atteindre des spécifications entièrement fonctionnelles?
Je suis une personne UX, mais plutôt un hybride entre l'analyse UX et l'analyse commerciale et cela fait ma tête lorsque les wireframes sont effectués en premier. Je pense que les utilisateurs devraient savoir comment les choses apparaissent sur le site, donc comment son contenu est géré, etc.
Chaque fois que je suis sur des projets de conception, nous rencontrons d'énormes problèmes. Et cela est principalement dû au fait de ne pas avoir d'exigences. Les concepteurs pensent souvent que les wireframes sont toujours le début d'un projet. Ils ont souvent déclaré que les exigences détruisent la créativité. Je pense que c'est si mal et conduit à un enfer total dans toute l'équipe aux étapes ultérieures du projet.
Tout d'abord, chaque projet doit être abordé différemment. Il n'y a pas deux projets identiques, il convient donc de les aborder en conséquence. Je déclare toujours qu'avant de mentionner les wireframes, nous devons d'abord comprendre, puis équilibrer les éléments suivants:
- connaître vos utilisateurs (recherche d'utilisateurs)
- connaître votre contenu (audits et modélisation, entretiens d'experts en la matière)
- connaître votre processus éditorial (workflows & gouvernance)
- connaître votre entreprise (modèle d'entreprise)
- connaître vos systèmes (CMS et gestion et gouvernance du vocabulaire contrôlé)
Les exigences sont divisées en fonctionnelles et non fonctionnelles. La liste des exigences fonctionnelles dès le début est essentielle. La façon dont ils sont écrits devrait être facile pour tous les techniciens et non techniciens.
Ces exigences dérivent d'une combinaison de sources:
- besoins et désirs de l'entreprise
- besoins et désirs des utilisateurs, qui peuvent provenir de différentes méthodes de recherche des utilisateurs
- besoins éditoriaux (si c'est un projet de bout en bout)
Je travaille dans une société de conseil, et nos clients vont de ceux qui maîtrisent la technologie et comprennent la conception et peuvent parler des configurations de serveur à ne rien comprendre de la technologie ou de la conception. J'ai en quelque sorte changé le processus chez mon employeur actuel.
J'ai trouvé qu'avoir quelques réunions pour susciter des exigences de conception/fonctionnelles est un excellent moyen d'aider à définir les éléments et les fonctionnalités dont le client a absolument besoin d'être sur une page. Cependant, je ne laisse pas ces réunions m'empêcher de simplement montrer au client des croquis/prototypes rapides et sales pour commencer à comprendre les flux et les interactions. Avec ces réunions d'exigences de conception, je crée un document UX/Exigences de conception. C'est un tableau de notre wiki qui répertorie le type de section/contenu et tous les éléments requis sur cette page, ainsi que des notes très générales sur cette exigence. Une fois cela approuvé, je passe au wireframing ou au prototypage. En tant que prototype ou filaire, une documentation fonctionnelle est en cours d'élaboration pour les développeurs.
Je pense que le fait d'avoir une documentation fonctionnelle motive les décisions de conception avant même de voir comment cette interaction fonctionne et se sent est vraiment un désastre qui attend de se produire et entraînera seulement beaucoup plus d'itérations que la normale.
Je crois que les exigences devraient être écrites avant les wireframes et c'est ainsi que j'ai vu la plupart du temps tout au long de ma carrière. Les exigences proviennent du client ou du chef de produit, et c'est à l'équipe UX de traduire ces exigences en wireframes qui offriront toute l'expérience et guideront l'interface utilisateur, les développeurs, etc.
Tout dépend du projet. Quiconque travaille sur la collecte des besoins de l'entreprise et sur la recherche d'utilisateurs et de concurrents aura besoin d'un certain niveau de compréhension avant qu'un vision apparaisse et que la magie commence.
Je proposerai une autre approche, que je ne préfère pas particulièrement, mais cela ne me dérange pas pour le moment. Je travaille avec un collègue sur un projet où le client insiste sur une combinaison de wireframes annotés et de prototypes interactifs sans connaître les exigences. Ils utilisent les wireframes pour un examen interne rapide et les prototypes pour des tests encore plus rapides, puis utilisent les données pour s'appuyer sur les travaux précédents. Ce processus n'est pas dicté par les besoins des utilisateurs et les exigences de l'entreprise, car ils sont tous deux générés au fur et à mesure que nous progressons.
Dans ce projet, le FRD est écrit au dernier moment possible pour les développeurs uniquement avec tous les wireframes et prototypes interactifs supplémentaires disponibles comme références. Je ne recommanderais pas cette méthode, mais le client aime travailler de cette façon pour certains aspects de son entreprise et cela semble fonctionner pour lui. On pourrait dire qu'ils aiment sortir des sentiers battus.
Les exigences fonctionnelles passent avant les wireframes.
Avant les FR, il y a des exigences commerciales qui déclenchent la chaîne d'événements.
Les exigences commerciales communiquent un besoin, quelque chose qu'un intervenant aimerait voir se produire.
Les exigences fonctionnelles indiquent comment les choses devraient fonctionner après l'implémentation de la nouvelle fonctionnalité.
Une exigence commerciale pourrait être comme Autoriser les utilisateurs à se connecter avec leur identité sur d'autres sites comme Google, FB ou Twitter . Cela peut résulter d'une comparaison compétitive.
Les wireframes pour implémenter une telle fonctionnalité pourraient être assez évidents, copiés à partir d'un autre site implémentant OAuth. Mais la fonctionnalité n'est pas si évidente.
Il est donc possible de montrer des captures d'écran aux parties prenantes après avoir fait un petit copier-coller et d'obtenir une approbation.
Mais la réalité de l'impact d'une telle implémentation sur ce site particulier n'est connue qu'après que quelqu'un agissant en tant qu'analyste fonctionnel l'a compris. Comme par exemple, cela pourrait se produire un impact profond dans toutes les interactions de back-office et la structure de la base de données des utilisateurs, nécessitant des modifications importantes partout et un plan de migration.
Cette complexité technique se traduit par des dépenses de développement plus élevées.
Donc, après avoir montré au gestionnaire une connexion simplifiée OAuth filaire de connexion, comment pouvons-nous lui répondre quelques jours plus tard en lui demandant un budget énorme? Après avoir montré les écrans à son méchant vice-président?
C'est pourquoi les exigences fonctionnelles viennent en premier.
Bien sûr, vous pouvez lui montrer les captures d'écran des bâtards et lui dire de retenir son souffle pendant que les devoirs sont terminés, mais cela dépend du niveau de formalité. S'il s'agit d'une entreprise de 12 personnes, les choses sont différentes de celles d'une entreprise Fortune-500.
Cela dit, l'art de faire des exigences fonctionnelles implique de ne pas mentionner l'interface utilisateur. Il est mauvais d'écrire "définir un bouton pour que l'utilisateur choisisse", le FR doit seulement indiquer que l'utilisateur doit être autorisé à choisir.
Les grands avantages de garder l'interface utilisateur hors des FRs sont connus depuis de nombreuses années (peut-être les années 70, je pense), et sont exprimés dans Larry Constantine résultats.
L'une des principales constatations (Larry et Lucy) était que plus tôt on commençait à dessiner des boîtes dans un IDE de programmation, plus l'application mettrait de temps à atteindre un niveau d'utilisation acceptable.
Les exigences fonctionnelles ressemblent souvent à de longues listes avec des phrases courtes commençant toutes par Le système doit ... . Ce ne sont pas des FR, avec un peu de chance, ils peuvent être considérés comme des exigences commerciales ( ce que fait, pas comment pour le faire).
La meilleure façon d'exprimer les exigences fonctionnelles est d'utiliser les cas d'utilisation.
Mais ne froncez pas les sourcils si vite. Ce ne sont pas les UC de votre père, et définitivement pas les UC de RUP.
Je suis atteindre dépassant la longueur d'une réponse raisonnable, donc pour conclure, l'idéal est d'écrire des UC informelles et légères, pour capturer les exigences fonctionnelles.
Deux raisons principales:
- Ils sont la charnière entre les utilisateurs et les mondes informatiques, et
- S'ils sont bien écrits, les UC rendent le codage plus rapide et plus sûr, et donc beaucoup moins cher.
Cascade = les exigences viennent en premier. Agile = ils sont développés en parallèle.
Pour le développement d'applications Web, je suggère de créer plusieurs documents que vous mettez à jour/maintenez parallèlement à mesure que vous grandissez:
- Résumé de 1 à 5 pages sur l'application, quel est le scénario
- définir tous les rôles d'utilisateur possibles - et cesser de faire référence à l'utilisateur après cela. Il est enregistré, utilisateur pro, utilisateur admin, propriétaire, spectateur, etc.
- définir toutes les pages vues possibles auxquelles vous pouvez penser. Connexion, accueil, paramètres de notification - sans configurer de hiérarchie
- répertorier toutes les actions possibles que chaque rôle peut effectuer, quelle que soit la page. Connectez-vous, aimez, commentez, supprimez votre propre commentaire, etc.
- chaque application aura quelque chose d'unique, par exemple enchères, vote, processus de commande, etc. Pour ces cas, dessinez un organigramme pour couvrir tous les résultats possibles - pour les utilisateurs plus avancés, essayez l'organigramme de couloir, très utile.
Au fil de chaque étape ci-dessus, vous découvrirez un nouvel élément, continuez à améliorer votre scénario et les étapes 1 à 5 jusqu'à ce que vous vous sentiez prêt à commencer le wireframing. Les exigences techniques peuvent être insérées sous forme de notes directement dans les wireframes.
Un autre document ennuyeux que je suggère de maintenir est la liste des variables pour chaque page. Nom du champ, type, options déroulantes, champ obligatoire, validation, valeur par défaut, etc. - pour les utilisateurs avancés, utilisez le diagramme de base de données.
En utilisant cette méthode, vous pouvez créer des wireframes en un rien de temps sans bloc constant.
Beaucoup de bonnes pensées ici sur un sujet que je clarifie avec un client en ce moment.
Ce que je vois, c'est que les deux (wireframes/prototypes et FRD) sont si étroitement liés que cela n'a pas d'importance "Il n'y a pas d'avant-dernier" ce qui est plus important est qu'aucun n'est terminé (signé) jusqu'à ce que l'autre soit dans un accord comparable Etat.
Si un FRD doit détailler les règles métier, les exigences en matière de données (sources) et les fonctions que l'entreprise souhaite exposer à l'utilisateur, l'entreprise doit s'engager ou confirmer que ces données seront disponibles lors de la conception de l'interface et de l'IA ces données/fonctionnalités doivent être transmises via. Sans cette confirmation, l'existence des données est selon mon expérience parfois discutable car les fondations sur lesquelles on s'appuie ne sont pas toujours aussi solides que prévu.
Les règles commerciales, les exigences en matière de données et les fonctions sont tous des défis de conception à ce stade, presque personne qui représente l'entreprise appréciera pleinement le détail ou le manque d'inclusion dans un FRD.
En tant que concepteurs, notre rôle est d'interopérer le FRD (un dossier de conception si vous le souhaitez) en quelque chose de significatif - c'est-à-dire présentable et compréhensible - qui répond et remet en question les concepts et les exigences du document. À ce stade, nous nous en sommes tenus aux "besoins et non aux boutons", des méthodes familières de navigation dans les informations communes sont appliquées avec suffisamment de détails pour garantir que les complexités ou cette activité particulière sont disponibles de manière compréhensible et reposent sur des bases solides.
Sans ces bases solides, une grande partie de la compréhension acquise grâce à la recherche, à la conception et au prototypage peut être invalidée en un instant. Cela peut rarement être corrigé avec l'ajout ou la suppression de boutons ou de fonctionnalités, car chaque élément dépend souvent de la présence d'autres pour le contexte qui informe et confirme le modèle en métal d'un utilisateur de ce qu'il navigue ou auquel il accède.
Comme le note Aadaam "Il n'y a ni premier ni dernier", ils sont un dans la même chose.
Vous pourriez dans une certaine mesure.
Mais vous vous retrouverez à travailler au-dessus de ce que vous pensiez auparavant. Et cela peut conduire à des fonctionnalités non prises en charge sur une structure et une mise en page de site déficientes qui ne feront pas face à des idées émergentes.
Mieux vaut créer une spécification fonctionnelle qui n'ira pas au-delà des interactions clés, du plan du site et de la navigation .. Et puis .. eh bien vous devrez refaire et mettre à jour.