Avantages quantifiables du wireframing et du prototypage?
J'essaie de trouver quelques sources pour les avantages quantifiables du wireframing et du prototypage, mais j'ai du mal à trouver des résultats. J'ai vu beaucoup de "réduire la phase des exigences, améliorer la qualité, etc." mais je cherche des études avec quelques chiffres de plus.
EDIT: J'ai mis à jour le titre de la question pour mieux refléter ce que je demande. Je ne recherche pas nécessairement un calcul traditionnel du retour sur investissement du wireframing et du prototypage, mais je recherche des avantages quantifiables qui sont un résultat direct. Des études qui peuvent afficher, par exemple, "30% (nombre arbitraire) de retouches réduites résultant directement de la mise en œuvre de wireframes et de prototypes", c'est ce que je recherche.
J'utilise certaines métriques de la question "ROI of UX", telles que "50% du temps des développeurs est consacré à la retouche", ce qui aide mon cas, mais des résultats spécifiques directement du wireframing/prototying sont souhaités.
EDIT 2:
Je reçois beaucoup de "conseils de réponses" qui ne sont finalement pas le but de cette question. La plupart d'entre nous ici à UX.SE comprennent les prototypes et les avantages généraux. Je recherche des données quantifiables, issues de préférence d'analyses scientifiques.
Voici un extrait que j'ai trouvé, c'est le type d'informations que je recherche:
"Dans une expérience menée à l'UCLA, certaines équipes de développement ont utilisé des méthodologies de développement conventionnelles tandis que d'autres ont utilisé des prototypes dans le processus de développement logiciel (sans accent particulier sur l'interface).… Le code des systèmes finaux produits par les groupes de prototypage n'était que d'environ 40% comme celle de leurs homologues, peut-être à un coût en général de conception. Enfin, les groupes de prototypage ont accompli leur tâche avec 45 pour cent d'efforts de moins que les autres groupes. "
http://eprints.cs.vt.edu/archive/00000179/01/TR-89-42.pdf - page 5.
Modifier 3:
Un autre excellent exemple des informations que je recherche. Ceci est tiré du livre "Prototyping: A Practitioner's Guide" de Todd Zaki Warfel:
Une société de conseil au Royaume-Uni est passée d'un processus orienté exigences à un processus orienté prototypage. Le changement de processus a entraîné les avantages suivants:
Le temps et les efforts nécessaires pour produire le prototype et le document supplémentaire de 16 pages sont moins de la moitié requis pour le document de spécification de 200 pages
Les estimations du temps et du coût de construction sont devenues 50% plus précises
La demande d'éclaircissements de l'équipe de développement a été réduite de 80%
Le nombre de retouches et de corrections de bugs après le lancement a été réduit à 25% des projets précédents similaires
La réponse directe à cela est assez simple:
C'est dans la nature d'un prototype d'être bénéfique.
Si ce n'est pas bénéfique, vous vous trompez ...
Si ce n'est pas bénéfique, ce n'est pas du prototypage par définition ...
Lorsque vous démarrez le prototypage, vous devez savoir pourquoi vous faites du prototypage. Vous devez savoir quels seront les avantages. Si vous ne connaissez pas le but du prototypage, laissez-le tomber. ... ... ... ou lisez le sujet ;-)
Deuxième partie mise à jour de la réponse
Je vous ai signalé l'article de Scott Overmyer (de 2002), " Prototypage rapide révolutionnaire contre évolutionnaire rapide: équilibrer la productivité logicielle et les problèmes de conception HCI ". Cet article est cité comme une référence à la façon dont le prototypage "Temps et coûts réduits" sur Wikipedia .
Le document n'était pas disponible auparavant, mais l'auteur a maintenant téléchargé le document sur academia.ed .
En bref, l'article compare le prototypage révolutionnaire et le prototypage évolutif et préconise une solution hybride de ces méthodes (rappelez-vous que l'article a été écrit en 2002, de sorte que l'état des approches de prototypage s'est développé depuis).
Cinq études de cas sont analysées (et l'auteur souligne qu'il est difficile de trouver de telles études dans la littérature).
Étude de cas n ° 1: Prototypage révolutionnaire. L'effort de prototypage a représenté environ 6% de l'effort total de développement logiciel de 10 années-personnes. 5 itérations ont donné un bon aperçu de plusieurs aspects du système. La livraison a été un succès.
Étude de cas n ° 2: Un effort de développement logiciel extrêmement important avec 1200-1500 affichages graphiques et tabulaires. Les données ont été collectées à partir d'essais d'utilisateurs et ont été utilisées comme entrée dans un modèle de simulation de système, résultant en une prévision de performance plus précise pour l'architecture globale du système.
Etude de cas n ° 3: Une étude de terrain de 48 entreprises "Fortune 1000". Il conclut que le prototypage révolutionnaire est le concept de "coquille vide idiote" de développement de systèmes d'information. L'échec de la banque de Chicago à utiliser avec succès le prototypage révolutionnaire pour la définition des exigences est utilisé à titre d'exemple. Dans ce cas, les utilisateurs finaux ont passé en moyenne 250 heures à développer chacun des six prototypes révolutionnaires. Les développeurs du système ont passé entre 75 et 225 heures pour chaque application prototypée pour construire le système opérationnel. Cela représente un effort redondant compris entre 30 et 90% par prototype.
(Remarque: cette étude de cas a été réalisée en 1987. Avant la zone Windows et avant la zone Internet. Je ne sais pas si ces numéros sont toujours valides.)
Étude de cas n ° 4: Prototypage évolutif effectué en 12 cycles de conception, de mise en œuvre et d'évaluation. Chaque cycle dure environ 2 semaines pour une durée totale de 2 ans. Pendant cette période, 412 modules ont été produits à partir de 32 745 lignes de code, ce qui a nécessité 2613 heures (65 personnes-semaines) d'effort. Un chiffre intéressant est que 12 957 lignes de code ont été supprimées au cours de l'effort, avec environ 1/6 de ce montant rejeté lors de la phase d'optimisation finale.
Étude de cas n ° 5: Expérience avec des étudiants de 1984. L'effort de prototypage (et de spécification) s'est déroulé sur une période de 11 semaines.
Conclusion tirée de ces cinq cas:
Il est affirmé que le prototypage rapide révolutionnaire est une manière plus efficace de traiter les problèmes liés aux besoins des utilisateurs, et donc une plus grande amélioration de la productivité globale des logiciels.
Le prototypage évolutif peut être utilisé pour résoudre les problèmes de performances du système, cependant, il n'est pas clair si cette technique est supérieure à la modélisation et à la simulation architecturales combinées à la simulation de l'homme dans la boucle via un prototypage rapide.
Pour les systèmes interactifs, il bénéficiera probablement d'un prototypage rapide révolutionnaire pour les besoins des utilisateurs en combinaison avec un prototypage évolutif pour les exigences logicielles et le développement du système.
Je pense que la meilleure façon est de regarder la quantité de temps et d'efforts dépensés dans les cycles de sprint avec et sans ces actifs, mais il est très difficile de faire une étude à ce sujet car je ne pense pas que de nombreuses organisations collectent ce type d'informations, ou s'ils le font, il n'y a aucune raison particulière de le mettre à la disposition des gens. Personnellement, vous devez également mettre cela en balance avec le coût de création et de maintenance d'un ensemble supplémentaire d'actifs.
Alternativement, vous pouvez regarder l'effort/estimation actuel pour l'équipe de développement et spéculer sur le potentiel de faire plus de travail lié à l'expérience utilisateur pour réduire les coûts de développement et également les efforts de formation applicables à votre organisation. Je pense qu'il y a déjà beaucoup écrit sur le retour sur investissement de l'expérience utilisateur, mais il est temps que les gens commencent à cadrer cela dans le contexte de leur propre organisation.
Bien que l'article ci-dessous de J. Nielsen ne mentionne pas le retour sur investissement, le wireframing ou le prototypage, sa conclusion est applicable à votre question: environ 5 utilisateurs aident à découvrir ~ 80% des problèmes d'utilisation.
Maintenant, cela devient une question de processus de développement de produit: tester les prototypes et itérer jusqu'à ce que l'UX soit correct, avant de brûler les ressources de développement, augmentera le retour sur investissement de l'UX.
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
Suivi de l'édition 3
Selon votre exemple, vous devriez jeter un œil aux métriques clés de gestion de produits et de projets.
La partie quantifiable serait le "coût en temps et en matériaux".
Pour construire quelque chose, il faut le prototyper. Cela pourrait être un croquis à une extrémité de l'extrême, ou manipuler les matériaux finaux sur place serait l'autre extrémité.
Ainsi, par exemple, si je devais construire une maison, je dois commencer par la fondation.
Avec un processus prototype défini: croquis de serviette de la propriété, quelques croquis de la maison sur ladite propriété. Si rien d'autre n'a été fait, nous avons au moins une assez bonne idée de l'endroit où la fondation devrait aller.
Sans processus prototype défini: creusez un trou, construisez une fondation. Est-ce un bon endroit? Non? Remplissez le trou, creusez un nouveau trou, construisez une autre fondation. Est-ce un bon endroit?
Le fait étant que pour terminer un produit, ce processus doit se produire. Et moins ce processus doit se produire avec les produits/matériaux finaux les plus coûteux, moins il sera cher.
Pour le mettre dans le contexte du code, 3 wireframes rapides sur le tableau blanc pour aider à réduire la solution à une seule option seront beaucoup moins chers que d'avoir 3 développeurs utilisant le code réel pour trouver 3 solutions différentes à comparer.
Le groupe Nielsen Norman devrait pouvoir vous aider. Une recherche rapide sur leur site a renvoyé ces articles:
http://www.nngroup.com/articles/usability-roi-declining-but-still-strong/http://www.nngroup.com/articles/when-high -cost-usability-makes-sense /
... entre autres. Le retour sur investissement dans les études d'utilisabilité a un impact mesurable, tout comme les tests avec des prototypes. La combinaison des deux ensembles de données serait-elle suffisante pour quantifier un retour sur investissement du prototypage rapide, ou recherchez-vous également des données sur les coûts d'opportunité?
Il me semble que (même si ce n'est pas votre intention) votre question demande essentiellement "quel est l'avantage de planifier à l'aide de wireframes/prototypage par rapport à autre chose?" Le problème avec cette question est qu'une partie de tout le reste comprendra à la fois aucune planification et des équivalents aux wireframes/prototypage. Il n'y a aucun moyen de faire une comparaison statistiquement (ou financièrement) saine dans un tel scénario.
En d'autres termes, vous devriez comparer x et y. C'est à dire. filaire vs pas de planification. C'est à dire. filaire vs organigrammes.
Si le but de votre question était de demander l'avantage de la planification en termes plus généraux, vous devriez regarder bien au-delà du wireframing (comme le suggèrent la plupart des autres réponses). Si vous souhaitez distinguer des techniques spécifiques telles que le wireframing, vous devez également définir les alternatives auxquelles vous souhaitez les comparer.
Je vais hors sujet pour obtenir un raisonnement plus valable pour tous les commentaires qui ont été mentionnés ici.
Nari Gandhi, un architecte, dit qu'il a travaillé sans bureau ni dessin - de manière similaire, cela signifie qu'il avait utilisé plus de "Visual Scoping" ou "Seamless adjustement" pour guider son idée et l'élaguer avec de bonnes suppositions (peut-être qu'il a dessiné des miniatures ou des croquis plus petits pour avoir un palpeur), dans ce cas, cela signifie que le retour sur investissement (temps dans les choses intrigantes) de ses produits est considéré comme des artefacts vivants - où un client est heureux de vivre dedans, sans jamais avoir une voie traditionnelle de pratique du dessin (peut être bio avec sa méthode - mais avait un produit final) - Le résultat! Mais quand même, Les clients sont toujours dans le noir sans savoir ce qui va se former. Proposition risquée.
"Nari a travaillé sans bureau et a rarement fait des dessins pour aucun de ses projets. Nari a passé beaucoup de temps sur ses sites et a travaillé en étroite collaboration avec les artisans et a souvent participé lui-même au processus de construction", comme extrait de Wikipedia.
Si vous deviez superposer cela à la pratique UX - je pourrais toujours rester comme la façon dont cet architecte ferait équipe avec les travailleurs, l'artisan et le site lui-même - le Guy UX devait collaborer avec les autres membres de l'équipe.
C'est vraiment bien si son architecture, car vous verriez des résultats tangibles - mais dans UX, vous pouvez construire un codage direct mais vous deviez toujours dépendre d'autres ressources humaines - plus souvent car le produit est intangible et beaucoup de complexité comme la vitesse, le serveur, la base de données et les connaissances techniques inconscientes ralentissent ou sont pratiquement impossibles pour un responsable UX de le parcourir seul.
Tout cela dit - Wireframing ou Mocking-up est un moyen de trouver le résultat, mais pas en soi n résultat! Vous pouvez choisir de ne pas suivre cette route et de prendre une autre route où le codage direct peut vous trouver des résultats comme dans le cas de Nari Gandhi.
Je n'ai pas de point de recherche direct sur votre question, mais une mesure qualitative dirait certainement que le temps passé sans travail de base ou proto est une supposition de quiconque - qui est la consommation de temps (quantifiable) et beaucoup de boucles en boucle ou se terminant dans un labyrinthe, à moins que jamais son effort si collaboratif.
Je suis très curieux de savoir pourquoi vous recherchez ces données.
Je doute que vous trouverez jamais des résultats quantifiables pour le retour sur investissement sur le wireframing/prototypage parce que le retour sur investissement pour ces activités est mesuré en fonction du travail que vous ne faites pas faire.
Prenons un exemple simple de création d'un formulaire Web ou d'une boîte de dialogue unique. Afin de mesurer le retour sur investissement pour la création d'un filaire de ce formulaire ou boîte de dialogue, vous devez effectuer les opérations suivantes:
- Créer le filaire/la maquette
- Décidez que vous n'aimez pas la structure filaire/maquette
- Allez-y et implémentez le formulaire/dialogue de toute façon, même si vous savez que vous ne le voulez pas
- Mesurez la différence entre le temps de développement pour # 3 et le temps qu'il a fallu pour faire # 1.
Personne sensé ne ferait cela. Je doute qu'il existe des études sur ce sujet, car les avantages sont manifestement évidents pour quiconque ayant une expérience du monde réel.
Le wireframing et le prototypage font partie du processus de conception de logiciels. Ce n'est pas différent que de travailler avec des diagrammes et des plans avant de fabriquer un objet physique. Personne ne demande jamais le retour sur investissement sur la conception d'un objet physique avant de le fabriquer :).