Design with User-Stories - the curse of the technical/UI story !
No Technical or UI Stories
I’ve been hearing lots of conversations or read posts lately where people mention “technical stories. We even can spot some of these “technical stories” in the invaluable Scrum and Xp From the Trenches, p9 . And reading this thread on agile UCD made me react on this concept of “UI stories” ! To me, it makes the same feeling as “technical stories” do : it makes me shudder !
As I see it, a story is something across all layers that “provides some value” to a user. Let’s rephrase it : “something that brings an actor using the software closer to (at least one of) its goal(s)”. Stories should stay “above the water”, as mentioned in Cockburn’s Writing Effective Use Cases . They should avoid dealing too much with the solution and focus on dealing with a problem the user has.
User-stories should stay “above the water”
Some people write “technical stories” to creating a new table in a DB or add a button. These are not stories, but merely tasks that need to be done in one solution to such stories. Actually, I consider it pointless to talk about anything other than “User(/actor) Stories” (actor because stakeholders, admins, deployment and other software also interact with the product). Since Kent Beck coined the term “user story” and thanks to Mike Cohn’s book spreading the use, working with stories was imho a great step as it brought back some focus on the user side, away from “the system shall…”. Let’s not forget that.
That being said, it’s true that some stories have a greater focus on usage (and thus the UI), some on a complex business logic, some involve technical feats underneath… But all should be user stories.
USER stories
What are user-stories ? It’s not just about using flashy post-it notes or cards, to prevent us from writing lengthy specs to bury somewhere. It’s not just about doing things fast and dirty. It’s not a matter of dividing the work to come in “sprint items”. It’s a matter of design.
User Stories should be the focal point (as illustrated in this article about the product owner), enabling communication between all perspectives : UX, design, dev… Here I’m using the term “design” on intent, refering to its two perspectives, as in “apple products have a great design” and “a well refactored oo design”. These two perspectives are not opposite. They are the two sides of the same coin.
User-stories should be the focal point between all perspectives
Design is finding a solution to a problem. User-stories enable us to have conversations (as in cards, conversation, confirmation by Ron Jeffries) about design : how do we solve things for users ! They are anchors for conversations
So, how we phrase user-stories, how we slice them (like Maven and Motley), how we picture them should not be dealt carelessly !
Organizing stories
First, how do we picture and organize them ? For that, storymaps are a great concept that have been gaining popularity lately thanks to InfoQ, initially brought forward by Jeff Patton and Todd Warfel through his Task Analysis grid. Whereas a classical backlog is a 1-dimensional list of stories, storymaps help you organise them in two dimensions. On a horizontal axis, the workflow of user activities. On a vertical one, the necessity of stories, from bare necessities to luxury.
Do you try to avoid building your application in a horizontal component-layered structure one component at a time, to favor a vertical one providing some value to the user across all layers ? Just step back and there you can see the vertical slices of your application. This helps a lot ! You can still have horizontal slices but they have a different meaning. You use them to iterate and refine features.
User-stories are organised in a storymap
This provides a big picture of features for a whole product, enables you to outline a functional roadmap. I also use that to visualize and litterally pinpoint risks… I’m curious of your experience : any other usage of your storymaps ? The backlog is dead : long live the storymap !
Phrasing stories
Let’s focus a little about specifically on how to phrase them. So, my user-stories don’t look like those for instance of the story card template described by Scott Dunn, or like the standard “as a
You don’t have to state why its’s valuable to the business because you only write one when answering one need of an actor toward its goal. Should we begin by considering technical constraints, as usual from an architect perspective, as most IT departments do ? My answer is a clear NO !
I prefer to see how technical constraints and risks map on the functional and incremental view of the product : the storymap.The order by which you pick up stories is made obvious through a storymap by outlining a release plan.
Dealing with constraints
User-stories should not mention the tool, that is the UI or the technical solution used : this should only feed the constraints, whether directly in the DoD (for the french crowd) (Definition of Done) or for specific stories. If it’s not obvious to you, yes UX (user experience) considerations should also appear in the DoD.
Constraints are for the validation part of User-stories
Any business rule/data requirement/whatever constraint (UX, performance, *ity) is specified in the validation part of the story. This should be succinct enough to fit in one or two lines of an spreadsheet cell. If not, work on stating clearly what is the intent behind and question that. When dealing with a business logic that is not straightforward, this is all transposed in some acceptance tests one iteration at a time, ready for discussion at sprint planning time. Of course, there are some issues uncovering some potential complexity that have to be anticipated. Anyone remembers the work on software reuse from the 90’s and axis of variability ? Discussions on design again !
What process do I follow ?
So how do I use user-stories ? I first define the actors and their objectives, which is a first take at personas, that may be refined later. Other actors or roles may be later added or divided into more specific roles or profiles, but franckly, the few ones appearing at the first pass will already provide you lots of insights.
As all cards refer to at least one actor whose goal has been stated, the value doesn’t have to be stated for each story : away the “in order to” from the canonical from. They can thus focus on the action part of the story. A little step toward literally drawing stories : a symbole or picture in a top corner of a card is a good way to do that. Directly using names of personas is a very good idea that I’ll use next time ! Any card that doesn’t provide and fit in an actor’s goal will be thrashed, it’s as simple as that. They are grouped into activities, ordered by necessity, may be sliced with varying “conditions of validation” from a minimal service to the full monty. They are then estimated on a “just-in-time” basis for the next release, that is one or two iterations in advance.
User-stories enable us to have conversations about design
All this is subject to lots of conversations. The cards may be rephrased as the intent behind the stories becomes clearer. As the solution for a problem of a user becomes clearer. As the design becomes clearer.
I emphasized the importance of user-stories, as a support for conversations for design. But knowing that we’re visual animals, I’m also convinced (thanks to Dan Roam talks ) that we must use more our visual potential. Crafting “Product Boxes” is a one step toward that. Appart from traditional oo diagrams and other potatoids, I’m convinced that we should draw more to support our designs.
Any examples of what and how you draw to support your stories / your designs ?
Agilité : utopie du consensus ?
En réponse à l’article d’Emmanuel Chenu sur les critiques courantes faites à l’agilité, j’essaie de revenir pour 2009 derrière le clavier pour mon blog. Emmanuel, dans son article, répond à tout un ensemble d’idées fausses : manque de rigueur, absence de conception notamment… Assez d’accord sur l’ensemble des arguments qu’il apporte, je réagis sur le dernier point qu’il aborde : “Ces démarches vivent sur l’utopie du consensus dans l’équipe”.
On évoque la notion de consensus pour les équipes agiles, parce que celles-ci mettent en avant l’idée d’équipes auto organisées, portant collectivement les décisions prises. Equipes auto-organisées, où chacun dans le groupe est prêt à accepter les opinions divergentes et à faire le deuil de ses positions, privilégiant l’écoute et le dialogue plutôt que la discussion, où chacun cherche à faire triompher son opinion.
Cela ne se fait pas bien sur sans travailler à long terme sur la dynamique d’équipe, point sur lequel l’agilité met justement l’accent.
Concrètement, je connais peu d’équipes qui évoluent sur un mode purement collectiviste, indépendamment de toute autorié susceptible de trancher. Dans les faits, questions de hiérarchie mise à part, il y a souvent un expert qui fait autorité sur le sujet et qui départage les positions. Par contre, il peut arriver que la personne en position n’ose pas assumer son rôle et trancher justement. Ça nous ramène à la question du courage et de la responsabilité individuelle.
Au niveau de l’équipe, il ne peut y avoir de responsabilité collective que si chacun assume sa part de responsabilité individuelle.
Aparté systémique sur la question. On peut étendre ces questions de responsabilité à tout système : l’organisation, la société, le couple… En l’absence de responsabilité individuelle, on obtient que de l’irresponsabilité collective et pas grand chose de bon. Alors quelles considérations pour qu’un système tourne un peu ? S’entendre sur les valeurs qui unissent les parties, s’assumer soi en respectant l’autre dans son individualité et être prêt à l’introspection individuelle et collective… D’aparté systémique en réflexion personnelle. En fait, je pensais au couple parce que je n’ai justement pas été exemplaire récemment, que j’en constate directement les conséquences et que la question était là omniprésente à mon esprit ; certains auront lu “société” et ça me va ; les autres auront lu “équipe” sans que la digression nuise trop au propos j’espère.
Revenons à nos moutons et à la notion de consensus pour lui tordre un peu le cou. Non une équipe agile n’est pas guidée par la recherche du consensus. Le consensus est un effet de bord de son auto organisation. Par contre l’équipe agile est guidée par la volonté de délivrer de la valeur à son client, dans le respect des valeurs qui l’anime.
Dans le doute, c’est donc la voix du client, du responsable produit qui tranchera toujours, guidé par les autres expertises (notamment techniques) nécessaires.
Vous me direz, et si cette décision est en opposition avec le processus/l’équipe ? Le scrummaster, le coach est justement là pour protéger l’équipe. Encore une manière agile de gérer la chose : deux responsables distincts pour deux dimensions orthogonales : celle lié aux objectifs produit et celle liée au processus et à la dynamique d’équipe. Une façon d’éviter la schizophrénie usuelle du chef de projet (celui qui n’a pas renoncé à l’idée de prendre soin de son équipe en tout cas). Mais lorsque l’on en arrive là, à une opposition entre ces deux perspectives, c’est vraisemblablement qu’il y a un problème d’alignement entre les objectifs du produit et l’équipe qui le porte, et que l’on a peut être pas compris que l’un ne va pas sans l’autre.
C’est justement une des clés de voute de l’agilité : Produit = Equipe !
Voila sur l’utopie du consensus. Pour tout dire, l’appétit vient en bloguant et j’ai maintenant aussi envie de réagir sur un autre point : la vision à long terme. Ca me fera l’occasion de bloguer de nouveau. Comme quoi, si vous n’avez pas blogué depuis longtemps, n’hésitez pas à réagir sur ce post =;]
Coopérer : être plus efficace et mieux vivre face au changement
Merci à tous ceux qui ont répondu à cette étude en psychosociologie sur les impacts de la coopération. Les nombreuses réponses à travers le monde (plus de 260 dans une vingtaine de pays) ont permis d’aboutir à des résultats très clairs.
Ceux-ci sont présentés dans le mémoire (Document .pdf) de Delphine Allin : “Comment concilier performances et bien-être au travail ? Les effets de la culture organisationnelle coopérative sur les comportements citoyens organisationnels, la performance adaptative et l’épuisement professionnel.”
Qu’est-ce qu’on peut en retenir dans une perspective agile ?
Tout d’abord l’étude montre clairement que les employés d’organisations basées sur une culture coopérative souffrent de moins d’épuisement et ont de meilleures performances adaptatives. Ils sont en effet plus efficaces pour la résolution créative des problèmes, la gestion de l’incertitude et de l’imprévisible, l’apprentissage de nouvelles tâches, technologies ou procédures, et la gestion du stress et des situations de crise.
Pour ce qui est des entreprises agiles, on constate que les employés ont une plus grande loyauté : ils ont plus tendance à agir de façon innovante pour améliorer le fonctionnement du département ou à travailler au-delà de ce qui est attendu. Sans doute le reflet d’équipe autonomes et responsabilisées (”empowered” en anglais), capables de réfléchir sur leurs pratiques.
Etonnament, on constate une absence de lien spécifique entre agilité et à la fois la culture organisationnelle coopérative et performances adaptatives. C’est surprenant au regard du manifeste agile !…
Plusieurs raisons à cela. Tout d’abord le fait que, selon le modèle utilisé dans l’étude, les entreprises agiles mixent des caractéristiques de plusieurs cultures différentes, en étant non seulement centrées sur le groupe, mais aussi sur les besoins du client et avec un parti pris d’innovation et de réactivité au changement. L’agilité, ce ne sont pas que des équipes auto-organisées, mais aussi des équipes coopérant avec le client pour la production rapide de valeur.
La deuxième raison vient sans doute du fait que les équipes agiles font partie d’organisations plus larges dont la culture n’est pas cooperative. D’où l’importance de ne pas faire évoluer les comportements vers plus d’agilité qu’au sein des équipes, mais d’infuser au-delà dans les modèles de pensée et de fonctionnement, notamment des équipes dirigeantes.
La coopération : une stratégie gagnante ! Cela veut dire des équipes moins fatiguées et mieux à même d’être efficaces faces à des situations nouvelles. En fait, on en revient à ce qui est montré par le dilemme du prisonnier : j’ai tout intérêt à coopérer, à condition d’être dans cadre propice à la confiance.
Coopérer : travailler mieux pour vivre mieux ?
Tout est dit dans le titre ! Voila une étude internationale qui va s’intéresser aux effets de la coopération sur les conditions de travail, et leurs répercussions sur les comportements citoyens, la performance, les réactions de stress et de burnout.
Pour cela, il suffit de répondre au questionnaire ici (en anglais).
Les résultats devraient permettre d’en savoir un peu plus sur le sujet, peu exploité, de la coopération. Ca devrait aussi permettre de répondre a la question : les équipes agiles sont-elles vraiment plus coopératives ? Quelles conséquences pour les collaborateurs ?
Vous avez un avis sur la question ? Ca m’intéresse !
Comment libérer les projets du triangle de fer
Lorsque je fais le point avec un client sur la situation de son organisation, on en arrive souvent à faire un même constat : les équipes sont à fond en production, cravachent dur pour livrer tout ce qui est dans le cahier des charges et tenir les délais. Trop de fonctionnalités, trop peu de temps… des previsions ne seraient-ce qu’un peu depassées et les marges diminuent… Ce n’est pas l’envie qui manque de developper d’autres axes, mais le temps manque tout simplement. On est pris dans le triangle de fer !
Le triangle de fer
Parmi les décideurs d’un projet, chacune des parties prenantes a une perspective différente sur le projet : * la perspective financière qui cherche à obtenir un produit/système à moindre coût, * la perspective managériale dont le but est de respecter les délais et de manager les personnes. Cela se résume dans la figure suivante, dite du “triangle de fer”.
La réussite d’un projet repose donc sur la satisfaction de ces trois critères : livrer l’ensemble des fonctionnalités, dans les délais et au budget prévu.
Faire varier les ressources ?
Ce triangle est qualifié de triangle de fer car il ne peut évoluer. Un projet doit aboutir dans les délais en livrant l’ensemble des fonctionnalités. Classiquement, la seule variable d’adaptation sur laquelle on peut jouer passe donc par l’ajustement des ressources.
Si les délais et le périmètre sont fixes et que le projet prend du retard, on peut alors avoir l’impression qu’assigner des personnes supplémentaires permettra de résoudre les problèmes et de livrer dans les temps. C’est le genre de solution d’autant plus facile lorsque l’on dispose d’une ressource abondante (et les mauvaises langues diront corvéable à merci =;]) : on rajoute des stagiaires. Toutefois, cette approche a des limites. Comme on dit : “9 femmes ne peuvent avoir un enfant en 1 mois” .
On sait, notamment depuis le livre “Mythical Man-Month” de Brooks que le fait de rajouter des personnes sur un projet en retard est d’ailleurs avant tout une source de complexification et d’échec des projets. Comme il le dit lui-même “Adding people to a late project makes it later.”
“Rajouter des personnes sur un projet en retard ne fait que le retarder d’avantage.”
Ca parait bête à dire, mai les ressources humaines ne sont pas interchangeables. Ou alors seulement dans le cas de projets sans vraies contraintes de ressources, de délais ou de complexité.
Une dimension cachée : la qualité
Le triangle de fer contient une dimension cachée, implicite : la qualité. Ce n’est plus un triangle : c’est une pyramide ! Autant il est facile de quantifier les ressources, de surveiller les délais ou de lister les fonctionnalités, autant pour évaluer et garantir la qualité d’un projet informatique, on entre dans l’irrationnel, les cncantations vaudoues, les rituels mysterieux…
“Pourvu que ca tienne !”
C’est regrettable à dire, mais dans le monde logiciel : la qualité tend à être un élément à part des fonctionnalités. Parlez à un client de qualité et il vous dira qu’il la veut… mais sans être prêt à en payer le prix. Si l’on cherche à figer à la fois les délais, les coûts et le périmètre d’un projet, on ne dispose d’aucune marge de manoeuvre et on risque vite être déçu. Quand les échéances se rapprochent et que les budgets explosent, on a plus aucune marge de manoeuvre et c’est justement elle la première victime : la qualité.
Autant se tirer une balle dans le pied. A long terme, c’est le genre de situation synonyme d’un client insatisfait car les méchantes bestioles (1 et 2) refont toujours surface! Tant qu’on est sur une note humoristique, Mike Vizdos lui aussi aborde le sujet avec ses cartoons.
La dimension humaine
Comment tenir les délais en essayant de ne pas trop bâcler la qualité, si l’on ne tombe pas dans le piège de rajouter du monde dans l’équipe ou tout simplement lorsque l’on ne dispose pas de personnes supplémentaires à mobiliser ? En fournissant ‘un dernier coup de fouet’… ‘en se mobilisant’… ‘en faisant le forcing’…
C’est le genre de comportement courant, voire même valorisé ! Il faudrait presque ériger un monument à la mémoire des héros infatigables qui à grands renforts de café tapote sur leurs claviers des nuits entières et livrent l’oeil hagard une application impeccable au petit matin…
Nous le savons tous, ce n’est jamais un bon présage sur le plan de la qualité. Ni à long terme pour l’ambiance et l’épanouissement au travail…
Comment s’en sortir ?
Comme nous le rappelle Alistair Cockburn, il y a une dimension supplémentaire : le processus. Comment donc s’en sortir ? Grâce à une approche agile bien sur.
Etre agile : “Cheating legally to win” !
Le point essentiel est de se débarrasser du “Big Design Up-Front”, qui consiste à recueillir l’ensemble des besoins avant la conception et le développement. C’est un aspect que j’avais aborde précédemment et que je risque de répéter…
L’approche agile propose à la place de privilégier un raffinement progressif des besoins en s’appuyant sur des discussions fréquentes. On recueille juste ce qu’il faut de besoins et on développe les fonctionnalités correspondantes pour obtenir un feedback rapide sur une application fonctionnelle.
On prend ainsi en compte le fait que les besoins évoluent fatalement non seulement en même temps que l’environnement métier ou le marché, mais surtout avec la connaissance que l’on acquière au fur et à mesure du projet.
Pire, prendre en compte l’ensemble des exigences dans une même livraison, c’est courir droit vers l’explosion des besoins. Cela revient au mieux à livrer des fonctionnalités inutiles. Au pire, à ne rien livrer, parce que l’on est tout simplement débordé.
Voila pour aujourd’hui. Je répondrais dans la deuxième partie à la question : comment l’agilité aide-t-elle concrètement dans tout ça ?
Methodes Agiles et Design d’interaction
J’ai fait Mardi dernier pour Designers Interactifs une présentation que j’avais annoncée dans un précédent billet sur les méthodes agiles et le design d’interaction.
Le public était varié puisque l’on y trouvait des directeurs artistiques, développeurs et graphistes. Dont certains qui avaient déjà entendu parler de l’agilité. Il y avait même quelques pratiquants dans l’assemblée. La présentation avait plusieurs objectifs.
Tout d’abord montrer les problèmes que soulèvent les pratiques classiques de gestion de projet et ce qu’apporte l’approche agile. Ensuite montrer les points communs avec le Design centré utilisateur : approche centre sur le client, importance des tests et du feedback utilisateur.
Mais aussi montrer les changements de comportement que ça implique. Le principal est d’abandonner le fonctionnement traditionnel par phases pour une approche itérative ou le produit est progressivement raffiné. Enfin donner une idée des pratiques agiles qui peuvent être mises à profit par les designers interactifs pour évoluer. C’était presque un manifeste pour une ergonomie agile.
La présentation est disponible sur slideshare en slidecast, c’est a dire avec une bande son qui l’accompagne. Seul petit hic, en ce moment il ne fait pas bon courir dans les bois pendant des heures sous la grêle et ma voix n’est donc pas des plus claires… Pour ceux qui veulent creuser un peu la question de l’utilisabilite agile, Scott Ambler en donne un bon apercu.
J’étais très curieux à la fois de l’accueil que pourrais recevoir une telle présentation et des échanges qui pouvaient s’ensuivre et je n’ai pas été déçu. On a eu des témoignages, avec notamment celui d’une graphiste qui travaille dans une équipe XP avec une itération d’avance par rapport aux développeurs et à qui l’approche agile semblait très naturelle.
On a aussi abordé les obstacles que chacun pouvait voir à passer à une approche agile. Celui qui est le plus revenu est celui de l’implication des clients non matures : - des clients qui ne s’impliquent pas dans la boucle, - une perspective client bicéphale, - des clients qui veulent se décharger de toute responsabilité, - des clients qui veulent tout, tout de suite…
C’est vrai, l’approche agile demande d’éduquer le client, de lui faire comprendre qu’on ne peut avoir le beurre et l’argent du beurre : un produit qui me correspond, mais sans m’impliquer… Toutes les fonctionnalités, maintenant ! Pour ça, il faut mettre en place les choses progressivement, en lui donnant une visibilité sur l’avancement, en l’assistant pour piloter le projet par la valeur, et surtout en effectuant des livraisons fréquentes de produit bien concret.
Viens ensuite l’inévitable question des contrats. J’aurais d’ailleurs pensé que cette question se serait invité au débat avec plus d’ardeur, je suis positivement étonné. En effet, les participants n’était pas trop inquiets à l’idée de fonctionner par lot.
Bref, un accueil très positif. Certains seraient même conquis par l’agilité et pourtant, je n’ai pas parle de télépathie…
Mettre les exigences en boite
Dave Nicolett nous présente une méthode très intéressante pour structurer l’expression des besoins dans une approche agile, sous forme de user-stories ou scénarios. Je préfère utiliser ce dernier terme car à mon sens plus pratique et évocateur.
L’idée est d’organiser le déroulement d’une interview client en 9 étapes successives, de façon à cerner l’ensemble des facettes des scénarios envisagés. On voit ça dans le schéma ci-dessous, retranscrit à ma manière.
On définit ainsi le problème, puis qui il affecte, puis comment serait la situation une fois le problème résolu (sans présager de la manière de le résoudre).
On retrouve ce principe de se projeter dans l’avenir dans l’exercice que j’aime bien utiliser Design the Box ou on imagine le produit une fois réalisé (Décidément on parle beaucoup de “box” !). Dans le même style, Claude Aubry évoquait récemment Remember the future qui fonctionne sur les mêmes principes.
Revenons à nos moutons. Pour chacune des facettes, l’interview pose trois types de questions. D’abord des questions ouvertes pour dégrossir le problème et découvrir les préoccupe sous-jacentes. Ensuite, on essaie de quantifier les choses et enfin on s’assure que l’on a bien saisi en reformulant. C’est l’occasion de se rendre compte s’il y a des éléments à préciser auquel cas on revient en arrière. Et en plus, comme on le voit dans le schéma, cette technique permet justement de faire ressortir les besoins non fonctionnels.
On a alors tout ce qu’il faut pour exprimer directement notre scénario. Dave Nicolett envisage de les exprimer sous leur forme “canonique” :
"As a <role> I want to<action> so that <value>."
Ce qui donne en français
"Comme <rôle>, je veux <action>, de façon a <valeur>."
Personnellement, j’énonce les scénarios différemment et c’est justement ce qui m’a marque dans cette technique, c’est qu’il suffit de prendre les colonnes dans l’ordre pour les formuler sous la forme :
"Pour <valeur>, comme <rôle>, je veux <action>."
On a ainsi une expression des scénarios explicitement 1. conduite par la valeur, 2. centrée sur l’utilisateur et 3. independant de la solution ou des taches.
C’est justement tout l’intérêt d’exprimer ses besoins au moyen de scénarios ! Reste en plus à le faire de manière itérative, selon un raffinement progressif qui l’imite l’inventaire…
Présentation - méthodes agiles et design d’interaction
Je ferai une présentation sur les méthodes agiles le 4 Décembre prochain au Cafe Dune de 20h à 21h30 dans le cadre des Designers Interactifs.
“Un cahier des charges respecté mais un client pas 100% convaincu… La motivation et la créativité engluées dans le ventre mou des projets qui s’allongent… Un marché, des besoins, des technologies, des usages en évolution constante…”
Voila quelques-uns des problèmes que cherchent à résoudre les méthodes agiles par une approche basée sur la collaboration et des livraisons rapides et régulières au client.
Cette présentation dressera donc un aperçu des méthodes agiles, des valeurs qu’elles mettent en avant et des pratiques sur lesquelles elles reposent. Elle devrait être l’occasion d’engager un débat autour des questions telles que : - la place du design d’interaction au sein des projets - la collaboration au sein des equipes et avec le client, - les rapports entre expérience utilisateur et feedback, - la relation entre livrables et valeur produit.
Elle s’adresse a tous ceux - DA, webdesigner, chef de projet - qui souhaite échanger sur leurs expériences et pratiques en matière de conception centrée utilisateur et conduite de projet ou tout simplement découvrir de nouvelles perspectives. N’hésitez donc pas d’ici la à faire part en commentaires de vos questions, attentes ou témoignages pour rendre l’échange le plus interactif et fructueux !
Wireframes, fidelite et feedback
J’ai assisté la semaine dernière à la présentation faite par Eric di Pol pour Designers Interactifs sur l’utilisation des wireframes. Il a commencé par nous introduire quels utilisations ceux-ci avaient, selon deux axes : le support et le degré de fidélité.
- Premier axe : soit un support print, plutôt pour de la documentation. Soit à l’opposé, une utilisation logicielle pour simuler et valider.
- Second axe : la fidélité, qui va de lofi à hifi, basse et haute fidélité. D’un cote des wireframes haute-fidélité, sensés être très proches du produit final et en donner une bonne idée. Et à l’opposé des wireframes lo-fi, beaucoup moins fidèles au produit final.
Cela étant dit, en fait la question primordiale est : dans quel but utiliser des wireframes. Est-ce que le but est juste de documenter ou est-ce que le but c’est de simuler et valider avec le client ? Seconde question à propos de la validation : est-ce pour une validation a priori ou comme référence a posteriori ?
On a donc une matrice à deux entrées avec 4 perspectives différentes, qui permettent d’essayer de répondre à cette question : des wireframes pour quoi faire ?
La première de ces perspectives c’est l’usage de wireframe haute-fidélité pour le print : on investi beaucoup de temps pour quelque chose de fidèle que l’on va pouvoir montrer mais qui ne permet aucune simulation.
A l’opposé dans la matrice, on va avoir le lofi logiciel qui permet , grace à des bibliothèques de widgets, assez facilement de concevoir mais pas de simuler. Quel investissement en temps cela demande-t-il de faire du lofi logiciel, au regard de l’utilité et des bénéfices ?…
Cette même question se pose pour du hi-fi logiciel, ou l’on pousse le réalisme avec des widgets précis et un comportement réaliste, notamment dans l’enchaînement des pages. Et la, il me semble que l’on atteint un paradoxe en passant du temps avec des outils cela dit très bien fait. Eric nous a d’ailleurs montré les avantages de Visio et la puissance d’Axure pour arriver à pousser très loin le réalisme. Puissance qui va jusqu’à générer une documentation. Ces deux outils sont largement repandus et tres utilises puisque l’on en parle partout, de GUUUI à Quality Street récemment.
On a donc un investissement important lié à l’utilisation d’outils pour la production de ces wireframes et en retour ça nous permet à la fois de simuler et de générer une spécification presque fonctionnelle. “Presque”, c’est la le problème. Reste au produit final à respecter cette spécification très poussée !
Mon avis sur la question, c’est que l’on a un outil qui permet de figer des le départ cette spécification très propre et les moyens d’obtenir une documentation qui permet l’accord contractuel du client. Le problème, c’est que, même s’il est puissant et relativement convivial, cet outil demande une certaine maîtrise, ce qui exclut de travailler avec le client de façon collaborative.
On est loin d’une perspective agile : on se situe bien dans le cadre d’une approche classique à phases distinctes et faibles espaces de feedback entre client/designer d’interaction/chef de projet/développeurs. L’accent est mis sur un document plutôt que sur une interface directement fonctionnelle comme élément de specification.
Reste le dernier point, à mon sens le plus intéressant, et qui s’inscrit parfaitement dans une approche agile basée sur l’interaction avec le client et des itérations courtes : le lofi non logiciel ou prototypage papier, décrit par Carolyn Snyder. Dans l’idée de cette dernière, si l’on construit un prototype, c’est pour le tester avec des clients. Le principe, c’est au contraire d’investir relativement peu dans le support en restant dans la basse fidélité. On dispose ainsi d’outils appropriables par tous : papier, postits, tableaux blancs avec lesquels il est facile de simuler en changeant de post-its et d’annoter pour le client.
Ces propriétés sont très utiles dans une séance de travail conjointe entre maîtrise d’oeuvre et maîtrise d’ouvrage : on peut facilement interagir avec le client sans faire de supposition sur la forme finale. Celle-ci n’est donc pas décidée par un architecte dans sa tour d’ivoire mais dépendra des technologies et compétences utilisées par celui qui implémente : on fait du push).
Il est ainsi plus facile de faire comprendre à l’utilisateur que ce que l’on cherche à valider, c’est le workflow et les fonctionnalités globales et non l’apparence précise. Cela suppose que le développeur soit implique pour “contraindre” en fonction de ce qui est possible ou non, selon les technologies employées. Ca ne pose pas de problème si l’on est en mesure de faire fréquemment des démonstrations au client du produit fonctionnel. L’étape de réalisation est donc “encadrée” par deux occasions de collaboration avec le client : une séance de travail de prototypage papier et une séance de démo. Quand le client ou son proxy n’est pas sur site avec les développeurs ! Voire…
Je n’ai parlé que des aspects fonctionnels et pas des aspects purement graphiques, que l’on perd justement avec le prototypage papier. Il est pour cela intéressant de travailler sur l’identité graphique dans un premier stade avec des planches de tendance et par la suite directement avec une interface fonctionnelle. On différencie ainsi, comme le fait Garrett dans The Elements of User Experience, les aspects lies au périmètre fonctionnel, à la structure et au squelette d’une part et ceux lies à la surface d’autre part. Mais, c’est un sujet à part entière qui nécessitera d’autres articles.
Pour résumer, l’avantage du prototypage papier, c’est d’avoir un outil qui permet de valider facilement avec le client, à moindre coût et rapidement.
Scrum en 69 mots
A partir d’une discussion sur la liste ScrumDev (en) [1] est nee l’idée de décrire Scrum en 100 mots. Claude Aubry en propose d’ailleurs une définition en français sur son blog [2]. Sans assister pour autant à une course à la miniaturisation, en voila un résumé encore un peu plus succinct, mais je l’espère représentatif et suffisamment complet, qui peut servir d’”Elevator Pitch”.
> Scrum est un processus léger permettant de gérer et de contrôler le développement de produits logiciels. Mettant en oeuvre des pratiques incrémentales, Scrum est une méthode efficace, qui met l’accent sur la qualité et les exigences du client en se recentrant sur les personnes et leurs interactions. C’est l’une des méthodes agiles les plus employées, car elle permet d’améliorer notablement la productivité tout en accélérant le retour sur investissement.
Donc, si vous avez à parler de Scrum en coup de vent à quelqu’un qui s’interroge dessus mais qui file en réunion et n’a pas le temps, vous arriverez peut-être à placer 69 mots…
