Le wireframing est-il excessif?

Question

37 Signal Getting Real de Signal m'a convaincue que la trame filaire et la rédaction de documents de spécifications fonctionnelles sont des étapes intermédiaires inutiles pour la création d'applications Web et de sites Web dynamiques.

Les frais généraux de ces étapes en valent-ils la peine? Le prototypage en HTML / CSS ou même en documents Photoshop (afin que les concepteurs puissent les travailler directement) est une meilleure option que d'utiliser un logiciel tel que Visio? Personnellement, je me balance vers ce dernier mais je ne suis pas sûr.

Answer 1

"Échec de la planification, échec" - ou quelque chose comme ça.

Wireframing ne se limite pas aux applications Web; il est couramment utilisé partout où une vue d'ensemble de haut niveau de tout système est nécessaire (cela s'appelle simplement autre chose).

Spécifications fonctionnelles, lorsque vous savez ce qu'il faut faire & amp; comment le faire serait en effet exagéré. Un diagramme de haut niveau de vos intentions suffirait. Et cela ne sera jamais inutile . Cela vous aide principalement à vous concentrer sur la portée et l’intention / la cible de ce que vous voulez faire.

L’accent devrait être mis sur la prévention des efforts inutiles - découvrir à mi-chemin qu’un élément essentiel, qui a un impact sur tous les autres objets, manque, n’est pas ce que vous voulez découvrir. Dans ce cas, la configuration par fil aiderait à détecter les besoins fonctionnels les plus importants. Vous aurez seulement besoin de développer des spécifications fonctionnelles où absolument nécessaires. Utiliser Photoshop pour concevoir votre volonté sera également un "effort inutile" - Mieux vaut utiliser le prototypage évolutif (technique RAD) avec CSS / HTML - tout en utilisant Pen & amp; maquette papier de vos intentions.

Answer 2

37Signals recommande de sauter même Photoshop et d’utiliser HTML. Voir http://www.37signals.com/svn/posts / 1061-pourquoi-nous-sautons-photoshop . Je suis d'accord avec leur évaluation de la planification préalable. Je ne pense pas que cela vaille la peine, à long terme, de passer du temps à construire un prototype fonctionnel en HTML / CSS / JS.

Answer 3

Dans la vie réelle, vous souhaitez éviter de rechercher l'idéal "idéal". façon de faire les choses. Utilisez plutôt ce que vous comprenez dans un but clair et spécifique.

Les maquettes peuvent vous faire économiser des tonnes de temps et d’efforts. Comme ils peuvent être simplement du temps supplémentaire que vous avez consacré à leur création et à leur maintenance.

Exemple concret n ° 1: Les maquettes ont sauvé la journée. Gros système pour le gouvernement, le délai est ridicule.

Raison: des mois se sont écoulés dans la production de tous types de documents d’architecture, qui sont en fait totalement inutiles, car les architectures matérielle et matérielle sont figées dans le moindre détail et existent déjà.

Solution: 20 jours frénétiques de création de maquettes avec le client, jusqu’à ce que nous ayons simplement passé les écrans avec nos notes aux développeurs. Les développeurs ont dû demander des clarifications, mais avec une architecture fixe, des exigences claires et bien définies, ils ont été en mesure de créer des tonnes de fonctionnalités requises en un rien de temps.

Exemple concret n ° 2: Les maquettes ont gâché la journée. Grand système gouvernemental qui a "reconnu" le besoin de maquettes.

Celui-ci montre la capacité humaine (ou corporative?) de transformer la meilleure chose du monde en cauchemar.

Une grande agence gouvernementale a demandé à la grande société de conseil de diriger la grande entreprise informatique pour résoudre un problème. Un organisme gouvernemental a également mis en place un grand groupe d'experts ad hoc du gouvernement afin d'aider et d'accélérer le processus.

Les mois se sont écoulés en gros mots et en décidant des méthodologies appropriées à utiliser et des moyens appropriés de les utiliser. Bien entendu, toutes sortes de compromis ont été faits pour ne blesser personne ni l'importance de personne.

Résultat: l’architecture Sw devait être la source de tout, y compris des maquettes. Lesquels devaient être conçus en premier et dessinés en second. Mappage des actions de OOAD et des diagrammes de séquence, création des diagrammes UX, puis reconnaissance des objets logiques et des ensembles de contenu de l'interface utilisateur, création des écrans et incorporation dans des cas d'utilisation formels, présentation des UC aux utilisateurs lors d'ateliers formels organisés une fois par mois. ces ateliers ont doublé en tant que réunions d'acceptation des exigences, car quelqu'un a compris que le temps passait.

Lors de ces ateliers, même de force, les clients ne pouvaient pas comprendre les UC (très formels, avec beaucoup de tableaux décrivant les attributs de données, etc.), chacun d'environ 30 pages. Lorsque les clients ont eu des commentaires, c'était sur les maquettes. Toutefois, les commentaires étaient découragés, car tout changement de maquette entraînait la modification des diagrammes de séquence, des diagrammes de composants, du modèle opérationnel, des diagrammes UX, la vérification des matrices de traçabilité, la mise à jour des textes UC, etc., etc. ("Zut les clients, ils ne sont jamais satisfaits." était la moto). Après le déploiement de la v1.0 avec des fonctionnalités limitées, plus personne ne se souciait de la documentation, il y en avait tellement. Les développeurs se battaient pour leur vie, apportant chaque jour une myriade de petits changements, juste pour que le système soit opérationnel (après le lot de changements effectué hier qui a fait autre chose).

Ce n’est PAS le moyen d’utiliser des maquettes. Le projet a duré presque deux ans plus longtemps que prévu.

En d’autres termes, ne cherchez pas la méthodologie idéale. Ou toute méthodologie que vous ne comprenez pas. Quel est ton objectif pour le moment? Quel est le moyen le plus rapide que vous connaissez (les autres moyens ne comptent pas) pour atteindre cet objectif? Fonce.

Answer 4

Cela dépend probablement de la personne avec qui vous travaillez. Si c'est vous et un concepteur, alors une spécification fonctionnelle risque de poser trop de problèmes. Mais, dans mon travail, les cadres veulent savoir précisément ce qu'ils vont obtenir à la fin d'un projet et nous avons donc eu beaucoup de difficulté à mettre en œuvre le développement itératif. En général, les itérations sont définies avec des structures filaires, des spécifications fonctionnelles et des maquettes.:)

Answer 5

L'objectif principal des structures en fil de fer est de clarifier les exigences. Il est toujours conseillé de documenter les exigences et il n’ya pas de meilleur moyen que de visualiser une exigence. Les structures filaires sont très utiles ici, car elles donnent au propriétaire du produit (client) une idée précise de ce à quoi s'attendre du produit final. Sur approbation du propriétaire du produit, il fournit également à l’équipe de développement une idée plus précise de ce qui doit être développé. En un sens, il permet de gagner beaucoup de temps de développement et d’éviter les conflits. À mon avis, les filaires sont toujours utiles pour une exécution de projet fluide, même lorsque le projet est petit.

Answer 6

Je pense que cela dépend de votre compréhension de ce que vous essayez de faire. Si vous travaillez pour un client et que celui-ci n'exprime pas beaucoup d'exigences, vous voudrez peut-être une approche avec des itérations extrêmement rapides. Si vous avez déjà une bonne compréhension et pouvez produire quelque chose de plus substantiel sans vous soucier de le jeter parce que c'était la mauvaise direction, vous pouvez passer plus de temps. Quoi qu'il en soit, un prototype cliquable peut grandement contribuer à déterminer ce que le véritable site doit être à la fin. Si vous pouvez obtenir un accord sur le prototype, lorsque votre application correspond au prototype, vous savez que celle-ci est terminée.