Prólogo

En lisant Lean UX, vous êtes sur le point de vous embarquer dans un parcours vers une nouvelle façon de
travailler. Pour ceux d'entre nous qui sont immergés dans les techniques de gestion
traditionnels, cela peut sembler un peu déroutant. Parfois, j'aime imaginer comment
ce serait d'avoir une vue panoramique de la typique corporation moderne. D'en haut, dans son
Je pourrais examiner chaque silo d'excellence fonctionnelle un à un : marketing,
opérations, fabrication, TI, ingénierie, conception, et ainsi de suite dans une rangée ordonnée
de silos nets et bien gérés.

Imaginons qu'il se soit penché pour attraper l'un de ces silos et en ait enlevé le sommet pour
ver el interior. ¿Qué verías? Al ser una empresa moderna, vería que cada silo está
conçu pour une efficacité maximale. Pour atteindre cette efficacité, il est probable que
trouvez une approche hautement itérative et centrée sur le client pour la résolution de
problèmes. Dans la fabrication, vous rencontrerez la pensée Lean traditionnelle. Dans
Ingénierie ou TI, peut-être une variation dans le développement agile. En marketing, développement de
clients. En opérations, DevOps. Et, bien sûr, en design, le dernier en pensée
de design, design d'interaction et techniques de recherche utilisateur.

Si nous nous rapprochons de notre point le plus élevé, il est possible qu'on nous pardonne pour
penser : « Cette entreprise utilise une variété de méthodologies rigoureuses, basées sur
hypothèses, centrées sur le client et itératives. Il doit sans aucun doute s'agir d'une entreprise
extrêmement agile, capable de réagir rapidement aux changements des conditions
du marché et innovant continuellement.” Mais ceux d'entre nous qui travaillons dans
les entreprises modernes savent à quel point cela est loin de la vérité.

Comment est-il possible que nos silos départementaux fonctionnent avec agilité mais
que nos entreprises soient désespérément rigides et lentes ? Depuis notre point éloigné
de vista, nous avons perdu quelque chose d'essentiel. Bien que nos départements puissent
valoriser l'agilité, les interconnexions entre eux sont encore embourbées dans un
passé industriel obsolète.

Considérez seulement un exemple, qui j'espère vous sera familier. Une entreprise décide qu'elle doit
innover pour survivre. Chargez une équipe de conception (interne ou externe) pour
étudier l'avenir de votre secteur et recommander de nouveaux produits innovants qui
ils pourraient sécuriser leur avenir. Un période de grande excitation commence. Les clients sont
interviewés, observés, analysés. Les expériences, enquêtes, groupes de discussion,
prototipos y pruebas de humo se suceden uno tras otro. Los conceptos se conciben,
prouvent, rejettent et raffinent rapidement.

Et que se passe-t-il à la fin de ce processus ? Les designers présentent avec fierté, et l'entreprise
célébrez avec enthousiasme, un document de spécifications massif avec vos découvertes et
recomendaciones. Cesa la iteración, la experimentación y el descubrimiento. Ahora se
demande à l'ingénierie d'exécuter ce plan. Et bien que le processus d'ingénierie puisse être agile,
Le document de spécifications est rigidement fixé. Que se passe-t-il si les ingénieurs
découvrent que la spécification était inviable ou même légèrement défectueuse ? Que se passe-t-il ?
si les concepts fonctionnent très bien dans le laboratoire mais n'ont pas d'attrait
commercial ? Que se passe-t-il si les conditions du marché ont changé depuis qu'ils ont eu lieu
l'"apprentissage" original ?
Une fois, j'ai parlé avec une entreprise qui avait commandé, à un coût terrible, une étude de
plusieurs années de son industrie. Le résultat fut un impressionnant écran de "vue du"
futur" personnalisée dans son siège social. À l'intérieur de cette salle, on pouvait voir une
extrapolación de cómo serían los próximos 10 años en su industria, con demostraciones
de travail de concepts de produits futuristes. Pouvez-vous deviner ce qui s'est passé pendant
les dix années suivantes : absolument rien. L'entreprise a fait tourner des centaines ou des milliers de
dirigeants, gestionnaires et travailleurs à travers cette vision de l'avenir. Et en fait, 10 ans
ensuite, la chambre ne semble plus futuriste. Contre toute attente, ses prévisions
se sont avérés en grande partie précis. Et pourtant, l'entreprise n'avait pas réussi
commercialiser même une des recommandations du document de spécifications
correspondant. Alors je demandai à l'entreprise ce qu'elle prévoyait de faire à
suite. On m'a dit qu'ils allaient revenir avec les designers originaux et qu'ils leur demandaient
que pronostiqueront les 10 prochaines années ! L'entreprise a blâmé ses ingénieurs et ses responsables,
non aux designers, pour leur échec dans la commercialisation.

Lorsque je raconte cette histoire aux non-designers, ils sont horrifiés et veulent me convaincre
que la faute revient à l'entreprise de design élégant. Quand je le dis aux hauts
des cadres, tant dans les grandes entreprises que dans les start-ups, se
les secouer. Ils sont constamment inundés de plaintes de chacune des
des fonctions qui sont rapides et à la pointe, mais ce sont les autres départements qui
ralentissent l'entreprise. Lorsque toute l'entreprise ne parvient pas à trouver de nouvelles sources de
crecimiento, hay mucha culpa.

Mais la faute n'incombe pas aux designers, aux ingénieurs ou même aux dirigeants. Le problème
ce sont les systèmes que nous utilisons pour construire des entreprises. Nous continuons à construire
organisations linéaires dans un monde qui exige des changements constants. Nous sommes encore
construisant des silos dans un monde qui exige une collaboration approfondie. Et pourtant
nous investissons dans l'analyse, discutons des spécifications et produisons
livrables de manière efficace dans un monde qui exige une expérimentation continue pour
réaliser une innovation continue.

Lorsque ce livre a été publié pour la première fois en 2012, il était encore trop tôt pour Lean
Startup. Il a passé quinze ans depuis que j'ai commencé à écrire et à parler de ce que
c'était donc un concept très nouveau, et 2021 est également le dixième anniversaire de la
publication de The Lean Startup : comment les entrepreneurs d'aujourd'hui utilisent la méthode continue
Innovation pour atteindre des entreprises radicalement réussies (Crown Business, 2011).
, j'ai vu les idées croître et se diffuser, d'industrie à industrie, de secteur à secteur et
de fonction en fonction. Chaque fois que nous rencontrons un nouveau terrain, nous avons
confié dans des dirigeants visionnaires pour aider à traduire les principes fondamentaux et
développer de nouveaux processus pour les mettre en œuvre. Nous avons beaucoup appris sur la façon de
il peut être utilisé et des professionnels du monde entier ont apporté de nouveaux outils
et méthodes.

Lean UX est un pas important dans cette évolution. Et grâce à l'engagement de Jeff Gothelf
y Josh Seiden de continuer à progresser dans la discipline, cette nouvelle édition est basée sur le
que déjà était un regard complet sur la manière dont les principes du Lean Startup s'appliquent dans un
contexte de conception. Les outils et techniques fondamentaux qu'il présente pour parvenir à
une collaboration supérieure, une livraison plus rapide et, ce qui est le plus important, des produits
dramatiquement meilleures ont été augmentées pour inclure des entrées plus récentes comme Lean
UX Canvas et Hypothesis Prioritization Canvas. Il y a aussi plus sur la relation entre
Lean UX et le mapping des histoires, ainsi que sur les sprints de design.

Lean Startup est une grande tente. Il repose sur des idées établies de nombreuses disciplines,
de la fabrication ajustée à la pensée design. Cela nous fournit un vocabulaire
commun et un ensemble de concepts qui peuvent être utilisés pour accélérer les résultats dans
toute l'entreprise. Nous pouvons arrêter de perdre du temps à discuter de qui est responsable
et quel département devrait gouverner le jour.

J'espère que nous nous souviendrons tous de répondre à l'appel de Jeff de "sortir du métier de"
les livrables" et ramener notre approche à l'endroit qui lui appartient, en préparant tout le
corporation dans sa tâche la plus urgente : ravir les clients.

Il est temps de démolir les silos, d'unir les clans et de se mettre au travail.

Eric Ries

28 juillet 2021

San Francisco, CA

Cette édition de Lean UX est une contribution opportune au monde en évolution du design.
l'entrepreneuriat et l'innovation. Il y a dix ans, une partie de notre travail avec
les entreprises impliquaient de devoir convaincre les dirigeants de la valeur de l'innovation au-delà
de son activité principale. Ce débat a presque disparu. Les leaders
les entreprises sont maintenant convaincues que l'innovation est le meilleur moyen de
impulser la croissance à long terme au sein de vos entreprises.

Bien que les dirigeants voient désormais la valeur de l'innovation, un défi demeure.
différent. Très peu de leaders sont satisfaits des performances d'innovation de leur
entreprise. Il semble qu'une grande partie du travail effectué par les équipes d'innovation ne
suivez un processus répétable. C'est la question que les leaders nous posent maintenant
constamment : Quelles sont les structures et les processus qu'ils doivent mettre en œuvre pour
tener una innovación repetible?

C'est ce qui rend cette édition de Lean UX si opportune. Nous croyons que la
l'innovation est une profession, pas simplement un appel pour quelques élus. Pour
professionaliser l'innovation, nous devons développer les outils et les processus
adéquats pour que les innovateurs les utilisent dans leur travail quotidien. À mesure que les
les personnes apprennent à utiliser ces outils, elles pourront produire une valeur répétable pour
ses organisations. C'est la contribution continue que fait Lean UX.

Même après la publication de la première édition de Lean UX, le plus grand mensonge dans
le développement de logiciels et de produits reste la phase deux. L'idée est que les équipes
ils devraient être autorisés à exécuter tout ce qu'ils ont sur leur feuille de route et ensuite gérer
les problèmes des clients après le lancement (c'est-à-dire dans la deuxième version de
produit). Le problème est que nous n'atteignons jamais la phase deux et les produits défectueux
restent sur le marché. C'est probablement la raison pour laquelle 7 sur 10
les lancements de nouveaux produits échouent.
Alors, comment résolvons-nous ce défi ? D'abord, nous devons développer des outils
qui s'ajustent à la nature de l'innovation. Lean UX repose sur une compréhension claire
que l'innovation n'est pas un défi technologique ou d'exécution. En revanche, le défi
pour les équipes, il s'agit de chercher des propositions de valeur qui résonnent avec les clients et les modèles
d'affaires qui soient rentables.

Cette recherche exige que les équipes naviguent à travers la complexité et la

incertitude. Ce n'est pas un processus linéaire basé sur une simple cause et effet. C'est un
processus non linéaire. Lean UX fournit des moyens pour que les équipes naviguent à travers cela
complexité se déplaçant de manière itérative et créative à travers les eaux troubles de la
innovation jusqu'à ce qu'ils trouvent quelque chose qui fonctionne.

Une fois, nous avons travaillé avec un leader qui demandait à ses équipes de lui apporter dix
fois plus d'idées. Nous essayons de rappeler gentiment au leader qu'il serait impossible pour lui
et son équipe identifier une idée 10x le premier jour. Les leaders ne peuvent pas choisir des idées
gagnantes ; ils ne peuvent que créer le contexte dans lequel les meilleures idées émergent. En suivant le
processus établi dans Lean UX, les équipes peuvent travailler ensemble pour esquisser et tester
rapidement ses idées commerciales. Les idées gagnantes émergeront à travers ces tests
é itérations.

La complexité de l'innovation signifie également que les équipes ne peuvent pas naviguer.
vers le succès sans collaborer avec des collègues de diverses fonctions clés. Il y a un grand
distance à parcourir entre avoir une idée et ensuite concevoir, tester et lancer cette idée
marché. Ce travail nécessite une collaboration multifonctionnelle. Le défi est que
beaucoup d'organisations maintiennent encore des silos et des transferts qui tuent la
capacité des équipes à collaborer.

Nous avons travaillé avec plusieurs organisations où les équipes d'innovation ont besoin
obtener la aprobación legal y de cumplimiento para ejecutar experimentos. En una de esas
organisations, il a fallu plus de deux mois pour qu'un simple soit approuvé
expérience du Magicien d'Oz. Lean UX décrit des moyens pratiques qui peuvent être utilisés
pour surmonter ces barrières à l'innovation.

Même après le lancement du produit, l'état d'esprit articulé dans Lean UX aide
aux équipes de continuer à esquisser et à tester. Il est essentiel que les équipes ne
consideren el lanzamiento de un producto como el final del proceso. Es fundamental que
continuez à améliorer votre offre en utilisant des méthodes Lean UX. Il est important de se rappeler
tant que les entreprises ne sont pas dans le métier des livrables ; elles sont dans le métier
de ravir les clients!

Nous espérons que vous n'allez pas seulement apprécier la lecture de ce merveilleux livre, mais que vous allez aussi
Prenez les leçons et appliquez-les à votre travail quotidien.

Alex Osterwalder

30 mai 2021

Lausanne, Suisse

Tendayi Viki
30 mai 2021

Harare, Zimbabwe
Note de l'auteur
Lorsque nous avons décidé d'écrire la troisième édition de ce livre, nous avons réalisé que
que l'influence d'un groupe toujours diversifié de professionnels, écrivains, entraîneurs
et les consultants ont aidé Lean UX à croître et à évoluer pour répondre aux besoins
changements dans la conception et le développement de logiciels. Nous voulions prendre un moment pour
les remercier.

Nous continuons à apprendre du groupe central de collègues et de camarades guerriers de la

route qui partagent leur sagesse et leurs commentaires avec nous, y compris Tendayi Viki,
Teresa Torres, Melissa Perri, Hope Gurion, Barry O'Reilly, Sam McAfee, Andy Polaine
David Bland, Andi Plantenberg, Jonathan Bertfield, Kate Leto, Daniel Stillman, Beth
Temple, Jocelyn Miller, Bob Gower, David Bland, Douglas Ferguson, Martina Hodges-
Schell, Erin Stadler, Jeff Patton, Petra Wille, Janet Bumpas, Jonathan Berger et Adrian
Howard. Nous construisons nos idées sur les leurs et celles de nos clients.

Comme toujours, nous aimerions remercier les nombreuses personnes qui ont contribué avec
matériel, histoires, pistes d'enquête, aide de Twitter, sagesse technique et soutien
émotionnel au livre. En particulier, nous aimerions remercier Andrew Bourne, Ike Breed,
Steven Cohn, Regine Gilbert, Victor M. Gonzalez, Zach Gottlieb, Jamila Isoke, Liz Laub
Jon Loyens, Dan Maccarone, Jono Mallanyk, Lin Nie, Greg Petroff, Steve Portigal, Leisa
Reichelt, Delphine Sassi, Alexander Schardt, Kristin Skinner, Erik Skogsberg, Jessica
Tiao, Kate Towsey, Ben Walker, Rosie Webster et Lee Weiss.

Nous sommes reconnaissants envers l'équipe [Link], y compris Dave West, Steve Porter,
Erik Weber et Gary Pedretti, ainsi que tous les entraîneurs professionnels de Scrum qui
nous avons rencontré là-bas ceux qui ont aidé à apporter notre travail à la communauté Scrum et qui nous
ils ont aidé à améliorer notre compréhension des besoins de cette communauté.

Merci à Eric Ries de continuer à soutenir le travail de Lean UX et des autres auteurs.
títulos de la Serie Lean, y a Melissa Duffield, Angela Rufino, Mary Treseler y Jennifer
Pollock et O'Reilly, qui continuent de le rendre possible pour que ce livre réussisse.

Enfin, nous serions négligents si nous ne remerciions pas les membres du groupe de travail.
Équipe Équilibrée, où nous avons commencé à travailler avec ces idées il y a tant d'années. Nous sommes
remerciants envers Lane Goldstone d'être le catalyseur et la force motrice pour unir à
ce groupe et unir tant de personnes merveilleuses. En particulier, nous avons une dette de
gratitude à Janice Fraser, qui nous a présenté pour la première fois les idées de Lean Startup
y quien acuñó la frase "Lean UX".

Nota : de Jeff
À mesure que notre association entre dans sa deuxième décennie, je continue de voir Josh comme
un ami, collaborateur et caisse de résonance logique. La façon dont nous pratiquons ces
les idées sont différentes des jours où nous avons commencé à le faire, mais au fur et à mesure que cela change
les besoins du marché et les réalités du monde, nous continuons à travailler ensemble
pour trouver de nouvelles façons d'offrir de meilleures méthodes de travail à l'entreprise.
monde. Je suis reconnaissant pour cela et pour sa recherche incessante du pain au levain parfait
caséres et viande en conserve.

Comme toujours, rien de tout cela n'arriverait sans le soutien et l'amour de la famille. Carrie, Grace et
Sophie continue à plaire à mon travail, à mon écriture et à mes blagues de papa. Je ne pourrais pas
demander plus. Je t'aime tout. Merci.

Nota : de Josh
Dans ce livre, Jeff et moi décrivons un style de travail qui est profondément
collaboratif. C'est mon style de travail préféré : je sens toujours que j'apprends plus et je suis
plus efficace lorsque je collabore. Tout ce que j'ai pu apporter à ce livre est le
résultat des incroyables collaborations que j'ai eu la chance de vivre dans ma
carrera. Vous savez qui ils sont. Je vous suis très reconnaissant à tous.

Cependant, il y a une collaboration de travail que je dois mentionner : cela a été un véritable
placer de continuer à collaborer avec Jeff. Jeff apporte beaucoup de choses à cette association
que je ne peux pas, y compris l'optimisme sur les délais, l'audace à fixer des objectifs et
la inlassable évangélisation. C'est un partenaire intelligent, travailleur et sans ego. Pourtant,
Ce n'est pas drôle. Si nécessaire, je dois normalement le fournir.

Merci, enfin, à Vicky, Naomi et Amanda. Je t'aime.

De Jeff et Josh
Cela fait cinq autres années depuis la dernière fois que nous avons mis à jour ce livre. Nous continuons
étonnés par la communauté et le travail qu'ont généré les idées de ce livre. Beaucoup
a changé et, cependant, de nombreux problèmes auxquels sont confrontées les équipes de
La conception et le développement de logiciels restent les mêmes. Le défi a toujours été
construire non seulement une collaboration interfonctionnelle plus large, mais aussi une conversation
continue avec le client qui influence le travail que nous choisissons de faire. La bonne nouvelle est
que, avec l'assimilation la plus profonde d'Agile et de Scrum, ainsi que le cadre de
établissement d'objectifs et de résultats clés (OKR), les organisations sont
analysant de plus près comment devenir plus agiles et plus centrés sur le
client. Nous avons également appris comment les techniques en Lean UX peuvent être appliquées
encore plus efficacement. Nous sommes ravis de partager cela avec vous.

Chaque fois que nous enseignons Lean UX ou que nous l'utilisons dans notre travail quotidien, nous apprenons une
meilleure façon de l'appliquer. Nous essayons quelque chose de nouveau, nous l'inspectons, nous nous adaptons de
apprentissage et nous mettons à jour notre pensée. Nous soupçonnons qu'il fait cela
même et nous serions ravis de le savoir.

Veuillez rester en contact avec nous et partager vos réflexions. Vous pouvez
communiquer avec nous àjeff@[Link] yjosh@[Link] Toujours
nous espérons avoir de vos nouvelles.

Préface
Le plus grand mensonge dans le logiciel reste la phase deux.

Si vous avez consacré du temps à la création de produits numériques au cours des 30 dernières années,
indépendamment de sa fonction, il a ressenti le poison de ce mensonge. Et si son équipe
dire être agile, la phase deux reste-t-elle un concept valable ? Les équipes priorisent
fonctions et idées pour chaque sprint, avançant vers une date de lancement tout en
Ils portent des idées non prioritaires à la phase de travail suivante. Sauf que cette phase n'arrive jamais.
et ces caractéristiques ont disparu, on n'en a plus jamais eu de nouvelles. En tant que designers, managers
de produit, formateurs et consultants, nous avons eu des centaines, voire des milliers, de wireframes,
éléments du portefeuille de produits et des flux de travail qui se terminent ici même
groupe.

Mais ces idées ont-elles été abandonnées parce qu'elles étaient défectueuses ? Parce que quelque chose a changé dans le
marché ? Les fonctions qui ont été envoyées ont-elles vraiment atteint les objectifs
commerciaux et des clients ? Ou l'équipe a-t-elle simplement oublié ? Ils ne sont jamais arrivés à la
phase deux.

Dans The Lean Startup, Eric Ries expose sa vision sur la façon de garantir que les idées qui
ils ont la plus grande valeur obtiennent la plus grande quantité de ressources. La méthode que Ries
promote se base sur l'expérimentation, les itérations rapides d'idées et de processus
évolutifs. Dans un environnement véritablement agile, les équipes lancent des fonctionnalités
en continu, ce qui fait que l'implémentation réelle du code n'est pas un événement. Tout
le concept de la phase deux est devenu discutable.

L'union de Lean Startup et la conception de l'expérience utilisateur (UX), et leur coexistence

simbioiquement bénéfique, c'est Lean UX.

Qu'est-ce que Lean UX ?

Les principes Lean qui sous-tendent Lean Startup s'appliquent à Lean UX de trois
formes. Tout d'abord, ils nous aident à éliminer les déchets de notre processus de conception de
UX. Nous faisons le travail nécessaire, que ce soit le design, la recherche, la rédaction, peu importe.
pour faire avancer la conversation entre le design, le développement et le produit. Celles-ci
des conversations minimalement viables nous éloignent des longues négociations
désenchaînées par des transferts très documentés. En revanche, un processus Lean UX crée
seuls les artefacts de conception dont nous avons besoin pour faire avancer l'apprentissage
équipe. En second lieu, les principes Lean nous poussent à harmoniser notre
"système" de designers, développeurs, chefs de produits, ingénieurs de
assurance qualité, commerçants et autres dans une collaboration transparente
et multifonctionnel qui attire les non-designers dans notre processus de conception. Lean UX est
un processus transparent qui non seulement révèle ce que font les designers, mais qui favorise
la participation de tous les membres de l'équipe.

Enfin, et peut-être le plus important, c'est le changement de mentalité que nous obtenons en
adopter un modèle basé sur l'expérimentation et l'apprentissage validé. Au lieu de
dépendre d'une seule personne (un designer héros, l'ingénieur principal, une partie
intéressée par l'entreprise) pour deviner la meilleure solution depuis un seul point de vue,
nous utilisons l'expérimentation et la mesure rapides pour avoir une vision de l'extérieur vers
adentro de la experiencia que vivimos. volver a crear. Nos esforzamos por aprender
rapidement, pour découvrir, à quel point (ou mal) nos idées répondent aux besoins
de nos clients. Dans tout cela, le rôle du designer commence à évoluer au-delà
de la mera creación de artefactos hacia la facilitación del diseño, y con eso, asumimos un
nouveau jeu de responsabilités.

En plus de Lean Startup, Lean UX a deux autres bases : la pensée de

design et philosophies de développement agile. La pensée de design nous aide à
élargir la portée de notre travail au-delà des interfaces et des artefacts. Le
La pensée design analyse les systèmes et nous aide à appliquer les outils.
de la conception à des problèmes plus larges. Cela repose sur la collaboration, l'itération,
création et empathie comme éléments fondamentaux pour la résolution de
problèmes. Peut-être que le plus important de la pensée design est son approche sur
generar empatía, en todo el equipo, para el usuario final. Practicar Lean UX
cela signifie que toute l'équipe développe cette empathie. Agile recentre le développement
de logiciels en cycles plus courts, livraison régulière de valeur et apprentissage
continuo. Cherche à faire parvenir des idées (souvent sous forme de logiciel fonctionnel) aux
clients rapidement, sentir comment ces idées sont reçues et répondre avec
fréquence à de nouveaux apprentissages tout au long du chemin. Comme le dit le guide de
Scrum : inspectez et adaptez.

Lean UX utilise ces fondamentaux pour unir la rapidité d'Agile et le besoin de

design dans le cycle de vie du développement de produits. Si vous avez rencontré des problèmes pour
découvrir comment le design UX peut fonctionner dans des environnements agiles, Lean UX est la
réponse.

Lean UX brise les barrières qui ont maintenu les concepteurs de logiciels isolés de
les besoins commerciaux réels, d'une part, et de la mise en œuvre réelle, de l'autre
Un autre. Lean UX n'apporte pas seulement des designers à la table, mais apporte également nos partenaires.
en administration des produits, des affaires et de la technologie au tableau pour travailler avec
nous dans les meilleures solutions de manière continue.

Au début de sa carrière, Jeff a travaillé avec un grand client pharmaceutique qui avait
embauché par l'agence pour laquelle je travaillais pour redesign sa plateforme de commerce
électronique. L'objectif était d'augmenter les revenues de 15%. Jeff était le designer de
interaction principale de l'équipe. Dans le vide de son bureau, Jeff et son équipe ont passé des mois
enquête sur le système actuel, la chaîne d'approvisionnement, les concurrents, le public
objectif et les scénarios d'utilisation contextuels. Ils ont recherché des personnes et assemblé
modèles stratégiques. Jeff a conçu une nouvelle architecture de l'information pour le catalogue
de produits et a créé une nouvelle expérience d'achat et de paiement.

Le projet a pris des mois. Et quand le travail a été terminé, l'équipe l'a empaqueté.
tout dans une plateforme de diapositives PowerPoint. C'était un formidable paquet, et
cela devait être le cas, compte tenu du prix de 600 000 $ ! L'équipe est allée au bureau du client
et il a passé une journée entière de huit heures à passer en revue chacun des pixels et des mots
de cette plateforme. Lorsque cela a terminé, le client a applaudi. (Ils l'ont vraiment fait). Jeff et le
l'équipe s'est sentie soulagée. Le client a adoré le travail. Et l'équipe de Jeff n'a jamais
elle regarda à nouveau ce jeu de cartes.
Six mois après cette réunion, rien n'avait changé sur le site du client. Le client
il ne regarda plus cette barre.

La morale de cette histoire : la construction d'une spécification parfaite en pixels

cela peut être un moyen d'obtenir des tarifs de consultant à six chiffres, mais ce n'est pas une façon
de marquer une différence significative dans un produit réel qui est crucial pour les utilisateurs
réelles. Ce n'est pas non plus la raison pour laquelle un designer est entré dans le secteur du design de
produits. Nous nous sommes mis au travail pour créer des produits et des services précieux, pas
pour rédiger des spécifications.

Lorsque nous pratiquons le Lean UX, nous nous assurons que nous résolvons un problème.
réel pour les clients réels de manière significative. Certains groupes avec lesquels
Nous travaillons aujourd'hui à créer des produits ou des services complètement nouveaux. Ils ne fonctionnent pas à l'intérieur.
de un cadre ou une structure de produit existante. Dans des projets « greenfield » comme ceux-ci,
simultanément, nous essayons de découvrir comment ce nouveau produit sera utilisé ou
service, comment il se comportera et comment nous allons le construire. L'essentiel est que
Nous voulons valider que vous résolvez un problème significatif pour votre public.
objectif. C'est un environnement de changement continu et il n'y a pas beaucoup de temps ni de patience pour
planifier ou concevoir à l'avance.

D'autres équipes travaillent avec des produits établis qui ont été créés avec des méthodes
traditionnels de conception et de développement. Leur défi est différent. Les systèmes dans lesquels
ils ont été développés pour satisfaire les besoins d'une période de temps
spécifique. Le rythme rapide du changement sur le marché signifie que ces besoins
ils ont probablement évolué. Ces équipes doivent optimiser ces plateformes.
existants pour faire face à de nouvelles réalités tout en augmentant les revenus et le
valeur de la marque. En général, ils ont plus de ressources à leur disposition qu'une startup de
planteau, mais ils doivent encore utiliser leurs ressources de manière efficace, découvrant la
meilleure façon de dépenser ces ressources pour créer des produits et des services que vos clients
réellement désirent.

Peut-être que l'un des changements les plus difficiles que Lean UX nous demande de faire est de surmonter
la sensation que nous montrons un travail dans un état "inachevé" ou
"feo". Même aujourd'hui, après presque 15 ans de travail de cette façon, nous luttons encore.
con este. Hemos aprendido a lo largo de los años que nuestro primer intento
inevitablement nécessitera une révision. Donc, plus vite nous sortirons nos idées,
avant que nous puissions découvrir quelles devraient être ces révisions. Attendre trop pour
obtenir ce retour est un gaspillage. Nous investissons trop dans la conception
initial et nous sommes moins flexibles aux changements en raison de l'effort que nous avons déjà fourni.
Plus tôt nous saurons quels changements doivent être apportés, moins nous investirons dans l'idée.
actuel. Cela fera moins mal de changer de cap. Accepter la nature itérative du design et, dans
termes plus généraux, le logiciel nécessite le soutien d'une équipe collaborative,
humble et de haute performance. L'équipe doit savoir que cela va faire les
bien les choses la première fois et que tout le monde travaille ensemble pour répéter le chemin vers
continuer. La mise en œuvre du code n'est pas la mesure du succès d'une équipe Lean
UX. C'est l'impact positif qu'il a sur ses clients.

Il y a de nombreux éléments qui affectent le succès des systèmes numériques. Le design est sans
doute un composant important, mais la gestion des produits, l'ingénierie, le marketing,
les aspects légaux, la conformité et la rédaction publicitaire (pour en nommer quelques-uns)
ont un impact sur le système. Aucune discipline n'a toutes les réponses. Avec cela
fin, aucun point de vue n'a toutes les réponses non plus. Plus le
diversité de son équipe (diversité de genre, diversité raciale, etc.), plus innovantes
y de mayor alcance serán las soluciones que generará el equipo. La inclusión es clave
para una colaboración exitosa. Esta es la naturaleza de nuestro medio digital. La
une large collaboration crée un meilleur travail. La révision et l'itération rendent que les
les produits soient meilleurs. Dans les pages de ce livre, nous avons résumé les connaissances
et les tactiques qui nous ont permis d'adopter ce point de vue et de créer un véritable succès pour
les équipes de produits et d'affaires, et une satisfaction réelle pour les clients.

Pour qui est Lean UX ?

Ce livre est, avant tout, destiné aux designers de produits qui savent qu'ils peuvent
contribuer davantage et être plus efficaces avec leurs équipes. Cela dit, nous croyons que
L'« expérience utilisateur » est la somme totale de toutes les interactions qu'un utilisateur a.
avec votre produit et service. Il se crée à partir de toutes les décisions que vous et votre équipe
tiennent sur ce produit ou service. Ce n'est pas seulement l'interface utilisateur ou la
fonctionnalité. Il s'agit également des prix, de l'expérience d'achat, de l'incorporation,
soutien, etc. En d'autres termes, l'expérience utilisateur est créée par toute l'équipe. Pour cette raison
raison, ce livre est également destiné aux chefs de produit qui ont besoin de meilleures façons de
définir vos produits avec vos équipes et les valider auprès de vos clients. C'est aussi pour les
développeurs et maîtres de Scrum qui comprennent qu'un environnement d'équipe agile et
collaboratif conduit à un meilleur code et un travail plus significatif. Et, finalement, c'est
pour les gestionnaires : gestionnaires d'équipes UX, équipes de projets, lignes de métiers,
départements

Que tires de cela ?

Le livre est divisé en quatre sections.

La Partie I, Introduction et principes , fournit un aperçu et un

introduction à Lean UX et ses principes fondamentaux. Nous exposons les raisons pour lesquelles
que l'évolution du processus de conception de l'UX est si critique et nous décrivons Lean
UX. Nous avons également discuté des principes sous-jacents que vous devrez comprendre afin que
Lean UX a du succès dans ses environnements de travail agiles.

La Partie II, Processus, présente le canevas Lean UX et passe en revue chacun de ses huit
étapes. Nous partageons également des exemples de la façon dont nous et d'autres avons fait ces choses
dans le passé.

La Partie III,Collaborationanalyse en profondeur la collaboration entre designers et

d'autres disciplines, et introduit des outils et des études de cas pour rassembler plusieurs formes
populaires au travail, comme les sprints de conception, les systèmes de conception et la recherche
collaborative avec Lean UX. Enfin, nous partageons quelques considérations pour
intégrer mieux Lean UX dans les rythmes d'un processus agile.

La Partie IV,Lean UX dans votre organisation, aborde l'intégration des pratiques Lean
UX dans votre organisation. Nous avons discuté des changements organisationnels qui doivent avoir lieu.
au niveau de l'entreprise, au niveau de l'équipe et au niveau du contributeur individuel pour que cela
les idées se concrétisent vraiment.

Notre espoir est que ce livre continue de servir de voie à suivre pour les
designers UX, leurs collègues et équipes de produits dans toutes les organisations qui
ils attendent encore la "phase deux". Bien que le livre soit plein de tactiques et de techniques pour vous aider
à développer ses processus, nous aimerions que vous vous souveniez que Lean UX est, en essence, une
mentalité.

—Jeff et Josh
Parte I. Introducción y principios
À propos de la partie I
Dans cette première partie, nous fournissons une introduction à Lean UX et à ses principes
fondamentales. Nous discutons pourquoi l'évolution du processus de conception et de développement de
les produits est si critique et nous décrivons ce qu'est Lean UX. Nous discutons également des principes
sous-jacents que vous devrez comprendre pour que Lean UX fonctionne dans votre organisation.

Le Chapitre 1,Plus important que jamaisfournit une brève histoire du

conception et développement de produits et pourquoi il est temps que ce processus évolue.

En leChapitre 2,Principes, nous présentons une analyse détaillée des principes clés
qui stimulent le processus Lean UX. Ces principes offrent un cadre pour un processus de
découverte et conception de produits plus agiles, et fournissent également des directives de gestion
de base pour ces équipes. Ils sont fondamentaux pour le succès de Lean UX et, si on les
incorporant à leur organisation, ils auront un impact profond sur leur culture et sur la
productivité et le succès de ses équipes.

Le Chapitre 3,Résultats, se concentre sur l'idée de résultats, qui ont toujours été un
concept important en Lean UX, mais au fil des ans, nous avons développé de nouvelles
façons de penser et de travailler avec eux. Étant donné que les résultats sont si critiques pour
Lean UX, nous avons élargi notre discussion sur ce concept. Ce chapitre partage
avec vous notre compréhension actuelle de l'idée.
Capítulo 1. Más importante ahora que
jamais
Ce n'est pas une itération si vous le faites juste une fois.

Jeff Patton

Le design est toujours en évolution

Lorsque les designers ont pour la première fois amené leur métier dans le logiciel dans les années 80 et
90, abordèrent le travail de la même manière qu'ils avaient abordé les matériaux précédents avec
ceux qui ont travaillé. En design industriel, design d'impression, design de mode ou tout autre
Dans un domaine impliquant des produits physiques, l'étape de fabrication est une contrainte critique. À
concevoir pour des matériaux physiques, les designers doivent découvrir ce qu'ils font avant
démarrer la production, car la production est coûteuse. Il est cher de monter une usine
pour produire des articles ou des vêtements. Il est coûteux de configurer une imprimerie pour un
tirage d'impression.

En travaillant sur des logiciels, les concepteurs ont été confrontés à de nouveaux défis. Ils ont dû
décoder la grammaire de ce nouveau medium et, en le faisant, ils ont vu émerger de nouveaux
des spécialités telles que le design d'interaction et l'architecture de l'information. Mais
le processus pour lequel les designers ont pratiqué est resté en grande partie
incuestionnable. Les concepteurs continuaient à concevoir des produits avec grand détail par
avancé, car ils devaient encore faire face à un processus de "fabrication": le travail
il devait être dupliqué sur des disquettes et des CD, qui étaient ensuite distribués sur le marché
exactement de la même manière que les produits physiques. réparti. Le coût de le faire
mal continue à être élevé. Cependant, paradoxalement, cette façon de travailler n'a pas empêché que
personne ne se trompera. Trop souvent, les designers ont travaillé de manière
isolée, dans des silos, avant de passer son travail aux développeurs, qui à leur tour
Ils ont travaillé dans un silo avant de transférer le travail au contrôle de qualité, et ainsi de suite. Et
tout le monde travaillait avec des commentaires limités du marché.

Aujourd'hui, nous faisons face à une nouvelle réalité. La production de logiciels est devenue
continue. Internet a changé la façon dont nous distribuons des logiciels. La prolifération
des appareils mobiles, des dispositifs portables et de l'Internet des objets a changé la façon dont cela
nous consommons. Nous ne sommes plus limités par un processus de fabrication physique, et nous pouvons
mettre nos produits et services numériques entre les mains des clients à un rythme sans
précédentes il y a quelques années.

Cela change tout.

Les équipes sont maintenant confrontées à une intense pression des concurrents qui utilisent
techniques telles que le développement de logiciels agiles, l'intégration continue et la mise en œuvre
continue à réduire radicalement les temps de cycle. Prenons Amazon comme
exemple. Le géant du commerce électronique envoie un nouveau code en direct à ses
clients chaque seconde de chaque minute.1Et ils utilisent ces cycles courts comme
un avantage concurrentiel : ils lancent rapidement et fréquemment, obtiennent des retours du
le marché et itèrent en fonction de ce qu'ils apprennent à créer une conversation continue avec les
clients. En essence, ils découvrent leur produit en même temps qu'il
ils remettent. Cela a beaucoup de résultats, mais ceux-ci sont peut-être les deux plus
importantes

• La capacité d'apprendre, de manière continue et rapide, à quel point vos produits

satisfont les besoins du client.
• Augmenter les attentes des clients en termes de qualité du produit et
temps de réponse de l'entreprise à vos préoccupations et commentaires.

De plus, cette nouvelle façon de travailler ne repose pas sur des technologies coûteuses. Les plateformes
et les services qui rendent cela possible sont disponibles gratuitement ou presque gratuitement pour
presque tous les équipements de démarrage. Cela expose les entreprises établies à une menace
qu'ils ne connaissaient pas auparavant. Spécifiquement, les barrières à l'entrée, dans presque tous les
les domaines n'ont jamais été aussi bas. Sans avoir besoin de "fabriquer" un produit physique,
Toute personne ayant accès à Internet peut concevoir, coder et mettre en œuvre des services.
pour toute autre personne. Face à ces nouvelles menaces, les approches traditionnelles
de "tout résoudre d'abord" ne sont tout simplement pas viables. Alors, que devraient-ils faire ?
les équipes produit?

Il est temps d'un changement.

Lean UX est l'évolution du design de produits et de la collaboration en équipe. Prenez les

meilleures parties de l'ensemble d'outils du designer, les combine avec le développement
de logiciel agile et la pensée Lean Startup, et met tout ceci à la disposition de tout le
équipe produit. Permet aux équipes d'exploiter cette nouvelle réalité pour maximiser le
apprentissage, découvrir continuellement le meilleur chemin à suivre et amplifier la voix du
client

Lean UX est profondément collaboratif et multifonctionnel parce que les designers,

les chefs de produit et les ingénieurs logiciels ne peuvent plus se permettre de travailler
isolés les uns des autres. Les jours du processus en cascade sont terminés. Le travail est
continuo. Nous ne pouvons pas nous permettre d'attendre le travail des autres, ni nous pouvons faire en sorte que d'autres
attendez notre travail. En revanche, nous avons besoin d'un engagement quotidien et continu avec
nos collègues si nous voulons réussir. Cet engagement continu nous permet d'éliminer
les livrables lourds (et le temps nécessaire pour les créer) en faveur de techniques qui
Ils construisent une compréhension partagée avec nos coéquipiers.
la compréhension partagée permet à nos équipes de prendre des décisions plus rapidement et nous
permet de participer à des conversations plus stratégiques. Oui, nous avons encore la
responsabilité d'obtenir les bons détails : créer de beaux éléments d'interface et
elegantes flujos de trabajo, y pensar en todas las pequeñas cosas que hacen que el diseño
d'un produit fonctionne, de l'accessibilité aux temps de chargement de la page,
et depuis les étiquettes des boutons jusqu'aux messages d'erreur. Mais en supprimant les dépenses
générales de communication, nous avons plus de temps pour nous concentrer sur des activités plus
fondamentales, comme recueillir des informations qui peuvent affecter les choix stratégiques
de notre produit.

Lean UX nous permet également de changer la façon dont nous parlons de design. Au lieu de
parler des caractéristiques et des documents, nous pouvons parler de ce qui fonctionne
les résultats que nous essayons de créer. Dans cette nouvelle réalité, nous avons plus d'accès
aux commentaires du marché qui ne viennent jamais. Cela nous permet de reconsidérer les conversations
de conception en termes d'objectifs commerciaux, de clients et d'utilisateurs. Nous pouvons mesurer
ce qui fonctionne, apprendre et ajuster.

Lean UX est trois choses. Cela commence comme un changement de processus pour les designers et les équipes.
de produits. Mais c'est bien plus que cela. C'est un changement de culture qui nous permet
aborder notre travail avec humilité ; nous reconnaissons que nos solutions initiales
probablement seront incorrectes et nous utilisons de nombreuses sources de connaissance pour nous améliorer
continuement notre pensée. Enfin, cela implique un ensemble de changements
organisationnels dans la façon dont nous organisons et gérons les équipes de design et
développement de logiciels pour qu'ils soient plus inclusifs, collaboratifs et
transparents. Nous approfondirons chacun de ces aspects de Lean UX dans le reste du
livre.

Cependant, peut-être que la meilleure façon de résumer cette introduction est la suivante : Lean UX est la
forme dans laquelle nous devons travailler maintenant.

1JonJenkins, «Vélocité 2011 : Jon Jenkins, 'Culture de Vélocité'», O'Reilly, 20 juin

2011, vidéo de YouTube, 15:13,[Link] ;Joe McKendrick, “Comment
Amazon gère un nouveau déploiement de logiciel chaque seconde
2105,[Link] ; Werner Vogels, "L'histoire d'Apollo - Amazon's
Moteur de déploiement", Toutes choses distribuées, 12 novembre
2014[Link] .
Chapitre 2. Principes
Va par ce chemin. Vraiment vite. Si quelque chose se met en travers de ton chemin, tourne !

Meilleur mort (1985)

Au cœur de Lean UX, vous trouverez un ensemble de principes fondamentaux qui régissent
le processus de design, la culture de l'équipe et l'organisation de l'équipe. Traitez ces aspects.
principes comme un cadre. Commencez avec eux pour que vos équipes visent dans la
dirección correcta y téngalos en cuenta cuando comience a implementar los procesos
Lean UX que décrivons plus loin dans ce livre. Il est très important de comprendre que
Lean UX n'est pas un ensemble de règles. Au lieu de cela, c'est une approche que vous adoptez. Étant donné que
infinie variété de contextes dans lesquels travaillent les équipes de produits et les différentes
industries, entreprises, cultures, réglementations, clients et missions auxquelles ils servent les
designers, it is inevitable that I need to adjust the processes we described so that
fonctionnent dans votre organisation. Les principes de ce chapitre vous fourniront un guide
pour vous aider à effectuer ces ajustements.

En fin de compte, si vous pouvez appliquer les principes, vous découvrirez que cela changera la culture de
votre équipe. Certains principes auront plus d'impact que d'autres et il sera plus difficile d'agir
sur certains. Quoi qu'il en soit, chaque principe décrit ici vous aidera à construire
une organisation de conception de produits qui soit plus collaborative, plus multifonctionnelle et
s'ajuste mieux à la réalité agile d'aujourd'hui.

Les fondements du Lean UX

Lean UX est basé sur une série de fondements importants : c'est une combinaison de
certaines écoles de pensée différentes. Comprendre d'où cela vient vous aidera à
appliquer les méthodes et trouver des ressources lorsque vous êtes bloqué.

La première base de Lean UX est la conception de l'expérience utilisateur. Lean UX est, en

essence, une façon de pratiquer le design de l'expérience utilisateur. S'appuyant sur les
racines dans les domaines des facteurs humains et de l'ergonomie, ainsi que dans les idées de
design centré sur l'homme qui est né dans les années 1950 avec le travail
des designers industriels comme Henry Dreyfuss, ces méthodes et mentalités se
aujourd'hui, ils connaissent le design de l'expérience utilisateur (ou simplement UX), un terme
accrédité à Don Norman.1L'UX englobe une série de domaines de conception, y compris la conception
de interaction, l'architecture de l'information, le design graphique et bien d'autres. Mais
Le cœur de la pratique de l'UX est qu'il commence par identifier les besoins humains,
les besoins des utilisateurs du système.

Au cours de la dernière décennie, nous avons vu une augmentation de la popularité

delpensamientodediseño. La pensée design est née dans les académies dans les
décades des années 1970 et 1980 et a été popularisé par la firme de design IDEO au début des
la décennie de 2000. C'est une façon d'appliquer des méthodes de conception axées sur l'humain
une large gamme de problèmes. Tim Brown, directeur général et président d'IDEO,
décrivit la pensée design comme "innovation guidée par ... l'observation"
directement ce que les gens veulent et ont besoin dans leur vie et ce qu'ils aiment ou n'aiment pas
aime la façon dont les produits sont fabriqués, emballés, commercialisés et vendus
spécifiques". et soutenu ".2

Brown continua : "[c'est] une discipline qui utilise la sensibilité et les méthodes du
designer pour faire correspondre les besoins des personnes avec ce qui est
techniquement faisable et ce qu'une stratégie commerciale viable peut en faire
valeur pour le client et opportunité de marché.

La pensée design est importante pour Lean UX car elle adopte une position explicite
que tous les aspects d'une entreprise (ou de tout autre système) peuvent être abordés
avec des méthodes de conception. Donne la permission aux concepteurs de travailler au-delà de leurs limites
typiques. Cela encourage également les non-designers à utiliser des méthodes de design pour résoudre
les problèmes auxquels ils font face dans leurs rôles. Alors, UX et son cousin, la pensée de
le design, constitue la première base fondamentale qui encourage les équipes à considérer les
besoins humains, collaborer avec des rôles qui ne sont pas de design et aborder le design de
produits depuis une perspective holistique.

La base suivante de Lean UX est le développement de logiciels agiles. Les développeurs de

les logiciels ont utilisé des méthodes agiles pendant des années pour réduire leurs délais de
cycle, créer une cadence d'apprentissage continu et offrir de la valeur au client avec
régularité. Bien que les méthodes agiles puissent poser des défis de processus pour les
designers (que nous vous montrerons comment résoudre dans les Parties II et III), les valeurs centrales
de Agile sont parfaitement alignés avec Lean UX. Lean UX applique les quatre valeurs
fondamentaux du développement agile au design de produits :

1. Individus et interactions sur les processus et les outils.

Lean UX favorise la collaboration et la conversation sur les livrables et le

processus rigide. Impliquez toute l'équipe pour générer des idées sous divers angles
de vue. Favorise l'échange d'idées libre et fréquent pour permettre que le
l'équipe débat, décide et avance rapidement.

2. Logiciel de travail sur la documentation complète.

Chaque problème d'entreprise a d'innombrables solutions, et chaque membre d'un El

l'équipe aura une opinion sur laquelle est la meilleure. Le défi est de découvrir quoi
la solution est plus viable. Parfois, il est difficile ou impossible de prédire à l'avance ce que
la solution fonctionnera. En mettant nos idées entre les mains des clients (souvent
à travers des logiciels de travail) auparavant, l'équipe peut évaluer rapidement les
solutions pour l'ajustement et la viabilité du marché.

3. Collaboration avec le client sur la négociation de contrats.

En collaborant avec ses coéquipiers et ses clients, il construit une compréhension

partagée de l'espace du problème et des solutions proposées. Créer un consensus
Derrière les décisions. Quel est le résultat ? Des itérations plus rapides, une véritable participation
dans la fabrication de produits et l'investissement de l'équipement dans l'apprentissage
validé. Cela réduit également la dépendance à une documentation lourde car
Tous les membres de l'équipe ont déjà participé à la prise de décisions. La
 la collaboration crée une alignement de manière plus efficace que la communication écrite
les arguments et la défense élaborée.

4. Répondre au changement concernant le plan suivant.

La supposition dans Lean UX est que les conceptions de vos produits initiaux seront à
moins partiellement incorrect, donc l'objectif de l'équipe devrait être
descubrir qué se equivocaron lo antes posible. Tan pronto como el equipo
découvre ce qui fonctionne et ce qui ne fonctionne pas, ajuste ses propositions et teste à nouveau. Ceci
L'information du marché maintient les équipes agiles, les poussant.
constamment dans une direction "plus correcte".

La base finale de Lean UX est la méthode Lean Startup d'Eric Ries. Lean Startup utilise
un circuit de rétroaction appelé "construire-mesurer-apprendre" pour minimiser le
risque du projet et faire en sorte que les équipes construisent et apprennent rapidement. Les
les équipes créent des produits minimums viables (MVP) et les envoient rapidement pour
commencer le processus d'apprentissage le plus tôt possible.

Comme le dit Eric, "Lean Startup plaide initialement pour la création de prototypes rapides"
conçus pour tester les hypothèses du marché et utilisent les commentaires des clients
pour les faire évoluer beaucoup plus rapidement que par des pratiques d'ingénierie
logiciels plus traditionnels.3

Les processus Lean Startup réduisent le gaspillage en augmentant la fréquence

de contact avec de vrais clients, par conséquent, ils testent et évitent des hypothèses de marché
incorrects le plus tôt possible.

Lean UX es una aplicación directa de esta filosofía a la práctica del diseño de productos.

Chaque conception est une solution d'entreprise proposée : une hypothèse. Son objectif est de valider
la solución propuesta de la manera más eficiente posible utilizando los comentarios de
les clients. Le plus petit que vous pouvez construire pour tester chaque hypothèse est votre
MVP. Il n'est pas nécessaire que le MVP soit codé : il peut s'agir d'une approximation de
l'expérience finale, cela pourrait même ne pas être un produit ! Rassemblez ce que vous apprenez de
son MVP et développe ses idées. Puis il le refait.

Alors, quelle est la définition du Lean

UX ?
Voici comment nous définissons Lean UX :

• Lean UX est une approche de design qui met en lumière la véritable nature d'un
produit plus rapide, d'une manière collaborative, multifonctionnelle et centrée sur le
utilisateur.
• Les méthodes Lean UX construisent une compréhension partagée de l'utilisateur, ses
necesidades, nuestras soluciones propuestas y nuestra definición de éxito.
 • Lean UX privilégie l'apprentissage continu pour générer des preuves pour les
décisions de l'équipe et garantir une livraison de produits, services et valeur en
amélioration constante.

Principes
Dans le reste de ce chapitre, nous exposerons les principes derrière Lean UX. Pendant que
explorez cette approche, gardez à l'esprit ces principes. Pensez à votre expérience avec le Lean
L'UX comme un voyage d'apprentissage. Utilisez ces principes pour garder le cap.
correct pour vous et votre équipe.

Nous avons organisé ces principes en trois groupes : des principes pour guider l'organisation
de l'équipe, principes pour guider la culture et principes pour guider le processus.

Principes pour guider l'organisation de l'équipe

Commençons par jeter un œil aux principes du Lean UX liés à

l'organisation des équipes :

• Multifonctionnel
• Petit, dédié, situé
• Autosuffisant et autonome
• Centré sur le problème

Principe : multifonctionnel

Qu'est-ce que c'est ? Les équipes multifonctionnelles sont composées des diverses disciplines.
impliquées dans la création de votre produit. Ingénierie logicielle, gestion des produits,
diseño de interacción, diseño visual, estrategia de contenido, marketing, aseguramiento
de la qualité, tous font partie des équipes de Lean UX. Lean UX exige un haut
niveau de collaboration entre ces disciplines. Leur participation doit être continue depuis le
premier jour du projet jusqu'à la fin de l'engagement.

Pourquoi le faire ? Des équipes diverses créent de meilleures solutions parce que chaque problème
se voit sous de nombreux points de vue différents. La création d'équipes diversifiées limite la
besoin de processus fermés et basés sur des transferts (« cascade »). En revanche, les
les équipes peuvent partager des informations de manière informelle, ce qui crée une collaboration dans
une étape plus précoce du processus et stimule une plus grande efficacité de l'équipe.

Principe : petit, dédié, situé

Qu'est-ce que c'est ? Gardez votre équipe petite : pas plus de 10 personnes principales.
total. Dédiélez à un projet et mettez-les au même endroit.

Pourquoi le faire ? Le bénéfice des petites équipes se résume à trois

palabras:comunicación, enfoque y camaradería. Los equipos más pequeños son más
faciles de rester informés sur l'état du projet, les changements et le nouveau
apprentissage. Dédier son équipe à un projet maintient les membres de l'équipe
axés sur les mêmes priorités tout le temps et élimine les dépendances des autres
équipements. Avoir tout l'équipement au même endroit permet de favoriser les relations entre collègues
croissent.

UNENOTESURLEPLACEMENT

En 2020, en raison de la pandémie de COVID-19, notre industrie a été contrainte d'apprendre

beaucoup sur le travail à distance. Nous parlerons du travail à distance avec plus de profondeur
plus tard dans le livre, mais pour l'instant, nous voulons commenter ce principe et pourquoi
nous continuons à plaider pour le placement. Le "placement" consiste à réunir des personnes
dans le même espace physique. Nous avons appris l'année dernière que nous pouvons rassembler des équipes dans un
espace virtuel partagé et créer des expériences similaires. Cette façon de travailler a
certains avantages (pyjamas, chats et moins de temps de déplacement) et quelques
inconvénients (pyjamas, chats et outils de collaboration numérique inconfortables). Sans
embargo, en général, nous croyons que le cœur de ce qui rend la placement puissant
c'est la façon dont elle favorise la compréhension partagée. Elle encourage les équipes à avoir
conversations décontractées et non planifiées et rend les collaborations de plusieurs
les personnes avec une grande bande passante soient beaucoup plus faciles. Bien que nous ayons appris
beaucoup sur le travail à distance et nous avons appris à le faire fonctionner, nous croyons que
il perd quelque chose lorsqu'ils ne sont pas ensemble dans une pièce. Alors, s'il travaille de
de manière distante, pour quelque raison que ce soit, essayez de le faire d'une manière qui limite les
transferts, favorisez la collaboration informelle et recherchez d'autres avantages subtils de
s'asseoir dans la même pièce que ses collègues.

Principe : autosuffisant et autonome

Qu'est-ce que c'est ? Offrez à vos équipes toutes les capacités dont elles ont besoin pour fonctionner sans dépendances.

externes. Assurez-vous qu'ils disposent des outils nécessaires pour créer et lancer
logiciel. Donnez-leur la permission de découvrir comment résoudre les problèmes auxquels ils sont confrontés et pour
interagir avec les utilisateurs et les clients par le biais d'un contact direct.

Pourquoi le faire ? Les équipes sans dépendances externes peuvent optimiser leur processus.
pour atteindre la maximale efficacité. Ils ne veulent pas de ressources externes, ni ne veulent d'expérience
externe. Les équipes qui peuvent créer et lancer des logiciels par elles-mêmes peuvent se déplacer
à un rythme rapide et peuvent maximiser leur apprentissage. Enfin, les équipes ne peuvent pas
aprender del mercado si no se les permite interactuar con el mercado. Los equipos deben
pouvoir interagir directement avec les clients pour obtenir des retours
ont besoin de créer des solutions efficaces.

Principe : centré sur le problème

Qu'est-ce que c'est ? Une équipe centrée sur les problèmes est celle à laquelle un problème a été assigné.
entreprise ou utilisateur pour résoudre au lieu d'un ensemble de caractéristiques pour
implémenter. En d'autres termes, c'est une équipe qui s'est organisée autour d'un
résultat.

¿Por que hacerlo?Asignar problemas a los equipos para resolver demuestra confianza en
ces équipes. Cela leur permet de proposer leurs propres solutions et stimule un sens plus
profond fierté et propriété dans les solutions mises en œuvre par l'équipe. Aussi
change the appearance of 'fact'; instead of simply sending a function, teams
que ont l'espace pour vraiment résoudre les problèmes devront normalement
itérer jusqu'à ce que le problème soit réellement résolu.

Principios para guiar la cultura

La culture et le processus sont indissociables. Adopter Lean UX signifie adopter une culture
d'apprentissage et de curiosité. Ce sont les principes de Lean UX qui peuvent aider à
guider sa culture vers cet état final :

• Passer du doute à la certitude

• Résultats, pas sortie
• Élimination des déchets
• Compréhension partagée
• Sans étoiles du rock, gourous ou ninjas
• Permission de échouer

Principe : Passer du doute à la certitude

Qu'est-ce que c'est ? Le développement de logiciels est complexe et imprévisible. Pour cette raison, Lean UX
Commencez par l'idée que tout est une supposition jusqu'à ce que nous le prouvions.
au contraire. À mesure que nous travaillons, nous gagnons en clarté. Par conséquent, nous sommes toujours
passant d'une position de doute à une position de certitude.

Pourquoi le faire ? Tout projet commence par une série d'hypothèses. Parfois, ces
Les suppositions sont faciles à détecter ; parfois nous ne les voyons pas avant qu'il ne soit trop tard.
tard. Pour éliminer le risque d'investir beaucoup de temps et d'efforts dans un travail qui se
basa en suppositions erronées, nous commençons par valider nos
suppositions. Nous adoptons une mentalité de scepticisme enthousiaste. Cela signifie que
nous partons du doute et procédons à valider ce que nous savons, de la manière la plus systématique
et rigoureuse possible. Dans le processus, notre apprentissage nous permet d'être plus sûrs de
nos positions pendant que nous cherchons des améliorations continues dans notre travail.

Principe : résultats sur la production

¿Qué es?Las características y los servicios [Link] objetivos que deben alcanzar
sonré[Link] Lean UX, les équipes essaient avant tout de créer un résultat : un
changement mesurable dans le comportement humain qui crée de la valeur. Lean UX mesure le
progrès en termes de résultats explicitement définis.

Pourquoi le faire ? Lorsque nous essayons de prédire quelles caractéristiques obtiendront des résultats
spécifiques, pour la plupart nous nous consacrons à la spéculation. Bien que ce soit plus facile
administrer le lancement d'ensembles de fonctions spécifiques, souvent nous ne pouvons pas
prédire si une fonction sera efficace jusqu'à ce qu'elle soit sur le marché. En gérant les
résultats (et les progrès réalisés vers eux), nous obtenons des informations sur l'efficacité
des fonctions que nous construisons. Si une fonction ne fonctionne pas bien, nous pouvons
prendre une décision objective sur si cela doit être conservé, changé ou remplacé.
Principe : élimination des déchets

¿Qué es?Uno de los principios básicos enLa manufactura esbelta es la eliminación de

tout ce qui ne conduit pas à l'objectif final. Dans Lean UX, l'objectif final est d'améliorer les
résultats ; par conséquent, tout ce qui ne contribue pas à cela est considéré comme un gaspillage
et doit être éliminé du processus de l'équipe.

Pourquoi le faire ? Les ressources de l'équipe sont limitées. Plus je peux éliminer un
équipe le gaspillage, plus vite il pourra se déplacer. Les équipes veulent travailler sur les
défis corrects. Ils veulent être efficaces. Penser en termes de création de valeur et
l'élimination des déchets peut aider les équipes à maintenir leur concentration laser où
correspondre. Penser au gaspillage, et spécifiquement à l'éliminer, nous permet de penser
críticamente sobre nuestro proceso de diseño. Nos anima a pensar en la mejora continua
dans la façon dont nous travaillons. Mais ce n'est pas seulement le processus. Quel est le gaspillage
final? Faire des choses que les gens ne veulent pas. Ne fais pas ça. Concentre-toi sur l'utilisateur et
utilisez votre énergie pour offrir des choses précieuses.

Principe : compréhension partagée

Qu'est-ce que c'est ? La compréhension partagée est la connaissance collective qui s'accumule avec
le temps au fur et à mesure que l'équipe travaille ensemble. C'est une grande compréhension du
espace, le produit et les clients.

¿Por que hacerlo?El entendimiento compartido es la moneda de Lean UX. Cuanto más
comprennent en équipe collectivement ce qu'ils font et pourquoi, moins ils auront besoin
discuter de ce qui s'est passé et pourront rapidement passer à comment résoudre le nouveau
apprentissage. De plus, cela réduit la dépendance à l'égard de l'équipe de rapports de seconde main et
Documents détaillés pour continuer votre travail. Plus vous pouvez créer un
compréhension partagée de ce dont les utilisateurs ont besoin, plus il pourra dépasser son ego, les
jeux de pouvoir et décisions de conception autoréférentielles.

Principe : pas d'étoiles du rock, de gourous ou de ninjas

Qu'est-ce que c'est? Lean UX prône un état d'esprit basé sur les équipes. Stars du rock, gourous,
ninjas : nous utilisons ces étiquettes pour décrire des étoiles individuelles. Au lieu de
centrarse en los artistas estrella, Lean UX busca la cohesión y la colaboración del equipo.

Pourquoi le faire ? Les rock stars ne partagent ni leurs idées ni le centre de

Attention. La cohésion de l'équipe se brise lorsque l'on ajoute des individus avec de grands égos.
qui sont décidés à exceller et à devenir des étoiles. Quand la collaboration se brise, elle perd
l'environnement dont vous avez besoin pour créer la compréhension partagée nécessaire pour avancer à
manière efficace.

Principe : permission d'échouer

Qu'est-ce que c'est ? Pour trouver la meilleure solution aux problèmes d'entreprise, Lean UX
Les équipes doivent expérimenter des idées. La plupart de ces idées échoueront. La permission
pour échouer signifie que l'équipe dispose d'un environnement sûr pour expérimenter. Cela
il s'applique tant à l'environnement technique (ils peuvent promouvoir des idées d'une manière techniquement
segura) comme à l'environnement culturel (ils ne seront pas pénalisés pour essayer des idées qui n'ont pas
succès)

Pourquoi le faire ? Le permis d'échouer est la plateforme sur laquelle se construit une
culture de l'expérimentation. L'expérimentation génère la créativité. La créativité, à son
produisent des solutions innovantes. Lorsque les équipes n'ont pas peur pour leur travail si
ils font quelque chose de mal, ils sont plus enclins à prendre des risques. De ces risques surgissent, en fin de compte
instance, les grandes idées.

LESVERTUSDEL'AMÉLIORATIONCONTINUE

Dans une vidéo intitulée "Pourquoi tu dois échouer", le fondateur de CD Baby, Derek Sivers,
décrivez les résultats surprenants d'un cours de céramique.4

Le premier jour, l'instructeur a annoncé à sa classe que les étudiants seraient divisés en deux
groupes. La moitié des étudiants n'aurait besoin de faire qu'un seul pot en terre chacun.
durant le semestre. Ses notes dépendraient de la perfection de cette casserole
solitaire. L'autre moitié de la classe serait simplement évaluée par le poids des pots de fleurs.
ce qu'ils ont fait pendant le semestre. S'ils fabriquent 50 livres de casseroles ou plus, ils obtiendront un A.
Quarante livres gagneraient un B; 30 livres, un C; etc. Ce qu'ils ont vraiment fait, c'est
irrelevant. L'instructeur a dit qu'il ne regarderait même pas vos casseroles. Il se contenterait de prendre son
pèse-personne au dernier jour de classe et pèse le travail des étudiants.

À la fin du semestre, quelque chose d'intéressant s'était produit. Les observateurs externes de la
la classe ont remarqué que les casseroles de la plus haute qualité avaient été fabriquées par le "groupe de
quantité". Ils avaient passé tout le semestre à travailler le plus vite possible pour faire
vases. Parfois, ils réussissaient et parfois, ils échouaient. Avec chaque itération, chaque expérience,
Ils ont appris. À partir de cet apprentissage, ils sont devenus plus capables d'atteindre l'objectif.
final : faire des pots en argile de haute qualité.

Au contraire, le groupe qui a réalisé un objet ne a pas profité de ces itérations ratées et
il n'a pas appris assez rapidement pour performer au même niveau que le groupe
de cantidad". Habían pasado el semestre teorizando sobre lo que haría una vasija de barro
de 'grade A', mais ils n'avaient pas l'expérience pour exécuter cette grande vision.

Principes pour guider le processus

Maintenant que nous avons une idée des principes organisationnels et culturels plus larges,
jetons un coup d'œil tactique à la façon dont les équipes doivent changer leur mode de travail :

• Ne fais pas la même chose plus vite.

• Attention aux phases.
• L'itération est la clé de l'agilité.
• Travaillez en petits lots pour atténuer le risque.
• Adoptez la découverte continue.
• Sors du bâtiment.
• Exterioriza tu trabajo.
• Refaire l'analyse.
• Sortez du secteur des livrables.
Principe : ne fais pas la même chose plus vite

Qu'est-ce que c'est ? Lorsque les équipes adoptent Agile, les premières tentatives impliquent souvent
faire les mêmes choses que ceux qui ont toujours fait, juste plus vite. Cela ne fonctionne jamais
Bien. Vous ne pouvez pas faire huit semaines de recherche en deux semaines. Pas même cela.
intentes. En revanche, tu dois te comporter d'une manière nouvelle. Tu dois reconceptualiser
le travail.

Pourquoi le faire ? L'objectif d'Agile n'est pas de travailler rapidement. Ce n'est pas pour travailler sur
sprints de deux semaines. L'objectif n'est pas de suivre toutes les règles. L'objectif est de travailler
d'une manière qui soit appropriée pour le milieu du logiciel et, ce faisant, créer de meilleures
produits et services qui offrent plus de valeur. Alors, les méthodes agiles nous fournissent la
opportunité de repenser la façon dont nous travaillons, la façon dont nous collaborons, la
façon dont nous délivrons de la valeur. Parfois, nous pouvons simplement adapter des processus
anciens dans des rythmes agiles. Parfois, nous ne pouvons pas. Lorsque cela se produit, ne forcez pas les
méthodes, revoyez-les !

Principe : attention aux phases

¿Qué es?Cada vez que tienes unUna fase de investigación, una fase de diseño, una fase
de développement, une phase de test, une phase de durcissement (Dieu ne le veuille pas), en
réalité, une phase de quoi que ce soit, devrait servir de signal d'alarme de
que quelque chose ne va pas. Les équipes agiles devraient faire toutes ces choses continuellement,
en chaque sprint. Tu devrais investiguer continuement. Conception
en continu. Construire en continu. Tester… Tu comprends le point.

Pourquoi le faisons-nous ? Le travail agile repose sur une idée fondamentale : inspecter et
adapter. Il souhaite avoir un travail terminé qu'il puisse inspecter fréquemment.
y régulier. Les phases, qu'elles soient des phases de recherche, des phases de conception, des phases de
construction, quoi que ce soit, ne donne pas comme résultat un travail terminé. Donnent comme
résultat étapes de processus terminées. Pour arriver au travail terminé, vous devez passer par le
travail par phases au travail continu.

Principe : l'itération est la clé de l'agilité

Qu'est-ce que c'est ? Lorsque vous décomposez le travail en petites tâches, ne vous contentez pas de
portions incrémentales. À la place, adoptez une approche itérative. Attendez-vous à concevoir et
tester son travail, souvent le même travail, plusieurs fois jusqu'à ce qu'il le fasse bien.

Pourquoi le faire ? Beaucoup d'équipes agiles mélangent des approches incrémentales (diviser une
caractéristique grande en parties petites et la livrer en plusieurs sprints) avec des approches
itératifs (travailler sur une fonctionnalité encore et encore pour l'améliorer). En partie, cela
nous tenons à travailler en petites quantités, et les deux approches sont en fait
approches de petits lots. Cependant, l'itération est un engagement de refaire votre
je travaille jusqu'à ce que je le fasse bien, jusqu'à ce que je résolve le problème que j'essaie de
résoudre, jusqu'à ce qu'il satisfasse les besoins de l'utilisateur (pas simplement répondre aux
spécifications fonctionnelles), jusqu'à ce que je livre le résultat que vous essayez
créer. L'itération est également la clé pour mettre fin à l'une des frustrations les plus
comunes que expérimentent les designers UX dans le monde Agile : la sensation de
nous n'avons jamais le temps suffisant pour bien le faire. En travaillant sur une fonction
jusqu'à ce que ce soit correct, les équipes ont l'opportunité de faire un excellent travail de
qui sont fiers, qui satisfont l'utilisateur et résolvent le problème que l'entreprise a
proposer de résoudre.

Principe : travailler en petites quantités pour atténuer le risque

Qu'est-ce que c'est ? Un autre principe fondamental de la fabrication lean est la pratique de diviser le travail.
en petites unités olotes. La fabrication agile utilise cette notion pour maintenir
l'inventaire bas et la qualité haute. Traduit en Lean UX, cela signifie créer seulement le
conception qui est nécessaire pour faire avancer l'équipe et éviter un grand "inventaire" de
idées de design non testées et non mises en œuvre.

Pourquoi le faire ? Tout projet commence par des hypothèses. La conception de grands lots
commencez par ces hypothèses non prouvées et créez une grande quantité de travail de conception
en plus d'elles. Cela signifie que, si nous découvrons qu'une hypothèse fondamentale est
incorrecte, nous devons jeter beaucoup de travail. En travaillant par plus petites étapes, nous pouvons
concevoir et valider nos décisions en cours de route, ce qui réduit le risque de
gaspillage de travail.

Principe : embrasser la découverte continue

Qu'est-ce que c'est ? La découverte continue est le processus continu d'engagement du client.
durant le processus de conception et de développement. Cela se fait à travers des activités
programmé régulièrement, utilisant des méthodes tant quantitatives que qualitatives. Le
L'objectif est de comprendre à la fois ce que l'utilisateur fait avec ses produits et pourquoi.
hace. Así que investigas con frecuencia y a un ritmo regular. La investigación involucra
à tout le monde.

Pourquoi le faire ? Des conversations régulières avec les clients offrent des opportunités
fréquences pour valider de nouvelles idées de produits. L'incorporation de toute l'équipe au
le cycle de recherche développe l'empathie pour les utilisateurs et les problèmes auxquels ils sont confrontés
ils font face. Vous créez une compréhension partagée. Enfin, à mesure que l'équipe
apprends ensemble, réduis le besoin de futures conversations et de documentation.

Principio : sors de l'immeuble

Qu'est-ce que c'est ? Cette phrase, popularisée par Steve Blank, professeur, entrepreneur et auteur de
Stanford fait référence à la pratique de ce que les gens de l'UX connaissent simplement comme
Recherche d'utilisateurs. Dans le monde de la fabrication agile, vous entendrez une idée
similaire exprimée par "aller et voir".

Ce que toutes ces communautés ont découvert ensemble, c'est l'idée que non
vous trouverez la vérité sur vos utilisateurs dans une salle de conférence. Vous devez aller où
ils sont, observer ce qu'ils font et vraiment interagir avec eux pour comprendre ce
ce qu'ils font, ce qu'ils essaient de faire et pourquoi ils essaient de le faire.

Lean UX s'aligne avec cette recette : offrez aux clients potentiels l'occasion de
fournir des commentaires sur vos idées plus tôt que je ne le ferais dans le passé. Beaucoup
avant. Mettez vos idées à l'épreuve avec une forte dose de réalité pendant qu'elles sont encore jeunes. C'est
mieux découvrir que vos idées ne frappent pas dans le mille avant d'avoir investi du temps et
recursos en la creación de un producto que nadie quiere.

Pourquoi le faire ? En fin de compte, le succès ou l'échec de votre produit n'est pas une décision
de l'équipe, c'est du client. Ils devront cliquer sur le bouton "Acheter maintenant" qui
Concevoir. Plus il leur donnera rapidement une voix, plus il saura s'il a une idée qui fonctionne.

Principio : externalisez votre travail

Qu'est-ce que c'est ? Extérioriser signifie réussir à travailler en dehors de sa tête et en dehors de son
ordinateur et à la vue du public. Les équipements utilisent des tableaux, des espaces virtuels
partagés, tableaux avec noyau en mousse, murs d'appareils, impressions et notes
adhésifs pour exposer votre travail en cours à vos coéquipiers, collègues et
clients.

Pourquoi le faire ? L'externalisation du travail permet à tous de voir où se

trouve l'équipe. Crée un flux d'information environnementale passif dans tout le
équipe. Inspire de nouvelles idées qui se basent sur celles qui ont déjà été partagées. Permet que
tous les membres de l'équipe, même les plus calmes, participent à des activités de
échange d'informations. Vos notes autocollantes ou croquis sur le tableau sont si bruyants
comme la personne la plus éminente de l'équipe.

Principe : changement d'analyse

Qu'est-ce que c'est ? Valeurs Lean UX qui font plus d'analyses. Créer la première version d'une idée
a plus de valeur que de passer une demi-journée à débattre de ses mérites dans une salle de conférence.

Pourquoi le faire ? La réponse aux questions les plus difficiles auxquelles l'équipe sera confrontée ne
se répondra dans une salle de conférence ; ce sont les clients sur le terrain qui leur
Ils répondront. Pour obtenir ces réponses, il est nécessaire que les idées soient concrètes ; c'est
nécessaire de créer quelque chose auquel les gens peuvent répondre. Débattre des idées sans données basées
sur le marché, c'est un gâchis. Au lieu d'analyser des scénarios potentiels, agissez.
sortez du bâtiment avec cela.

Principe : sortez du secteur des livrables

Qu'est-ce que c'est ? Lean UX change l'approche du processus de conception loin des documents qui
l'équipe est en train de créer. En revanche, elle se concentre sur les résultats qu'elle obtient.
équipe. Avec une plus grande collaboration interfonctionnelle, la conversation avec les parties
les personnes intéressées deviennent moins préoccupées par quel artefact est en train d'être créé et plus par quel résultat
on y arrive.

Pourquoi le faire ? Les documents ne résolvent pas les problèmes des clients, les bons.
produits oui. L'équipe doit se concentrer sur l'apprentissage des fonctionnalités qui ont le plus grand
impact sur ses clients. Les artefacts utilisés par l'équipe pour obtenir et communiquer cela
La connaissance est sans importance. Tout ce qui compte, c'est la qualité du produit, mesurée
par la réaction du marché à celui-ci.
Terminant
Ce chapitre présente un ensemble de principes fondamentaux pour Lean UX. Ceux-ci sont
les attributs centraux que toute équipe de Lean UX devrait s'efforcer de
incorporer. Au fur et à mesure que vous commencerez à former votre pratique, nous vous encourageons à utiliser ces
principes pour définir la composition, l'emplacement, les objectifs et les pratiques de votre
équipe.

1DonNorman et Jakob Nielsen, « La définition de l'expérience utilisateur », Nielsen Norman

Groupe, consulté le 15 juin 2021,[Link] .

2TimBrown, "Design Thinking", Harvard Business Review, juin

2008[Link] .

3JoshSeiden et Jeff Gothelf, « Les 3 fondations du Lean UX », O'Reilly Media, 25 de

octobre 2017[Link] .

4DerekSivers, « Pourquoi vous devez échouer - par Derek Sivers », 15 février 2011, vidéo
de YouTube, 14:54[Link] .
Chapitre 3. Résultats
Traditionnellement, les projets logiciels s'inscrivent dans des exigences et des livrables. Les
les équipes reçoivent des exigences et sont censées créer des livrables. Ces livrables
décriront les systèmes, les caractéristiques et la technologie qui satisferont ces
exigences. Dans de nombreux cas, les exigences arrivent sans un contexte stratégique. Pourquoi
Faisons-nous cela ? Pour qui ? À quoi ressemble le succès ?

Lean UX change radicalement la façon dont nous encadrons notre travail lors de la présentation
de nouveau le contexte stratégique pour nos choix de caractéristiques et de design et, le
ce qui est le plus important, c'est nous, toute l'équipe, pas seulement le département de design,
nous définissons le succès. Notre objectif n'est pas de créer un produit ou une fonctionnalité : c'est
affecter positivement le comportement du client ou changer dans le monde, pour créer
un résultat.

Dans quel secteur sommes-nous ?

Lean UX signifie sortir du business des livrables. Ils étaient dans le business de la
création de résultats. Nous devons nous concentrer moins sur les choses que nous faisons (la
documentation, les maquettes et les prototypes, les fonctions, les pages et les boutons) et
plus en générer des résultats. Pour ce faire, nous nous concentrons uniquement sur le fait de faire des choses qui génèrent
les résultats que nous voulons.

Pourquoi se concentrer sur les résultats plutôt que sur les caractéristiques et les livrables ? C'est
parce que nous avons appris qu'il est difficile, et dans de nombreux cas impossible, de prédire si les
Les caractéristiques que nous concevons et construisons créeront la valeur que nous souhaitons créer.
un bouton incitera-t-il les gens à acheter ? Cette fonction générera-t-elle plus de participation ?
Les gens utiliseront cette fonction de manières que nous n'avons pas prévues ? Allons-nous changer avec succès la
façon dont les personnes interagissent avec notre service ? Par conséquent, au lieu de
se concentrer sur les fonctions, il vaut mieux se concentrer sur la valeur que nous essayons de créer et
continuer à tester des solutions jusqu'à ce que nous en trouvions une qui offre de la valeur, le résultat,
que nous souhaitons.

Ce changement d'accent s'applique à la fois aux choses que les concepteurs font comme partie
de son processus (documents, maquettes, structures filaires, spécifications,
prototypes) comme à la manière dont nous encadrons notre travail. Quel est le résultat
que veulent nos clients ou parties prenantes ? Bien sûr, il est possible qu'ils nous demandent de créer
un site web ou une application. Ils peuvent demander une nouvelle page, un nouveau flux,
une nouvelle copie. Mais ils le demandent pour une raison, et une partie de notre travail est
comprendre et articuler cette raison. Nous approfondirons comment le faire dans la partie suivante
del libro. Por ahora, sin embargo, queremos equiparlo con un poco de lenguaje para
l'aider à reconsidérer son travail loin des livrables et vers les résultats, en d'autres
mots, pour passer des produits aux résultats.

Une histoire sur les résultats

Imaginez une petite équipe travaillant dans une agence. Jono, Nicole, Alex et Amanda
se réunira avec un nouveau client pour la première fois. Le client a engagé l'agence pour
concevoir, construire et lancer un nouveau site web qui s'engage à en lancer davantage
avancer dans l'année.

L'équipe cliente s'est préparée pour cette première réunion. Ils ont préparé et envoyé une
liste détaillée des exigences que doit respecter le site web. La liste des fonctionnalités est
ambitieuse et, pour l'équipe de l'agence, plus qu'un peu effrayante. L'équipe de la
l'agence a également fait ses devoirs. Ils ont examiné la liste des exigences et ont un
ensemble de questions prêtes pour le client.

Après quelques présentations et politesses, Nicole va droit au but. Elle dit : « Donc
nous avons eu l'occasion de réviser la liste des exigences et il y en a beaucoup. Une chose
Ce qui nous aiderait, ce serait de nous éloigner des exigences un moment et simplement de parler.
sur le but du site et du service. Pouvez-vous nous dire pourquoi ce service est
importante pour votre entreprise?

«Bien sûr», dit Cecily, directrice générale de la petite entreprise qui a engagé la
agence. "Actuellement, nous proposons un service de planification d'événements et de voyages de
une aventure de très haut niveau pour peut-être 50 clients par an. C'est un service très
personnel. Nous aimerions lancer une version en ligne de notre service afin de pouvoir répondre
à des milliers de clients chaque année. Nous savons qu'il y a de la demande, mais l'économie nécessite un
approche de contact minimal, et c'est ce que fournira ce site web.

«C'est génial», dit Nicole. Jono s'approche du tableau et écrit : Impact : un service réussi de
sous contact qui nous permet de servir des milliers de clients chaque année.

Nicole continue : « Et lorsque ce service sera en direct, que pourront faire les clients qui
ne peuvent pas faire aujourd'hui?

« Eh bien », dit Cecily en faisant une pause un moment. « Bonne question. Notre
le service actuel est un service spécialisé de planification d'événements pour des événements à
mesure dans des lieux exotiques. Nous faisons nous-mêmes toute la planification. Dans notre
nouveau service, nous aimerions que les hôtes d'événements qui ne nécessitent pas notre
expérience de voyage peuvent trouver des planificateurs d'événements avec qui travailler que
se ajustent à leurs budgets et besoins.

«Impressionnant», dit Jono, qui écrit au tableau. Résultat : les hôtes de

L'événement rassemblera des planificateurs d'événements qualifiés pour des événements.
nationaux et locaux.

Cecily mira el tablero, un poco [Link] dice: “Eso es todo algo obvio.¿Por qué te
aide cela ?

Nicole explique : "Eh bien, la liste des fonctions dans son document de spécifications est très
ambitieuse". C'est la manière polie de Nicole d'expliquer que la liste est déraisonnablement
longue et devient souvent de la spéculation. Elle continue : « Étant donné que sa date
la limite est assez courte, nous devrons filtrer la liste et décider quoi compiler en premier et quoi
Les fonctions peuvent attendre jusqu'à plus tard. Comprendre le résultat qu'ils souhaitent de nos
les utilisateurs nous aideront à prioriser la liste des fonctionnalités afin que nous puissions nous concentrer sur
choses qui aident les clients à se connaître, à trouver des projets et à en faire des offres
ensemble. Tout ce qui ne génère pas ce résultat sera dépriorisé.
Déballer l'histoire : produit, résultats, impact

Maintenant, l'histoire précédente est une fiction, mais elle est basée sur d'innombrables réunions initiales.
réelles, et illustre l'une des idées clés en Lean UX : Lean UX consiste à se concentrer sur les
résultats.

Voyons l'histoire avec un peu plus de détails et parlons un peu du cadre derrière.
du processus de Nicole et Jono.

Tout d'abord, le client est arrivé avec une longue liste de exigences : celles-ci décrivaient les exigences
le site web et les caractéristiques du site que l'agence voulait qu'elle conçoive et
construira. Ce sont les choses que l'agence voulait que je fasse : le résultat.

L'équipe de l'agence savait que la liste des fonctions était trop longue (cela prendrait beaucoup
temps de compiler tout le document des exigences) et, ce qui est pire, ils soupçonnaient que
beaucoup des fonctions de cette liste ne seraient pas utiles pour les utilisateurs finaux ou
client. Ainsi, l'équipe de l'agence cherchait à aller au-delà de la liste des fonctionnalités.

Lorsque Nicole a posé des questions sur l'impact que recherchait le client, elle s'est tournée vers le panorama.
Si la directrice exécutive voulait garder son emploi, que devrait-elle remettre à
la junta ? Nous utilisons le mot "impact" pour décrire les objectifs les plus élevés que
établir une entreprise. Celles-ci ont tendance à être des choses comme les revenus, les bénéfices, la fidélité du
client. Mais ils peuvent également être de grands objectifs stratégiques, comme l'objectif de
Cecily de passer d'un fournisseur de services boutique à une organisation avec une portée
plus large.

Le problème avec les grands objectifs (objectifs au niveau de l'impact) est qu'il y en a tant
formes de les poursuivre et tant de facteurs qui y contribuent, que cela peut être difficile
savoir comment diviser le travail et comment mesurer le progrès vers cet objectif. Pour aborder
Donc, nous utilisons un objectif intermédiaire, appelé "résultat". Dans ce cas, l'équipe a capturé
l'objectif intermédiaire le plus important vers lequel ils travailleraient, qui était le
résultat : permettre aux professionnels qualifiés de se connaître et de créer des offres de
projets collaboratifs.

Alors, tandis que les produits sont des choses que nous faisons, comme des sites web et
les fonctions, les résultats sont des choses que les gens font. En fait, c'est la clé de notre
définition des résultats. Nous définissons un résultat comme "un changement dans le
comportamiento humano que crea valor". 1Lorsque nous utilisons cette définition de
résultat, nous utilisons une idée intrinsèquement centrée sur l'être humain pour
définir le succès. Quand nous nous éloignons des produits (les choses que nous faisons) et nous
nous nous orientons vers les résultats, nous choisissons de mettre les êtres humains et leurs besoins en premier
au centre de ce que nous faisons.

LEMODÈLELOGIQUE

Hemos extraído nuestro lenguaje (productos, resultados, impacto) de un modelo llamado

modèle logique, décrit pour la première fois en 2004 par la Fondation WK Kellogg. Ce
Le modèle a prouvé être populaire dans le monde à but non lucratif. L'objectif du modèle
era ayudar a las personas que ejecutan proyectos complejos a evaluar la eficacia de esos
programmes. Lorsque les donateurs font un don d'argent pour un programme, ils ont généralement
un impact sur l'esprit. Comment peuvent-ils évaluer si l'argent de leur subvention est en train de
dépensant bien ? Le cadre du modèle logique a été développé pour aider les évaluateurs
de programmes à répondre à cette question. Le modèle est généralement visualisé comme étant
voir la Figure 3-1.

FIGURE 3-1. LE MODÈLE LOGIQUE

Dans notre travail avec des équipes, nous avons découvert que ce modèle peut être vraiment
utile pour les équipes agiles. Nous l'avons un peu adapté à notre contexte plus
limité. Mais si vous êtes intéressé à obtenir plus d'informations, nous vous encourageons à consulter
la source et lisez-en plus sur l'évaluation des programmes sur le site de la Fondation Kellogg.

Un regard plus approfondi sur un résultat

Jetons un œil plus attentif au résultat de notre histoire. D'abord, nous avons dit que
Le résultat est un changement de comportement. De quoi parlons-nous avec cela ?
notre histoire, notre résultat a été : rencontrer des professionnels qualifiés et créer
propositions de projets collaboratifs. Ce projet, s'il a du succès, encouragera un
comportement : les professionnels se rencontreront en ligne pour créer ensemble les offres
du projet. Cela pourrait être un nouveau comportement, quelque chose que ces professionnels ne
Ils peuvent le faire aujourd'hui, ou cela pourrait tout simplement être une meilleure façon de faire quelque chose qu'ils font.
Aujourd'hui. Quoi qu'il en soit, nous considérons que c'est un changement de comportement.

Et qu'en est-il de la partie création de valeur de notre définition ? Eh bien, si notre

le travail réussit, ces professionnels pourront faire cette nouvelle chose et en tireront de la valeur
pouvoir le faire. Alors, nous avons satisfait les deux parties de notre définition. Les
Les professionnels pourront faire cela nouveau et en tireront de la valeur en le faisant.

Maintenant, ce qui est intéressant ici, c'est que ce nouveau comportement crée également de la valeur pour le
organisation. Ils bénéficient de ce nouveau comportement du client, car quand
satisfont leur client, le client paie pour le service, il est plus probable qu'il paie de
nouveau dans le futur et il est également plus probable qu'il recommande le service à d'autres. Si vous êtes
en lisant attentivement, vous remarquerez que ce sont aussi des comportements des clients : les
les clients paient pour le service, reviennent pour plus de service, recommandent le service. Tous
ce sont aussi des résultats, mais ces résultats ne bénéficient pas nécessairement au
L'utilisateur. En revanche, ces résultats profitent à l'organisation.

C'est quelque chose auquel nous devons prêter attention lorsque nous travaillons avec des résultats : Qui
obtient la valeur du comportement en question ? Quand un professionnel peut faire
entreprises plus facilement, obtient cette valeur. Lorsque le client paie pour ce résultat, le
l'organisation obtient de la valeur. En d'autres termes, la valeur dépend de ton point de vue.
vue. Nous en parlerons plus en détail dans leChapitre 8. Pour l'instant, rappelez-vous simplement que
Chaque résultat vient avec un point de vue intégré, et il est important de comprendre...
Quel point de vue sommes-nous en train de penser. (Voir la Figure 3-2.)
Voyons un système comme Facebook pour voir un exemple de point de vue. Quand un
L'utilisateur final se connecte à Facebook, il tire de la valeur en lisant et en publiant sur le fil d'actualité.
temps. Les annonceurs obtiennent de la valeur lorsque les utilisateurs de la ligne du temps voient et
interagissent avec les annonces. Et Facebook obtient de la valeur lorsque les utilisateurs passent plus
temps sur le site et les annonceurs leur paient pour accéder à ces personnes. Si vous souhaitez que
pour que votre système fonctionne, vous devez créer un ensemble de résultats alignés ; vous devez comprendre les
formes par lesquelles les différents utilisateurs obtiennent de la valeur et ensuite leur fournir cette valeur de manière
manière qu'elle crée également de la valeur pour son organisation.
Figure 3-2. Valeur alignée

L'exemple de Facebook apporte ici un autre point de vue, qui est lié à la valeur que
créez le système pour les personnes qui ne l'utilisent pas directement. L'impact de Facebook
dans la société c'est, eh bien, appellons-le controversé. En termes de notre modèle, ils ont
créé une manière d'offrir de la valeur aux utilisateurs, aux annonceurs et à eux-mêmes, mais
À quel coût pour la société ? Un cadre solide et éthique pour aligner la valeur doit avoir en
prend en compte les besoins d'un large éventail de parties prenantes, tant celles qui interagissent
directement avec le système comme celles qui sont affectées indirectement.2

Cela nous amène à un point final ici : aucun des systèmes sur lesquels nous travaillons ne peut
se décrire en une seule déclaration de résultats. Tous sont des systèmes de résultats
interreliés. De plus, tous ces résultats connexes se combinent pour créer le
impact (ou impacts) de haut niveau que nous recherchons. Cela peut compliquer le travail avec les
resultados: un sistema típico está compuesto por muchas personas que realizan muchos
comportements. Il est facile de se sentir rapidement dépassé. Quels comportements sont
importantes? ¿En cuáles deberíamos enfocarnos? En los próximos capítulos,
nous partagerons certaines techniques pour découvrir, comprendre et cartographier ces résultats
liés et pour naviguer à travers cette complexité pour trouver les résultats
clés sur lesquelles se concentrer.

Résultats, itération et validation

Lorsque vous changez l'approche de votre travail des produits aux résultats, vous créez de grandes
changement dans la façon dont il organise son travail. L'une des grandes choses qui changent est
la ligne d'arrivée : comment sait-on quand c'est terminé ?

Dans le monde du logiciel, nous utilisons normalement des exigences, des spécifications et des critères.
d'acceptation pour nous indiquer quand le travail est réalisé. Est-ce en cours d'exécution ?
{"software":"logiciel","¿Cumple con las especificaciones?":"Est-ce conforme aux spécifications ?","¿Cumplir con los requisitos?":"Répondre aux exigences ?","¿Cumplir con":"Respecter"}

les critères d'acceptation ? Remplit-il ce que Scrum appelle la "définition de

fait"? Ces méthodes sont bonnes car elles peuvent définir la ligne d'arrivée avec beaucoup de
précision, mais on nous demande presque toujours d'évaluer le résultat de notre travail. Et
si nous ne voulons pas nous arrêter là ? Que se passe-t-il si nous voulons mesurer les résultats que nous avons
créé ?

Il s'avère que, dans ce cas, nous ne pouvons pas cesser de travailler sur une chose lorsque nous avons terminé
de la faire. Pour mesurer les résultats, nous devons vraiment mettre cette chose dans le monde
et observer comment (ou si) le comportement des gens change. En d'autres termes,
Bien que nous devions compléter la sortie, cela n'est pas suffisant. Nous devons le valider.

Le processus de validation de notre sortie est intrinsèquement itératif. La plupart des

Parfois, les équipes ne font pas tout bien du premier coup. En général, notre premier
l'intention peut obtenir certains des résultats que nous recherchons, mais généralement non
tout. Lorsque nous nous concentrons sur les résultats, nous voyons l'opportunité d'améliorer et
nous continuons à travailler là-dessus jusqu'à ce que nous délivrions les résultats que nous nous sommes fixés. Ceci est
le processus que Lean Startup appelle le cycle de construction-mesure-apprentissage et ce que la
communauté Agile appelée inspecter et adapter. Quel que soit le nom que vous donnez à ces boucles,
décrivent une approche itérative. Une approche qui signifie la fin d'une et d'autre fois. Un
approche qui signifie que nous itérons jusqu'à obtenir le résultat.

1PPour obtenir plus d'informations sur les résultats, consultez le livre de JoshRésultats
sur les résultats : pourquoi le comportement du client est la métrique clé pour le
succès commercial (Sense & Respond Press, 2019)[Link] .
2PPour obtenir un bon résumé des problèmes ici, consultez l'article d'Oz Lubling.
La ligne floue entre l'autonomisation et l'exploitation en UX, Culture Clash, 4 de
février 2021[Link] .
Partie II. Processus
À propos de la Partie II
Dans la partie précédente, nous avons analysé les idées derrière Lean UX : les principes qui le sous-tendent.
le travail. Dans cette section, nous deviendrons très pratiques et décrirons en détail le
processus de faire Lean UX.

Nous avons organisé cette section autour d'un nouvel outil que nous avons été
utilisant ces dernières années : le Lean UX Canvas. Lean UX Canvas est une forme
de orchestrer son processus Lean UX. Il offre une vue "d'un coup d'œil" sur une seule page
pour encadrer votre travail dans une fonction, une épopée ou une initiative, ou même un
produit complet.

Cet outil d'une seule page regroupe tous les outils, méthodes, processus et
techniques clés de Lean UX dans un seul document avec une structure unifiée. C'est une
outil que vous pouvez utiliser pour obtenir depuis la première partie du processus de conception
(le cadrage initial du problème) à travers la conception, la création de prototypes et la
recherche.

Bien que vous n'ayez pas besoin d'utiliser le canevas pour faire du Lean UX, nous avons découvert que le canevas
c'est une excellente manière d'expliquer le processus, c'est pourquoi nous avons choisi de vous le présenter
le processus Lean UX par l'utilisation du canevas.

Le canevas Lean UX
Le Chapitre 4, Lean UX Canvas fournit une vue d'ensemble du Lean UX
Canvas. Vous apprendrez pourquoi Lean UX est sceptique à propos des exigences, pourquoi
adopte des hypothèses à sa place et comment le Lean UX Canvas est un véhicule qu'il peut utiliser
pour capturer et tester vos hypothèses. Ce chapitre présente également quelques idées sur
comment faciliter le processus de travail avec la toile.

Le Chapitre 5,Cuadro 1: Problema comercial , couvre la technique que vous utiliserez pour définir
le problème que vous et votre équipe essayez de résoudre du point de vue de la
entreprise.

Le Chapitre 6, Cuadro 2: Resultados comerciales , couvre comment il définit le succès de son

projet. Ce cadre vise à comprendre quels résultats vous essayez d'obtenir pour
votre entreprise, organisation ou clients.

Le Chapitre 7,Cuadro 3: Usuarios couvre la section du canevas qui définit ses utilisateurs
(y clients). Cette section décrit la technique du proto-persona et comment l'utiliser.

Le Chapitre 8,Tableau 4 : Résultats et bénéfices de l'utilisateur, il s'agit des objectifs

de l'utilisateur. Que tentent de faire ses utilisateurs (et clients) ? Qu'est-ce qui définira le succès pour
eux?
Le Chapitre 9,Tableau 5 : Solutionsc'est là où nous commençons à définir ce que nous ferons (ou
nous allons) pour résoudre les problèmes que nous avons définis.

Chapitre 10, Recuadro 6: Hipótesis , Chapitre 11, Encadré 7 : Qu'est-ce qui est le plus
Qu'est-ce qui est important que nous devions apprendre en premier ? , et leChapitre 12, Recuadro 8 : MVP et
Expérimentations, couvrent le tiers inférieur de la toile, ce qui stimule la conversation pour
vérifier si nous avons raison dans tout le reste sur la toile.

Profondissons dans chaque case et voyons exactement comment se développe chaque partie de
cette conversation, comment la faciliter avec succès et quoi prendre en compte à chaque étape
recuadro à mesure qu'il progresse dans les exercices et déclare ses hypothèses.
Chapitre 4. La toile Lean UX
Les suppositions sont les nouveaux requis.
Si vous travaillez dans une industrie où les choses sont relativement prévisibles, où il existe un
à faible risque et une haute certitude quant à ce que fait l'entreprise, ce dont on a besoin pour
faire son produit, à quoi il ressemble une fois terminé et ce que ses clients en feront une fois
qu'ils l'aient, il peut travailler confortablement avec un ensemble de exigences strictes et
prédéfinis. Dans un monde avec cette mentalité de l'ère de la fabrication, le grand
la conception à l'avance est la norme, et toute variabilité dans la production de votre
le produit n'est pas considéré comme une réponse agile à un marché en changement, mais comme
une déviation coûteuse du plan. Cette façon de penser aux exigences a été adoptée dans
les premiers jours de l'industrie du logiciel, a été le modèle dominant pendant des décennies
et continue d'imprégner les façons de travailler de nombreuses équipes même jusqu'à aujourd'hui.
aujourd'hui.

Les exigences supposent que nous savons exactement ce dont nous avons besoin
construire. Idéalement, ils proviennent du rigueur de l'ingénierie. Mais en logiciel,
généralement, ils n'ont pas le sérieux derrière eux. Néanmoins, ils sont pris au pied de la lettre selon
la crédibilité de son auteur ou le titre de l'organisation. Dans de nombreux cas, cette foi aveugle se
augmente avec la phrase "eh bien, ça a fonctionné avant". Les personnes ou les équipes qui remettent en question le
le caractère absolu des exigences qui ont été reçues est perçu comme perturbateur et
traités comme des boucs émissaires lorsque les projets ne respectent pas les délais,
dépassant la portée ou les deux. Dans les organisations qui dépendent encore en grande partie
medida de ellos como una forma de decirle a los equipos qué hacer, los requisitos a
menudo signifie simplement, comme aime à le dire notre ami Jeff Patton,
Tais-toi.

Mais les entreprises actuelles basées sur des logiciels opèrent dans une réalité dépourvue de
cohérence, prévisibilité, stabilité et certitude. Dire avec autorité qu'un
Une combinaison spécifique de code, de copie et de design obtiendra le résultat commercial.
désiré et sera remis intégralement à une date limite explicite non seulement
risqué ; dans la plupart des cas, c'est un mensonge. Le développement de logiciels est complexe
et imprévisible. Le rythme du changement est incroyablement rapide. Les entreprises non seulement
ils peuvent envoyer des fonctions en production de manière continue à des vitesses sans précédent,
mais les comportements des consommateurs changent avec elle
rapidité. Dès qu'un ensemble de caractéristiques a été décidé, une approche
de conception et une expérience utilisateur spécifique, votre audience commence à évoluer
vers de nouveaux modèles mentaux basés sur leurs expériences avec d'autres services en ligne.

La bonne nouvelle est que nous n'avons pas à dépendre des exigences. L'industrie a
développé de nouvelles façons de travailler qui nous permettent de nous éloigner des rigidités
exigences. Lorsque nous avons écrit la première édition de ce livre, Amazon envoyait le code
une production toutes les 11,6 secondes. Aujourd'hui, ils ont réduit leur délai de mise sur le marché à un
deuxième.1Ainsies: cada segundo, algún cliente de Amazon en algún lugar de su ecosistema
expérimentez un changement dans la façon dont le produit fonctionne. Soixante fois par
minute, Amazon a l'opportunité de savoir à quel point ils satisfont les
les besoins de leurs clients. Soixante fois par minute, ils ont l'occasion de répondre
à ce qu'ils apprennent. Soixante fois par minute, ils ont l'occasion de s'améliorer
votre expérience utilisateur. Avec cette capacité, l'idée même d'une exigence rigide est, dans
le meilleur des cas, anachronique. Dans le pire des cas, c'est un obstacle qui empêche
que les équipes fassent de leur mieux. Nous convenons qu'Amazon est à l'extrémité de
cela, mais ils servent d'inspiration et d'objectif clair pour ce qui est possible. Si nous pouvons
envoyer, détecter et répondre à cela rapidement,

Il y a d'autres raisons d'éviter les exigences. Le logiciel est difficile. Même les ingénieurs
des logiciels expérimentés vous diront que juste parce que quelque chose semble simple à construire
cela ne signifie pas qu'en réalité, ce sera facile à construire. Souvent, lorsque nous nous sommes fixés
offrir une expérience utilisateur spécifique, nous apprenons que, pour ce faire,
nous devrons développer plus de code que prévu. Le code que nous pensions que
il serait simple d'avoir des dépendances complexes ou a-t-il des limitations héritées ou se
trouver des obstacles non prévus, et nous finissons par devoir consacrer plus de temps
à enquêter sur la façon de résoudre ces problèmes. Cela va également à l'encontre des exigences
rigides basés sur des délais.

Y, bien sûr, ce n'est pas seulement le code qui est complexe et imprévisible. Les humains le sont aussi.
complexes et imprévisibles. Leurs motivations innées, personnalités, attentes,
les normes culturelles et les habitudes vont à l'encontre de ce que nous croyons être un service logiciel
idéal pour qu'ils l'utilisent. Nous mettons tant de foi en ce que nous croyons que ce sera "facile à utiliser" ou
«intuitif», juste pour découvrir que notre public cible fait tout son possible pour
éviter les simplifications que nous pensons avoir faites pour eux. Pourquoi font-ils
Ça ? Une variété de facteurs (que nous pourrions connaître grâce à des entretiens et
des recherches avec les clients) pourrait conduire à ces comportements inattendus,
pero todos tienen el mismo resultado neto: demuestran que nuestros requisitos son
incorrects.

Alors, que devons-nous faire ? Nous devons reconnaître que la plupart des exigences
Ce ne sont que des suppositions, exprimées avec autorité. Si nous éliminons l'autorité, le
excès de confiance et l'arrogance de la conversation, nous restons avec le meilleur
supposition de quelqu'un sur la meilleure façon d'atteindre un objectif utilisateur ou de résoudre
un problème commercial. Nous sommes fabricants de produits numériques, donc admettre
humblement que ce sont nos meilleures conjectures ou suppositions crée de manière
immédiate et explicite l'espace pour la découverte de produits et l'expérience de
utilisateur ajusté. Si nous comprenons comme équipe que le travail que nous réalisons est
risques précisément parce que nous ne pouvons pas prédire le comportement humain,
nous savons qu'une partie de notre travail devra inclure l'expérimentation, la recherche et
réélaboration. Nous réduisons notre attachement aux idées et créons une culture d'équipe qui
est plus disposée à ajuster le cap, même à abandonner une idée qui se poursuit
rendant inviable.

Alors, comment construisons-nous une conversation qui favorise les idées de toute l'équipe ?
mais qualifiez ces idées comme une série d'hypothèses ? Dans les versions précédentes de ce
Nous partageons une série d'exercices de déclaration d'hypothèses. Ces processus ont
aidé les lecteurs et les professionnels à exprimer leurs idées d'une manière nouvelle,
comosuposiciones comprobables. Au fil des ans, nous avons consolidé ces
exercices de déclaration de suppositions, ainsi que les étapes dont vous aurez besoin pour prouver vos
supposés, dans un seul outil de facilitation que nous appelons Lean UX Canvas.
Le canevas Lean UX
Le Lean UX CanvasFigure 4-1) réunit une série d'exercices qui permettent aux équipes
déclarer ses hypothèses sur une initiative. Il est conçu pour faciliter les
conversations au sein de l'équipe, mais aussi avec les parties prenantes, les clients et
d'autres collègues. N'oubliez pas qu'en Lean UX, nous tentons de construire une compréhension.
partagé, et pour le faire (surtout quand nous essayons de nous éloigner de la
nous avons besoin d'un vocabulaire partagé cohérent qui permette aux parties
intéressées et aux collaborateurs individuels de partager leurs idées et de créer de la clarté.

Si vous avez déjà effectué un travail Lean UX, vous reconnaîtrez la plupart de cela.
activités. Si vous avez déjà effectué des travaux de conception, vous reconnaîtrez l'importance
de todos los temas del lienzo y lo importante que es tener conversaciones sobre estos
thèmes au début d'un projet. Notre expérience avec l'utilisation de ce canevas est que
la structure de la toile aide à garantir que toutes ces conversations aient lieu,
que les conversations incluent un ensemble divers de points de vue et que, lorsque
haya terminado, el equipo ampliado haya construido un entendimiento compartido y el
chemin à suivre. c'est clair.

Figure 4-1. Lelienzo Lean UX

Le canevas a été conçu pour guider la conversation à partir de l'état actuel de votre produit ou
système, ou ce que Mike Rother a appelé la condition actuelle (« MAINTENANT » dans leFigure
4-2)
dans son livre The Toyota Kata2, alétat futur désiré ou condition objectif ("PLUS
TARD
Figure 4-2. Les domaines clés du Lean UX Canvas
UNAUTRETOILE?

Un autre canevas ? Bonne question. Depuis lors, Alex Osterwalder et l'équipe de

Strategyzer a offert au monde le Business Model Canvas, qui nous a conquis et
finalement, il nous a inondés de toiles. S'il ne publie pas une toile, est-il vraiment un leader ?
intellectuel ? Encore une fois, question juste. Mais les toiles sont utiles et peuvent servir comme
le morceau central d'une collaboration d'équipe équilibrée et inclusive. S'il est utilisé
correctement, les toiles :

• Consolidez une série d'activités dans un processus séquentiel conçu pour

impulsar una narrativa .
• Aide dans des environnements complexes. Ils nous aident à créer un modèle visuel unique pour
representar elementos clave de esa complejidad.
• Sert d'outil de facilitation facile à suivre pour les équipes
intéressés à avoir un type spécifique de conversation.
• Nivelez le terrain de jeu pour les membres de l'équipe les moins aptes à offrir
ses idées lors d'une séance de brainstorming standard.
• Cree un idioma compartido para que lo use el equipo.
• Cadrer avec succès le travail que doit réaliser l'équipe.
• Communiquez le défi ou le travail que l'équipe réalise au-delà du
équipe.

En utilisant la toile
Dans les chapitres suivants, nous décrirons chaque section de la toile en détail. Cependant,
Avant de faire cela, nous voulons répondre à quelques questions générales qui se posent à chaque fois.
que nous enseignons aux équipes sur le canevas.
Alors, quand devrions-nous utiliser le canevas Lean UX ?

Creemos que el lienzo es una excelente manera de iniciar una iniciativa. Ya sea que esté
travaillant sur une nouvelle fonction, une initiative importante ou un nouveau produit, la toile
c'est une excellente structure à utiliser lors de votre réunion initiale. À mesure que vous vous sentez à l'aise
avec l'outil, vous commencerez à comprendre quand une pièce de travail est trop
petite pour la toile. En général, nous pensons que c'est une bonne idée de l'utiliser chaque fois que
il prévoit une grande quantité de travail.

Le canevas Lean UX est-il plus adapté aux idées initiales ou pour maintenir la
innovation ?

La toile fonctionne vraiment bien pour les deux types de travail. La question clé est la
suivant : fait-il face à des inconnues, de l'incertitude ou de la complexité ? C'est là
où Lean UX Canvas, et, vraiment, Lean UX en général, peut aider. Dans les premières
Étapes du travail, les énigmes tendent à être de nature existentielle : existe-t-il la
nécessité de ce produit ou service ? Les gens utiliseront-ils notre solution ? Pouvons-nous
construire une entreprise en résolvant ce problème ? Pour maintenir l'innovation, les
les questions tendent à être plus petites, mais cela ne signifie pas que les réponses le soient davantage
claires. Dans les deux situations, Lean UX Canvas peut aider.

Qui devrait travailler sur la toile ?

L'une des valeurs de la toile est la façon dont travailler à travers elle crée de la compréhension.
partagé au sein de son équipe. Encourage l'équipe et les parties prenantes à faire le travail
de découverte de produits qui les transforme en produits réussis. C'est pourquoi nous croyons
que tous les membres de l'équipe doivent participer au travail sur la toile. Aussi
nous pensons que les parties prenantes et les clients doivent participer autant que possible,
surtout durant les parties du travail pour élaborer la déclaration du problème
commercial et les objectifs commerciaux.

Combien de temps devrions-nous prévoir de passer sur une toile Lean UX ?

Il est difficile de tout surmonter en moins d'une demi-session. Parce que la toile est
une grande activité de démarrage, pensez à combien de temps vous consacrez normalement à démarrer
projets. Est-ce un exercice de deux jours ? Une semaine complète ? Certaines équipes
ils travailleront à travers la toile de cette manière, surtout s'ils peuvent être tous ensemble
dans la même pièce. D'autres équipes choisiront d'organiser une série de réunions dans le
le cours de quelques semaines. En général, plus quelque chose est grand et important,
proyecto, más tiempo llevará. No se quede atascado en la parálisis del análisis. Cuando
n'importe quoi, mettez-le dans le parking et continuez. Après tout, l'objectif du
Le toile est de rassembler les choses que l'on ne sait pas afin de pouvoir commencer à apprendre à leur sujet.
rapidement.

Devrons-nous utiliser la toile pour faire du Lean UX ?

Absolument pas. Chaque partie de la toile contient une partie utile du Processus Lean.
UX. Tout en travaillant sur une initiative, vous voudrez réfléchir et répondre aux questions
implicites dans chacun des cadres de la toile. Cela dit, vous pouvez utiliser absolument
chaque tableau sur la toile comme une technique indépendante. Vous n'êtes pas sûr de ce que sont vos
utilisateurs ? Allez au Cadre 3, lisez sur les proto-personas et utilisez ces idées avec votre équipe
para obtener claridad. ¿No tiene claro cuál es la mejor solución a un problema? Pase a la
section de ce livre sur le Encadré 5 et guidez votre équipe à travers ce processus.

Si vous décidez d'utiliser la toile dans son ensemble, rappelez-vous que c'est un outil flexible. Utilisez
les exercices qui fonctionneront le mieux pour vous, en tenant compte de votre contexte et des formes
en quoi cela fonctionne pour votre équipe. Augmentez le nombre d'activités au fur et à mesure que votre
l'équipe se sent plus à l'aise avec la nature de ce travail. En fin de compte,
nous voulons nous assurer que le client soit au premier plan et au centre de toutes vos
conversations. Le Lean UX Canvas est un bon point de départ pour garantir que cela
suceda.

Facilitant chaque section

Dans les chapitres suivants, nous partagerons les instructions des exercices que nous
aime utiliser pour compléter la toile. Ici, nous aimerions souligner certains motifs généraux.

Être inclusif

Nous voulons que toute l'équipe participe à la réalisation de la toile.3Cela signifie que votre
la facilitation doit tenir compte des différents styles de participation, ainsi que les
diferentes niveles de poder y autoridad en la sala.

Pour aborder cela, nous aimons utiliser une variante du modèle 1-2-4-Tous. 4 C'est une forme
structurée pour obtenir la participation d'un groupe. Voici comment cela fonctionne :

• Commencez par demander aux personnes de travailler individuellement (le "1")

généralement en silence, que ce soit en écrivant des idées ou en dessinant quelque chose par soi-même
En général, vous souhaitez établir une limite de temps agressive à cet égard.
période (généralement cinq minutes) pour obliger les gens à exprimer leurs
idées et éviter de passer trop de temps à éditer et à peaufiner. Après cette période
de travail en solo, demandez aux gens de partager avec leur table ou leur sous-groupe. Si
les personnes ont travaillé avec des Post-its, il peut être logique de leur demander de
les apportent à un mur et les publient là-bas. Optionnellement, vous pouvez proposer un débat
durante este período. También puede pedirle a la gente que haga un mapeo de
affinité à ce point.
• Ensuite, demandez aux personnes de travailler par paires (les "2") pour élaborer ou
développer une idée. Le travail en binômes prend plus de temps que le travail en
solitaire, donc donnez aux couples plus de temps que ce qu'ils ont eu pour travailler sur
solitaire. Encore une fois, après cette période de travail en binômes, les binômes
présentent leur travail à leur table ou salle de sous-groupes, et il se peut qu'il y en ait plus
discussion à ce stade.
• A continuación, il est demandé à chaque table ou sous-groupe de développer son travail dans une
seule présentation. (C'est la partie "4" du motif).
• Enfin (si vous essayez de produire une idée finale), demandez à tout le groupe
qu'il développe une seule idée. (C'est la partie "Tous" du modèle).

1-2-4-Tous est efficace car il sollicite l'avis de tous dans la salle, permet des styles de travail.
tant en solo qu'en collaboration et, enfin, permet au groupe de se rassembler. Vous voudrez
adapter ce modèle à l'exercice spécifique, mais tenez-en compte lors de la planification du travail
en groupe.

Remoto versus en personne

Tous ces exercices peuvent être réalisés sous forme d'ateliers en présentiel ou de manière
à distance, avec un logiciel de visioconférence et des outils de tableau partagé. Si vous êtes
travaillant à distance, n'oubliez pas d'interrompre vos séances pour permettre aux
les personnes se lèvent et évitent la fatigue de Zoom. De plus, rappelez-vous que tout le
le monde est familier avec les outils du tableau en ligne, donc laissez
un peu de temps pour mettre à jour les participants les moins expérimentés. (Parfois
vous pouvez utiliser un exercice pour briser la glace qui aide les gens à apprendre le
outil). Nous avons créé des modèles Lean UX Canvas que vous pouvez utiliser.

Terminer
Dans les prochains chapitres de cette section, nous décrirons chaque section de la toile dans
détail.

1Vogels, "L’histoire d’Apollon : le moteur de mise en œuvre d’Amazon".

2MikeRother, La méthode Toyota : Gestion des personnes pour s'améliorer, s'adapter et

obtenir des résultats supérieurs (McGraw-Hill Education, 2009).

3L'idéede « toute l'équipe » variera selon son contexte, alors n'hésitez pas à l'adapter.
ce conseil selon la taille de votre groupe et les rôles des personnes dans la salle.

4C'estc'est l'un des modèles de la très utile collection Liberating Structures. Consultez « 1-
2-4-Tout Libérateur Structures, consulté el 16 de juin de
2021[Link] .
Chapitre 5. Encadré 1 : Problème
entrepreneurial

Figure 5-1. Encadré 1 du canevas Lean UX : problème commercial

Pour que Lean UX réussisse, les équipes doivent avoir des problèmes à résoudre, pas
solutions pour construire. Souvent, ces "solutions" s'expriment sous forme d'exigences ou
spécifications des fonctions. Mais si les exigences sont le mauvais chemin, quel est
le bon chemin ? La bonne façon est de comprendre et d'exprimer le problème que les
parties prenantes ou les clients essaient de résoudre. C'est ce qu'ils font
les déclarations de problèmes commerciaux. Les déclarations de problèmes
les commerciaux repensent le travail d'une manière qui exige explicitement qu'il soit effectué à
j'ai terminé le travail de découverte de produits.

Bien qu'il existe une certaine flexibilité dans l'aspect qu'une déclaration peut avoir
problème d'entreprise, au moins devrait :

• Fournissez un défi spécifique à l'équipe à résoudre plutôt qu'un

ensemble de caractéristiques à mettre en œuvre.
• Ancrer l'équipe dans une perspective centrée sur le client pour que le succès du
le client soit une partie intégrante de l'objectif final.
• Concentrez l'effort de l'équipe en spécifiant des lignes directrices et des contraintes qui lui clarifient.
Au groupe, ce qui est dans le périmètre et ce qui est hors du périmètre.
• Fournir des mesures claires de succès exprimées sous forme d'indicateurs clés de
performance de l'entreprise (impacts souhaités) ou résultats spécifiques que la
l'entreprise veut voir dans son public cible.
• Ne pas définir une solution (c'est étonnamment plus difficile qu'il n'y paraît).

Fondamentalement, les déclarations de problèmes commerciaux contiennent trois parties :

[Link] objectifs actuels du produit ou du système dans lequel il se trouve

travaillant l'équipe. En d'autres termes, pourquoi a-t-il été créé en premier
 lugar? ¿Qué problema se diseñó originalmente para resolver? ¿Qué valor se
avait l'intention d'offrir ?
Que s'est-il passé dans le monde et comment cela a-t-il eu un impact négatif sur le
produit ? En d'autres termes, où sont les objectifs que nous nous sommes fixés pour
ce produit qui n'est pas en cours d'exécution maintenant ?
[Link] demande explicite d'amélioration du produit qui s'éloigne de la spécification
une solution qui quantifie l'« amélioration » en termes de résultats.

Lorsque vous créez des déclarations de problèmes commerciaux, souvenez-vous que votre Es
probablement que les efforts initiaux soient remplis de suppositions. Tu découvriras que cela va
à être vrai pour chaque partie du Lean UX Canvas. Cela va bien; en fait, c'est
inévitable. Tenez simplement compte que, au fur et à mesure que vous commencez à travailler sur le problème,
c'est-à-dire qu'au fur et à mesure qu'il commence à faire le travail de découverte, il peut découvrir
preuve qu'il travaille sur le mauvais problème ou s'adressant au public
incorrecte ou mesurant le succès dans le sens inverse. C'est bien. C'est pourquoi tu fais
découverte ! Assurez-vous simplement de transmettre cet apprentissage à l'équipe et aux parties.
intéressées dès que possible pour s'assurer de ne pas perdre de temps et d'efforts
dans une déclaration de problème non valide.

Faciliter l'exercice
Pour créer une déclaration de problème commercial, vous pouvez certainement
s'asseoir informellement avec les parties prenantes et les propriétaires de produits pour
rédiger un ensemble. Cela dit, nous aimons faire cela dans le cadre d'un atelier avec tout le
équipe. Si vous faites cela, nous vous recommandons d'utiliser le processus suivant.

Fournissez un contexte et des antécédents pour l'équipe. Cela incombe souvent au responsable.
de produit et il est fondamental de bien cadrer le travail. Les questions que
le responsable produit doit répondre à l'équipe avant d'écrire une déclaration de
problèmes commerciaux incluent :

• Qu'avons-nous observé et mesuré qui nous amène à croire qu'il y a un problème ?

• À qui nous adressons-nous avec ce travail ?
• Comment ce travail s'inscrit-il dans le programme de travail plus large que vous menez ?
la fin de l'entreprise ?
• Quel est l'impact de résoudre (et de ne pas résoudre) ce problème sur la santé de
l'entreprise?

Si vous avez un grand groupe, divisez-le en paires ou en trios et écrivez le premier brouillon de
énoncé du problème commercial en petits groupes. Les petits groupes peuvent
faire cela ensemble. Ne passez pas plus de 30 minutes sur ce premier brouillon.

Voici le modèle que nous utilisons pour rédiger de bonnes déclarations de problèmes
[Link] existants:

[Nuestro servicio / producto] fue diseñado para lograr [estos objetivos

commerciaux / du client et offrir cette valeur]. Nous avons observé [de ce
manière]que le produit / service ne répond pas à ces objectifs, ce qui est
causant [cet effet / problème adverse] dans notre entreprise.
Comment pourrions-nous améliorer le service / produit pour que nos clients en aient plus
succès selon ce qui est déterminé par [ces changements mesurables dans son comportement] ?

Si vous travaillez sur des initiatives complètement nouvelles, le modèle est comme suit :

L'état actuel de [le domaine sur lequel nous travaillons] s'est concentré
principalement dans [ces segments de clients, ces points faibles, ces
flux de travail, etc.

Ce que les produits / services existants ne parviennent pas à aborder est [ce fossé ou changement
sur le marché].

Notre produit / service abordera cette lacune par [cette stratégie ou approche]
de produit]

Notre approche initiale sera[ce segment d'audience].

Nous saurons que nous avons réussi lorsque nous verrons ces comportements mesurables dans
notre public cible

Une fois que les couples ou les trios auront complété leur premier brouillon, rejoignez-vous à nouveau comme
équipe et lisez vos brouillons les uns aux autres. Fournissez des critiques et des commentaires, et faites
questions clarificatrices sur chaque brouillon. N'oubliez pas que la critique n'est pas une attaque directe
à l'œuvre, mais plutôt une recherche clarificatrice pour mieux comprendre ce que
voulaient dire les auteurs.

Une fois que tout le monde a partagé son brouillon, combinez-les en plus grands groupes de
quatre à cinq membres de l'équipe et consolidez dans un brouillon de déclaration. Ensuite
de 30 minutes de consolidation de sous-groupes, partagez les brouillons révisés avec
l'équipe en général. Enfin, consacrez 30 minutes de plus à rassembler les brouillons dans une
déclaration de problème commercial de toute l'équipe. N'oubliez pas que c'est un exercice
de déclaration des hypothèses. Inévitablement, certaines de ces hypothèses seront
incorrectes, c'est pourquoi l'objectif du Cadre 1 n'est pas d'écrire l'énoncé parfait de
problème. L'objectif est de commencer à construire une alignement au sein de l'équipe sur
Vers où se dirige cette initiative et comment saura-t-il qu'il a atteint l'objectif.

N'oubliez pas que les déclarations de problèmes commerciaux portent finalement sur le
statut du projet, donc si les parties prenantes n'ont pas été impliquées, il devra
les incorporer à ce stade pour obtenir leur engagement.

Ajoutez le brouillon de la déclaration de problème complète à votre canevas.

Quelques exemples d'énoncés de

problèmes
Voici un exemple de ce à quoi ressemble une bonne déclaration de problème
entrepreneurial
Lorsque nous avons lancé nos solutions de prêts numériques pour les petites et moyennes entreprises
entreprises (PME), le marché consistait en des produits obsolètes vendus par
institutions bancaires héritées. Dans ce monde, nos solutions de prêts
les digitales se sont d'abord démarquées et ont attiré des clients PME qui cherchaient de nouvelles
formes de travailler avec votre banque. Étant donné que les banques traditionnelles fonctionnent de plus en plus
plus comme des entreprises "fintech", notre marché est devenu plus concurrentiel et hautement
compétitif. Cela provoque une augmentation des coûts d'acquisition de nos clients
augmentent, la part de marché stagne et les coûts de service à la clientèle
augmenter.

¿Cómo podríamos rediseñar nuestra línea de productos para pymes para que nuestros
les clients croient que nous sommes conçus exprès pour soutenir leurs entreprises modernes
y, à son tour, réduire nos coûts d'acquisition et augmenter notre part de
marché ?

Cet exemple est de niveau relativement élevé. Il est conçu pour aborder un problème à
niveau d'unité commerciale. Il est important que l'équipe qui travaille sur ce problème
aura la juridiction et l'influence pour affecter le travail à ce niveau. Écrire des déclarations
de problèmes commerciaux que les équipes ne peuvent pas résoudre car elles manquent du niveau
l'influence requise est de faire échouer l'équipe.

Voici un exemple d'une déclaration de problème commercial supplémentaire.

tactique qui peut être assignée à une équipe de niveau de fonction :

La fonction de récupération de mot de passe a été mise en place pour aider les clients à
revenir rapidement au produit en cas de perte ou d'expiration de la
mot de passe. De plus, ce service supplémentaire réduirait le nombre d'appels au
centre de service à la clientèle, réduisant notre nombre d'appels de support annuels généraux,
ya que las llamadas de restablecimiento de contraseña representan al menos el 35% de
les appels entrants.

Nous avons noté à travers des rapports analytiques et des commentaires d'études d'utilisabilité
consistants que nos clients luttent pour trouver la fonction de récupération de
mot de passe et, même lorsqu'ils le font, ils ne terminent pas le processus de réinitialisation par
eux-mêmes au moins 42 % du temps en raison de leur complexité. Cela provoque un
augmentation des coûts de support du centre d'appels de 12 % tout en
exacerbe l'insatisfaction du client avec notre produit, ce qui entraîne potentiellement
une augmentation de 0,7 % du taux d'abandon.

¿Cómo podríamos rediseñar la experiencia de recuperación de contraseñas para que

nos utilisateurs connaissent plus de succès selon les taux d'achèvement
du processus de 90% et la réduction de 50% des appels au service d'assistance à la clientèle
client concernant la réinitialisation des mots de passe ?

À quoi faire attention

Non spécifiez la [Link] ejercicioAl s'appeler déclaration
deproblemaempresarial, nous voyons souvent des équipes qui intègrent des solutions dans la
déclaration. Cela se manifeste souvent dans la partie « comment nous pourrions » de la déclaration
Comment pourrions-nous mettre en œuvre une application mobile qui résolve cela ?
... Les solutions ne devraient absolument pas être dans cet exercice. Nous réservons cela
conversación para el recuadro 5.

Obtenez le niveau correct. Nous avons précédemment mentionné "niveler" l'énoncé du

problème correctement, mais il vaut la peine de répéter que qu'ils écrivent leurs
propres énoncés du problème ensemble en tant qu'équipe ou si quelqu'un les écrit par
vous, votre équipe ne doit s'inscrire que pour une déclaration de problème qui soit capable de
faire. résolvant. Si le problème est encadré à un niveau trop élevé, l'équipe ne
pourra résoudre le problème tout seul. Cela conduira à la frustration, pas seulement avec et
à l'intérieur de l'équipe, mais avec le processus général de Lean UX en lui-même.

Se especí[Link] antipatrón común es la falta de especificidad en la declaración. En

À des occasions, les équipes laisseront des métriques explicites ou des preuves en dehors de l'énoncé du
problème. Les détails sont importants pour encadrer l'importance du problème, ainsi
comme pour établir des critères clairs de succès au niveau de l'entreprise pour l'équipe. En cas
Sans aucun doute, insistez toujours pour que la déclaration soit précise.

Enfin, la spécificité est importante non seulement pour les métriques, mais aussi pour le
zone de produit abordée. Les équipes utiliseront des phrases telles que "interface utilisateur"
"intuitive" ou "grande expérience utilisateur" pour décrire le travail qui a été réalisé ou qui est
attendre qu'il se réalise. Dans tous les cas, des phrases comme celles-ci décrivent des caractéristiques
(bien qu'en abstrait) que, en général, devraient être laissés en dehors des énoncés du
problème.

Voici deux exemples de phrases comme celles-ci dans des déclarations de problèmes commerciaux
et comment les corriger :

Lorsque nous avons décidé d'améliorer notre expérience d'achat, nous avons mis en œuvre une
interface utilisateur intuitive pour augmenter la valeur moyenne des commandes.

Dans cet exemple, il n'est pas clair ce qui a été mis en œuvre, donc l'équipe ne sait pas
réellement quelles parties de l'interface utilisateur doivent potentiellement pointer
pour s'améliorer.

Dans l'exemple suivant, la phrase ambiguë se termine par la partie "comment nous pourrions" qui
semble suffisamment bénigne mais qui met déjà l'équipe en direction d'une solution spécifique
avant que le travail de découverte ait été effectué :

Comment pourrions-nous créer une interface utilisateur plus intuitive pour que les clients
ajoutez plus d'articles à votre panier lors de chaque visite ?

Vous pouvez voir ici que le cadrage du travail indique à l'équipe de ne chercher que les améliorations
de l'interface utilisateur au lieu de chercher la cause profonde de la diminution des valeurs
moyenne des commandes.

Et si cela peut servir à quelque chose, tout le monde s'efforce d'offrir des interfaces utilisateur intuitives. Personne
ne dit jamais : "Nous allons offrir une interface utilisateur de mauvaise qualité pour la plateforme de
commerce électronique
Chapitre 6. Encadré 2 : Résultats
commerciaux

Figura 6-1. Recuadro 2 del lienzo Lean UX: resultados empresariales

Nous couvrons le concept de résultats dans le Chapitre 3. La boîte 2 est là où ils font leur première
apparition dans Lean UX Canvas. Une fois que vous aurez une déclaration du problème commercial,
voudra approfondir les changements de comportement de base qu'il recherche comme partie de
l'initiative. Normalement, les critères de succès dans une déclaration de problème sont de
haut niveau. Les critères de succès ont tendance à être des indicateurs clés de performance ou des métriques
d'impact, les choses que l'on trouve dans les tableaux de bord exécutifs. Celles-ci pourraient
être des indicateurs tels que les revenus, les bénéfices, le coût des biens vendus et la satisfaction du
client. Ce sont des outils utiles pour mesurer la santé de l'entreprise, mais les équipes de niveau de
la fonction doit travailler à un niveau inférieur.

Dans cet exercice, nous travaillons ensemble pour découvrir les principaux indicateurs de ceux-ci.
métriques d'impact. La question à laquelle nous essayons de répondre est : que fera la
les gens différemment si nos solutions fonctionnent ? Si nous choisissons le
combinaison correcte de code, copie et design, que espérons-nous qu'il se passe?Les
les réponses à ces questions sont celles que nous recherchons dans cet exercice de déclaration de
hypothèses.

Chaque option dans ce brainstorming doit commencer par un verbe, et chaque réponse doit
être quelque chose de précieux que les clients font déjà dans le système, quelque chose qui n'est pas précieux et qui nous
j'aimerais qu'ils fassent moins, ou quelque chose de nouveau que nous pensons sera précieux. et que nous
j'aimerais qu'ils commencent à le faire. En essence, nous réfléchissons et mettons en avant les voyages.
des utilisateurs.

Utilisation du parcours utilisateur

L'objectif de cet exercice est de trouver les comportements précieux des clients
que je veux me concentrer. Pour cela, il est utile de commencer par un modèle de comportement
del cliente: ¿qué está haciendo la gente hoy? ¿Qué están tratando de hacer que sea
difícil? ¿Qué están haciendo hoy que no sea productivo para ellos o para nosotros? ¿Qué
Quels nouveaux comportements précieux pouvons-nous débloquer ? Pour répondre à cela
question, pouvons-nous utiliser l'idée des voyages des utilisateurs.

Le mappage du parcours utilisateur peut être très simple. Nous pouvons utiliser un modèle, comme
Métriques de pirate ou Montagne des métriques (toutes deux décrites ci-dessous). Ou nous pouvons utiliser
outils que nous avons empruntés au Service Design pour créer une carte du voyage de
utilisateur. Indépendamment du cadre que nous choisissons, l'idée est de rassembler l'équipe et les
parties prenantes autour de la carte et générer une compréhension partagée du voyage de
comment les personnes se déplacent à travers notre système et quelles parties de ce voyage doivent
être le centre de notre travail.

Selon vos circonstances, voici quelques modèles pour commencer.

Tipo de viaje del usuario: métricas piratas

Une façon de générer des métriques de résultats est d'utiliser les Pirate Metrics. Conçu dans le
l'incubateur de startups 500 Startups, l'entonnoir des Pirate Metrics est devenu une
forme standard de penser au parcours de l'utilisateur à travers nos
produits. Nous pouvons l'utiliser ici pour nous aider à déterminer quelles parties de ce voyage sont
pertinents pour le problème que nous abordons.

Les métriques pirates se composent de cinq types de comportements des clients :

Acquisition

Ce sont les activités qui amènent les clients au produit en premier lieu. Les
Les options viables ici incluent le nombre de téléchargements, les visites sur la page d'inscription,
nombre d'enregistrements, etc.

Activation

Une fois qu'un client a été acquis, nous pouvons commencer à mesurer s'il est vraiment
usando el producto. Las métricas de activación incluyen cosas como la cantidad de
cuentas creadas, la cantidad de personas seguidas, el porcentaje de nuevos registros
que ont effectué un achat, etc. Ces métriques doivent refléter la fonctionnalité principale
du produit.

Rétention

Si nous pouvons amener les clients à essayer le produit, le prochain défi est d'arriver à
qu'il continue à l'utiliser régulièrement. Dans ce cas, la 'base régulière' sera contextuelle
pour votre produit. (Pour un produit comme Netflix, vous mesureriez les habitudes de visionnage.
journaux, mais si vous créez un thermostat intelligent à "apprentissage", il est probable que
vous mesureriez combien d'interactions l'utilisateur a eues avec l'appareil). Si nous retenons
Les clients, en termes généraux, reviennent souvent pour utiliser le produit, ils sont
faisant plus sur le produit et ils passent aussi du temps.

Revenus
 Si nous leur avons fait parvenir le produit, nous les avons convaincus de l'essayer, et maintenant
ils l'utilisent régulièrement, nous paient-ils ? C'est le niveau suivant de
engagement que nous recherchons chez nos clients. Notre objectif est de voir où et comment
Nous transformons les clients en utilisateurs payants et comment ces modèles évoluent
avec le temps. Les métriques à considérer ici incluent le pourcentage d'utilisateurs payants
versus gratuits, la valeur moyenne de vie de chaque client, etc.

Remise

Le dernier pas dans l'entonnoir des métriques pirates est d'évaluer si nos clients sont
en se référant à d'autres au produit. S'ils l'aiment vraiment, ils ont l'impression d'en obtenir de la valeur
de lui et ils ne peuvent pas vivre sans lui, ils le diront à leurs amis ou sur Internet à travers de
avis. C'est le meilleur type de marketing que vous puissiez obtenir. Les métriques pour
rastrear ici inclut le pourcentage de nouveaux utilisateurs qui sont arrivés par
références, le pourcentage d'utilisateurs actuels qui référencent d'autres et le coût de
acquisition par un nouvel utilisateur.

À ce stade, vous avez probablement remarqué que l'acronyme de cette méthode épelle
AARRR, ce qui est, apparemment, comment parlent les pirates, d'où le nom Pirate
Métriques. Nous pouvons affirmer avec certitude qu'aucun des deux n'a jamais rencontré un
pirata y, por lo tanto, no podemos confirmar que se trate de un lenguaje pirata.

Tipo de viaje del usuario: Metrics Mountain

L'une des choses qui nous a dérangés pendant un certain temps au sujet de Pirate Metrics est
sa visualisation comme un entonnoir. Dans le monde réel, tout ce que vous mettez dans un entonnoir
sors de cet entonnoir. Cela prend un peu plus de temps, mais l'idée que parte du liquide (par
l'exemple) que vous versez par le haut de l'entonnoir ne sorte pas par le bas est
ridicule. Bien sûr qu'il le fera. Il y a un trou à l'autre extrémité ! Il devait y avoir
une meilleure métaphore.

Au lieu d'un entonnoir, nous présentons Metrics Mountain (Figure 6-2).

Figure 6-2. Montagne métrique. Concept de Jeff Patton et Jeff Gothelf.

L'idée d'une montagne pour visualiser le cycle de vie du client a beaucoup de sens
car nous avons pour objectif d'amener le plus grand nombre de nos clients au sommet de la
montagne. Toutefois, de manière réaliste, nous allons perdre des gens en chemin. Se
ils se fatigueront. Ils s'ennuieront. Ils se distraire. Ils déserteront un concurrent. Ce n'est pas tout.
réussiront (c'est-à-dire, là où se brise la métaphore de l'entonnoir).

À mesure que vos clients montent en flèche sur la montagne des métriques, on leur demande de faire plus et
plus avec son produit ou service (la montée devient plus difficile). Son objectif est de faire
que le processus soit aussi facile que possible et les motiver à poursuivre. Certains d'entre eux
ils feront cela, surtout s'ils ont une proposition de valeur, une expérience utilisateur et un
modèles commerciaux convaincants. Mais de plus en plus, à mesure que vos clients montent la
montagne, ils vont descendre. Notre objectif doit être de construire le type d'expériences qui
ils mènent le plus grand pourcentage de personnes au sommet de la montagne.

Faciliter la conversation sur les résultats commerciaux avec Metrics Mountain

Vous pouvez utiliser la métaphore de la montagne pour faciliter la conversation avec votre équipe et les
parties prenantes concernant les comportements que vous pensez que vos utilisateurs devraient avoir
progresant à mesure qu'ils utilisent leur produit. Voici comment faire :

1. Commencez à la base et identifiez ce que doit faire un utilisateur pour

commencer à utiliser votre produit. Comment les acquérez-vous ? Comment trouvent-ils le nouveau
fonction sur laquelle vous travaillez?
2. Définissez un "plateau" dans la montagne pour chaque étape ultérieure du parcours.
client et déterminez le comportement de l'utilisateur nécessaire pour y parvenir.
3. Quel pourcentage d'utilisateurs grimpant la montagne son équipe considère-t-elle comme réussi ?
Chaque étape ? Ajoutez ces numéros au diagramme de la montagne.
1. Par exemple, sur 100 % de ses visiteurs quotidiens, il aimerait voir au moins
75% découvrir la nouvelle fonction qu'il est en train de créer, et 50% de cela
gente la prueba. À partir de là, il aimerait voir au moins 25 % des
qui ont tenté de continuer à utiliser la fonction chaque semaine, et 10 % d'entre eux
Enfin, il vous paiera pour cette nouvelle capacité.
4. Si vous n'êtes pas sûr du parcours exact de votre client, commencez par Pirate
Des métriques comme les cinq « étagères » de la montagne. C'est une bonne façon de
commencer cet exercice.

Type de voyage de l'utilisateur : voyages de service et cartes d'histoires de l'utilisateur

Parfois, visualiser le parcours de l'utilisateur comme un entonnoir ou une montagne n'a pas
sentido. Connaissez bien votre produit et il est possible que ces modèles ne s'appliquent pas dans votre
cas. Ne le forcez pas. À la place, vous pouvez créer une carte de voyage de service ou une carte de
histoires d'utilisateur qui cartographient plus étroitement la façon dont un utilisateur se déplace à travers
de votre produit ou service. Le formulaire n'est pas vraiment important ici : utilisez le
método que tenga sentido para usted y su producto. El objetivo es poder visualizar el flujo
à travers le produit d'une manière que tout le monde puisse voir et comprendre, puis utiliser cela
modèle pour s'approcher des parties les plus importantes du voyage, identifier les
comportements spécifiques cruciaux pour le succès de votre initiative et déterminer les
métriques de résultats qui indiqueraient le succès de ce voyage.
Cartographie des résultats à l'impact
Le mappage de résultats à impact est une autre technique pour visualiser la connexion entre les
métriques d'impact dans la déclaration de votre problème commercial et les résultats tactiques
que vous espérez voir chez vos clients. Cela fonctionne bien avec votre équipe de niveau fonctionnel et aussi
C'est un exercice puissant à faire avec vos parties prenantes.

Cet exercice visualise également le concept des indicateurs avancés et

rezagados. Vous découvrirez que les métriques d'impact sont plus souvent des indicateurs
rezagados : mesures rétrospectives de ce qui s'est déjà passé. Au fur et à mesure que cela progresse
exercice, vous trouverez de nombreuses métriques de niveau inférieur, les résultats, à être
indicateurs avancés. Ces comportements sont souvent les choses qui doivent se produire
avant que nous puissions atteindre la métrique d'impact. Par exemple, un client doit d'abord
téléchargez notre application avant de pouvoir dépenser de l'argent pour notre service. Le premier
c'est un indicateur avancé du second. Ce que les équipes trouvent souvent, c'est que
Il existe de nombreux indicateurs principaux pour une ou deux métriques d'impact. Cet exercice
aide à éclaircir ce fait et oblige à une conversation (espérons-le) productive
sur la priorisation.

Voici comment cela fonctionne :

1. Rassemblez l'équipe et les clients potentiels dans une salle de réunion.

2. Sur un tableau, demandez à la personne la mieux payée de la salle d'écrire l'objectif
stratégique actuel pour l'année en haut d'une série de notes autocollantes.
3. Debajo de eso, pídale a esa misma persona (u otro ejecutivo) que enumere las
medidas de éxito para esa estrategia (pista: estas deben ser métricas de impacto y,
souvent, ce sont des indicateurs retardés).
4. Sous chaque métrique d'impact, commencez à dessiner des lignes qui dépassent de
chacune (comme si j'étais en train de construire un organigramme).
5. Demandez à la salle de compléter la ligne sous les métriques d'impact avec les
comportements des clients qui impulsent ces métriques (indicateurs)
principales). Utilisez des Post-it et faites en sorte que tout le monde travaille individuellement sur une
brainstorming initial.
6. Maintenant, faites en sorte que l'équipe fasse une autre ligne en dessous de la dernière qui montre les
comportements des clients qui stimulent l'ensemble initial des résultats.

À ce stade, votre tableau devrait commencer à ressembler à la carte montrée dans

laFigure 6-3:
Figure 6-3. Cartographie du résultat à impact

Une fois que tout le monde a contribué, vous devriez avoir des dizaines de Post-it sur le tableau qui
indique une variété de comportements des clients (résultats) qui aideront à votre
entreprise à atteindre son objectif stratégique et ses objectifs d'impact. Aussi dans ce
point, your team may be overwhelmed. Most of the times we have done this
ejercicio, al equipo nunca se le ocurre que hay tantas formas de impulsar un cambio
positif.

Maintenant, la partie difficile. À travers un tour de vote ponctuel (ou un autre exercice de
sélection facilitée), demandez à l'équipe de choisir les 10 résultats en lesquels ils croient que
devraient d'abord se concentrer.

Ce que vous avez fait ici, c'est créer un lien direct entre les résultats (comportements
du client) et les métriques d'impact (ce qui importe aux dirigeants) et les a obligés à
choisir où il faudrait se concentrer pour le prochain cycle. La dernière étape consiste à créer une ligne
de base pour chacun de ces résultats (c'est-à-dire, où ils en sont aujourd'hui) et un objectif (c'est-à-dire,
où nous aimerions qu'ils soient à la fin du cycle) et les assigner à l'équipe comme objectifs.
pour leur prochain cycle.

Maintenant, chaque fois qu'une équipe rend compte de l'avancement de son résultat spécifique, ses
les parties prenantes auront une idée claire de pourquoi l'équipe travaille là-dessus
ycómoafecta les métriques d'impact qui comptent le plus pour eux.

De quoi être attentif

Aucun nombre ou pourcentage n'est une métrique de résultat. Jeff travaillait avec un
grand conglomérat de distribution allemand dans cet exercice spécifique. Son objectif de niveau de
L'impact était d'augmenter les ventes dans le même magasin d'année en année. Pendant que nous travaillions
dans l'exercice de cartographie des résultats à l'impact, certains membres de l'équipe ont ajouté
éléments aux lignes de résultats qui disaient "pourcentage de produits sur l'étagère que
son de notre marque". Maintenant, techniquement, il s'agit d'une métrique, mais ce n'est pas une mesure
du comportement du client. C'est une décision de stratégie de produit qui espère que
impulse le comportement du client. Un problème similaire est survenu une fois avec un autre
client qui était en train de construire un outil d'automatisation. Une personne du
équipe a énuméré le "pourcentage de tâches manuelles maintenant automatisées par le
système". Encore une fois, ce n'est pas une mesure du comportement du client. C'est une
facette du système en cours de construction, une décision de produit. L'objectif final
l'objectif était de réduire le temps consacré par le personnel aux tâches répétitives, ce qui est une
bonne métrique de résultats.

L'autre chose que nous avons souvent constatée, c'est que ces graphiques deviennent encombrés. C'est
facile de les rendre beaux dans un livre ou sur une diapositive PowerPoint. En réalité,
nos activités ne sont pas si linéaires et ces graphiques peuvent devenir un peu difficiles
de conduireFigura 6-4 Les équipes découvriront souvent qu'un résultat génère
múltiples métricas de impacto (esto es perfectamente razonable) y debe duplicarse en
tout le graphique. Créez le graphique qui fonctionne pour votre entreprise et votre équipe. Simplement
ne compromettez pas le contenu de l'exercice.
Figure 6-4. Exemple du monde réel d'une carte des résultats à l'impact, avec l'aimable autorisation de Delphine Sassi
et l'équipe de King
 Chapitre 7. Encadré 3 : Utilisateurs

Figure 7-1. Encadré 3 du Lean UX Canvas : Utilisateurs

Les designers ont longtemps été des défenseurs de l'utilisateur final. Lean UX
ne change pas ça. À mesure que nous faisons des suppositions sur notre entreprise et les
résultats que nous aimerions atteindre, nous devons encore garder l'utilisateur au devant et au centre
de notre pensée. Le cadre 3 de la toile initie une conversation plus profonde
sur notre public cible.

La plupart d'entre nous avons appris à penser à une personne comme à un outil pour
représenter ce que nous avons appris dans notre recherche. Et il arrivait souvent que le cas de
que nous créons des personnes comme résultat d'études de recherche longues et coûteuses. Il y a
certains problèmes avec les personnes qui se créent de cette manière.

D'abord, nous avons tendance à les considérer comme intouchables en raison de tout le travail qui a été accompli.
pour les créer. De plus, il arrive souvent que ces personnes aient été créées par une équipe
de recherche ou un fournisseur externe. Cela crée un écart de connaissance
risque entre les personnes qui ont mené l'enquête et celles qui utilisent les
personas.

En Lean UX, nous modifions l'ordre des opérations dans le processus de persona. Également
nous avons changé la création de personas d'une activité unique à un processus continu, un
qui a lieu chaque fois que nous apprenons quelque chose de nouveau sur nos utilisateurs.

En créant des personas dans cette approche, nous commençons par des hypothèses puis nous recherchons pour
valider notre hypothèse. Au lieu de passer des mois sur le terrain à interviewer des gens,
nous avons passé quelques heures à créer des proto-personas. Les proto-personas sont notre meilleure conjecture
sur qui utilise (ou utilisera) notre produit et pourquoi. Nous les avons esquissés sur papier
avec la contribution de toute l'équipe ; nous voulons capturer les hypothèses de
tous. Puis, au fur et à mesure que nous effectuons une recherche en cours, nous découvrons
rapidement à quel point nos conjectures initiales sont précises et nous ajustons nos personnes
en réponse.

En plus de mettre le client au premier plan au centre d'une équipe de développement de produits
Diversifié, les proto-personas servent à deux autres objectifs clés.

Compréhension partagée

Imaginez votre équipe assise autour d'une table et quelqu'un dit le mot
«chien». Quelle image vous vient à l'esprit ? Est-ce la même image qui leur vient à
la mente à ses collègues (Figure 7-2) ? Comment le sais-tu ?

Figure 7-2. Chiens. Nous sommes redevables à notre érudit collègue Adrian Howard pour cela.
concept
Il en va de même lorsque quelqu'un dit "l'utilisateur". L'approche de la proto-persona assure
que tout le monde ait la même image en tête quand on évoque l'"utilisateur".
En se rappelant que nous ne sommes pas l'utilisateur

Il est souvent facile de supposer que nos utilisateurs sont comme nous, surtout si
nous consommons les produits que nous fabriquons. La réalité est que nous avons un niveau de
compréhension et tolérance pour la technologie que nos clients raremment
partagent. Passer par un exercice de protopersona met l'accent sur les utilisateurs
externes, éloignant l'équipe de ses préférences personnelles pour le produit.
UTILISATIONDESPROTO-PERSONAS

Une équipe avec laquelle nous travaillions à New York était en train de créer une application
quemejoró l'expérience de l'Agriculture Soutenue par la Communauté (ASC) pour les
résidents de la ville de New York. CSA est un programme qui permet aux résidents
de la ville rassembler son argent et acheter des produits agricoles d'une valeur d'une saison
complète d'un agriculteur local. L'agriculteur livre ensuite les récoltes chaque semaine à
les membres de la CSA. Beaucoup d'abonnés de la CSA sont des personnes âgées de 20 à 30 ans.
des années à jongler entre une vie professionnelle chargée, une vie sociale
activa et le désir de participer à la CSA.

L'équipe a supposé que la majorité des consommateurs de CSA étaient des femmes qui leur
Aimait cuisiner. Environ une heure s'est écoulée à créer une personne appelée
Susan. Mais quand ils sont sortis sur le terrain pour enquêter avec de jeunes professionnels de 20
Années, ils se rendirent rapidement compte que l'immense majorité des cuisiniers et, par conséquent
tant, les utilisateurs possibles de son application étaient des jeunes hommes. Ils sont revenus à la
bureau et ont examiné sa personnalité pour créer Anthony.
Anthony demostró ser un usuario objetivo mucho más preciso. El equipo no había perdido
plus de temps à peaufiner des idées pour le mauvais public. Maintenant, ils étaient concentrés sur un
audience qui, bien qu'elle n'était pas encore parfaite, était beaucoup plus correcte que ses
suppositions initiales.

Le modèle Proto-Persona
Nous aimons dessiner des protopersonas sur papier en utilisant des tressections (Figure 7-3 ). Le
le quadrant supérieur gauche contient un croquis de la personne avec un nom et
fonction. Le tableau supérieur droit contient des informations démographiques, psychographiques et de
comportamiento básica. Un antipatrón de las personas que vemos es un énfasis excesivo
en la demografía. Para el diseño de productos, nos preocupamos menos por la demografía
et plus en fonction des besoins, des objectifs et des comportements. Par conséquent, lorsque vous pensez à
données démographiques, essayez de vous concentrer sur les informations qui prédisent un type spécifique de
comportement : comportement pertinent pour notre produit ou service. Par
par exemple, il peut y avoir des cas où l'âge de la personne est totalement irrélévant,
tandis que son accès à un dispositif spécifique, comme un iPhone, changera par
complétez la façon dont il interagit avec son produit. Nous voulons seulement annoter les
des différences qui font la différence
Figure 7-3. Un modèle de proto-persona complété

La moitié inférieure de la proto-persona est l'endroit où nous plaçons les détails les plus
importantes. Ici, nous capturons les objectifs, les besoins, les résultats souhaités et
les obstacles qui les empêchent d'atteindre ces besoins. N'oubliez pas que les utilisateurs sont rarement
ils ont besoin de "fonctions". Ce dont ils ont besoin, c'est d'atteindre un certain type d'objectif. (Non
c'est toujours un objectif concret : parfois c'est un objectif émotionnel, un désir non articulé,
etc.) C'est notre travail de décider de la meilleure façon de les amener à leurs objectifs.
Faciliter l'exercice
Une fois de plus, nous aimons commencer le processus de création de personas par un brainstorming.
ideas:

1. Los miembros del equipo comienzan ofreciendo sus opiniones sobre a quién
le projet devrait être dirigé et comment cela affecterait son utilisation du produit.
2. L'équipe crée une liste de types de personnes.

Par exemple, cette liste pourrait contenir des segments cibles tels que "étudiants".
["universitaires","enthousiastes du streaming","travailleurs médicaux de première ligne"]
ligne", etc.

3. Réduisez les idées à un ensemble initial de trois ou quatre personnes que l'équipe
crea que ont plus de chances d'être votre public cible.
4. Essayez de différencier les personnes en fonction des besoins et des rôles dans
lieu de l'information démographique.
5. Une fois que vous avez réduit la liste des utilisateurs potentiels, faites en sorte que l'équipe
complétez un modèle de protopersona pour chacun.

Vous pouvez vous diviser en petits groupes et faire en sorte que chaque groupe se concentre sur un
persona, puis amenez-les au groupe pour qu'ils les examinent.

6. Examinez chaque personnage en fonction des commentaires.

Une fois que vous avez un groupe de personnes avec lesquelles vous êtes d'accord, partagez-les avec
sus collègues au-delà de l'équipe pour obtenir leurs commentaires.

Validation anticipée

En este punto del proceso, puede comenzar a validar algunos de sus

premiers postulats. En fait, avant d'approfondir trop la déclaration de
suppositions, c'est un bon endroit pour commencer à tester certaines de celles-ci
Hypothèses. Utilisez vos personnages comme cibles de recrutement pour commencer votre
enquête.

Immédiatement, il y a trois choses que vous pouvez déterminer en fonction de vos proto-personas :

Le client existe-t-il ?

En embauchant les personnes qu'il a créées, vous pouvez rapidement déterminer à quel point c'est réaliste
ce sont les hypothèses de son équipe. S'il ne peut pas trouver les personnes qu'il a dessinées,
il se peut qu'ils n'existent pas. Apprenez de cela et modifiez vos personnages.

Ont-ils les besoins et les obstacles que vous pensez qu'ils ont ?

En d'autres termes, résolvons-nous des problèmes réels ? Vous pouvez mesurer cela.
simplemente observando y hablando con las personas que recluta. Si estas
les conversations et les observations ne confirment pas le problème, alors cela crée
solutions pour des problèmes qui n'existent pas, et cela finit rarement bien.
Valoriseraient-ils une solution à ce problème ?

Le fait qu'un client soit réel et qu'il ait les points faibles qu'il résout, ne
cela signifie qu'il va évaluer une nouvelle façon de résoudre ce problème. En d'autres termes, seulement
Pourquoi ils mangent des bananes dans leur céréales tous les jours et n'aiment pas couper des bananes, non
significa que comprarán su cortadora de bananas ( Figure 7-4 ). Il est important
comprendre comment vos clients satisfont actuellement ces besoins et ce
quelles sont les probabilités que votre idée remplace la solution existante. Si vous essayez de
déplacer des outils de longue date comme le courrier électronique ou les feuilles de calcul,
Il est possible que vous soyez dans une dure bataille. C'est bien d'obtenir cette information.
tôt que tard.

Figure 7-4. Le coupe-banane. Qui achète ça ?

Une fois, nous avons travaillé avec une startup qui répondait aux besoins des investisseurs providentiels.
par la création d'un dépôt en ligne pour tout ce qui concerne ses
investissements. C'était un produit robuste qui promettait d'accélérer et de simplifier la vie de ces
utilisateurs. En rejoignant le projet, nous avons travaillé avec l'équipe pour construire des proto-personas
et nous nous sommes fixés comme objectif de trouver le public cible. Il s'avère que cela n'a pas été un défi dans
absolu. Aux États-Unis, du moins, il y a beaucoup de gens qui se qualifient comme
investisseurs anges (c'est-à-dire qu'ils disposent de 50 à 100 mille dollars supplémentaires pour
invertir). La personne existe !

Ensuite, nous avons commencé à parler avec ces personnes pour comprendre si elles
nous résolvions un problème réel. Il s'avère que, oui, en effet, le suivi de
présentations, feuilles de termes, tableaux de limites et les informations du tour de
Le suivi a été fastidieux pour ce public. Le problème existe ! Cela se passait
devenant excitant.

Enfin, l'équipe a commencé à percevoir une tendance lorsque la conversation s'est centrée
en solutions numériques pour ce problème. L'immense majorité de notre public
objectif, quelque chose de proche de 95%, a investi une ou deux fois par an au maximum. Pour un ou
dos inversiones por año, el correo electrónico y Microsoft Excel funcionaron
Bien. Notre audience était intimement familiarisée avec ces outils, et
aucune quantité de solidité, de complexité ou même de facilité d'utilisation de notre
un outil de gestion d'investissements en ligne ferait que notre audience abandonne le
e-mail et Excel en faveur de notre produit. L'outil que nous étions
construire était destiné à 5% des investisseurs pour qui c'était une profession, une
population trop petite pour justifier l'effort qui y était consacré
produit qui était en cours de construction. C'était une conversation difficile à avoir dans le
bureau, comme tu peux l'imaginer. Le fait que la personne existe et qu'elle soit en train de résoudre un
Un problème réel ne signifie pas toujours qu'ils apprécieront la solution que vous construisez. C'est
mieux vaut le découvrir maintenant, dans la Boîte 3 du Lean UX Canvas, que lorsqu'il a commencé
à envoyer le code en production.

À quoi faire attention

Beaucoup d'équipes avec lesquelles nous avons travaillé et dont nous avons entendu parler au cours de
les années exécutent cet exercice de proto-persona ; cependant, beaucoup moins d'entre eux
Ils reviennent vraiment et ajustent leur pensée après l'exercice de création initial.
il est important que vous considériez les proto-personas comme des documents vivants. Chaque fois que
réalisez des conversations avec des clients ou des études d'utilisabilité, demandez-vous combien de
les croyances actuelles de l'équipe sur son public cible restent vraies. Au fur et à mesure
que se révèle de nouvelles informations, mettez-les en discussion et ajustez les personnes pour que les
les efforts de recherche futurs peuvent être plus spécifiques et réussis.
Chapitre 8. Encadré 4 : Résultats et
avantages de l'utilisateur

Figure 8-1. Encadré 4 du Lean UX Canvas : Résultats et avantages pour l'utilisateur

Malgré la prolifération de techniques agiles telles que les histoires d'utilisateur, l'utilisateur et
Les objectifs se perdent souvent dans de longs débats sur les caractéristiques,
conceptions et mises en œuvre techniques. L'empathie est au cœur de l'excellence
produits et services. Les designers ont souvent été responsables de défendre le
utilisateur d'un point de vue empathique. Comme nous le savons maintenant, ce n'est pas
responsabilité exclusive du designer. Pour parvenir à une compréhension partagée plus
une compréhension plus large des utilisateurs et un sens plus profond de l'empathie pour ce qu'ils essaient de
réussir, nous demandons à nos équipes de déclarer leurs hypothèses sur ce que les
les utilisateurs essaient de faire, sous forme de résultats et d'avantages pour les utilisateurs.

Avant de commencer avec le cadre 4, il se peut que vous vous demandiez : Quelle est la
différence entre les résultats commerciaux, les résultats du client et les résultats du
utilisateur ? Bonne question. Jetons un coup d'œil à un exemple dans lequel vous travaillez pour une
entreprise qui fabrique des logiciels de suivi des dépenses d'entreprise.

Le résultat commercial que l'entreprise essaie d'atteindre est d'acquérir plus de clients.
retenir ceux qui ont déjà et augmenter les revenus mensuels par abonnement de logiciel.

Les clients de cette entreprise, d'autres entreprises qui achètent le logiciel de suivi de
dépenses pour leurs employés, ils essaient d'améliorer l'efficacité de leurs équipes de
comptabilité, réduire le paiement des dépenses non remboursables et réduire les coûts
opérations générales.
Les utilisateurs du logiciel sont les employés de ces entreprises clientes. Leur objectif
Souhaité est d'obtenir le remboursement de vos dépenses le plus rapidement possible et de réduire le temps
que les amène à saisir ces dépenses correctement.

Tous ces résultats sont basés sur le comportement, mais chacun a

son propre point de vue. En d'autres termes, ils font référence aux différents objectifs qui
ils poursuivent les différents groupes de personnes.

En plus du changement de comportement, il existe des objectifs émotionnels tant au niveau du

client comme de l'utilisateur. Les acheteurs de ce logiciel veulent sentir qu'ils sont
aidant l'entreprise à avoir plus de succès et de rentabilité. Ils veulent bien paraître devant leurs supérieurs
et veulent pouvoir indiquer leurs contributions spécifiques au succès de l'entreprise. Cela les
motivait à rechercher une marque de logiciel de suivi des dépenses qui leur permettrait
le faire facilement.

Les utilisateurs du logiciel souhaitent être remboursés rapidement et comptent sur le fait que leur
les dépenses seront remboursées intégralement sans une grande quantité de démarches bureaucratiques et
problèmes d'entreprise. Cela inciterait ces utilisateurs à être plus diligents et délibérés
dans l'utilisation de ce logiciel au lieu de le convertir en un autre outil informatique d'entreprise
que ne s'utilise pas ou se résout.

Il convient de noter que tous ces résultats sont importants et doivent être mentionnés.
spécifiquement comme résultats commerciaux, de clients ou d'utilisateurs. Cependant, ne
tout est quantifiable. Répondre aux objectifs émotionnels des utilisateurs est difficile,
surtout si l'équipe a tendance à se concentrer sur les métriques, car ces facteurs sont mesurés
émotionnels de différentes manières. Cela dit, le fait que ce soit difficile ne signifie pas que
tu ne devrais pas prêter attention à ce type d'objectifs. Ces objectifs émotionnels sont
fondamentales : ce sont ceux qui aident les équipes à comprendre quel type d'expérience
ils essaient d'offrir et, en fin de compte, s'ils le font bien, cela conduira à un meilleur
rendement dans les métriques quantifiables.

Faciliter l'exercice
Une fois que vos protopersonas ont été créées, vous pouvez utiliser le matériel dans la partie
inférieur de la proto-persona comme base pour cette discussion. Travaillant individuellement,
en petits groupes ou en équipe complète, travaillez à votre manière à travers chaque
proto-persona. Utilisez les questions suivantes comme directives :

Que cherche à accomplir l'utilisateur ?

Je veux acheter un nouveau téléphone.

Comment l'utilisateur veut-il se sentir pendant et après ce processus ?

Je veux sentir que j'ai le téléphone dont j'ai besoin à un bon prix
et que je suis à jour avec mes collègues (c'est-à-dire que je veux me sentir bien).

Comment notre produit ou service rapproche-t-il l'utilisateur d'un objectif ou d'un rêve dans la vie ?

Ejemplo de respuesta: Quiero sentirme conocedor de la tecnología y respetado por ello.

Pourquoi l'utilisateur chercherait-il votre produit ?

Je veux m'intégrer avec mes amis à l'école.

Quel changement de comportement pouvons-nous observer qui indique qu'ils ont atteint leur objectif ?

Ils apportent leur nouveau téléphone à l'école tous les jours.

Veuillez noter que tous les résultats des utilisateurs n'existent pas dans tous les
niveaux. Mais penser aux résultats en ces termes peut vous aider à trouver
dimensions importantes de votre solution sur lesquelles travailler, à partir des résultats
fonctionnels et axés sur les tâches jusqu'aux résultats les plus émotionnels orientés vers la
expérience.

Cette section de la toile est l'endroit où l'équipe s'aventure dans le côté émotionnel de la
conversation. Nous ne parlons pas de fonctions, de pixels ou de code ici. Nous voulons
comprendre ce qui pousse nos personnes à chercher notre produit et, quand il
ils se trouvent, que pourraient-ils faire. Quand vient le moment de commencer à essayer,
commercialiser ou promouvoir le produit, le travail que nous faisons dans cette section devient
dans une mine d'or pour le contenu, les appels à l'action et le texte instructif utile.

De quoi faire attention

Parfois, les équipes se concentrent tellement sur les fonctions que cet exercice devient un
un exercice récursif. Nous avons vu les équipes écrire des caractéristiques dans cette section.
pourquoi supposent-ils que c'est ce qui motive leurs clients. Noter un avantage pour l'utilisateur
comme "intégration de calendrier" n'est pas l'objectif de cet exercice. L'objectif ici est
comprendre les besoins latents de l'utilisateur. "Ne soyez plus jamais en retard à une autre réunion" est
bien plus important et attrayant pour l'utilisateur que les détails de la fonction qui le
ils aideront à y parvenir. Apple est toujours très bon pour différencier l'iPhone de cela.
manière contre Samsung et d'autres concurrents. Alors que la concurrence est
promouvant des caractéristiques telles que "caméra de 12 mégapixels", Apple annonce,
Montre à la grand-mère le bébé de tout le pays.
Capítulo 9. Recuadro 5: Soluciones
Figure 9-1. Encadré 5 du Lean UX Canvas : Solutions

Enfin, nous arrivons au point du processus Lean UX lorsque nous parlons de

solutions. C'est par conception. Bien que nous aurions certainement pu commencer notre
travail discutant les solutions ou caractéristiques que nous aimerions construire (et, dans la
la majorité des cas, c'est là que commencent les projets : avec les solutions
requis!), Notre travail est meilleur lorsque nous faisons un pas en arrière et que nous mettons quelques
restrictions en place. Dans notre cas, nous avons établi des restrictions avec notre
declaración de problemas comerciales, los resultados comerciales, el trabajo personal que
nous avons réalisé et notre discussion sur les résultats et les avantages pour l'utilisateur. Sans cela
les limitations, les solutions résoudront le mauvais problème pour les gens
équivoquées ou finiront dispersées et floues. Chaque ensemble de suppositions que
nous avons jusqu'à présent limité l'espace dans lequel nous pouvons créer des solutions,
et la créativité prospère dans les limitations.

Nous ne sommes pas encore entrés dans le travail de conception détaillé ici. Cela viendra une fois que
nous complétons la toile. Cependant, nous commençons à être précis sur ce que nous croyons
que nous amènera, nous et nos clients, de leur état actuel à
la condition objective.

Faciliter l'exercice
Comme c'est le cas avec la plupart de ces exercices de déclaration de suppositions, il y a plusieurs
formes de les faciliter. Ci-dessous, nous énumérons plusieurs approches pour vous aider à
commencer, mais n'hésitez pas à ajouter vos techniques préférées de brainstorming de design pour
vous aider, vous et votre équipe, à compléter le Tableau 5.

Cartographie d'affinité

Le mapping d'affinité est la façon la plus simple et facile d'obtenir un travail d'équipe.
ensemble dans le Tableau 5. Faites en sorte que chaque personne travaille individuellement pour générer des idées
de solution qui résoudrait le problème commercial et réaliserait les résultats commerciaux
y d'utilisateurs souhaités pour votre persona cible. Chaque persona doit générer autant d'idées
comme je peux, en mettant une idée par note adhésive. Tout comme avec n'importe quelle activité.
de brainstorming, est aussi bonne que la question de cadrage utilisée pour demander
réponses. Dans ce cas, la question que vous devez poser à votre équipe est :

Quelles solutions pouvons-nous concevoir et construire qui servent nos personnes et créent les
résultats souhaités ?

Chaque personne peut écrire des mots ou créer de petits croquis sur des post-it
pendant cinq minutes. Ensuite, l'équipe partage ses idées entre elles, classant les idées
similaires en groupes avant de voter par points quels approches croyez-vous avoir les plus grandes
possibilités de succès.

Bien que le mappage d'affinité vous fasse traverser le processus plus rapidement, prenez votre temps.
ici vous pouvez générer des bénéfices supplémentaires au-delà de simplement identifier des idées de solutions
de haut niveau.
Conception collaborative : une approche plus structurée

Une façon plus délibérée de développer des idées de solutions est la méthode de design
collaboratif que nous appelons Design Studio. (Nous écrivons plus sur les méthodes de design
collaboratif, y compris les Design Sprints, dans leChapitre 14). Quand il faut rassembler tout le monde
Pour une session de travail formelle, le Design Studio est une méthode populaire pour cela.

Cette méthode, née dans le monde de l'architecture où elle a été appelée Design Charrette,
c'est une façon de réunir une équipe multifonctionnelle pour visualiser des solutions possibles à
un problème de conception. Briser les silos organisationnels et créer un forum pour les points
de la part de ses coéquipiers.

En réunissant des designers, des développeurs, des experts en la matière, des chefs de produit,
analystes commerciaux et autres compétences dans le même domaine, axés sur le même
défi, vous créez un résultat bien plus important que ce que permet de travailler en silos. Vous avez
un autre avantage. Commence à instaurer la confiance dont votre équipe aura besoin pour passer de
ces sessions formelles à des collaborations plus fréquentes et informelles.

Réalisation d'une étude de design

La technique décrite dans les sections suivantes est très spécifique; cependant, elle doit
se sentir à l'aise pour réaliser des études de design moins ou plus formelles selon cela
justifiez votre situation et le moment. Les détails du rituel ne sont pas tant le point que le
activité de résoudre des problèmes avec ses collègues et clients. Indépendamment de
approche que vous choisissez, rappelez-vous que l'objectif est de générer des idées de solution qui résolvent votre
problème commercial.

Configuration

Pour exécuter une séance de Design Studio, vous souhaiterez trouver un créneau horaire dédié.
dans lequel il peut rassembler l'équipe. Il doit planifier un bloc d'au moins trois
horas. Querrá una habitación con mesas alrededor de las cuales la gente pueda
se réunir. La pièce doit avoir un bon espace sur les murs, afin que je puisse
placer le travail en cours sur les murs au fur et à mesure de son avancement.

Si vous travaillez dans une session à distance, utilisez un bon outil de tableau pour l'équipe
como Mural o Miro. Recuerde dedicar un tiempo a asegurarse de que todos se sientan
à l'aise avec l'outil de votre choix ; il se peut que vous deviez consacrer un certain temps à
début de la réunion pour que tout le monde soit au courant des outils.

L'équipe

Ce processus fonctionne mieux pour une équipe de cinq à huit personnes. Si vous en avez plus
personnes, vous pouvez créer plus d'équipes et faire en sorte que les équipes comparent les résultats à
fin du processus. (Les groupes plus importants prennent beaucoup de temps à compléter les étapes
de critique et de rétroaction, il est donc important de diviser les groupes de plus de huit
personnes dans des équipes plus petites, qui peuvent passer par le processus suivant en parallèle,
convergeant à la fin).
Avec des sessions à distance, voici où une vidéoconférenceLa fonction de "salle de
"descanso" entre en jeu. Étant donné que nous n'avons pas d'espace physique pour nous diviser, les salles
des groupes vidéo offrent à chaque équipe l'intimité et la concentration dont elle a besoin pour
faire son propre travail.

Processus

Le studio de design travaille dans le flux suivant :

• Définition des problèmes et des limitations

• Génération d'idées individuelles (divergence)
• Présentation et critique
• Itérer et affiner en paires (émerger)
• Génération d'idées d'équipe (convergente)

Fournitures

Pour la session en personne, voici les fournitures dont vous aurez besoin :

• Crayons
• Plumes
• Marqueurs à pointe en feutre ou similaires (plusieurs couleurs / épaisseurs)
• Surligneurs (plusieurs couleurs)
• Modèles de croquis (vous pouvez utiliser des modèles préimprimés un à un et par six)
une, ou vous pouvez utiliser des feuilles blanches de papier de 11" x 17" [A3] divisées en six
casiers)
• Almohadillas de caballete autoadhesivas de 25 "x 30,5" (A1)
• Dessiner des points (ou tout type de petites autocollants)

Avec des équipes distribuées, tous ces outils deviennent discutables en faveur de la
outil de collaboration en ligne que vous avez choisi d'utiliser. Cela dit, nous avons constaté que
certains facilitateurs à distance défient encore les gens d'utiliser du papier et un stylo pour
les croquis initiaux, photographier ces croquis et les partager dans l'outil de tableau
en ligne après les avoir créés localement.

Définition du problème et limitations (15 minutes)

La première étape dans Design Studio est de s'assurer que tout le monde soit conscient de cela.
hypothèses qu'il a déclarées jusqu'à présent : le problème commercial qu'il essaie de
résoudre, les résultats qui définissent le succès de l'effort, les utilisateurs auxquels il est
attendant et les bénéfices qu'ils cherchent à atteindre. Dans la plupart des cas, le
L'équipe en est déjà consciente, car ils ont travaillé ensemble sur la toile jusqu'à ce
momento. Si no han hecho este trabajo juntos, planifique un tiempo adicional para
informer l'équipe et répondre à ses questions.

Generación de ideas individuales (10 minutos)

Vous travaillerez individuellement à cette étape. Remettez à chaque membre de l'équipe un modèle.
de six, qui est une feuille de papier avec six cases vides, comme indiqué dans laFigure 9-
2Vous pouvez en faire un en pliant une feuille de papier blanc de 11 "x 17" (A3), ou en faire un
modèle préimprimé à remettre aux participants. (Si vous utilisez un outil
en ligne, n'obligez pas les gens à dessiner sur cet outil, qui est souvent difficile et
lente. À la place, demandez aux gens de travailler sur papier puis partagez une photo ou
escanee).

Figure 9-2. Un modèle de "six" vierge

Parfois, il est difficile pour les gens de faire face à une page blanche. Si c'est le
caso, essayez cette étape optionnelle. Demandez à tous de marquer chaque case sur leurs feuilles
avec l'une de ses personnes et le point de douleur ou problème spécifique qu'ils aborderont pour cela
persona. Escriba el nombre de la persona y el punto de dolor en la parte superior de cada
une des six cases. Vous pouvez écrire la même paire de personne / point de douleur autant de fois que vous le souhaitez
fois comme j'ai des solutions à ce problème, ou je peux écrire une combinaison de
persona / point de douleur différent pour chaque cadre. N'importe quelle combinaison
Ça fonctionne. Consacrez cinq minutes à faire cela.

Ensuite, avec vos feuilles de six devant vous, donnez à tous cinq minutes pour générer
six croquis de solutions basse fidélité (consultez laFigure 9-3 ) pour chaque paire de
persona / problema en su hoja de seis en uno. Deben ser articulaciones visuales (bocetos
de l'interface utilisateur, des flux de travail, des diagrammes, etc.) et non des mots écrits. Anime
à son équipe révélant le petit et sale secret du design d'interaction : si vous pouvez
dessiner un cercle, un carré et un triangle, vous pouvez dessiner toutes les interfaces. Nous sommes
assurent que tous dans votre équipe peuvent dessiner ces formes, et cette idée apparemment
tonta peut aider à niveler le terrain de jeu.
Figure 9-3. Un mur rempli de six dessins complets.
Présentation et critique (3 minutes par personne)

Lorsque le temps sera écoulé, partage et critique ce que tu as fait jusqu'à présent. En parcourant
la salle, donnez aux participants trois minutes pour partager leurs croquis et les présenter au
équipe (Figure 9-4). Les présentateurs doivent indiquer explicitement pour qui ils étaient
résoudre un problème (en d'autres termes, quelle personne) et quel point de douleur ils avaient
abordant, puis expliquer le contour.

Chaque membre de l'équipe doit fournir des critiques et des commentaires au présentateur.
miembros del equipo deben centrar sus comentarios en aclarar las intenciones del
présentateur.

Aidez votre équipe à comprendre que donner de bons commentaires est un art. Rappelez-leur que,
En général, il est préférable de poser des questions que de partager des opinions. Les questions aident à
équipe à parler de ce qu'elle fait et aide les gens à réfléchir à leur
travail. Les opinions, d'autre part, peuvent arrêter la conversation, inhiber la
collaboration et mettre les gens sur la défensive. Par conséquent, lorsque vous donnez des critiques, essayez
utiliser des questions comme "Comment cette fonction aborde-t-elle le problème spécifique de la"
persona? "Je ne comprends pas cette partie du dessin. Peux-tu développer ?" Des questions comme celles-ci
ils sont très utiles. Des commentaires comme "Je n'aime pas ce concept" apportent peu de valeur
et ils ne donnent pas au présentateur d'idées concrètes à utiliser lors de l'itération.
Figure 9-4. Une équipe qui présente et critique des dessins lors d'une étude de design.
Empareiller pour itérer et affiner (10 minutes)

Demandez maintenant à tout le monde de se regrouper pour le tour suivant. (Si deux personnes dans la session
ils ont des idées similaires, c'est une bonne idée de leur demander de travailler ensemble). Pour les séances
à distance, chaque couple doit travailler dans sa propre salle de réunion.

Chaque couple travaillera pour revoir ses idées de design (Figure 9-5). L'objectif ici est
que chaque couple choisisse les idées qui ont le plus de mérite et développe une version plus
évoluée et intégrée de ces idées. Chaque couple devra prendre certaines décisions
sur ce qu'il faut conserver, ce qu'il faut changer et ce qu'il faut jeter. Attendez-vous à ce que cela soit difficile et que chaque

pareja no esté de acuerdo en algunas cosas. Resista la tentación aquí de crear un acuerdo
rapidement en train de devenir plus général ou abstrait. En revanche, demandez à chaque couple de prendre
certaines décisions et soyez plus spécifique. Faites en sorte que chaque paire produise un seul dessin
sur une feuille de six feuilles de 11" × 17" (A3). Donnez à chaque équipe 10 minutes pour cette étape.

Lorsque le temps est écoulé, rassemblez tout le monde et repassez par le processus de présent et
critique.
Figure 9-5. Une équipe qui travaille ensemble sur un exercice de Design Studio
Génération d'idées en équipe (45 minutes)

Maintenant que tous les membres de l'équipe ont des commentaires sur leurs idées
individus et les personnes se sont associés pour développer plus d'idées, l'équipe doit
converger vers une idée. À ce stade, l'équipe essaie de sélectionner les idées qui
Ils pensent avoir plus de chances de succès. Cet ensemble d'idées servira de base
pour la prochaine étape du processus Lean UX : créer des hypothèses et, enfin, concevoir et
exécuter des expériences.

Demandez à l'équipe d'utiliser une grande feuille de papier autocollant ou un tableau blanc.
pour dessiner les composants et le flux de travail de votre idée. Il y aura beaucoup de compromis
y disputas en esta etapa, y para llegar a un consenso, el equipo deberá priorizar y reducir
les fonctions.

Anime l'équipe à créer un "parking" pour les bonnes idées qui ne font pas le
coupe. Cela facilitera le fait de mettre de côté les idées. Encore une fois, il est important
prendre des décisions ici : résistez à la tentation d'arriver à un consensus en généralisant ou
reporter les décisions.

Si vous avez divisé un grand groupe en plusieurs équipes dans l'atelier de conception, demandez à chaque équipe de
présentez votre idée finale dans la salle lorsqu'ils auront terminé pour un tour final de critique et
comentarios y, si lo desea, convergencia.
En utilisant la sortie

Le travail que j'ai réalisé dans un studio de design sera intégré à la création d'hypothèses.
finalement conception d'expériences. Cela ne signifie pas que toutes les idées passeront à la
considération finale, mais les idées sur lesquelles l'équipe a convergé seront mises à l'épreuve
à partir du Tableau 6, la création d'hypothèses.

Pour garder la sortie visible, publiez-la sur un mur de design ou un autre endroit en évidence.
pour que l'équipe puisse la consulter. Décidez quels dessins intermédiaires (s'il y en a) ils souhaitent
conserver les personnes et les montrer avec le dessin final, à nouveau pour que les
les membres de l'équipe peuvent consulter les idées. Peu importe ce que tu publies
sur le mur, il est généralement bon de photographier tout et de le conserver dans un dossier
d'archive de quelque type. On ne sait jamais quand il voudra revenir pour trouver
C'est aussi une bonne idée de mettre une seule personne en charge de la création de ceci.
Fichier. Créer une certaine responsabilité tendra à garantir que l'équipe maintienne de bonnes
enregistrements.

À quoi faire attention

La partie la plus difficile du design collaboratif est d'assurer une participation égale. Si
le maintien de l'exercice simple, la plupart des gens sentiront qu'ils peuvent participer
avec beaucoup de facilité. (Tout le monde peut écrire sur une note autocollante). Si vous décidez
utiliser des techniques plus complexes telles que Design Studio, vous devrez vous assurer que la
facilitation de première catégorie. (Et n'oubliez pas que tout cela sera plus difficile dans
sessions à distance). Si les membres de votre équipe se déconnectent pendant cette partie car
sontiment que ces exercices étaient trop avancés pour eux, il est probable que
présentent une résistance beaucoup plus grande à certaines des options de caractéristiques et
conception que l'équipe réalise par la suite. Dans ce cas, autant que dans n'importe quel autre
à cet endroit, la facilitation de la conception devient un ensemble de compétences de base pour
les designers de votre équipe.
Chapitre 10. Encadré 6 : Hypothèse

Figure 10-1. Encadré 6 du Lean UX Canvas : Hypothèse

Lorsque l'équipe arrive au Box 6, elle a toute la matière première dont elle a besoin.
commencer à rédiger des hypothèses tactiques et vérifiables. Cependant, avant de faire cela,
parlons d'hypothèses en général.

L'hypothèse est récemment devenue un mot populaire dans le développement de

produits, en grande partie parce que deThe Lean Startup, dans lequel Eric Ries décrit un
méthode de développement de produits inspirée par la méthode scientifique. Elle prône l'expérimentation
votre hypothèse tôt et souvent. Alors, qu'est-ce qu'une hypothèse en fin de compte
modos ? Selon le Dictionnaire Oxford des Mots Difficiles, c'est "une supposition ou
explication de la proposition faite sur la base de preuves limitées comme point de départ
pour une plus grande recherche.1

C'est ce que nous sommes sur le point de créer : nous allons prendre toutes nos suppositions (les
les suppositions sont des déclarations basées sur "des preuves limitées"), et nous allons les rassembler dans
une déclaration unifiée (notre "explication proposée" de notre problème et
solution) pour que nous puissions commencer notre processus de recherche et d'essai (notre
investigation exhaustive

Bien, avec cela hors du chemin, commençons à écrire des hypothèses. Voici le modèle que
nous recommandons :

Nous croyons que nous atteindrons [ce résultat commercial]

Si[ces personnes]

Obtenez [ce bénéfice / résultat de l'utilisateur]

Con[ceci fonction ou solution]

Le modèle commence par les mots "nous croyons". C'est explicite parce que cela ne
nous savons. Nous faisons des suppositions. Et ensuite nous remplissons le modèle d'hypothèses
en nous basant sur le matériel que nous avons créé dans chaque cadre de toile avant de
nous extrayons les résultats commerciaux du Tableau 2, les personnes du Tableau 3, les
les avantages du Tableau 4 et les solutions du Tableau 5. D'une certaine manière, cette partie du
le processus consiste simplement à remplir les espaces vides.

Mais nous devons faire un peu plus que cela. Notre objectif ici est d'écrire des hypothèses.
qu'elles aient du sens et auxquelles nous croyons. Ces hypothèses sont, en essence, des histoires très
brèves conçues pour générer un soutien afin de suivre une direction de conception
particulier. Écrire une bonne hypothèse qui a du sens et que vous et votre équipe croyez
c'est en réalité la première façon de tester la validité des remue-méninges de son
solution. Si vous ne pouvez pas formuler une déclaration d'hypothèse convaincante pour l'une des
idées de solution dans le Tableau 5, alors cette idée ne devrait pas passer à la partie suivante
du processus. Et, pour être plus clair, une hypthèse convaincante est celle dans laquelle la
la fonction a un utilisateur clair, l'utilisateur obtient un avantage évident de la fonction et le
changement de comportement de l'utilisateur après aide à résoudre le problème commercial
que nous articulons dans le Tableau 1.

Faciliter l'exercice
Nous aimons créer un tableau comme celui de laFigure 10-2. et ensuite complétez-le en utilisant le
matériau que nous avons rempli dans les parties précédentes de la toile. Nous avons déplacé physiquement
nos notes Post-it aux tableaux correspondants pour former des rangées d'idées
liées. Chaque colonne est directement liée à une case spécifique du
toile, du cadre 2 à gauche au cadre 5 à droite.

Figure 10-2. Un tableau d'hypothèses

Au cours de cet exercice, vous rencontrerez souvent des lacunes dans vos idées initiales.
il est possible que certains résultats commerciaux n'aient pas de fonctions créées pour eux,
tandis que certaines fonctions peuvent ne générer aucune valeur pour le client ou la
entreprise. C'est une partie de l'objectif de cet exercice : organiser et donner un sens à votre tour
initial thought. Once you have identified the gaps in your brainstorming,
remplissez-les avec de nouvelles notes autocollantes (Figure 10-3) o, mieux encore, laissez les idées moins
éléments pertinents en dehors du tableau. Cela aidera à donner un sens à la grande quantité indéniable de
idées générées par son équipe.

Avec des équipes distribuées utilisant un outil de tableau blanc virtuel, cet exercice se
devenez encore plus facile. Copiez et collez vos notes d'autres parties de la toile dans la Case 6 et
Déplacez-les selon les besoins pour compléter le tableau.

Figure 10-3. Travaillant sur le graphique des hypothèses

Une fois que vous avez complété le graphique (de 7 à 10 lignes sont un bon objectif initial),
Commencez à extraire des hypothèses de caractéristiques de celui-ci. Utilisez le modèle d'hypothèses.
pour s'assurer qu'il inclut tous les éléments pertinents de la déclaration de
hypothèse. Voici à nouveau ce modèle :

Nous croyons que nous atteindrons [ce résultat commercial]

Si ces personnes

Obtenez [ce bénéfice / résultat de l'utilisateur]

Con[esta fonction ou solution]

Tout en écrivant ses hypothèses, considérez à quelle(s) personne(s) vous servez avec vos
solutions proposées. Il n'est pas rare de trouver des solutions qui servent plus d'une personne
à la fois. Il n'est pas non plus inhabituel de créer une hypothèse dans laquelle plusieurs caractéristiques
générez des résultats similaires. Lorsque vous voyez que cela se produit, affinez l'hypothèse pour
se concentrer sur une seule caractéristique. Les hypothèses avec plusieurs caractéristiques ne sont pas
faciles à tester. La chose importante à retenir dans tout ce processus est de maintenir vos
idées suffisamment spécifiques pour que je puisse créer des tests significatifs pour voir
si ses idées sont valides.

Quelleestladifférenceentreleshypothèsesetleshistoiresd'utilisateursagiles?

On nous demande souvent de faire la distinction entre les hypothèses, les déclarations et les histoires d'utilisateur.
classiques de l'Agile. La différence est subtile mais puissante. L'un des formats les plus populaires
pour les histoires d'utilisateur agiles, cela a cet aspect :

En tant que <type d'utilisateur>,

Je veux <un but>

pour <une raison>.

Vous remarquerez que l'utilisateur et le résultat de l'utilisateur sont présents dans cette histoire. Dit
la plupart des équipes avec lesquelles nous avons travaillé remplacent "un certain objectif"
por "esta función". Una vez que se escribe la historia del usuario, la mayoría de los
des équipes rejettent les pièces autour d'un "objectif" et commencent à mettre en œuvre la
fonction. L'utilisateur oublie rapidement pendant que l'équipe travaille diligemment pour
acelerar su velocidad y ofrecer la función. El criterio de aceptación del equipo (es decir,
su definición de éxito) es que el sistema permite al usuario completar una tarea. No hay
discussion sur la question de savoir si la solution est utilisable ou souhaitable, et encore moins agréable. On ne se
discute si la fonction génère un résultat. Le seul test effectué est si le système
fonctionne selon ce qui est prévu

Les hypothèses ont des changements de comportement (résultats commerciaux) comme leur
définition du succès. L'envoi d'une caractéristique de travail est un pari de table. C'est
le début de la conversation. Le succès de notre équipe ne se mesure pas à la rapidité avec
la que peuvent lancer les fonctions. En revanche, nous mesurons le succès en fonction de à quel point
Bien, nos clients peuvent atteindre 'un certain objectif' initial et en continu.

C'est la différence clé entre les histoires d'utilisateur et les hypothèses. Elles recentrent l'équipe sur
ce qui est vraiment important, c'est de faire réussir le client et, par conséquent, d'atteindre un
objectif commercial, au lieu de mesurer la productivité de l'équipe comme succès.

Ceci dit, il a encore besoin d'une manière de parler des résultats et des fonctions, les
choses que l'équipe est en train de construire. Si leurs histoires d'utilisateur sont centrées sur
fonctions, c'est bien. En fait, il arrive souvent qu'une certaine hypothèse donne comme
résultat de nombreuses histoires d'utilisateurs. Cependant, décide de faire un suivi du
travail, ça va. Assurez-vous simplement qu'une partie de votre processus connecte le travail que
il est en train de faire au niveau des fonctions avec les résultats commerciaux et d'utilisateur de niveau
supérieur qu'il essaie de créer.

Prioriser les hypothèses

Lean UX est un exercice de priorisation implacable. Il est rare d'avoir un budget de
projet strictement centré sur l'apprentissage. Dans la plupart des cas, également
nous devons expédier le produit. La raison pour laquelle nous déclarons nos hypothèses au
Le début de notre travail est de pouvoir identifier les risques du projet et
établir des priorités. Qu'est-ce qui est risqué et nécessite des tests ? Qu'est-ce qui n'est pas risqué et,
par conséquent, facile à commencer ?

Après avoir enchaîné nos suppositions en hypothèses, nous créons une accumulation de
travail potentiel. Ensuite, nous devons déterminer lesquels sont les plus risqués, pour
que nous puissions travailler dessus en premier. Comprenant qu'il ne peut pas tester tous les
hypothèses, comment décide-t-il laquelle tester en premier ?

Il existe de nombreuses façons d'établir des priorités, mais nous avons découvert que
il peut souvent être utile de le faire de manière collaborative et d'avoir un cadre pour cela
travail. C'est pourquoi nous avons créé le canevas de priorisation des hypothèses qui est montré dans lefigure
10-4(Oui, une autre toile.) Le HPC est une matrice de deux par deux avec l'axe x mesurant le risque et
l'axe y mesure la valeur perçue. Nous utilisons la valeur "perçue" car c'est une grande
supposition. Nous croyons qu'une idée a une forte valeur perçue si sa mise en œuvre
aura un impact significatif sur l'expérience utilisateur et, par conséquent, sur le
entreprise. Lorsque nous parlons de risque, nous évaluons chaque hypothèse selon ses propres
mérites. Certaines hypothèses seront techniquement risquées. Certaines supposeront un risque
pour la marque. D'autres mettront en défi nos capacités de conception. Dans ce cas, non
nous normalisons pour un type spécifique de risque, donc nous pouvons considérer tous les
aspects du risque pour chaque hypothèse.

Figure 10-4. Le canevas de prioritisation des hypothèses

Mettez vos hypothèses sur la toile en équipe.

 • Les hypothèses qui atterrissent dans le quadrant 1 sont les hypothèses que nous allons
Tester. Les cases 7 et 8 se graduent sur la toile Lean UX.
• Si une hypothèse tombe dans le quadrant 2 du HPC (haute valeur, faible risque), la
nous construirons. Écrivez les histoires des utilisateurs, mettez-les sur la liste de
travaux en cours et les envoyer. Mais n'oubliez pas de mesurer cette caractéristique une fois que
est active. Si cela ne répond pas à vos attentes, c'est-à-dire les résultats
Les commerciaux définis dans l'hypothèse comme succès doivent revoir cette idée.
• Toute hypothèse qui tombe en dessous de l'axe de risque dans la zone de faible valeur
perçu ne se teste pas. S'il tombe dans le quadrant 4 de la HPC (haut risque, faible
valeur), nous le rejetons. Il n'est pas non plus nécessaire de le construire.
• Les hypothèses qui se terminent dans le quadrant 3 de la HPC (risque faible, valeur faible)
ils ne sont pas testés et, dans la plupart des cas, ils ne sont pas construits. Cependant, il y aura
certaines hypothèses qui se terminent ici qui, bien qu'elles ne soient pas particulièrement précieuses
o risquées, elles doivent encore être construites pour que vous puissiez faire fonctionner votre entreprise.
par exemple, vous devrez mettre en place un système de paiement si vous créez un service
de commerce électronique, mais cela ne le différenciera pas sur le marché. Dans ce cas,
nous construisons les cas d'utilisation de base sachant que nos caractéristiques
innovantes et délicieuses, les caractéristiques les plus risquées, seront testées et
validées avant la mise en œuvre.

De quoi être attentif

La rédaction d'hypothèses, comme la plupart des nouvelles techniques, s'améliore avec
pratique. Les équipes écrivent souvent des hypothèses qui sont trop grandes pour
les essayer au début de votre voyage Lean UX. Si vous vous trouvez dans cette situation, reconsidérez
l'étendue de son hypothèse. Comment pouvez-vous la rendre plus petite ? Comment peut-elle
dimensionner l'hypothèse jusqu'à un point où son équipe peut avoir la propriété totale
sur sa portée ?

La rédaction d'hypothèses, tout comme la rédaction de déclarations de problèmes commerciaux,

il bénéficie également de la spécificité. Utilisez des chiffres spécifiques dans les résultats de
votre entreprise. Soyez clair sur la fonction que vous aimeriez créer. C'est un autre domaine dans lequel
des phrases comme "meilleure expérience utilisateur" et "interface utilisateur intuitive" n'ont pas
sens. Si on vous demande d'essayer cette "interface utilisateur intuitive" (et, pour être clair,
estará en el siguiente paso del lienzo), ¿qué probará? Considere reemplazar frases
ambiguës comme celle-ci par d'autres plus spécifiques comme "paiement en un clic" ou "authentification
de reconnaissance faciale.

1Archie Hobson (éd.), Le Oxford Dictionary of Difficult Words (New York : Oxford)
University Press, 2004), sv "hypothèse".
Chapitre 11. Encadré 7 : Qu'est-ce qui est le plus
important que nous devons apprendre
d'abord?

Figure 11-1. Encadré 7 du canevas Lean UX : apprentissage

Une fois que vous avez priorisé vos hypothèses et identifié lesquelles vous allez tester, le
siguiente paso en el proceso es resaltar los principales riesgos en cada hipótesis. Para
faire cela, nous posons la première des deux questions clés de Lean UX : Quelle est la plus importante ?
quelle est l'importance de ce que nous devons d'abord apprendre sur cette hypothèse ?

Lorsque nous posons des questions sur l'apprentissage, nous avons en réalité une conversation.
sur le risque. Nous voulons découvrir toutes les choses qui pourraient briser notre hypothèse. Si
il fait cela avec une équipe multifonctionnelle, comme nous le conseillons tout au long du livre,
vous obtiendrez au moins autant de réponses à cette question qu'il y a de disciplines dans la salle. Les
les ingénieurs en logiciels discuteront des complexités du développement de la fonction.
Les designers soulèveront des problèmes de flux de travail et des problèmes d'utilisabilité. Les
les chefs de produit s'interrogeront sur la question de savoir si cela apportera des avantages commerciaux que
nous anticipons. Tous ces risques sont valables, mais ceux sur lesquels nous voulons nous concentrer maintenant
ceux qui invalideront l'hypothèse et nous permettront d'avancer rapidement si nous
nous nous sommes trompés.

Dans les premières étapes du cycle de vie de l'hypothèse, le plus grand risque est généralement
lié à la valeur de la solution. Les gens ont-ils besoin d'une solution ? L'
chercheront-ils ? Essaieront-ils ? L'utiliseront-ils ? Trouveront-ils de la valeur dedans ? Ce sont là les choses
que importent depuis le début. Si la réponse à ces questions est "non", alors non
il n'est pas nécessaire de s'inquiéter de la façon dont nous allons le concevoir ou le construire. Si nous sommes
en train de traiter une hypothèse plus mature, celle dans laquelle la valeur a été validée et nous avons
passé à la mise en œuvre technique, donc penser à des choses comme des défis techniques,
l'usabilité et l'évolutivité deviennent les prochains risques logiques à explorer.

Faciliter l'exercice
En termes généraux, c'est une conversation. L'équipe se réunit pour examiner la
priorisation des hypothèses et détermine lesquelles il veut tester en premier. Ensuite, faites le
questionQuelle est la chose la plus importante que nous devrions apprendre en premier sur cela
hypothèse ? Si la conversation se bloque, vous pouvez choisir de faire un brainstorming ici,
puis faire un mappage d'affinité et voter par points. Ou il peut céder devant un membre
de l'équipe qui a une opinion ferme. En général, cette étape ne nécessite pas beaucoup
processus. Le point ici est d'identifier les principaux risques de un à trois liés à
cette hypothèse, puis passer à la planification de son expérience, ce qu'il fera dans le Cadre
8.

À quoi être attentif

Le consensus est bon mais n'est pas toujours atteignable. Si tu trouves cette équipe Si la discussion
ne parvient pas à un consensus, c'est une indication claire que l'équipe a besoin de plus d'informations
pour prendre cette décision. La seule façon de le faire est de prendre une décision et de passer à
Encadré 8 pour créer une expérience. Dans la plupart des cas, le chef de produit
vous pouvez passer cet appel. Lorsque vous faites cela, rappelez-vous que nous ne quitterons pas cela
hypothèses, suppositions et risques pour toujours. Nous avançons simplement avec une
et, s'il est prouvé que c'est faux, nous reviendrons à l'accumulation des hypothèses pour faire le
processus à nouveau.
Chapitre 12. Encadré 8 : MVP et
experiments

Figure 12-1. Encadré 8 de la Lean UX Canvas : MVP et expériences

La dernière étape du Lean UX Canvas se concentre sur l'expérimentation. La deuxième question

La clé du sujet auquel nous devons répondre est : Quelle est la plus petite quantité de travail ?
que devons-nous faire pour apprendre la chose suivante la plus importante ? La réponse à
cette question est l'expérience que vous allez réaliser pour tester votre hypothèse.

Faire le moins de travail n'est pas de la paresse. C'est de la maigreur. Rappelez-vous, nous essayons de
éliminer le gaspillage, et le travail supplémentaire dédié à tester votre idée est un
gaspillage. En fait, plus vous découvrirez rapidement si votre idée est quelque chose dans lequel vous devriez
continuer à travailler, moins on investira en elle. Cela fait que changer de cap est beaucoup
más fácil, lo que aumenta la agilidad del equipo.

Les expériences qui lui viennent à l'esprit dans le Cadre 8 sont ses produits minimums viables.
o MVP. En fait, c'est la définition exacte de MVP de The Lean Startup d'Eric
Ries.

Qu'est-ce qu'un MVP de toute façon ?

Si vous demandez à une salle pleine de professionnels de la technologie : « Qu'est-ce qu'un MVP ? »
probablement que j'écoute une liste longue et diversifiée qui inclut des joyaux comme ceux qui suivent :

C'est le plus rapide que nous puissions sortir par la porte qui fonctionne encore.

C'est un lancement moche qui est plein de compromis et fait que tout le monde se sente
infelices.

C'est ce que le client dit que c'est.

C'est l'ensemble minimum de caractéristiques qui nous permet de dire 'ça fonctionne'.

C'est la phase 1. (Et nous savons tous ce qu'il en est de la probabilité de la phase 2).

La phrase MVP a causé beaucoup de confusion dans sa courte vie. Le problème est qu'elle est utilisée
au moins de deux manières différentes. Parfois, le terme est utilisé pour signifier "un
lancement petit et rapide". C'est la signification à laquelle se réfèrent les citations
antérieures. Ce n'est pas ainsi que nous utilisons la phrase.

Lorsque nous parlons de MVP, nous parlons d'une petite et rapide façon d'apprendre.
algorithme. Parfois, c'est une version de logiciel. Parfois, ce ne l'est pas, cela peut être un dessin, une
page de destination ou un prototype. Sa principale préoccupation n'est pas de créer de la valeur mais de créer
apprentissage. Cela dit, ces deux idées ne sont pas mutuellement exclusives. Après
Tout, l'une des choses clés que vous essayez d'apprendre est ce que le marché considère
précieux. Souvent, un bon MVP créera de la valeur et de l'apprentissage. Pour nous, cependant,
L'objectif d'un MVP est de se concentrer sur l'apprentissage.

Ejemplo: ¿Deberíamos lanzar un boletín informativo?

Prenons, par exemple, une entreprise moyenne que nous avons consultée il y a quelques années. Ils étaient
explorant de nouvelles tactiques de marketing et souhaitaient lancer un bulletin mensuel. Créer un
Un bulletin d'informations réussi n'est pas une tâche facile. Il nécessite de préparer une stratégie de
contenu, calendrier éditorial, mise en page et design, ainsi qu'une stratégie continue
de marketing et de distribution. Il a besoin d'écrivains et d'éditeurs pour y travailler. Cela dit,
c'était une grande dépense pour l'entreprise. L'équipe a décidé de traiter cette idée de bulletin comme une
hypothèse.

L'équipe s'est demandé : Quelle est la chose la plus importante que nous devons apprendre en premier ?
respuesta: ¿Hubo suficiente demanda por parte de los clientes de un boletín informativo
pour justifier l'effort ? Le MVP que l'entreprise a utilisé pour tester l'idée était un
formulaire d'inscription sur votre site Web actuel. Le formulaire d'inscription promouvait le
boletín y solicitaba la dirección de correo electrónico de un cliente. Este enfoque no
n'offrirait aucune valeur au client, pour l'instant. En revanche, l'objectif était de mesurer la demande et
obtenir des informations sur la proposition de valeur et la langue qui promouvaient les
inscriptions. L'équipe a estimé que ces tests leur fourniraient suffisamment d'informations
pour prendre une bonne décision sur la poursuite ou non.

L'équipe a passé une demi-journée à concevoir et à coder le formulaire et a pu le lancer ce jour-là.

même après-midi. L'équipe savait que son site recevait une quantité significative de trafic chaque
jour : ils pourraient apprendre très rapidement s'il y avait de l'intérêt pour le bulletin.

À ce stade, l'équipe n'a fait aucun effort pour concevoir ou créer la newsletter.
réel. Ils ne le feraient qu'après avoir recueilli suffisamment de données de leur premier
expérience, et seulement si les données montraient que ses clients voulaient la newsletter. Si les données
s'ils étaient positifs, l'équipe passerait à son prochain MVP, un qui commencerait à offrir de la valeur
et je créerais un apprentissage plus approfondi autour du type de contenu, du format de
présentation, fréquence, distribution sociale et d'autres choses qu'ils devraient apprendre. pour
créer un bon bulletin. L'équipe prévoyait de continuer à expérimenter avec les versions
MVP du bulletin, chacun améliorant son prédécesseur, qui fournirait plus et
différents types de contenu et de design et, en fin de compte, offriraient le bénéfice
commercial qu'ils cherchaient.

Création d'un MVP

Lorsqu'il s'agit de créer un MVP, la première question est toujours : que est le plus ?
importante que nous devons apprendre ensuite ? Dans la plupart des cas, la
la réponse sera une question de valeur ou une question d'implémentation. Quoi qu'il en soit,
vous voudrez concevoir une expérience qui vous fournisse suffisamment de preuves pour répondre à votre
demander et l'aider à décider s'il faut continuer ou non avec l'idée.

Créer un MVP pour comprendre la valeur

Voici quelques lignes directrices à suivre si vous essayez de comprendre la valeur de votre
idea:

Arriver au but
Indépendamment de la méthode MVP que vous choisissez d'utiliser, concentrez votre temps à distiller
sa idée à sa proposition de valeur centrale et la présente à ses clients. Les choses qui entourent
votre idée (des choses comme la navigation, les connexions et les flux de récupération de
les mots de passe) seront irrélevants si votre idée en elle-même n'a pas de valeur pour votre public
objectif. Laisse ces choses pour plus tard.

Utilisez un appel à l'action clair

Vous saurez que les gens apprécient votre solution lorsqu'ils montreront l'intention de l'utiliser ou
(¡ay!) Payez pour elle. Donner aux gens un moyen de s'abonner ou de s'inscrire à un
Le service est un excellent moyen de savoir s'ils sont intéressés et s'ils s'investiraient vraiment.
argent pour cela.

Mesurer le comportement
Créez un MVP avec lequel vous pouvez observer et mesurer ce que les gens font. Cela vous permet
ignorer ce que les gens disent qu'ils feront en faveur de ce qu'ils font réellement. Dans le
Conception de produits numériques, le comportement l'emporte sur l'opinion.
Parle avec tes utilisateurs

Mesurer le comportement vous dit ce que les gens ont fait avec votre MVP. Sans savoir pourquoi ils l'ont fait.
se comportaient de cette manière, itérer leur MVP est un acte de design aléatoire. Essayez
capturer les conversations tant de ceux qui se sont convertis que de ceux qui ne l'ont pas été
ils ont fait.

Prioriser sans pitié

Les idées sont bon marché et abondantes. Laissez les meilleures se prouver elles-mêmes, ainsi
qu'il ne s'accroche pas à des idées invalidées simplement parce qu'il les aime. En tant que designers, nous savons
que cela est particulièrement difficile à pratiquer. Les designers ont tendance à être optimistes
y, à souvent, nous pensons que nos solutions, que nous travaillions dessus pendant
 cinq minutes ou cinq mois, elles sont bien conçues et bien pensées. Rappelez-vous, si les
les résultats de votre expérience ne correspondent pas à votre hypothèse, vous avez tort.

Reste agile
Les apprentissages arriveront rapidement ; assurez-vous de travailler dans un environnement ou
outil qui vous permet de effectuer des mises à jour facilement.

Ne réinvente pas la roue

Muchas de las herramientas, sistemas y mecanismos que necesita para probar sus ideas
ya existen. Considere cómo podría usar el correo electrónico, SMS, aplicaciones de chat,
groupes Facebook, vitrines Shopify, outils sans code, forums de
discussion et d'autres outils existants pour obtenir l'apprentissage qui est
cherchant.

Création d'un MVP pour comprendre l'implémentation

Voici quelques lignes directrices à suivre si vous essayez de comprendre l'implémentation

qu'il envisage de lancer à ses clients :

Être fonctionnel

Il doit exister un certain niveau d'intégration avec le reste de votre application pour créer un
scénario d'utilisation réaliste. Il est important de créer votre nouveau flux de travail dans le
contexte de la fonctionnalité existante.
Intégrer avec les analyses existantes

La mesure de la performance de votre MVP doit être effectuée dans le contexte des flux
de travail des produits existants. Cela vous aidera à comprendre les chiffres que vous êtes
voyant.

Soyez cohérent avec le reste de l'application

Pour minimiser tout biais envers la nouvelle fonctionnalité, concevez votre MVP pour qu'il soit
adapte à son apparence, sensation et marque actuelles.

Quelques consignes finales pour la création de MVP

Les MVP peuvent sembler simples, mais en pratique, ils peuvent se révéler difficiles.
la plupart des compétences, plus vous pratiquez, mieux vous deviendrez.
faire. En attendant, voici quelques lignes directrices pour créer des MVP précieux.

Il n'est pas facile d'être pur

Vous découvrirez qu'il n'est pas toujours possible de tester une seule chose à la fois : Souvent, vous essayez
savoir si votre idée a de la valeur et déterminer les détails de mise en œuvre
temps. Bien qu'il soit préférable de séparer ces processus, il est important de prendre en compte les lignes directrices avant

mentionnées lors de la planification de vos MVP vous aidera à naviguer à travers les compromis et
engagements qu'il devra faire.

Soyez clair sur vos objectifs d'apprentissage

 Assurez-vous de savoir ce que vous essayez d'apprendre et assurez-vous d'avoir bien compris quoi
des données à collecter pour apprendre. C'est une mauvaise sensation de commencer une expérience
seulement pour découvrir qu'il n'a pas instrumenté correctement et qu'il n'arrive pas à capturer
quelques données importantes.

Commence petit

Indépendamment du résultat souhaité, créez le MVP le plus petit

possible. Rappelle-toi que c'est un outil pour apprendre. Tu vas itérer. Tu le feras.
modifiant. Il est très probable que je le jette complètement. Ce sera beaucoup plus facile
le jeter si tu ne consacres pas beaucoup de temps à le construire.

Tu n'as pas nécessairement besoin d'un code

Dans de nombreux cas, votre MVP n'impliquera aucun code du tout. À la place,
dépendra de nombreux outils existants du designer UX : croquis,
création de prototypes, rédaction de textes publicitaires et conception visuelle.

La courbe de la vérité

La quantité d'effort que vous mettrez dans votre MVP doit être proportionnelle à la quantité de
évidences que vous avez que votre idée est bonne. C'est le point du graphique (Figure 12-2)
créé par Giff Constable.1L'axe x montre le niveau d'investissement que vous devez investir dans votre
MVP. L'axe y montre la quantité de preuves basées sur le marché que vous avez sur votre
idée. Plus j'ai de preuves, plus la fidélité et la complexité de mon
MVP. (Il aura besoin d'un effort supplémentaire, car ce qu'il doit apprendre devient plus
compliqué). Moins il aura de preuves, moins d'efforts il voudra mettre dans son
MVP. N'oubliez pas la deuxième question clé : Quelle est la chose la plus petite que vous pouvez faire ?
pour apprendre la chose suivante la plus importante? Tout ce qui est au-delà de cela est un
gaspillage.
Figure 12-2. Notre version adaptée de la Courbe de la vérité est un rappel utile que le
l'apprentissage est continu et qu'un investissement plus important n'est justifié que lorsque les faits le justifient.
exigent.

Exemples de MVP
Jetons un coup d'œil à quelques types différents de MVP qui sont couramment utilisés.

Test de page d'atterrissage

Ce type de MVP aide une équipe à déterminer la demande de son produit. Cela implique
crear una página de marketing con una propuesta de valor clara, una llamada a la acción
et une façon de mesurer la conversion. Les équipes doivent générer du trafic pertinent vers cela.
page de destination pour obtenir une taille d'échantillon suffisamment grande pour que
les résultats soient utiles. Ils peuvent le faire en détournant le trafic des flux de travail
existants ou en utilisant de la publicité en ligne.

Les résultats positifs des tests de la page de destination sont clairs, mais les
Les résultats négatifs peuvent être difficiles à interpréter. Si personne ne se "convertit", non
cela ne signifie nécessairement pas que son idée n'ait aucune valeur. Cela pourrait simplement signifier que
tu ne racontes pas une histoire convaincante. La bonne nouvelle, c'est que les preuves de la
les pages de destination sont bon marché et peuvent être itérées très rapidement. Si tu le
tu crois, Kickstarter (et d'autres sites de financement participatif) sont remplis de MVP de
pages de destination, comme indiqué dans leFigure 12-3 Les personnes qui listent
les produits sur ces sites recherchent la validation (sous forme de soutien financier) que
ils devraient investir dans la construction de leurs idées proposées. Les preuves de la page de
les destinations n'ont pas à être des pages. Elles peuvent être des annonces ou d'autres messages en ligne qui
ayez les composants énumérés ci-dessus.
Figure 12-3. Un exemple de page Kickstarter
Caractéristique fausse (également connue sous le nom de bouton vers nulle part)

Parfois, le coût de mise en œuvre d'une fonction est très élevé. Dans ces cas, il est moins cher
et rapidement créer l'apparence de la fonction là où elle n'existe vraiment pas. Les boutons HTML,
les appels à l'action et autres indications et liens offrent à votre client l'illusion
il existe une fonction. En cliquant ou en touchant le lien, l'utilisateur est informé que la
la fonction "sera bientôt disponible" et qu'on vous avertira lorsque cela se produira. Les
les contrefaçons de caractéristiques sont comme des mini-pages de destination en ce sens que
ils existent pour mesurer l'intérêt. Ils doivent être utilisés avec modération et éliminés dès que
un seuil de succès a été atteint. S'il pense qu'ils pourraient avoir un impact négatif sur votre
relation avec son client, il peut le corriger en offrant une carte-cadeau ou un autre type
de compensation à ceux qui ont trouvé leur souricière.

La figure 12-4montre une caractéristique fausse utilisée par Flickr. Dans ce cas, ils ont offert
un bouton avec l'étiquette "Utiliser comme économiseur d'écran" qui semblait être
destiné à ce que l'utilisateur spécifie un album photo comme économiseur d'écran pour
votre appareil.

Figure 12-4. Un exemple d'une fonction factice trouvée dans l'application Apple TV de Flickr

Cependant, lorsque les utilisateurs ont cliqué sur le bouton, ils ont été accueillis par le
écran qui s'affiche dans leFigure 12-5. Flickr a utilisé cela pour recueillir des preuves que
un client aimerait cette fonction. En mesurant les taux de clics, ils pourraient évaluer la
demande de cette fonction avant de la créer.
Figure 12-5. L'écran qui apparaît après avoir cliqué sur le bouton de fonction fausse

Figura 12-6. presenta otro ejemplo de función falsa. Aquí, MapMyRun ofreció la
opportunité de prendre et de charger des photos tout en courant en utilisant deux superpositions
modales. Il n'y avait aucune fonction jusqu'à ce qu'ils reçoivent une indication que a) la
Les gens voulaient cette fonction etb) combien ils seraient prêts à payer pour elle.
Figure 12-6. Un autre exemple d'une fonction fausse, celle sur le site web de MapMyRun
mago de Oz

Une fois que vous avez prouvé la demande de votre idée, un MVP du Magicien d'Oz peut
ayudarlo a descubrir la mecánica de su producto. Este tipo de MVP le parece al usuario
un service numérique pleinement opérationnel. Cependant, en arrière-plan, les données et la
La communication avec le groupe initial d'utilisateurs est gérée manuellement par des humains.
exemple, l'équipe d'Amazon derrière Echo a exécuté un MVP de Wizard of Oz comme
une partie de vos tests initiaux pour comprendre les types de requêtes que les gens feraient et
la rapidité avec laquelle ils s'attendraient à une réponse. Dans une pièce, un utilisateur faisait
des questions à "Alexa", et dans une autre pièce, un être humain écrivait des requêtes sur Google,
obtenait des réponses et répondait. Les utilisateurs de test ne savaient pas qu'ils n'utilisaient pas
logiciel. Le reste de l'équipe a pu observer les utilisateurs et comprendre comment ils l'utiliseraient
ce nouveau produit, avant qu'un effort d'ingénierie significatif ne soit investi.

Ejemplo: MVP del Mago de Oz para Taproot Plus

En 2014, notre entreprise a travaillé avec une organisation appelée Fondation Taproot pour
créer un marché en ligne pour les bénévoles pro bono. (Pro bono signifie lorsqu'un professionnel
donnez vos compétences pour aider une cause digne. Contrairement aux services de
bénévolat non qualifié auquel beaucoup d'entre nous ont participé le week-end dernier,
le service pro bono implique l'utilisation de vos talents professionnels dans un contexte de
volontariat).

Notre client, la Taproot Foundation, avait aidé des bénévoles pro bono et
des organisations à but non lucratif à se rencontrer pendant des années, mais il y avait toujours
offrant ce service de mise en relation "à la main", par le biais d'appels téléphoniques,
courriels et réunions en personne. Maintenant, ils voulaient mettre ce processus en ligne :
ils voulaient créer un site web qui agirait comme un marché à deux faces pour les bénévoles
pro bono et les organisations qui pourraient bénéficier de ses services.

Lorsque nous avons commencé le projet, nous avons été confrontés à toute une série de questions : comment
le processus de mise en correspondance devrait-il fonctionner? Les volontaires devraient-ils annoncer leurs
services ? Les organisations doivent-elles promouvoir leurs projets ? Qu'est-ce qui fonctionnerait ?
mieux ? Et après que les parties se soient rencontrées sur le site web, comment devraient-elles
commencer le projet ? Comment les organisations devraient-elles communiquer leurs
besoins ? Comment les bénévoles devraient-ils aborder le travail ? Même les petits
les détails étaient de grandes questions : comment les parties devraient-elles programmer leur premier appel
téléphonique?

Nous avons décidé que c'était le moment parfait pour créer un MVP de Mago de Oz. Nous avons créé un
site web simple, codant à la main seulement les quelques pages statiques dont nous avions besoin
pour donner l'apparence que nous étions ouverts aux affaires. Nous avons commencé avec une douzaine
de páginas en total: una página de índice y luego una página para cada uno de los 12
projets pilotes que nous avions alignés. En coulisses, un administrateur de la
la communauté a rassemblé une liste de bénévoles potentiels et nous leur avons envoyé un e-mail,
en leur envoyant un appel à l'action et un lien vers notre nouveau site. Pour maintenir la
illusion que nous avions un système en cours d'exécution, nous nous sommes assurés que le courrier
électronique semblerait provenir de notre nouveau système, non de l'administrateur de la
communauté.

Lorsque les bénévoles ont cliqué sur le lien dans l'e-mail, ils ont vu notre
site du Magicien d'OzFigure 12-7 ). Quand ils ont utilisé le site pour demander un
opportunité de bénévolat, ils avaient l'impression d'interagir avec le système, mais
detrás de escena, simplemente envió un correo electrónico al administrador de la
communauté et l'équipe. Nous avons suivi toutes nos interactions dans un
tableau Trello simple (Figure 12-8), qui a servi de notre "base de données".

Figure 12-7. Le site du Magicien d'Oz pour la Fondation Taproot

Figure 12-8. Notre "base de données" était simplement un tableau Trello

Nous avons opéré le système de cette manière pendant quelques mois, apprenant progressivement de
nos interactions, en mettant à jour nos processus commerciaux et en ajoutant
automatisation et autres mises à jour du site web au fur et à mesure que nous avons appris. Enfin,
nous avons ajouté un backend fonctionnel réel, éliminant une grande partie de l'aspect de "homme
derrière le rideau" du site. Nous avons également mis à jour le style visuel, en appliquant quelque chose de
pulido maduro en le design graphiqueFigure 12-9 ), après avoir appris ce
suffisant pour comprendre comment communiquer notre marque.
Figure 12-9. Le site de Taproot Plus avec un design graphique plus soigné

En utilisant une approche du Magicien d'Oz, nous avons pu tester les parties à haut risque.
du design (le design des processus commerciaux), apprendre en cours de route et éliminer
el riesgo de gastar mucho tiempo y dinero en diseñar y construir el Cosa incorrecta.

Création de prototypes
L'une des façons les plus efficaces de créer un MVP est par le biais de prototypes de la
expérience. Un prototype est une approximation d'une expérience qui te permet de simuler
comment utiliser le produit ou le service en question. Il doit pouvoir être utilisé dans une variété de
dispositifs cibles. En même temps, leur objectif doit être de dépenser le moins d'effort possible.
possible dans la création du prototype. Cela rend le choix de la technique de création
que les prototypes soient importants.

Le choix de la technique à utiliser pour votre prototype dépend de plusieurs facteurs :

• Qui interagira avec lui ?

• Ce que vous espérez apprendre
• Ce que tu sais déjà être vrai
• Combien de temps as-tu pour le créer

Il est essentiel de définir le public cible pour votre prototype. Cela vous permet de créer le
prototypage le plus petit possible qui générera des commentaires significatifs à ce sujet
audience. Par exemple, si vous utilisez le prototype principalement pour montrer des idées
aux ingénieurs logiciels de votre équipe, vous pouvez largement omettre les domaines principaux
du produit qui ne sont pas affectées par la nouvelle expérience, par exemple, la navigation
global. Ses développeurs savent que ces éléments sont là et qu'ils ne vont pas changer,
donc il n'est pas nécessaire de les illustrer.

Les parties prenantes, souvent moins familières avec leur propre produit que
ils n'admettront jamais, ils auront probablement besoin d'un niveau de fidélité plus élevé dans le prototype
pour comprendre vraiment le concept. Pour satisfaire les divers besoins de ceux-ci
audiences disparates, son kit d'outils de création de prototypes doit être assez
large. Jetons un coup d'œil aux différentes techniques de création de prototypes et
considérons quand utiliser chacune.

Prototypes en papier

Faits des composants les plus accessibles (papier, stylos et ruban), les prototypes de
le papier leur offre la capacité de simuler des expériences de manière rapide, ingénieuse et
divertissante. Aucune investissement numérique n'est nécessaire. En utilisant des tactiques telles que des onglets pour
montrer et masquer différents états sur une page ou même créer une « fenêtre » pour que
fais une présentation de diapositives d'images, tu peux commencer à donner à l'équipe
une idée de la façon dont le produit devrait fonctionner. Vous pourrez avoir une idée immédiate de ce que
est disponible dans l'expérience et ce qui manque. La création de prototypes en papier peut
donner une idée de la façon dont le flux de travail commence à se fusionner autour des éléments
de l'interface qu'il a assemblée. Cette méthode est particulièrement utile avec les interfaces tactiles.
qui nécessitent que l'utilisateur manipule des éléments sur un écran.

Avantages

• On peut créer en une heure.

• Facilement réparé et réorganisé
• Pas cher et facile à jeter si vous vous trompez
• Il peut être assemblé avec des matériaux déjà présents dans le bureau.
• Activité amusante que de nombreuses personnes apprécient
Contras

• L'itération et la duplication rapide du prototype peuvent prendre beaucoup de temps et

résulter en étant ennuyeux.
• La simulation est très artificielle, car elle n'utilise pas les mécanismes de
entrées réelles (souris, pavé tactile, clavier, écran tactile, etc.).
• Le retour d'information se limite à la structure de haut niveau, l'architecture de la
informations et flux du produit.
• C'est uniquement utile avec un public limité.

Maquettes en écran de basse fidélité

Création d'un écran sur lequel on peut cliquer à faible fidélité L'expérience
(wireframes sur lesquels on peut cliquer, par exemple) vous permet de passer à un prototype au
niveau suivant de fidélité. Votre investissement dans les pixels offre une sensation un peu
más realista al flujo de trabajo. Los participantes de la prueba y los miembros del equipo
ils utilisent des mécanismes d'entrée numériques pour interagir avec le prototype. Cela lui permet
obtenir une meilleure perspective et des commentaires sur la manière dont ils interagiront avec le
produit au niveau du clic, du toucher ou du geste.

Avantages

• Fournissez une bonne idée de la durée du flux de travail.

• Révéler les principaux obstacles à l'accomplissement de la tâche principale
• Permettre l'évaluation de la possibilité de trouver des éléments de base
• On peut l'utiliser pour se connecter rapidement à "quelque chose sur lequel on peut cliquer"
pour que votre équipe apprenne de ses actifs existants plutôt que de forcer la création
de autres nouveaux.

Contras

• La plupart des personnes qui interagissent avec ces actifs sont le

suffisamment intelligents pour reconnaître un produit inachevé.
• On accorde plus d'attention que d'habitude à l'étiquetage et à la copie.

Prototypes à l'écran de haute et moyenne fidélité

Les prototypes de fidélité moyenne et haute ont significativement plus de détails que les
prototypes basés sur des wireframes. Ils les utiliseront pour démontrer et tester des conceptions développées
avec un niveau d'interaction, un design visuel et un contenu similaire (ou indistinguable) de la
expérience du produit final. Le niveau d'interactivité qu'il peut créer à ce niveau
varie d'un outil à l'autre ; cependant, la plupart des outils de cet
la catégorie lui permettra de représenter des simulations de pixels parfaits de l'expérience
final. Vous pourrez créer des éléments d'interface comme des champs de formulaire et des menus
des déroulants qui fonctionnent, et des boutons de formulaire qui simulent des actions de
envoi. Certains outils permettent des bifurcations logiques et des opérations de base de
Données. Beaucoup permettent quelques types d'animations mineures, de transitions et de changements.
de l'état.
Avantages

• Produisez des prototypes de haute qualité et réalistes.

• On peut tester le design visuel et les éléments de la marque
• On peut évaluer les interactions du flux de travail et de l'interface utilisateur

Contras

• L'interactivité est encore plus limitée que celle des prototypes entièrement natifs.
• Por lo general, los usuarios no pueden interactuar con datos reales, por lo que
il existe une limite aux types d'interactions de produits qu'il peut simuler.
• Selon l'outil, cela peut prendre beaucoup de temps à créer et à maintenir.
ces prototypes. Cela crée souvent un effort duplicatif pour maintenir un
prototype haute fidélité et le maintenir synchronisé avec le produit réel.

MVP sans code

Il est possible de produire un prototype de votre produit ou service qui est fonctionnel et sans
embargo, n'a aucun aspect visuel semblable au produit final qu'il a en tête. Ceci
se logra convirtiendo lo que se conoce como MVP sin código. Los MVP sin código se
basent sur la large gamme d'outils comme Airtable, Zapier et Webflow qui ne
ils nécessitent le développement de logiciels, mais qui permettent encore de connecter un service qu'ils offrent.
fonctionnalité et, espérons-le, quelque chose de valeur pour les clients et les utilisateurs finaux.

Avantages

• Fournissez un moyen rapide de tester la fonctionnalité avant d'écrire

logiciel personnalisé
• Il vous aide à vous concentrer sur les parties uniques et différenciantes de votre service, sans
perdre du temps à construire une grande quantité d'infrastructures.
• Requiert peu ou pas de compétences en développement de logiciels

Contras

• Difficile de représenter la marque, le design graphique et d'autres points plus fins de

la présentation.
• Difficile à maintenir dans le temps
• Bon marché pour commencer, mais cher à scaler

Prototypes codés et de données en direct

Les prototypes codés offrent le niveau de fidélité le plus élevé pour les expériences.
simulées. À tous égards, les personnes qui interagissent avec ce type de prototype ne
ils devraient pouvoir le distinguer du produit final à moins qu'ils ne rencontrent les limites de leur
portée (c'est-à-dire, cliquant sur un lien vers une page qui n'était pas un prototype). Les
Les prototypes codifiés existent généralement dans l'environnement natif (le navigateur, le système
opératif, sur le dispositif, etc.) et utilisent tous les éléments interactifs
attendus. Les boutons, les menus déroulants et les champs de formulaire fonctionnent
comme l'attendrait l'utilisateur. Ils reçoivent des informations de la souris, du clavier et de la
écran. Ils créent un motif d'interaction le plus naturel possible pour les évaluateurs du
prototype.

En termes de création de prototypes avec des données, il y a deux niveaux de fidélité ici : des données
codifiés (ou statiques) et données en direct. Les prototypes codifiés ressemblent et fonctionnent
comme le produit final, mais ils ne gèrent pas l'entrée, le traitement ou la sortie des données
réelles. Elles ne sont toujours que des simulations et, en général, illustrent certains scénarios
prédéfinis. Les prototypes de données en direct seront connectés à des données réelles, traiteront
l'entrée de l'utilisateur et afficheront les sorties de données appropriées. Ceux-ci sont souvent
implémentant chez des clients réels et offrant un niveau de réalisme aux clients et une vision
de l'utilisation du prototype par des clients qui ne sont pas disponibles dans les prototypes
codifiés. Vous pouvez également les utiliser lors de la réalisation de tests A / B (c'est-à-dire comparer deux
versions d'une fonction pour voir laquelle fonctionne le mieux) certaines fonctions ou changements
dans le flux de travail actuel.

Avantages

• Potentiel de réutiliser le code pour la production

• La simulation la plus réaliste pour créer
• On peut générer à partir d'actifs de code existants.

Contras

• L'équipe peut s'embourber en débattant des points les plus fins du prototype.
• Il faut beaucoup de temps pour créer un code de travail qui offre
l'expérience souhaitée.
• Il est tentant de perfectionner le code avant de le livrer aux clients.
• Mettre à jour et itérer peut prendre beaucoup de temps.

Que devrait inclure mon prototype ?

Vous avez choisi l'outil pour créer votre MVP et vous êtes prêt à commencer. Il n'est pas nécessaire.
créer un prototype de toute l'expérience du produit. Concentrez-vous sur les flux de travail
centrales qui vous permettent de tester les plus grands risques dans votre hypothèse.

Se concentrer sur les flux de travail principaux lors de la création de votre MVP donne à l'équipe une
sensation de vision tunnel temporaire (dans le bon sens !), ce qui leur permet de se concentrer
dans une partie spécifique de l'expérience et évaluer sa validité et son efficacité.

Démos et aperçus

Il est possible que vous ayez développé votre MVP en vous concentrant sur un seul type d'utilisateur ou
seulement un segment de sa base de clients, mais il peut beaucoup apprendre en partageant son
travaille avec ses collègues. Testez votre prototype MVP avec vos coéquipiers, parties
interesadas y miembros de otros equipos. Llévalo a la zona del almuerzo y compártelo
avec quelques collègues qui travaillent sur différents projets. Assurez-vous que,
interne, les gens fournissent des informations à l'équipe sur le bon fonctionnement.
comment ils l'utiliseront et s'il vaut la peine d'investir davantage en lui. Laissez les parties prenantes faire
cliquez dessus et donnez-leur vos points de vue et vos pensées.
Si votre équipe a un jour de démonstration (et si elle n'en a pas, elle devrait le faire), apportez le
prototype là pour montrer les progrès du projet. Plus il reçoit d'exposition, le
MVP, vous aurez plus d'informations sur sa validité. Ensuite, apportez votre prototype à
clients et clients potentiels. Permettez-leur de cliquer sur l'expérience et de recueillir leurs
commentaires.

Exemple : utilisation d'un prototype de MVP

Voyons comment une équipe avec laquelle nous avons travaillé récemment a utilisé un prototype de
MVP. Dans cette étude de cas, l'équipe envisageait de faire un changement
significatif dans son offre. Nous utilisons un prototype de MVP pour soutenir le processus de
recherche et prise de décision.

Ce démarrage établi avait des difficultés avec son produit actuel : un

communauté basée sur un abonnement exclusif pour la collaboration en groupe. J'avais été
sur le marché pendant quelques années et a eu un certain élan initial, mais l'adoption s'est
s'était stagné : les nouveaux utilisateurs ne s'inscrivaient pas. De plus, le produit se
faisait face à une concurrence de plus en plus forte. Réalisant qu'il était nécessaire d'un
changement radical, l'équipe a envisagé de renouveler son modèle économique et d'ouvrir le produit à
un segment de marché significativement plus large. Sa préoccupation était double :

1. Les utilisateurs actuels accepteraient-ils ce changement, puisqu'il altérerait le caractère

exclusif à la communauté ?
2. Le nouveau segment de marché serait-il intéressé par ce type de produit ?

L'équipe s'inquiétait de recevoir un double coup. Ils craignaient que les utilisateurs
les existants abandonneront le produit et qu'il n'y aurait pas assez de nouveaux utilisateurs pour
compenser le déficit.

Nous avons travaillé avec l'équipe pour définir notre plan comme une hypothèse. Nous avons conçu le nouveau
segment de marché et nous avons défini l'ensemble de fonctionnalités de base que nous voulions
leur offrir. C'était un sous-ensemble de la vision définitive, mais cela pourrait être démontré dans
cinq wireframes.

Nous avons passé une semaine à créer les maquettes pour nous assurer que nos
les développeurs, les spécialistes du marketing et les dirigeants étaient engagés avec la
nouvelle adresse. Nous montrons les wireframes aux clients actuels, obtenant deux tours
des commentaires des clients au cours de ces cinq jours, et nous avons terminé avec un
prototype cliquable : notre MVP.

Le moment de notre expérience était fortuit : il y avait une conférence pleine de clients
potentielles programmées pour la semaine suivante au Texas. L'équipe est allée à la conférence
y caminó por los pasillos del centro de convenciones con el prototipo en nuestros iPads.

Les maquettes ont très bien fonctionné sur les iPads : les clients ont touché, glissé et
Ils ont discuté avec nous de la nouvelle offre. Trois jours plus tard, nous sommes revenus en ville.
de New York avec des commentaires écrits sur chaque note adhésive et morceau de papier qui
nous avons pu trouver.
Nous avons classé les notes en groupes et quelques thèmes clairs ont émergé. Les commentaires de
les clients nous ont permis de conclure que, bien que ce nouveau plan d'affaires ait ses
mérites, nous devrions nous différencier davantage des produits existants sur le marché si
nous voulons réussir.

En total, nous avons passé huit jours ouvrables à développer nos hypothèses, à créer notre
MVP et en obtenant des retours du marché. Cela nous a placés dans une excellente position
pour changer notre position et affiner le produit afin qu'il s'adapte à notre segment
de manière plus efficace.

1GiffConstable, « La courbe de la vérité », 18 juin 2013[Link] .

Chapitre 13. Tout réunissant
Dans cette section, nous avons présenté toutes les techniques principales du Lean UX, depuis
encadrer son travail comme une déclaration de problème commercial jusqu'à définir le succès
en termes de résultats tant pour l'entreprise que pour l'utilisateur. Nous vous montrons comment
capturer l'essence de ce qu'il sait sur ses utilisateurs en tant que protopersonas. Nous avons parlé
sur comment commencer à découvrir leurs solutions. Et nous avons partagé des façons d'écrire
et de tester vos hypothèses. Lean UX Canvas vous offre une façon concise et d'une seule page
d'organiser son travail tout en appliquant ces techniques dans le monde réel.

Ceci dit, le monde réel est un endroit désordonné, et chaque projet sur lequel vous travaillez
será desordenado a su manera. (¡Esa es una de las razones para usar el lienzo en primer
Endroit !) Pour conclure cette section, nous avons pensé partager quelques histoires d'équipes
que utilisent Lean UX dans ce monde réel si désordonné. Vous verrez à quel point Lean fonctionne bien
UX; de hecho, lo adecuado que es para abordar el desorden del mundo real.

Dans ces histoires, vous verrez que certaines de ces équipes ont utilisé la toile. D'autres simplement
ils ont utilisé certaines des techniques Lean UX qui sont intégrées dans la toile, sans utiliser le
lienzo en soi pour organiser son travail. Comme nous l'avons dit précédemment, c'est bien. Prenez ces
outils et faites-en votre propre. Nous espérons que ces histoires vous fourniront quelques idées et
inspiration sur comment faire précisément cela.

Le canevas Lean UX dans l'entreprise

Récemment, nous avons entendu un responsable produit et design dans une grande entreprise de
logiciel d'entreprise à Silicon Valley. Cette entreprise développe une plateforme de
informatique en nuage pour aider les entreprises à gérer les flux de travail
numériques pour les opérations commerciales. Ils ont pris contact car ils voulaient
Racontez-nous comment vous aviez utilisé la toile Lean UX pour lancer des projets et des nouvelles
initiatives. Nous pensions que c'était une belle histoire à partager.

Une équipe de cette entreprise travaillait sur le deuxième lancement d'un produit.
qu'il avait reçu de bons commentaires de la part des clients. Le produit avait une forme
novedosa de mostrar datos : un écran qui était vraiment magnifique, qui a bien fonctionné et
qui a généré des commentaires vraiment positifs de la part des clients. Le produit a utilisé un
élément d'interface utilisateur inhabituel : une carte personnalisée qui a aidé les utilisateurs
à visualiser les processus de travail et à détecter des opportunités pour améliorer les processus.

En plus de générer des commentaires positifs des clients, cette interface utilisateur se
montra très bien en interne. Les parties prenantes adorent et soutiennent l'idée de
l'améliorer. Il semblait donc naturel de tirer parti du succès de cette fonction dans la
prochaine version et, en fait, c'est ce que l'équipe prévoyait de faire : réellement se
soutiendrait cette fonction pour la deuxième version.

Néanmoins, ils avaient récemment découvert Lean UX Canvas comme un outil.

y les gustó la forma en que estimuló el pensamiento metódico sobre el trabajo que
ils avaient besoin de faire. Ils ont décidé de travailler à travers un Lean UX Canvas pour cela
initiative. Quand ils l'ont fait, quelque chose d'intéressant s'est produit. Quand ils sont arrivés auCapítulo 8,
tuvieron un gran avance.

Para completar el Cuadro 4, el equipo tuvo que volver a los datos de retroalimentación
que déjà avaient été recueillies auprès des clients. Cela arrive souvent lorsque vous travaillez dans un
Lean UX Canvas : vous devez trouver les informations dont vous avez besoin pour compléter un
section. Parfois, cela signifie que vous devez effectuer des recherches supplémentaires et, parfois,
cela signifie simplement qu'il doit revoir la recherche qu'il a déjà effectuée.

Dans ce cas, lorsque l'équipe a examiné ses données, elle a remarqué un modèle important dans les
commentaires des utilisateurs qui avaient été négligés : les clients leur disaient que les
j'aimais la carte, mais ils voulaient plus du produit que simplement la visualisation
de données. Ils voulaient que le produit soit plus proactif. En gros, ils disaient : "L'écran
elle est vraiment belle, mais nous voulons qu'elle se démarque là où nous devrions prêter attention.

Le processus de compléter un Lean UX Canvas a obligé l'équipe à s'arrêter et à examiner

méthodiquement les données qu'ils avaient compilées. Un membre de l'équipe m'a dit : « De
En fait, nous avions le retour. Nous ne l'écoutions tout simplement pas !
Il continua : "Quand nous utilisons la toile pour examiner les données sur ce qui était
matériellement important pour nos clients, nous nous sommes rendu compte que simplement
nous avions ignoré les données.

Ainsi, l'équipe a consacré du temps à interpréter ces commentaires. Réellement

ils ont enquêté et résolu ce qu'ils pensaient que signifiaient les commentaires et ce que
signifiaient sur les résultats que les clients recherchaient. Lorsqu'ils sont revenus aux
clients pour valider ces idées, les clients ont répondu positivement.

Après cela, l'équipe a pris une décision facile : ils avaient besoin de changer leurs
priorités. Un membre de l'équipe nous a dit que la conversation dans l'équipe était
clara. "Quand le vote a été réduit, il ne s'agissait pas d'améliorer la carte ; c'était 'faisons le
que nos clients considèrent vraiment précieux.

Dans le pilote du deuxième lancement, "nous avons obtenu des notes vraiment élevées de
nos clients". Ces évaluations élevées ont aidé l'équipe à réussir un lancement
général encore plus rapide. "Nous sommes probablement arrivés là-bas six mois plus tôt grâce à cela.
commentaires

Validément : Validation de votre

produit avec des interviews de clients et un
prototypage de deux jours
L'entrepreneur en série Steven Cohn a eu l'idée de lancer Validamente en raison des défis
que a affronté en tant qu'entrepreneur en réalisant sa propre recherche d'utilisateurs. Quand
Il a examiné le panorama et a découvert que d'autres chercheurs d'utilisateurs avaient des défis.
similaires. Les chercheurs d'utilisateurs avaient l'habitude d'utiliser des outils gratuits comme
Skype et Google Docs pour réaliser ses études. Il savait que ces outils n'étaient pas
conçues pour la recherche d'utilisateurs et rendaient le processus
inefficace. Certains équipements ont complété ces outils avec le fournisseur de
services les plus connus du secteur,[Link]. Je savais qu'il y avait ici une
opportunité.

Steven et son équipe ont utilisé des entretiens avec les clients pour découvrir les besoins et
objectifs de cet utilisateur (Tableau 4 du Lean UX Canvas). Dans ces conversations,
ils ont découvert où ils devraient se concentrer quand on a demandé aux chercheurs ce que
ils font avec les résultats que leurs études ont générés. "C'est là que se trouve la majeure partie
de mon travail”, lui ont-ils dit. En fait, il a découvert que la majeure partie du travail des
les chercheurs commençaient une fois la recherche réelle terminée.

L'équipe de Validately a appris qu'après un tour d'entretiens avec les

clientes o pruebas de usabilidad, los investigadores tuvieron que volver a un documento
de notes Google longues et désorganisées et connecter ces notes avec les horodatages
dans la vidéo de l'étude. Ils utiliseraient ces marques temporelles (et un type d'outil de
édition de vidéo) pour créer des clips vidéo, assembler ces clips dans un montage en vedette
y finalmente compartir ese carrete con sus equipos, clientes y partes interesadas. Todo
esto solo para compartir lo aprendido durante el estudio.

L'équipe a réalisé des dizaines d'entretiens pour valider ce problème. Ils ont appris que ce
travail, la création de rapports et de vidéos en vedette, représentait souvent plus de
50 % de l'effort total consacré à chaque étude. Je savais que j'avais trouvé un problème.
qui valait la peine d'être résolu.

L'étape suivante a été de travailler sur la solution. (Encadré 5 du Lean UX Canvas). Steven et
votre équipe a créé un prototype dans InVision qui a formulé l'hypothèse de ce à quoi cela ressemblerait une
outil optimisé qui combinera la prise de notes, le suivi du temps et la
création de rapports et de mises en évidence. Ils ont passé deux jours à créer ce prototype avant de
le montrer aux clients.

Le prototype a répondu presque sans aide à la question "Comment es-tu meilleur"

[Link] fois que les clients potentiels ont vu la valeur de la
outil optimisé que Validately souhaitait construire, ils s'intéressèrent à
immédiat. À ce stade, Steven et son équipe ont demandé un type de plus de
« rétroaction ». On a demandé aux gens de s'engager dans l'acte, à acheter
un produit pas dans le futur mais maintenant, même s'il n'était pas prêt pour son
livraison. Le contrat offrait une clause d'annulation si la livraison n'était pas effectuée, mais
pour le reste, Steven a utilisé le prototype comme outil de vente pour un service qui
n'existait pas encore. Le lancement a fonctionné, ce qui a aidé à valider avec validité que son
la solution était correcte. Ils ont converti suffisamment de clients pour construire une entreprise
prospère dans les écarts entre des outils gratuits comme Google Docs et
Skype. A validement rencontré un grand succès, et a finalement été vendu à UserZoom en
2019.

Les MVP utilisés ici (conversation avec le client suivie d'un prototype de deux
jours) ont aidé Steven et l'équipe à rassembler trois niveaux de validation :

Temps
 Est-ce que les gens nous donneront 30 minutes de leur temps pour discuter de ce problème ?
au contraire, le problème que nous résolvons n'est pas suffisamment
important pour eux et probablement ce ne sera pas un espace dans lequel nous voulons jouer.

Social

Les personnes avec lesquelles nous parlons le porteront à leur patron, équipe, sécurité de
informations, acquisitions et autres dans l'organisation ? Vont-ils le socialiser et le
respaldarán internamente? Para entender esto, siempre preguntaban: "¿Me
présentera à d'autres personnes de l'organisation qui pourraient être intéressées par
cet outil ?" Encore une fois, si cela n'a abouti à aucune présentation, aussi
c'était un signe.

Argent

Si el cliente potencial da su tiempo y su reputación, se le pedirá que compre. Esta

c'est la validation définitive, car cela a réellement abouti à une vente.

Préparation pour l'examen de Kaplan :

utilisation de Lean UX pour lancer un nouveau
affaires
Kaplan Test Prep a aidé des étudiants aux États-Unis à se préparer pour
tests standardisés comme des examens d'entrée à l'université et à l'école de
médecine depuis 1938. Maintenant, avec l'éducation se transformant presque chaque année, Kaplan
vous devez sans cesse réinventer la façon dont vous offrez de la valeur à vos clients. Lee Weiss,
actuellement vice-président senior de l'entreprise, il a aidé Kaplan à faire
exactement cela depuis plus de 20 ans. Plus récemment, à l'automne 2018, Lee
il a commencé à penser à une nouvelle idée pour réinventer le business des associations
universitaires de Kaplan. Je voulais permettre aux universités de créer des cours en
ligne pour les étudiants du secondaire sur des sujets de préparation universitaire et
professionnel.

Son idée était de créer une manière sûre pour que les élèves de secondaire apprennent sur
plusieurs carrières professionnelles et essayez différentes universités en même temps. Lis et
ses collègues ont passé plusieurs semaines à esquisser quelques idées sur la façon dont cela pourrait fonctionner
cela et ont exprimé leurs pensées sur une plateforme PowerPoint. Ce tas se
se transforma en son premier experimento, son MVP, pour les aider à tester leur première
hypothèse : que les leaders seraient intéressés par leurs plans.

Au début de 2019, ils se sont réunis avec l'équipe de direction pour tester leur idée.
Les leaders de Kaplan étaient enthousiastes à propos de cette nouvelle idée et ont donné à Lee et à
sa collègue Liz Laub a donné le feu vert pour se concentrer uniquement sur cette nouvelle idée. L'équipe
Le leadership de Kaplan a dit à Lee et Liz : "Prends les 90 prochains jours et vois si tu peux
faire décoller ce concept.
Lee et Liz ont commencé par poser la première question clé de Lean UX : Qu'est-ce qui est le plus
Quelle est l'importance que nous devons d'abord apprendre ? (Encadré 7 dans le Lean UX Canvas).

Ils ont réalisé qu'ils n'auraient pas du tout d'affaires si je ne pouvais pas obtenir que
aucune université ne s'intéressera. Avec son plus grand risque identifié, ils ont pu passer à la
deuxième question clé de Lean UX : Quelle est la moindre quantité de travail que
que devons-nous faire pour l'apprendre ? (Encadré 8 dans Lean UX Canvas).

Ils ont commencé à parler avec des universités pour voir si elles seraient intéressées à s'associer avec
ils dans cette initiative, bien que l'initiative elle-même n'existait pas encore. En 90 jours, l'équipe
J'avais parlé à 20 universités différentes et j'ai fini avec 2 des universités les plus
grandes des États-Unis. Intéressées par l'idée, tout au long d'une conversation simple
y, parfois, fortuite. C'était une grande nouvelle, car cela donnerait à Lee et Liz suffisamment
informations pour faire une demande plus détaillée à la direction. Une demande de
budget pour lancer un produit sur le marché.

Cependant, avant qu'ils ne puissent faire cela, il y avait d'autres questions qui devaient
répondre : comme que voudraient les étudiants et les parents ? Comment serait leur
solution ? (Ce sont les types de questions que capture le Cadre 7 du canevas).

C'est ici que les obstacles ont commencé à apparaître : ses suppositions sur son offre de
produits (Chapitre 9 ) ont commencé à s'écraser contre les rochers de la
réalité. Au départ, ils espéraient construire un produit qui permettrait aux enseignants et
les étudiants interagissent ensemble en temps réel. Malheureusement, les fuseaux horaires se
ils ont mis en travers du chemin, quelque chose qu'ils ont rapidement appris à travers des conversations
tôt et continues avec les étudiants. Ils sont donc passés à des cours asynchrones et
rapidement ils ont été confrontés à un nouveau défi : comment créer un cours attrayant et de grande
valeur.

Ils ont supposé que la meilleure façon de le faire serait de construire des communautés basées sur
cohortes. Ils ont mis à l'épreuve leurs suppositions en commençant à créer des versions antérieures de cela.
offre. Bien que cela ait reçu un retour très positif de la part des étudiants qui
participé aux épreuves, il y avait encore une demande tant de la part des parents que des
étudiants pour recevoir des tutorats et un soutien en direct. Ils ont abordé cela en recrutant des anciens élèves
de ces universités comme mentors. Ces pièces ont été à la base d'un produit qui
a satisfait des besoins à la fois synchrones et asynchrones.

Había una última pieza del rompecabezas que tenían que explorar en su período inicial
de 90 jours, cependant : ses hypothèses sur le type d'organisation dont ils auraient besoin pour
construire et soutenir cette entreprise. Cela ne leur ferait aucun bien de résoudre ce besoin dans le
marché avec un produit attrayant s'ils ne pouvaient pas créer une entreprise viable et
durable. (Ces considérations sur la conception du service doivent faire partie de la
définition de sa solution dans le Encadré 5).

Ici encore, l'équipe a fait une série d'hypothèses sur qui elle aurait besoin.
embaucher, comment ils devraient fixer le prix du produit, combien cela coûterait de l'exécuter et, par
supposé, quelle forme devrait adopter le produit. Lee observe que presque tous ces
les suppositions étaient incorrectes rétroactivement, mais maintenant ils avaient suffisamment d'informations
pour revenir au leadership avec une demande plus détaillée : une demande de devis ($
700 000 pour être exact) pour construire le produit et le commercialiser. La demande était
approuvée, avec une réserve : elle a un an pour couvrir les frais.

L'équipe a commencé. En utilisant rien d'autre que des conversations avec des étudiants, des enseignants et
administrateurs dans leurs deux clients (maintenant signés), l'équipe a élaboré un programme d'études
initial de trois cours. L'objectif était de faire des cours de la plus haute qualité possible le plus
le plus rapidement possible.

Avec le programme d'études établi, l'équipe avait besoin de systèmes d'exploitation pour
soutenir le travail : CRM, systèmes de gestion de l'apprentissage, systèmes de gestion de
contenu, etc. Ils ont recherché des systèmes avec le mandat d'utiliser ce qui les mettrait en marche
plus rapide. Ils ont réuni une expérience légère en utilisant des produits SaaS, tout en dehors du
écosystème technologique de Kaplan, ce qui aurait ralenti sa capacité à exécuter
tests rapides. (C'est une grande utilisation de la technique MVP sans code).

Le premier cours de deux semaines avait huit étudiants, tous d'entre eux ont obtenu le
cours gratuit. Les huit ont terminé le cours et ont donné un retour positif fort
sur la qualité du produit et l'expérience générale. Maintenant était le moment d'acquérir
la première cohorte payée. Au début, il n'y avait pas beaucoup d'intérêt. Lee, Liz et l'équipe
commençaient à s'inquiéter. Sa demande était longue, le coût était élevé et les frais de demande
de 50 $ qu'ils avaient vus ailleurs et copiés dans leur produit semblaient empêcher que les
des clients potentiels enverront leurs demandes.

Les expériences suivantes étaient claires pour l'équipe : supprimer le droit de demande,
raccourcir le processus de demande et réduire le prix. Ils ont pu faire cela en deux
raisons. Tout d'abord, parce qu'ils étaient une équipe d'innovation interne, ils avaient l'autorité
pour prendre des décisions sur l'exploration des prix. Ils ont donc réduit leurs prix à la
mi-temps. La deuxième raison pour laquelle ils pourraient ressentir cela ? Ils travaillaient sur
sprints d'une semaine. Donc, même si une décision a été catastrophique, le maximum que
ils ont dû vivre avec elle pendant une semaine.

Cependant, l'équipe n'a pas eu à attendre longtemps. Le jour où ils ont fait les changements,
ils ont reçu plus de demandes que les deux semaines précédentes réunies. Les revenus par
les ventes ont quintuplé. À mesure que le produit a connu une traction plus forte, l'équipe
il a commencé à s'inquiéter de maintenir la qualité du produit à mesure que
ils escaladaient. Ils ont défini un ensemble de métriques basées sur les résultats pour guider leur prise de décision.
de décisions et maintenir une qualité élevée : ils voulaient s'assurer que tous les étudiants
ils se connecteront dans les 48 heures suivant le début de tout cours, ils voulaient
voir un taux d'achèvement du cours de 80 %, et je voulais maintenir un Net Promoter Score
(NPS) de 50.

En utilisant les résultats comme votre étoile du nord, la prise de décision basée sur la
l'évidence comme moteur et les cycles courts pour rester sur la bonne voie, l'équipe
il a réussi à construire une unité commerciale qui emploie maintenant plus de 30 personnes.
Ils ont démontré que suivre les données et l'instinct et escalader lentement les décisions le
permet de réaliser les meilleures corrections de cap tout au long du chemin. Quand
combinez ces données avec une équipe autonome et un mandat clair et basé sur les résultats,
les résultats parlent d'eux-mêmes.
Partie III. Collaboration
C'est mardi, et Rick, Mark, Olga et Arti sont debout devant le tableau, regardant une structure.
de fil qu'ils ont dessiné. Arti, la designer, a un marqueur dans la main, mais pas
dessine. Rick, je ne comprends pas ce que tu veux dire. Peux-tu expliquer le problème ? " elle demande.

Rick prend le marqueur, nettoie une section du tableau et réexplique le

règlement. L'équipe conçoit une application pour les opérateurs de bourse, et la
l'application doit obéir à un ensemble strict de réglementations. Rick, l'analyste de
Les affaires, est responsable de s'assurer que les conceptions de l'équipe soutiennent les règles.

Au bout d'un moment, l'équipe acquiesce et Arti reprend le marqueur. Elle suggère un
changement dans la conception de la structure métallique de l'application sur le tableau, et l'équipement
asiente à nouveau. Tout le monde sort ses iPhones, prend des photos du tableau et convient de revenir.
à se réunir le lendemain. Ils ont confiance que ce qui a été convenu sera prêt pour que les
les utilisateurs les essaient jeudi.

Arti revient à son bureau pour commencer à détailler le design qu'ils ont esquissé. Mark,
le développeur frontend commence à construire la page ; il utilise des composants du Design
Système que l'équipe a construit, donc il n'a pas besoin d'attendre Arti avant de mettre
les pièces de base à leur place. Rick ouvre la page wiki du projet et commence à
documenter les décisions que l'équipe a prises concernant le comportement de la
application. Il examinera ces options avec le propriétaire du produit plus tard dans le
jour. Et Olga, la testeuse de contrôle de qualité, commence le processus d'écriture de tests pour
la nouvelle section de l'application.

C'est le rythme du quotidien de Lean UX : une équipe qui travaille de manière collaborative,
itérative et en parallèle, avec peu de transferts, des livrables minimaux et un accent sur le
logiciel de travail et le retour du marché. Dans cette section, vous verrez comment se
faire.

À propos de la Partie III

Dans la partie précédente, nous avons analysé les idées derrière Lean UX : les principes qui le motivent.
le travail. Dans cette section, nous devenons très pratiques et décrivons en détail le
processus de faire Lean UX.

Le processus Lean UX

Le Chapitre 14, Conception collaborativeparle d'un des éléments principaux de

Lean UX : la façon dont elle favorise la collaboration interfonctionnelle. Elle encourage les
des designers à travailler avec leurs collègues qui ne sont pas designers pour créer les meilleurs
produits possibles. Ce chapitre parlera de certaines des formes les plus importantes dans
que le faisons.

Le Chapitre 15,Rétroaction et recherche, traite de la façon dont Lean UX plaide

pour la recherche continue et la recherche collaborative. Cela peut sembler un
changement pour de nombreuses équipes, c'est pourquoi nous avons discuté de certaines des choses clés que
vous aurez besoin de savoir ici.

Le Chapitre 16,Intégration de Lean UX et Agile, parle de la façon dont ils fonctionnent ensemble
métodos Lean UX y Agile. Agile es uno de los pilares fundamentales de Lean UX. Lean
L'UX est née de la nécessité de travailler avec des équipes de développement de logiciels agiles, une
lucha que muchos diseñadores enfrentan a diario. Este capítulo le ayudará a navegar.
Chapitre 14. Conception collaborative
Soyez ouvert à la collaboration. D'autres personnes et les idées d'autres personnes ont souvent
être meilleurs que les tiens. Trouve un groupe de personnes qui te défient et t'inspirent,
passe beaucoup de temps avec eux et cela changera ta vie.

Amy Poehler

Qu'est-ce qu'une "expérience utilisateur" ? C'est la somme totale de toutes les interactions qu'un
L'utilisateur a avec son produit et son service. Cela se crée à partir de toutes les décisions que vous prenez.
et son équipe prennent sur son produit ou service : la manière dont il fixe le prix, la façon
la manière dont il l'emballe et le vend, la façon dont il intègre les utilisateurs, la façon dont
le soutient, le maintient et le met à jour. Et ainsi de suite et ainsi de suite. Dans d'autres
mots, cela est créé par une équipe, pas par un designer individuel. Pour cette raison, Lean UX
commence par l'idée que la conception de l'expérience utilisateur doit être un processus
collaboratif.

Lean UX réunit des designers et des non-designers en co-création. Cela produit des idées qui sont plus
grandes et meilleures que leurs contributeurs individuels. Cependant, pour être clair, pas
estamos abogando por el “diseño por comité”, una frase que implica un proceso lleno de
mauvais compromis et prise de décision désinformée. En revanche, les processus Lean
UX son orquestés et facilités par des concepteurs et exécutés par des spécialistes en
une discipline qui travaille à partir d'un manuel de jeu commun. Lean UX augmente la propriété
de votre équipe sur le travail en offrant une opportunité pour que les points de vue
les individus se partagent de manière précoce et continue tout au long du processus. Dans
en dernière instance, il s'agit d'utiliser l'expérience diversifiée de votre équipe pour créer des conceptions
quefuncionen.

En este capítulo, exploraremos los muchos beneficios que se derivan de esta estrecha
collaboration multifonctionnelle.

Allons approfondir...

Conception collaborative
Dans leChapitre 10 , il a appris sur les hypothèses. Pour tester ses hypothèses, parfois
réalise simplement une recherche (décrite dans leChapitre 12 ).Mais d'autres fois,
vous devez concevoir et construire quelque chose qui vous aide à tester ces hypothèses. Par exemple, si vous
trouvez à la phase initiale d'un projet, vous pouvez tester la demande en créant une page
de destination qui mesure combien de clients s'inscrivent à son service. Ou s'il se trouve plus
avançant dans le cycle de vie du produit, il se peut que vous travailliez au niveau de
fonctions, par exemple, en ajoutant quelques nouvelles fonctions qui feront en sorte que les utilisateurs
soyez plus productifs. Parcourez les nombreuses options de design possibles pour cela
les fonctions peuvent s'avérer difficiles pour les équipes. À quelle fréquence avez-vous expérimenté
conflits d'équipe concernant les options de conception ?

La forme la plus efficace que nous avons trouvée pour rassembler une équipe autour d'un
la direction du design passe par la collaboration. À long terme, la collaboration produit
meilleures résultats que le design basé sur les héros (la pratique de faire appel à un designer ou
équipe de design pour qu'elle vienne, propose quelque chose de beau et décolle pour sauver le
prochain projet). Les équipes apprennent rarement ou s'améliorent en travaillant avec des héros. Dans
changement, de la même manière que la création conjointe d'hypothèses augmente le coefficient
l'intellectuel du produit de l'équipe, la conception conjointe augmente le quotient intellectuel
de conception de l'équipe. Permet à tous les membres de l'équipe d'articuler leurs idées. Offre
aux designers un ensemble d'idées beaucoup plus large sur lequel se baser pendant que
ils perfectionnent le design. Cela, à son tour, augmente les sentiments d'appartenance de tout le
équipe au travail. Enfin, le design collaboratif génère une compréhension
partagé au sein de l'équipe. Cette compréhension partagée est la monnaie d'échange de
Lean UX. Moins l'équipe comprend collectivement, moins elle devra
documenter pour aller de l'avant.

La conception collaborative est une approche qui permet à une équipe de concevoir ensemble. Cela aide à
équipements à développer une compréhension partagée à la fois du problème de conception et de
la solution. Elle leur fournit les moyens de travailler ensemble pour décider ce que
la fonctionnalité et les éléments d'interface mettent mieux en œuvre la caractéristique souhaitée
créer.

Le design collaboratif reste une activité dirigée par des designers. C'est le
la responsabilité du designer n'est pas seulement de convoquer des réunions de design collaboratif, mais
aussi les rendre accessibles. Parfois, tu auras des discussions informelles et des sessions de dessin. Parfois,
sessions individuelles plus structurées avec un développeur sur un tableau. D'autres fois,
réunira toute l'équipe pour un exercice d'étude de conception ou même un Sprint de
design. La clé est de collaborer avec un groupe diversifié de membres de l'équipe.

Lors d'une session typique de design collaboratif, les équipes dessinent ensemble, critiquent le travail.
au fur et à mesure qu'elle émerge et, en fin de compte, convergent vers une solution qu'ils considèrent que
a les plus grandes chances de succès. Le designer, tout en continuant à produire
conceptions, assume le rôle supplémentaire de facilitateur pour diriger l'équipe à travers une série
d'exercices.

Le résultat de ces sessions consiste généralement en des croquis en basse fidélité et

structures filaires. Ce niveau de fidélité est important. D'abord, il permet que
tout le monde contribue, même les membres de l'équipe avec moins de compétences en dessin
sophistiquées. Deuxièmement, il est essentiel de maintenir la malléabilité du
travail. Cela donne à l'équipe la capacité de pivoter rapidement si ses tests révèlent
que el enfoque no está funcionando. Es mucho más fácil pasar de un enfoque fallido si no
il a consacré trop de temps à dessiner, documenter et détailler laborieusement cela
approche.

Conception collaborative : l'approche informelle

Il y a quelques années, Jeff concevait un panneau pour une application web destinée à la
audience de recruteurs et d'employeurs de TheLadders. Il y avait beaucoup d'informations pour
tenir sur un écran, et j'avais du mal à faire en sorte que tout fonctionne. Au lieu de passer
trop de temps à son bureau à appuyer sur des pixels, il a pris un tableau blanc et a demandé à
Greg, le développeur principal, qui s'est joint à lui. Jeff a esquissé son idée originale sur
comment concevoir tout le contenu et la fonctionnalité de ce tableau (consultez leFigure 14-
1). Puis, les deux ont discuté de l'idée et, finalement, Jeff lui a remis le marqueur à
Greg. Il a esquissé ses idées sur le même tableau. Ils sont allés d'un côté à l'autre, et finalement
ils ont convergé vers un design et un flux qu'ils pensaient utilisables et réalisables, étant donné que
ils devaient offrir une solution dans le sprint actuel de deux semaines. À la fin de cela
séance de deux heures, ils sont retournés à leurs bureaux et ont commencé à travailler. Jeff a affiné le
boceto dans une structure filaire et un flux de travail plus formel, tandis que Greg
il a commencé à écrire le code d'infrastructure nécessaire pour transférer les données que
ils avaient besoin de la couche de présentation.
Figure 14-1. Exemples de croquis sur tableau noir

Ils avaient construit une compréhension partagée à travers leur session de conception.
collaboratif. Les deux savaient ce qu'ils allaient construire et ce que devait faire la
fonction. Ils n'ont pas eu besoin d'attendre pour le documenter. Cela leur a permis de construire le
première version de cette idée dans un délai de deux semaines.
CONVERSACIÓN:SUHERRAMIENTAMÁSPODEROSA

Lean UX promeut la conversation comme principal moyen de communication entre les

membres de l'équipe. De cette manière, cela est très en ligne avec le Manifeste Agile, qui
promote "individus et interactions plutôt que processus et outils". La conversation
rassemble une équipe autour d'une vision partagée. Apporte également des connaissances de
différentes disciplines au projet bien avant ce qu'autoriserait un cycle de conception
traditionnel. Au fur et à mesure que de nouvelles idées se forment ou que des changements sont apportés au design, le
la perception d'un membre de l'équipe peut rapidement contester ces changements d'une
manière que le designer n'aurait pas reconnu par lui-même.

En ayant ces conversations tôt et fréquemment, l'équipe est au courant de la

idées de tous et peuvent commencer par leur propre travail avant. S'ils savent que la solution
la proposition nécessite une infrastructure backend déterminée, par exemple, les
Les ingénieurs de l'équipe peuvent commencer ce travail pendant qu'il est affiné et finalisé.
conception. Les trajectoires parallèles pour le développement et la conception de logiciels sont le chemin le plus rapide
pour parvenir à une expérience réelle.

Ces conversations peuvent sembler inconfortables au début ; après tout, tu es

démolissant des murs éprouvés par le temps entre les disciplines. Cependant, à mesure que la
la conversation évolue, les concepteurs fournissent aux développeurs des informations sur
la mise en œuvre de certaines fonctions, ce qui garantit l'évolution appropriée de son
vision. Ces conversations favorisent la transparence du processus et le progrès. Ce
la transparence crée un langage commun et des liens plus profonds entre les membres du
équipe. Les coéquipiers qui se font confiance sont plus motivés à travailler.
ensemble pour produire un travail de meilleure qualité.

Trouvez des moyens d'avoir plus de conversations avec vos coéquipiers, à la fois
relatifs au travail comme non. Le temps consacré à cultiver des liens sociaux avec son
Équipe (manger ensemble, par exemple) peut faire en sorte que les conversations liées à
le travail soit plus facile, plus honnête et plus productif.

Lean UX y Design Sprints

Dans le Chapitre 9, nous avons écrit sur un exercice appelé "Étude de conception". C'est un
excelente manera de reunir un equipo para una sesión de diseño estructurada. En los
Au cours des dernières années, un approche similaire appelée "Design Sprint" a gagné en popularité. Décrit
en el libroSprintde Jake Knapp, John Zeratsky y Braden Kowitz (Simon y Schuster), un
le sprint de design est un processus de cinq jours qui réunit une équipe, définit une question,
développe des idées, construis un prototype et teste-le : tout en une seule semaine. Les Design
Sprints son como un estudio de diseño con esteroides. O como un mini ciclo de trabajo
Lean UX. En ayant facilité certains des nôtres, nous avons vu à quel point c'est puissant.
cela peut être ce processus. Si vous cherchez à mettre en place une équipe, un projet ou une
initiatif, un Design Sprint est un excellent moyen de le faire.1

Cela dit, il y a certaines parties peut-être contradictoires des méthodes. Lean UX a une
une façon particulière de cadrer les problèmes, par exemple. Les Sprints de design cadrent
les problèmes depuis le premier jour en utilisant une méthode différente. Lean UX recommande
hypothèses, expériences et MVP pour tester vos idées. Les Design Sprints amènent les équipes
à travers la création de prototypes et les tests durant les derniers jours du sprint de
une manière qui n'utilise pas d'hypothèses ou le mot MVP. Donc, parfois, il semble que les
les méthodes sont en conflit.

Notre perspective est que les méthodes sont profondément compatibles dans l'esprit, sinon
dans la pratique exacte. Si vous pouvez embrasser l'esprit des méthodes, les Design Sprints s'adapteront.
très bien dans une approche Lean UX.

Ceci dit, nous voulions en apprendre un peu plus, alors nous avons contacté Jake Knapp
pour parler de certaines de nos questions.

LEANUXETDESIGNSPRINTS:UNECONVERSATIONAVECJEFF,JOSHETJAKEKNAPP

Beaucoup de gens ont des questions sur la façon dont Lean UX et le Design fonctionnent ensemble.
Sprints. Avez-vous un point de vue sur cette question ?

Jake Knapp : Pour moi, Lean UX est comme un livre de cuisine que l'on peut utiliser tout au long du cycle.
de son produit et dans toute son organisation. Les Design Sprints sont une recette unique, quelque
très spécifique pour un moment spécifique avec une partie spécifique de son équipe. Les
les philosophies sont totalement compatibles. Quiconque est familièrement avec Lean UX
je devrais consulter les Design Sprints et vice versa.

P : Quelle flexibilité y a-t-il dans la recette du Design Sprint ? Pouvons-nous ajuster la recette ?

JK : Oui ... mais ne modifiez pas la recette avant d'avoir testé l'originale. Les étapes sont là.
pour une raison, et ils fonctionnent, mais si vous avez exécuté des Design Sprints selon le livre plusieurs fois
et il croit qu'il a besoin d'un ajustement, essayez !

C'est génial de l'entendre, car c'est ainsi que nous recommandons aux gens de réfléchir sur
Lean UX. C'est toujours une question d'essayer des choses, d'apprendre et de s'adapter en fonction de
ce qu'il a appris.

JK : C'est exact. Regarde ce qui se passe et prends des notes. Considère cela comme une expérience.
dans l'expérience. Et s'il trouve une amélioration, faites-le moi savoir.

P : En quoi les Design Sprints sont-ils vraiment bons ? Pour quoi ne sont-ils pas bons ?

JK : Les Sprints de Design sont géniaux pour les équipes qui souhaitent créer quelque chose de nouveau ou changer.
les choses. Ils sont idéaux pour commencer de grands projets et améliorer votre intuition sur la
ajustement du produit / marché. Ils sont excellents pour générer de l'élan et de l'alignement dans
une équipe ... en d'autres termes, un Design Sprint fait en sorte que tout le monde rame dans la même direction
direction avec un véritable objectif. Ils sont également excellents pour rétablir la culture de
équipe et favoriser le meilleur type de prise de décision et de risques. Ils peuvent faire en sorte que les
les personnes comprennent mieux leurs clients et se concentrent sur eux, et peuvent se rapprocher de
les personnes à leurs collègues. Elles peuvent apporter une nouvelle sensation de joie au travail,
parce que finalement tu peux mettre de côté toutes les bêtises et simplement faire ce que
plus importe.

P : D'accord, maintenant l'autre côté de cette question : pourquoi ne sont-ils pas excellents ?
JK : Les Sprints de Design ne sont pas destinés à concevoir chaque détail de votre produit ou à planifier
tout son programme de développement. Ils ne remplacent pas son MVP et ne lui offrent pas un chemin
de zéro au lancement. Ils sont vraiment bons en ce moment précis ; de
fait, je peux dire avec confiance que c'est la meilleure façon que je connaisse de commencer un
nouveau projet. Avant et après ce moment... ainsi, consultez le reste du livre que
cette célébration. :)

P : Il semble y avoir beaucoup de chevauchement entre les méthodes. Laquelle devrions-nous utiliser ?

JK : Les deux !

Utilisation des Design Sprints dans un processus Lean UX

Alors, comme vous pouvez le voir dans notre conversation avec Jake, tout le monde pense que les méthodes
fonctionnent bien ensemble. Alors, quelle est la meilleure façon d'utiliser Lean UX pour
Comment configurer un Design Sprint réussi ? Et comment peut-on utiliser Lean UX après avoir
exécuté un Design Sprint ?

Voici ce que nous recommandons :

• Rappelez-vous que Lean UX vous encourage à reconsidérer votre travail comme un problème pour
résoudre au lieu d'une 'chose à construire'. Ne pas entrer dans un sprint en pensant :
«Que pouvons-nous construire ?» À la place, utilisez votre sprint pour découvrir «Comment
pouvons-nous résoudre notre problème ?
• Lean UX les encourage à articuler leurs hypothèses sur le problème, le public
objectif, les solutions possibles et à quoi ressemble le succès. Cela vous permet de cadrer
hypothèse, ce qui peut être une excellente façon de cadrer un sprint de design.
• Utilisez votre ou vos hypothèses comme entrée pour votre Design Sprint.
• Utilise le travail que tu réalises dans le sprint pour commencer à briser ces suppositions.
les essayer et en sortir de l'autre côté avec un meilleur ensemble d'hypothèses et un ensemble
clair des prochaines étapes.
• Ce prochain ensemble d'hypothèses peut être utilisé comme entrée pour votre
prochain cycle de travail Lean UX.

Systèmes de conception
Como deja en claro la historia de Jeff y Greg en la pizarra, El diseño colaborativo es más
efficace lorsqu'on travaille avec ce que nous considérons comme un gros stylo. Design Sprints est
une autre technique qui adopte cette forme de travail au crayon épais. Ils dessinent ensemble,
prendre des décisions de haut niveau sur le concept, la structure, le flux et la fonctionnalité. Ce
c'est le niveau de résolution et de détail le plus approprié pour le design collaboratif. Le design
Le collaboratif ne signifie presque jamais que les équipes sont assises ensemble à une station.
de travail en déplaçant des pixels. En fait, ce type de groupe flottant au niveau des pixels
c'est ce que la majorité des designers considèrent comme leur pire cauchemar. (Pour être
clairs : ne fais pas ça).

Y, cependant, le design n'est pas terminé lorsque le croquis est terminé. Ce n'est pas
complet sur le tableau. En revanche, en général, ce n'est que le début. Alors, comment
portons le design au niveau des pixels ? Comment arrivons-nous au design visuel finalisé ?
De plus en plus, nous voyons que les équipes se tournent vers des systèmes de design. Les systèmes de
Le design est comme des guides de style sous stéroïdes. Quand nous avons écrit la première édition
de ce livre, les systèmes de design étaient quelque chose de nouveau. En fait, en tant qu'industrie, ils étaient encore
nous n'avions vraiment pas décidé comment les appeler. À cette époque, nous étions
entusiasmados con los sistemas de diseño porque prometían desbloquear la colaboración
entre designers et développeurs, et résoudre une fois beaucoup de problèmes
répétitifs et routiniers auxquels les designers étaient confrontés, ce qui signifiait que les
les designers pouvaient relever des défis plus difficiles qui ajoutaient plus de valeur.

Lorsque nous avons écrit la deuxième édition de ce livre, quatre ans plus tard, les systèmes de
le design s'était généralisé. Les grandes organisations ayant une vision d'avenir avaient
construit ou étaient en train de construire leurs systèmes à grande échelle. Les entreprises
les étaient mises en œuvre depuis le premier jour. Elles avaient émergé
organisations de conseil spécialisées dans les systèmes de design. Les conférences
ils étaient en train de réunir les stagiaires. Nous avions beaucoup plus d'exemples que nous pourrions inclure
dans la deuxième édition du livre, et nous les laissons à leur place pour référence.

Avance rapide jusqu'à aujourd'hui. Les systèmes de design sont maintenant une partie bien
établie de la manière dont se réalise le design dans notre industrie. Ils continuent
tenons nos promesses des premiers jours, y compris les avantages que nous
nous ont tant enthousiasmés quand nous les avons rencontrés pour la première fois : ils continuent de permettre que
les équipes de produits travaillent de manière collaborative et hautement agile. Avant de
s'immerger dans certaines des façons dont les systèmes de design aident les équipes
Pour être plus agiles, jetons un œil à ce que nous sommes.

Systèmes de design : Que contient un nom ?

Guides de style. Bibliothèques de modèles. Directives de la marque. Bibliothèques de

[Link]èmes de design. Il n'y a pas beaucoup de langage commun dans cette partie du monde du
design, alors prenons un moment pour clarifier nos termes.

Pendant des années, les grandes organisations ont créé des marques directrices (Figure 14-
2) : documents complets de conception de marque et règles d'utilisation pour ces entreprises. Dans les
Jours avant la numérisation, ces directives étaient des documents, parfois de quelques
pages, mais souvent de grands volumes reliés complets. Au fur et à mesure
que le monde se déplaçait en ligne, ces livres étaient parfois transférés sur le web comme
documents PDF, pages web ou même wikis.
Figure 14-2. Exemple de lignes directrices pour les normes de marque, ici de la NASA 2

En même temps, les éditeurs et les publications maintenaient souvent des guides de style.
que couvraient les règles de rédaction et de présentation du contenu. Les étudiants
Les universitaires aux États-Unis sont familiers avec le réconfort rigoureux.
Le Manuel de style de Chicago, Le Manuel de style MLA et le Guide de publications
Académiques et autres.

La version du monde de l'informatique d'un guide de style est illustrée par

célèbres directives d'interface humaine (HIG) d'Apple. Le HIG est
un document complet qui explique tous les composants du système d'exploitation de
Apple, fournit des règles pour l'utilisation des composants et contient des exemples qui
démontrent l'utilisation appropriée des composants.

Enfin, les développeurs sont familiarisés avec les bibliothèques d'actifs.

des collections d'éléments de code réutilisables sont destinées à faciliter le travail du
développeur en fournissant un code testé et réutilisable qui est facile à télécharger
depuis un référentiel de code toujours à jour.

Comme c'est le cas avec de nombreuses idées dans le monde numérique, les systèmes de design numérique (qui
nous appellerons systèmes de conception par souci de brièveté) sont une sorte de combinaison
de toutes ces idées. Un bon système de design contient une documentation complète des
éléments d'un design, règles et exemples qui régissent l'utilisation de ces éléments et,
de manière cruciale, le code et d'autres actifs qui mettent réellement en œuvre le design.

En pratique, un système de design fonctionne comme une seule source de vérité pour le
couverture de présentation d'un produit. Les équipes peuvent dessiner sur le tableau et ensuite
utiliser rapidement les éléments présents dans le système de design pour assembler
un prototype ou une interface prête pour la production.

La valeur des systèmes de design

Les systèmes de design sont un puissant moteur du Lean UX. Ils permettent que les détails
les visuels et les micro-interactions d'un design se développent et se maintiennent en parallèle avec
les autres décisions qu'une équipe prend. Par conséquent, les décisions telles que la structure
de l'écran, le flux du processus, la hiérarchie de l'information, les choses qui peuvent être
résoudre au tableau, peuvent être gérées par le bon groupe de camarades de
équipe, tandis que des éléments tels que la couleur, le type et l'espacement peuvent être gérés
par un autre groupe de personnes (très probablement superposées).

Cela présente quelques grands avantages pour les équipes :

Conçois plus rapidement

L'équipe ne réinvente pas la roue chaque fois qu'elle conçoit un écran.

Prototype plus rapide

Les développeurs frontend travaillent à partir d'un ensemble de pièces : non

ils doivent recréer les éléments d'une solution chaque fois; ils peuvent simplement
obtenir les pièces appropriées du système de conception.

Il a également de grands avantages pour les organisations :

Une plus grande cohérence

Un bon système de design est facile à utiliser pour les développeurs. Par conséquent,
il est plus probable qu'ils utilisent des pièces qu'ils trouvent dans le système de design et c'est
moins probable que "débrouillent les leurs". Cela signifie une plus grande
probabilidad de que su trabajo se adhiera a los estándares de la marca.

Meilleure qualité

En centralisant la conception et la création d'éléments orientés vers l'utilisateur, vous pouvez

profiter du travail de certains designers et développeurs d'UI hautement
qualifiés et hautement spécialisés. Leur travail de haute qualité peut être
mis en œuvre par d'autres développeurs moins spécialisés dans l'organisation
pour produire des résultats de premier niveau.

Coûts plus bas

Un bon système de design n'est pas gratuit. Il nécessite un investissement pour le construire et
personnel pour le maintenir. Mais avec le temps, il s'amortit en fournissant
outils et cadres qui rendent les utilisateurs du système, les autres
développeurs de l'organisation, soient plus efficaces et productifs. Permet à
les nouveaux designers se mettent à jour plus rapidement, par exemple, parce que
documenta todas las convenciones de frontend utilizadas en una aplicación. Del
 de la même manière, permet aux nouveaux développeurs de se mettre à jour plus
rapidement, car les éléments de base de votre travail sont
disponibles dans un cadre facile à utiliser.

Los equipos de sistemas de diseño son equipos de productos

Ne vous trompez pas : une équipe de systèmes de design est une équipe de produit. Bien que ce
l'équipe travaille sur un produit qui sera utilisé (dans la plupart des cas) par
utilisateurs internes, cette équipe est, néanmoins, une équipe produit. Elle aura beaucoup de
les mêmes préoccupations que pourra avoir n'importe quelle équipe produit : avant tout, elle doit
faire un produit que ses utilisateurs considèrent comme précieux. Comme avec n'importe quel produit
interne, sa mesure de succès n'est pas les ventes ; c'est l'adoption. Par conséquent, comprendre les
les besoins de ses utilisateurs et les prendre en compte seront clés pour une adoption rapide de son travail
y, en última instancia, clé pour son succès.

Les équipes de systèmes de design peuvent relever ce défi en utilisant des méthodes Lean.
UX. Certains méthodes, comme certains types d'expérimentation, peuvent être difficiles ou
impossibles pour les équipes de systèmes de design : en raison du fait que les systèmes de design
ce sont des produits de plateforme, les équipes les utiliseront dans une variété de contextes et
doivent s'intégrer dans une large gamme d'environnements. Par conséquent, les problèmes de
compatibilidad y estabilidad pueden limitar los tipos de experimentos que ejecuta.

Cela dit, étant donné que les utilisateurs des systèmes de design sont internes, cela devrait être
facile d'y accéder. Cela signifie que les équipes de systèmes de design peuvent s'appuyer sur
dans les techniques de conception collaborative, utilisant des ateliers, des sprints et des sessions de tableau
partagée pour générer la collaboration et la compréhension partagée entre les
développeurs et utilisateurs de systèmes de design.

Ne saute pas les marqueurs de gras

Une préoccupation surprenante que nous avons constatée, c'est que les systèmes de design deviennent plus.
omniprésente est que les systèmes de design peuvent être si bons et si faciles à utiliser
que les designers peuvent être tentés de sauter l'étape de conception du « marqueur »
gros" et passer directement au travail de haute fidélité. Quand cela se produit, les parties
intéressés, les collègues et même les propres designers peuvent mal interpréter les
artefacts qui représentent la phase initiale de la pensée (la phase de développement du
concept du travail). Il est dans la nature humaine de répondre aux maquettes de haute
fidélité d'une manière différente de celle dont vous répondez aux maquettes de basse
fidélité. Lorsque vous montrez aux personnes, en particulier à celles qui ne sont pas des concepteurs, une
maquette haute fidélité, tend à recevoir des commentaires sur les détails. Les sources, les
couleurs et le contenu. Mais quand il montre à des gens un croquis sur papier et crayon,
il n'y a pas de détails à commenter. En revanche, les gens lisent ces dessins comme des dessins
conceptuels et y répondent.

Alors, pour les designers, il est important de ne pas se laisser séduire par la facilité.
simplement sortir Figma, prendre les composants de son système de design et produire une
maquette crédible. Ne le fais pas. Commencez par vos marqueurs de graisse.

Cependant, pour les équipes de systèmes de design, il existe l'opportunité d'aider à

les utilisateurs à choisir l'outil approprié pour le travail. Lorsque nous écrivons le
première édition de ce livre, les designers avaient une variété d'outils de
structure de fils numériques qui étaient optimisées pour faire des dessins avec fidélité
aux croquis. Nous commençons à voir que les équipes de systèmes de design sont
envisageant d'ajouter des éléments de fidélité au croquis de vos kits d'outils. Cela
c'est une tendance fascinante et nous la suivrons pour voir où elle se développe.

Maintenant, examinons comment une grande organisation utilise les systèmes de design.
...

Étude de cas : système de design de GE

En 2012, GE a ouvert GE Software à San Ramon, en Californie. Ce nouveau « Centre de

L'« excellence » (CoE) a été conçu pour aider GE à améliorer son jeu de logiciels.
Des années auparavant, un examen stratégique a aidé l'entreprise à voir à quel point elle était devenue centrale.
converti le logiciel dans son entreprise : mesuré en lignes de code, GE était quelque chose comme
la 17ª compagnie de logiciels la plus grande du monde. Et, pourtant, ils sentaient qu'ils ne
ils traitaient le développement de logiciels avec l'approche qu'il méritait.

San Ramon a inclus une nouvelle équipe dans GE : l'équipe d'expérience utilisateur
logiciel de GE. Ce petit équipement au cœur d'une entreprise géante a créé son
premier système de design en 2013 pour amplifier l'impact qu'ils pourraient avoir. En fait,
avec moins de 50 concepteurs pour collaborer avec plus de 14 000 développeurs (à l'intérieur
d'une organisation de plus de 300 000 personnes), il n'y avait aucun moyen que cette équipe de
diseño de startups pudiera crecer lo suficientemente rápido como para tener un efecto
significatif en GE.

Le premier système de design de l'équipe, appelé IIDS, pour le Design de l'Internet Industriel
Le système a été conçu par un groupe de designers internes avec l'aide d'un petit
équipe de Frog Design, l'une des agences de design leaders dans le monde. L'équipe
il a construit le système sur Bootstrap, le cadre HTML / CSS créé par Twitter. Cela a résulté
incroyablement réussi. En quelques années, les développeurs internes l'avaient
téléchargé plus de 11 000 fois et avait été utilisé pour créer des centaines de
applications. A aidé les équipes de logiciels de toute l'entreprise à produire des applications
plus cohérents et d'apparence meilleure. Et, peut-être tout aussi important, a créé une grande
quantité de visibilité pour l'équipe de logiciel et l'équipe UX à San Ramon.

Avec ce succès sont apparus quelques problèmes. Sans aucun doute, le simple fait d'avoir un bon
Un kit de interface utilisateur ne signifie pas qu'une équipe puisse produire un bon produit.
conçu. Les systèmes de design ne résolvent pas tous les problèmes de design. Et
Bootstrap montrait ses limites en tant qu'option de plateforme. Il avait aidé
équipe à atteindre ses premiers objectifs : sortir quelque chose rapidement, fournir une
amplia cobertura de los elementos de la interfaz de usuario y crear una amplia adopción
en étant plus faciles à utiliser que les solutions "faites-le vous-même". Mais Bootstrap était difficile
de maintenir et de mettre à jour et était trop grand pour la plupart des besoins.

En 2015, GE Software, après avoir connu un grand succès en tant que bureau de services
internos, s'est transformée en GE Digital, une entreprise génératrice de revenus par droit
propre. Son premier produit s'appelait Predix (Figure 14-3), une plateforme sur laquelle
Les développeurs à l'intérieur et à l'extérieur de GE peuvent créer des logiciels pour des applications
industrielles. Et avec ce changement de stratégie, l'équipe s'est rendu compte qu'elle avait besoin de
repenser leur système de design. Alors que l'objectif précédent avait été
fournir une large couverture et une large adoption, le nouveau système de design
serait poussé par de nouveaux besoins : il fallait activer de grandes applications de
Predix, qui était un problème plus ciblé qu'auparavant. Il était nécessaire de limiter la quantité de
options d'UI au lieu d'admettre tous les widgets d'UI possibles. Je devais encore
être facile à adopter et à utiliser (il était désormais destiné à être utilisé par les clients de
GE), mais il était maintenant impératif qu'il soit également facile à entretenir.

L'équipe du système de design avait grandi pour atteindre environ 15 personnes et incluait des technologues de
design (développeurs frontend passionnés à la fois par le design et par le code)
designers d'interaction, designers graphiques, un rédacteur technique et un propriétaire de
produit.
Figure 14-3. Le système de design GE Predix

L'équipe a décidé de transférer le système de design sur une nouvelle plateforme technologique.
( Figure 14-4).Il ne repose plus sur Bootstrap, le système a été créé avec Polymer, un cadre
de JavaScript qui permet à l'équipe d'implémenter des composants web. Les composants
les web ont émergé ces dernières années comme un moyen de permettre des pratiques de développement
des frontend plus matures.

Pour créer le nouveau système de design, l'équipe a passé presque six

prototypes months. Significativement, l'équipe n'a pas travaillé de manière isolée. Au contraire,
ils se sont associés à l'une des équipes d'applications et ont donc conçu
composants pour satisfaire les besoins de ses utilisateurs, dans ce cas, les concepteurs
et les développeurs qui travaillaient dans les équipes d'applications. Ce point est vraiment
Important. Le design collaboratif prend de nombreuses formes. Parfois, cela signifie concevoir avec
votre équipe multifonctionnelle. Parfois, cela signifie concevoir avec vos utilisateurs finaux. Dans ce cas,
c'était un hybride : concevoir avec une équipe multifonctionnelle de designers et
des développeurs qui en réalité sont leurs utilisateurs.

Figure 14-4. Le système de design GE Predix sur GitHub

Collaboration avec des équipes distribuées

géographiquement
La distance physique est l'un des plus grands défis pour une collaboration efficace. Certains
des méthodes que nous avons discutées dans ce livre deviennent plus difficiles lorsqu'un
l'équipe n'est pas au même endroit. Cela dit, comme nous avons tous appris en 2020, grâce à
la crise de COVID-19, vous pouvez encore trouver des moyens de collaborer lorsque vous et votre équipe
sont séparés par la distance. Des outils comme Zoom, Skype, Google Meet et Slack
peuvent fournir aux équipes les moyens de collaborer en temps réel. Google Docs
et des systèmes similaires permettent aux personnes de collaborer sur des documents en même temps
temps. Les outils de collaboration en équipe comme Mural et Miro servent de un
espace pour la collaboration créative. Trello et les wikis rendent possible que les équipes
rassemblez les informations ensemble. Les outils de conception comme Figma sont créés à partir de
zéro avec la collaboration en tête. Et un téléphone avec un appareil photo peut faciliter le
échange rapide de photos de manière ad hoc.

Collaborer avec des équipes distribuées

Lorsque nous parlons d'équipes distribuées, nous parlons en réalité d'une

une variété de scénarios différents. Parfois, nous disons que nous sommes dans un bureau à
New York avec une partie de notre équipe et nous avons besoin de travailler avec d'autres collègues de
équipe qui travaille dans le bureau de Londres. D'autres fois cela signifie que nous sommes
encerrés dans le style de 2020, travaillant depuis chez nous avec nos animaux de compagnie, nos enfants et
nos partenaires dans la même chambre. Parfois, nous parlons d'une situation
hybride : la plupart d'entre nous sommes au bureau, mais certaines personnes sont
appeler pour une réunion. Ce qui fonctionne dans l'un de ces contextes peut ne pas fonctionner
dans d'autres, mais il y a quelques idées importantes que vous pouvez utiliser pour faciliter la
collaboration dans n'importe quel contexte.

Niveler le terrain de jeu. Avez-vous déjà convoqué une réunion où vous étiez le seul
Une personne au téléphone et tous les autres étaient assis autour de la table ? C'est
dur. Maintenant imagine une pièce pleine de gens travaillant sur des notes autocollantes ou
dessinant au tableau, pendant que tu es assis dans ta cuisine écoutant le téléphone. Ce sera
difficile, peut-être impossible, pour vous de faire une contribution significative. Une solution
Pour cela, il est important d'insister sur le fait de choisir les outils de la salle de réunion afin que tout le monde
puissent participer. Au lieu d'utiliser le tableau de la salle de conférence, votre équipe
vous pouvez ouvrir un document partagé ou utiliser un outil de tableau en ligne comme
Mural ou Miro. Cela signifie que tout le monde dans la salle de conférence aura besoin de son propre
ordinateur portable ou tablette, mais garantira également que tout le monde puisse collaborer
comme des camarades.

Créez des connexions sociales. Il peut être tentant de traiter les réunions en ligne comme une
manière très réglementée. Rassemblez l'équipe, fixez l'ordre du jour avec force, terminez à
temps, boom. Les réunions à distance commencent et se terminent de manière plus abrupte que
Les réunions physiques. Réfléchissez-y : quand nous nous réunissons dans une salle de conférence,
Nous avons discuté quelques minutes dans le couloir avant la réunion. Nous avons papoté pendant que
nous prenons nos chaises. Nous sortons de la pièce ensemble et prenons un café ensemble pour
parler. Ces moments peuvent sembler secondaires au travail que nous faisons, mais dans
la réalité est un composant crucial du travail : elle nous donne le temps de construire des liens
sociales qui permettent que le travail se produise. Faites un effort pour créer des connexions sociales.
à travers des collaborations à distance. Obtenez du temps supplémentaire pour les ouvertures lentes de
ses réunions. Programmation d'appels sociaux de l'équipe à distance. Créez des canaux sociaux /
pas de travail dans les espaces de travail Slack de votre équipe. Si vous pouvez voyager pour voir
vos collègues d'équipe à distance,

Faire en sorte que la collaboration fonctionne

Tous les équipes ne trouveront pas que la collaboration est facile. La plupart d'entre nous
nous avons commencé nos carrières en développant nos compétences techniques individuelles
en tant que designers, développeurs, etc. Et dans de nombreuses organisations, la collaboration
entre disciplines est rare. (Rarement enseigné aussi à l'école, que ce soit comme un sujet
explicite ou dans la manière dont nos systèmes éducatifs sont configurés). Pour
Donc, il n'est pas surprenant que cela puisse sembler un défi.

L'une des outils les plus puissants pour améliorer la collaboration est la technique agile.
de la rétrospective et la pratique associée de créer des accords de travail en
équipe. Les rétrospectives sont des réunions programmées régulièrement, qui généralement
se déroulent à la fin de chaque sprint, où l'équipe jette un regard honnête sur
sprint précédent. Ils examinent ce qui a bien fonctionné, ce qui a mal fonctionné et ce que l'équipe veut
améliorer. En général, l'équipe sélectionnera certaines choses sur lesquelles travailler pour le
prochain sprint. Nous ne pouvons pas penser à un outil plus puissant pour améliorer la
collaboration que la pratique régulière des rétrospectives efficaces.

Un accord de travail en équipe est un document qui sert de partenaire de la

rétrospective. Suivez comment l'équipe a choisi de travailler sur
ensemble. C'est un livre de règles de création propre et continuellement mis à jour que le
l'équipe s'engage à continuer. À chaque rétrospective, l'équipe doit vérifier son accord
de travail pour voir s'ils le suivent toujours et s'ils ont besoin de le mettre à jour pour inclure
nouveaux accords ou supprimer les anciens qui n'ont plus de sens.

Voici un résumé de ce que vous devriez envisager d'inclure dans les accords de travail de votre
equipo:

Vue d'ensemble du processus

¿Qué tipo de proceso estamos usando? ¿Ágil? Si es así, ¿qué sabor? ¿Cuánto duran
nos itérations ?

Cérémonies
Quels rituels l'équipe observera-t-elle ? Par exemple, quand fait-on un stand-up tous les
Jours ? Quand organisons-nous des réunions de planification et des démonstrations ?

Outils de communication

¿Qué sistemas usaremos para comunicar y documentar nuestro trabajo? ¿Cuál es

notre outil de gestion de projet ? Où gardons-nous nos actifs ?

Cultura / Seguridad / Resolución de conflictos

Quel type de culture d'équipe voulons-nous ? De quoi avons-nous besoin en tant qu'individus pour
nous sentir en sécurité avec nos coéquipiers ? Que ferons-nous quand (pas si !)
Y a-t-il un conflit ? Comment allons-nous résoudre les désaccords ?

Heures de travail
 Qui travaille où ? Quand les gens sont-ils au bureau ? Si nous sommes dans différents
endroits, quelles adaptations ferons-nous pour les différences de fuseau horaire ?

Exigences et conception

Comment gérons-nous la définition des exigences, la rédaction des histoires et la

priorización? ¿Cuándo está lista una historia para diseñar? ¿Cuándo está listo un diseño
pour se diviser en histoires ?

Développement
Dans quelles pratiques nous sommes-nous conformés ? Utilisons-nous la programmation par paires ? Que
estilo de prueba usaremos? ¿Qué métodos usaremos para el control de fuentes?

Limites des travaux en cours

¿Cuál es nuestra cartera de pedidos y el tamaño de nuestra nevera? ¿Qué límites de WIP
existent-ils à plusieurs étapes de notre processus?

Déploiement

¿Cuál es nuestra cadencia de liberación? ¿Cómo hacemos la aceptación de la historia?

Et tout accord supplémentaire.

SÉCURITÉPSYCHOLOGIQUE

Le design collaboratif est une activité créative. Pour être efficace, les gens doivent se sentir
sécure. Cela signifie sécurité physique, émotionnelle et psychologique. Nous entendons souvent
cette idée exprimée de manière superficielle, comme "il n'y a pas de mauvaises idées lors d'un brain storming"
il n'existe pas de questions stupides. Et bien que ces choses soient vraies, elles ne le sont certainement pas.
sont suffisants. La sécurité psychologique est plus que cela. L'auteure Alla Weinberg définit
la sécurité psychologique comme "la croyance partagée que personne dans l'équipe
n'avergondera ni ne punira personne d'autre pour avoir admis une erreur, posé une question ou proposé
une nouvelle idée

Lean UX concerne l'idée que la conception est un processus itératif. Vous devez tester,
apprendre et itérer. En d'autres termes, il est nécessaire de faire des erreurs pour progresser. Non
vous pouvez faire cela si vous et votre équipe ne vous sentez pas en sécurité.

Si vous ou votre équipe êtes bloqués dans une routine, vous éprouvez de hauts degrés
de conflit ou, en général, agissent apeurés, faites un pas en arrière et demandez : Est-ce que je me sens
en sécurité dans cette équipe ? Est-ce que je pense que les membres de mon équipe se sentent en sécurité ? Si ce n'est pas le cas
être sûr, envisagez de faire un pas en arrière et d'observer le travail d'écrivains comme Weinberg
y Amy Edmondson pour vous aider, vous et votre équipe, à aborder ces préoccupations.

Terminant

Le design collaboratif (Figure 14-5) est une évolution du processus de design UX. Dans
dans ce chapitre, nous discutons de la manière dont l'ouverture du processus de conception implique toute l'équipe
s'engage davantage dans le projet. Nous vous montrons des techniques pratiques que vous pouvez utiliser pour
créer une compréhension partagée, la monnaie fondamentale de Lean UX. En utilisant
outils tels que des systèmes de design, des guides de style, des sessions de conception collaborative,
Design Studio et une conversation simple, son équipe peut construire une compréhension
partagé qui leur permet d'avancer à un rythme beaucoup plus rapide que dans les environnements
traditionnels.

Figure 14-5. Une équipe qui utilise des techniques de conception collaborative

1Le mot "sprint" peut prêter à confusion ici. Dans ce contexte, nous ne parlons pas
d'un sprint de style agile, ce que Scrum appellerait une «itération». Lorsque nous utilisons l'expression
"Design Sprint", nous utiliserons des lettres majuscules pour indiquer que nous parlons de
processus spécifique décrit dans le livre Sprint.

2NASA, “Manuel des normes graphiques de la NASA”, 8 septembre

2015,[Link] .
Chapitre 15. Rétroaction et
recherche
La recherche est une curiosité formalisée. C'est fouiller et s'immiscer avec un but.

Zora Neale Hurston

La recherche avec les utilisateurs est au cœur du design UX. Trop à

Cependant, les équipes sous-traitent le travail de recherche à des équipes de
recherches spécialisées. Et trop souvent, les activités de
Des recherches sont menées rarement, que ce soit au début ou à la fin d'un
Le projet. Lean UX résout ces problèmes en rendant la recherche plus
tantocontinuacomocolaborativa. Profondissons pour voir comment faire cela.

Dans ce chapitre, nous couvrons ce qui suit :

• Techniques de recherche collaborative que vous pouvez utiliser pour générer un

entendement partagé avec son équipe.
• Techniques de recherche continue pour construire des études de recherche
petits et informels qualitatifs à chaque itération.
• Comment utiliser de petites unités de recherche régulières pour construire des études
de recherches longitudinales
• Comment concilier des commentaires contradictoires de multiples sources
• Quels artefacts tester et quels résultats pouvez-vous attendre de chacune de ces tests
• Comment intégrer la voix du client tout au long du cycle Lean UX

Recherche continue et collaborative

Lean UX prend des techniques de base de recherche UX et superpose deux idées
importantes. Premièrement, la recherche Lean UX est continue. Cela signifie qu'elle intègre
actividades de investigación en cada sprint. En lugar de ser un proceso costoso y
perturbateur du Big Bang, nous le faisons en petites quantités pour que nous puissions
l'adapter à notre processus en cours. Deuxièmement, la recherche Lean UX est
collaborative. Cela signifie qu'il ne dépend pas du travail de chercheurs spécialisés
pour offrir de l'apprentissage à son équipe. En revanche, les activités et responsabilités de
la recherche est distribuée et partagée entre toute l'équipe. En éliminant le transfert
entre chercheurs et membres de l'équipe, nous augmentons la qualité de notre
[Link] objectif dans tout cela est de créer une compréhension partagée riche
tout l'équipe.

Découverte collaborative

La découverte collaborative est le processus de travailler ensemble en tant qu'équipe pour

tester des idées sur le marché. C'est l'une des deux principales techniques multifonctionnelles qui
créer une compréhension partagée au sein d'une équipe Lean UX. (Le design collaboratif,
couverte en leChapitre 14, c'est l'autre). La découverte collaborative est une approche de
enquête qui sort toute l'équipe du bâtiment, littéralement et figurativement, pour
se réunir et apprendre des clients et utilisateurs. Offrir à tous les membres de l'équipe la
opportunité de voir comment les hypothèses sont testées et, plus important encore, multiplie
la quantité de perspectives que l'équipe peut utiliser pour recueillir des informations sur les
clients.

Il est essentiel que vous et votre équipe fassiez des recherches ensemble ; c'est pourquoi il
nous appelons découverte collaborative. La sous-traitance de la recherche réduit
drastiquement sa valeur : gaspille du temps, limite la formation d'équipes et filtre la
information à travers des livrables, des transferts et de l'interprétation. Ne le fais pas.

Les chercheurs se sentent parfois mal à l'aise avec cette approche. En tant que professionnels
qualifiés, ils ont raison de souligner qu'ils ont une connaissance spéciale qui est
important pour le processus de recherche. Nous sommes d'accord. C'est pourquoi cela doit
inclure un chercheur dans votre équipe si possible. Ne sous-traitez tout simplement pas le travail à
cette personne. À la place, utilisez le chercheur comme guide expert pour aider votre équipe
à planifier son travail et à diriger l'équipe à travers ses activités de recherche. De
de la même manière que Lean UX encourage les concepteurs à adopter une approche plus
facilitateur, Lean UX demande la même chose aux chercheurs. Les chercheurs doivent
utiliser votre expérience pour aider l'équipe à planifier une bonne recherche, faire
bonnes questions et choisir les méthodes appropriées pour le travail. Il suffit de ne pas
fais toute la recherche pour eux.

Découverte collaborative sur le terrain

La découverte collaborative est tout simplement une manière de sortir sur le terrain avec votre
équipe. Ainsi, vous le faites :

1. En équipe, passez en revue vos questions, suppositions, hypothèses et MVP. Décidez en équipe
ce qu'il doit apprendre. (Encadré 7 dans Lean UX Canvas).
2. En travaillant en équipe, décidez de votre méthode de recherche. (Encadré 8 dans Lean)
UX Canvas). Si vous prévoyez de travailler directement avec des clients et des utilisateurs, décidez avec
qui devra parler et observer pour atteindre ses objectifs d'apprentissage.
3. Créez un guide d'entretien (reportez-vous à la barre latérale "Le guide d'entretien") qui
tout le monde peut utiliser pour guider ses conversations.
4. Divisez votre équipe en paires de recherche, en mélangeant les différents rôles et
disciplines au sein de chaque paire (c'est-à-dire essayez de ne pas avoir des designers appariés)
con diseñadores). Si está haciendo esta investigación durante varios días, intente
mélanger les paires d'entretiens tous les jours afin que les gens aient le
opportunité de partager des expériences avec plusieurs membres de l'équipe.
5. Assemblez chaque paire avec une version de votre MVP, prototype ou d'autres matériaux que vous souhaitez.
montrer aux participants de la recherche.
6. Envoyez chaque équipe rencontrer des clients / utilisateurs.
7. Un membre de l'équipe interroge pendant que l'autre prend des notes.
8. Commencez par des questions, des conversations et des observations.
9. Démontrer le MVP plus tard dans la session et permettre au client d'interagir
avec lui.
10. Prenez des notes au fur et à mesure que le client fournit des commentaires.
11. Lorsque l'intervieweur principal a terminé, changez les rôles pour que le
Le preneur de notes a l'opportunité de poser des questions de suivi.
 12. À la fin de l'entretien, demandez au client des références à d'autres personnes qui également
ils pourraient fournir des commentaires utiles.

LEGUIDEDESENTRETIENS

Pour se préparer au travail de terrain, créez une petite feuille de triche qui tienne dans
sur son cahier. Sur sa feuille de référence, écrivez les questions et les sujets que vous avez décidés.
couvrir. De cette manière, vous serez toujours prêt à faire avancer l'entretien.

Lorsque vous planifiez vos questions, pensez à un entonnoir séquentiel :

• Tout d'abord, essayez d'identifier si le client fait partie de votre public cible.
• Ensuite, essayez de confirmer toute hypothèse de problème que vous avez pour cela.
segment

Enfin, si vous avez un prototype ou une maquette, montrez ce dernier pour éviter de limiter la
conversation à sa vision de la solution.

Un exemple de découverte collaborative

Une équipe avec laquelle nous travaillons chez PayPal a été établie avec un prototype pour réaliser
une session de découverte collaborative. L'équipe était composée de deux
designers, un chercheur UX, quatre développeurs et un chef de produit; se
Ils ont été divisés en équipes de deux et trois. Ils ont associé chaque développeur à un non
développeur. Avant de partir, ils ont fait une séance de brainstorming sur ce qu'ils aimerent.
apprendre de son prototype et utiliser ces idées pour écrire de courtes guides sur
interviews. Their product was aimed at a broad consumer market, so
ils ont simplement décidé de se rendre dans les centres commerciaux locaux disséminés par leur
bureau. Chaque paire a visé un centre commercial différent. Ils ont passé deux heures dans le champ,
en arrêtant des étrangers, en leur posant des questions et en montrant leurs prototypes. Pour
développer ses compétences individuelles, ont changé de rôle (de leader à annotateur) pendant une heure
après avoir commencé votre recherche.

Quand ils se sont retrouvés, chaque couple a lu ses notes au reste de l'équipe. Presque de
immédiatement, ils commencèrent à voir surgir des motifs, qui confirmaient certaines de leurs
hypothèses et rejetaient d'autres. En utilisant cette nouvelle information, ils ont ajusté le design de
prototyping et se dirigèrent de nouveau ce même après-midi. Après une journée complète de
investigation de terrain, il est devenu clair quelles parties de son idée ont bien fonctionné et quelles parties
ils auraient besoin d'ajustements. Lorsque le sprint suivant a commencé le lendemain, tous les
les membres de l'équipe travaillaient à partir de la même ligne de base de clarté,
ayant construit une compréhension partagée par le biais de la découverte
collaboratif la veille.

Apprentissage continu

Les concepteurs et les chercheurs font face à beaucoup de pression pour imposer leur travail dans
un cadre de sprint. Le problème est que certains travaux prennent simplement beaucoup de temps,
surtout certains types de recherche. Ce travail de long cycle a le potentiel
de créer des conflits dans les équipes agiles. Les chercheurs sont habitués à
planifier des projets de recherche de plusieurs semaines, par exemple. Et quand ils essaient
faire cela dans une équipe agile et mettre leur projet de recherche de huit semaines dans la
liste des travaux en attente, finissant par devoir expliquer à la fin de chaque sprint pourquoi
son travail n'est pas "terminé". Il rend tout le monde malheureux.

Retour aux principes

Lorsque vous êtes confronté à un conflit comme celui-ci, il est utile de revenir aux principes. Vous vous souvenez
ce principe duCapítulo 2 ?Ne fais pas la même chose plus vite. Et celui-ci ? Fais attention aux
Ces principes nous disent que nous ne devrions pas essayer de faire entrer une étude de
enquête de huit semaines dans un sprint de deux semaines. À la place, nous devrions
repenser la façon dont nous planifions notre recherche et la façon dont nous pensons
en fait pour le travail de recherche.

Pour ce faire, considérons pourquoi le cadre de Scrum insiste tant sur la notion
En fait, Scrum dit que tout travail que vous effectuez pendant un sprint doit être réalisé.
à la fin de ce sprint. C'est une fonction de force puissante : elle oblige tout le monde à montrer son
travail. Et suppose que le travail terminé est précieux. (Ce n'est pas toujours vrai, mais ce
c'est l'objectif).

Donc, pour nous, l'objectif de donnees est vraiment : "Être transparent et offrir
valeur à chaque sprint

Comment pouvons-nous utiliser cette idée lorsque nous planifions une recherche ? Eh bien, au lieu de
penser à compléter notre étude de huit semaines en deux semaines, nous pouvons
nous demander : « Comment pouvons-nous être transparents et offrir de la valeur toutes les deux semaines,
même quand nous travaillons sur une étude de huit semaines ? Nous pourrions livrer
un rapport d'expérience sur les réunions de démonstration de Sprint. Nous pourrions
présenter quelques conclusions initiales après avoir complété la moitié de nos
interviews. Nous pourrions présenter et discuter des nouvelles questions qui ont émergé à mesure
que nous commençons à apprendre de nouvelles choses. Toutes ces choses sont précieuses pour le
équipe. Ils rendent le travail transparent. Ils maintiennent l'esprit agile tout en faisant
ils maintiennent une haute intégrité du travail de recherche.

Recherche continue : la recherche ne cesse jamais

Une équipe agile de haut fonctionnement devrait être en train d'enquêter en continu. L'un des
les meilleures pratiques fondamentales en Lean UX sont de créer une cadence régulière de
participation du client. Conversations programmées régulièrement avec les
les clients vous permettent de minimiser le temps entre la création de l'hypothèse, la conception de
expérience et les commentaires des utilisateurs, ce qui lui donne l'opportunité de valider
ses hypothèses rapidement.

En d'autres termes, la recherche doit informer les décisions que prend

équipe produit. Étant donné qu'elle prend constamment des décisions, elle souhaite s'assurer d'avoir
à la main les données de recherche les plus récentes à tout moment. (Et, inversement, le
l'agenda de recherche devrait parfois stimuler les priorités de développement parce que à
Il est parfois nécessaire de faire des choses qui répondent spécifiquement aux besoins de vos
investigateurs. C'est une conversation bidirectionnelle).
En général, savoir qu'il ne reste que quelques jours avant de recevoir les commentaires des clients a
un efecto poderoso en los equipos. Elimina la presión de la toma de decisiones porque
sachez que vous aurez bientôt la possibilité d'obtenir des données significatives du marché et
corrigez-les rapidement si nécessaire.

Alors arrêtez de penser en termes d'études de recherche et de phases de recherche,

et au lieu de cela, pensez à la recherche comme une partie continue du rythme opérationnel de
votre équipe. Partagez votre travail. Fournissez de la valeur chaque semaine. Soyez honnête sur ce que
sait et ce qu'il ne sait pas. Aidez votre équipe à apprendre. Le reste de ce chapitre vous montrera
comment.

Apprentissage continu au laboratoire : trois utilisateurs chaque jeudi

Bien qu'il puisse créer un calendrier permanent de travail sur le terrain basé sur les idées
mentionnées précédemment, il est beaucoup plus facile (surtout pour les entreprises que
travaillent avec les consommateurs) attirer des clients dans le bâtiment; il suffit d'être un peu créatif
pour impliquer toute l'équipe.

Nous aimons utiliser un rythme hebdomadaire pour planifier la recherche, comme indiqué dans
laFigure 15-1 Nous appelons cela "Trois, douze, un" car cela repose sur les éléments suivants
pautas: tres usuarios; a las doce del mediodía; una vez por semana.

Figure 15-1. Le calendrier des activités de trois, douze et un

Ainsi se décomposent les activités de l'équipe :

Lundi : Recrutement et planification.

Décider, en équipe, ce qui sera testé cette semaine. Décidez qui vous devez recruter pour
les tests pour commencer le processus de recrutement. Sous-traitez ce travail si possible :
cela prend beaucoup de temps (voir la barre latéraleUn commentaire sur le recrutement de
participants).

Mardi : peaufiner les composants de l'épreuve

 Selon l'étape à laquelle se trouve votre MVP, commencez à affiner le design, le prototype
ou le produit jusqu'à un point qui lui permet de raconter au moins une histoire complète
quand vos clients vous verront.

Mercredi : Continuez à peaufiner, rédigez le scénario et terminez le recrutement.

Apportez les touches finales à votre MVP. Rédigez le script de test que votre modérateur suivra.
avec chaque participant. (Votre modérateur doit être quelqu'un de l'équipe si possible). Finissez
le recrutement et l'horaire des tests de jeudi.

Jeudi : Essaye !
Passez la matinée à tester votre MVP avec les clients. Ne consacrez pas plus d'une heure à chaque.
client. Tous les membres de l'équipe doivent prendre des notes. L'équipe doit planifier.
regarder depuis un emplacement séparé. Passez en revue les résultats avec toute l'équipe.
projet immédiatement après que le dernier participant ait terminé.

Vendredi : Plan
Utilisez votre nouvelle perspective pour décider si vos hypothèses ont été validées et ce que vous devez.
faire ci-dessous.

Simplifiez votre environnement de test

De nombreuses entreprises ont établi des laboratoires d'usabilité en interne, et il était d'usage que
Tu avais besoin d'un. De nos jours, tu n'as pas besoin d'un laboratoire ; tout ce qu'il te faut, c'est un endroit.
tranquille dans son bureau avec un ordinateur connecté à un réseau et une caméra
web. Il était autrefois nécessaire d'utiliser des produits de test d'usabilité spécialisés pour
enregistrer des sessions et connecter des observateurs à distance. De nos jours, même cela
vous avez besoin. Nous effectuons des tests de manière routinière avec des observateurs distants utilisant
rien de plus exotique que Zoom.

La capacité de connecter des observateurs distants est un élément clé. Esole permet
porter les sessions de test aux membres de l'équipe et aux parties prenantes qui ne
ils peuvent être présents. Cela a un impact énorme sur la collaboration car cela étend
la compréhension de ses clients au plus profond de son organisation. Il est difficile d'exagérer
la puissance de ceci.

Qui devrait regarder ?

La respuesta corta es todo su equipo. Como casi todosOtro aspecto de Lean UX, las
Les tests d'usabilité doivent être une activité de groupe. Avec toute l'équipe observant les
pruebas, absorbiendo los comentarios y reaccionando en tiempo real, encontrará reducida
la nécessité de rapports ultérieurs. L'équipe apprendra directement où ils se trouvent
avoir du succès et où échouent leurs efforts. Rien n'est plus humiliant (et motivant) que
ver a un usuario luchar con el software que acaba de crear.

QUELQUESMOTSSURLERECRUTEMENTDESPARTICIPANTS

Recruter, programmer et confirmer les participants prend beaucoup de temps. Épargnez à votre équipe
de cette surcharge supplémentaire en transférant le travail à un recruteur dédié. Certaines
les entreprises ont engagé des recruteurs internes pour effectuer ce travail dans le cadre de leur
équipe de DesignOps ou ResearchOps, tandis que d'autres sous-traitent le travail à un
troisième. Dans tous les cas, le coût en vaut la peine. Le recruteur fait le travail et est payé.
pour chaque participant qu'ils apportent. De plus, leur recruteur charge de la sélection,
programmation et remplacement des absences le jour de l'examen. Les recruteurs externes
ils ont tendance à facturer pour chaque participant qu'ils recrutent. Vous devrez également établir un budget
toute compensation que vous offrez aux participants eux-mêmes.

Recherche continue : quelques exemples

Les entreprises mettent en pratique la recherche continue dans de nombreux domaines différents
chemins. Par exemple, l'équipe d'ABN AMRO, une banque des Pays-Bas, exécute
ce qu'on appelle un carrousel de validation des clients une fois par semaine. Cet événement
la recherche utilisateur hebdomadaire est structurée comme des rendez-vous rapides. Chaque semaine,
cinq clients entrent dans les bureaux de l'entreprise. Chaque client est configuré dans son propre
station de recherche. Ensuite, un groupe d'intervieweurs entre dans la salle et se
dispersan, chacun assis avec un client. (Chez ABN AMRO, beaucoup des
Les intervieweurs sont des "personnes qui enquêtent", en d'autres termes, des concepteurs et des personnes
de produits au lieu de chercheurs qualifiés. En raison de cela, les chercheurs
Le personnel formé travaille avec eux avant l'événement pour les aider à créer leur plan
de recherche et guides de discussion. Les entretiens sont généralement réalisés par une paire de
interviewers who work together and take turns interviewing and taking notes).

Les intervieweurs effectuent des entretiens de 15 minutes avec chaque participant. Quand
Les 15 minutes se terminent, chaque intervieweur ou paire se lève et passe au suivant.
participante, quelque chose comme des chaises musicales. De cette manière, chaque intervieweur peut
parler avec chaque participant. Après que tout le monde a parlé avec tous les autres, les
les clients partent et les intervieweurs se réunissent pour informer. Normalement, à chaque
l'intervieweur se voit assigner un seul sujet, mais bien qu'il soit possible qu'il ne travaille pas
dans le même ensemble de questions, le rapport est précieux, car il les aide à comprendre
mieux aux clients et les aide à interpréter les données qu'ils viennent de recueillir. Ils capturent
ce que j'ai appris de cet événement dans un modèle d'information d'une seule page et ensuite
ils ajoutent ces documents à la base de données d'informations partagées de l'entreprise.
l'investigateur Ike Breed, qui a aidé à configurer ce processus, nous a dit que cette étape de
Le partage a réellement démocratisé la recherche. « Les gens pensaient que la base de données
de l'information précieuse était quelque chose de vraiment formel. On m'a demandé : 'Voulez-vous dire que
Puis-je mettre quelque chose là-bas ?". En ouvrant le processus à la contribution d'un groupe plus large,
a aidé les équipes de conception et de produits à se sentir plus propriétaires du processus de
connaissance du client et des données qui ont été collectées dans le cadre de ce processus.

Essaye les mardis

Un autre chercheur avec qui nous avons parlé nous a raconté comment il a commencé une pratique appelée
Mardi de test
technologie orientée vers le consommateur. Andrew Bourne a été embauché là-bas comme
chercheur en usabilité. Lorsqu'il est arrivé, il a découvert qu'un long travail l'attendait
en retard. Alors qu'il travaillait sur le travail en cours, il a commencé à rendre compte des
resultados de la investigación en cada demostración de Sprint, que, en su empresa, se
je le faisais tous les mardis. En raison d'une grande quantité de travail en retard,
il y avait toujours quelque chose de nouveau à rapporter. Pour vous aider à vous assurer que vos rapports
ont été entendus par toutes les parties concernées, il a commencé à publier le contenu de sa session
informations à l'avance par le biais d'annonces par e-mail. Il annonçait :
Cette semaine, je vais informer sur X. Cela a eu deux effets vraiment
positifs. Tout d'abord, il a incité les gens à se présenter à ses séances d'information ; souvent,
beaucoup plus de personnes étaient intéressées par les résultats que ce qu'il y avait
anticipé. De plus, les gens des produits ont commencé à le contacter pour lui demander son
collaboration dans la recherche qu'ils voulaient faire. En d'autres termes, cela a augmenté la
demande de recherche. Et pas seulement des études d'usabilité. Les personnes qui se rendaient à
ils demandaient toutes sortes de recherches, y compris des études exploratoires aux premières étapes.

RECHERCHECONTINUEDANSSPERIENTIALABS

Sperientia Labs est une agence de recherche sur l'expérience utilisateur d'environ 30
personnes établies à Puebla, Mexique. Sperientia offre des recherches aux clients dans
un format unique : ils utilisent une série de sprints de recherche d'une
semaine.« Nous utilisons une approche où le cadre Agile est toujours à l'esprit », dit
le fondateur Víctor M. González.

Cette approche présente plusieurs avantages. Tout d'abord, González dit que la plupart de ses
les clients travaillent déjà à un rythme agile. Cela permet à Sperientia de synchroniser son
ligne du temps avec la ligne du temps des clients.

Un autre avantage est la rapidité avec laquelle ces cycles produisent des résultats. Sperientia
offre des entretiens de découverte et des tests d'ergonomie au cours d'une
semaine très structurée. Ils planifient et recrutent le vendredi, continuent à recruter et
se préparant lundi, puis ils effectuent des tests avec entre trois et six participants mardi
et mercredi matin. Mercredi après-midi, ils ont une séance d'information avec
sus clients. "Dans de nombreux cas, ce rapport est tout ce dont les clients ont besoin et peuvent
ponerse a trabajar de inmediato en lo que han aprendido”, dice González. Aún así,
Sperientia utilise les jeudis pour capturer les résultats et les recommandations dans un
informe, et ensuite il se réunit avec les clients vendredi matin pour examiner les
découvertes en détail. Après le déjeuner de vendredi, ils sont prêts à commencer à
planifier votre prochain cycle.

Cependant, tous les objectifs de la recherche ne peuvent pas être atteints en une semaine,
Le programme de recherche typique de Sperientia dure de 3 à 12 mois. Alors,
bien qu'ils utilisent des cycles de recherche d'une semaine dans tous leurs programmes, ils ne se
limitent à répondre uniquement aux questions qui peuvent être répondues en une seule semaine. Dans
changement, ils utilisent des cycles continus d'une semaine pour aborder une gamme beaucoup plus
amplitude de questions.

L'agence travaille avec une variété d'objectifs de recherche de clients : ils aident à
les clients à comprendre et à développer des propositions de valeur, comprendre le travail que
les utilisateurs doivent réaliser et évaluer l'utilisabilité et le design de leurs offres.

En utilisant un programme de plusieurs cycles d'une semaine, Sperientia peut exécuter

programmes de recherche qui croissent et évoluent à mesure qu'ils apprennent. Ils peuvent
exécuter des programmes de recherche qui suivent le rythme du développement d'un
produit. Ils peuvent exécuter des programmes de nature longitudinale. Et bien que leur approche soit
fondamentalement qualitatif (basé sur des sessions individuelles avec des utilisateurs et des clients)
ils peuvent créer des programmes qui collectent des données quantitatives en posant les mêmes questions
semaine après semaine.

Récemment, Sperientia a commencé à expérimenter un nouveau format de sprint.

investigation de deux semaines. Ils utilisent ce format lorsqu'ils doivent répondre à des questions
qui impliquent un type de prototype. Dans ces cas, ils prolongeront le cycle pour inclure
une semaine de développement de prototypes, suivie de sa semaine typique de
investigation. Pour y parvenir, ils augmentent l'équipe de recherche pour inclure
des designers qui peuvent les aider à créer des prototypes pour effectuer des tests.

Par conséquent, travailler avec ces cycles courts d'une semaine aide l'agence à égaliser
le rythme de ses clients, l'aide à offrir des résultats rapides et continus et a un
bénéfice supplémentaire. González le décrit de cette manière : « Nous avons les week-ends
avec la tranquillité d'avoir terminé !

Donner du sens à la recherche : une activité en équipe

Que ce soit votre équipe qui effectue un travail de terrain ou de laboratoire, la recherche génère une
une grande quantité de données brutes. Comprendre cela peut prendre beaucoup de temps et être
frustrant, car le processus est souvent confié à des spécialistes à qui l'on demande
que résument les résultats de la recherche. Tu ne devrais pas faire ça. À la place,
travaille aussi dur que possible pour donner un sens aux données en équipe.

Dès que possible après la fin des sessions de recherche,

de préférence le même jour, sinon le lendemain, réunissez l'équipe pour une session de
révision. Lorsque l'équipe se sera à nouveau réunie, demandez à tous de lire leurs constatations.
entre elles. Une façon vraiment efficace de faire cela est de transcrire les notes que les gens lisent.
à voix haute sur des fiches ou des notes adhésives, puis organiser les notes par thèmes. Ce processus
la lecture, le regroupement et la discussion mettent sur la table les opinions de tous et construisent
la compréhension partagée que vous recherchez. Avec les thèmes identifiés, vous et votre
équipe peut déterminer les prochaines étapes pour son MVP.

Confusion, contradiction et (manque de) clarté

À mesure que vous et votre équipe recueillez des retours de diverses sources et essayez de
synthétiser leurs découvertes, ils se trouveront inévitablement confrontés à des situations dans lesquelles leurs
les données présentent des contradictions. Comment donner un sens à tout cela ? Voici un couple de
façons de maintenir son élan et de s'assurer qu'il maximise son apprentissage.

Cherchez des motifs

Tout en examinant la recherche, faites attention aux motifs dans les données. Ces motifs
révèlent de multiples instances d'opinion des utilisateurs qui représentent des éléments pour
explorar. Si algo no sigue un patrón, es probable que sea un valor atípico.

Mettez vos valeurs aberrantes dans un "stationnement"

Aussi tentant soit-il d'ignorer les valeurs aberrantes (ou d'essayer de les inclure dans votre
solución), no lo haga. En su lugar, cree un estacionamiento o un atraso. A medida que
votre recherche progresse avec le temps (rappellez-vous : vous faites cela chaque semaine)
Il est possible que vous découvriez d'autres valeurs aberrantes qui correspondent au motif. Soyez patient.
Vérifier avec d'autres sources

Si vous n'êtes pas convaincu que les commentaires que vous voyez à travers un canal soient
valides, recherchez-les sur d'autres canaux. Les courriels du service client
reflètent les mêmes préoccupations que leurs études d'usabilité ? La valeur de votre
le prototype se reflète-t-il chez les clients à l'intérieur et à l'extérieur de son bureau ? Sinon, votre
l'échantillon aurait pu être indûment biaisé.

Identifier des motifs au fil du temps

Les programmes typiques de recherche en UX sont structurés pour obtenir

une réponse concluante : il prévoit de faire suffisamment de recherche pour répondre de
manière concluyente à une question ou un ensemble de questions. La recherche Lean UX
adopte une approche différente. Donnez la priorité à la continuité, ce qui signifie que vous êtes
structurant leurs activités de recherche de manière très différente. Au lieu de
réaliser de grandes études, voit une petite quantité d'utilisateurs chaque
semana. Esto significa que algunas preguntas pueden permanecer abiertas durante un par
de semaines. Cependant, un grand avantage est que des motifs intéressants peuvent
se révéler avec le temps.

Par exemple, au cours de séances de test régulières de 2008 à 2011, l'équipe

de TheLadders a observé un changement intéressant dans les attitudes de ses clients au fil du temps
du temps. En 2008, lorsqu'ils ont commencé à se réunir pour la première fois avec des personnes qui
ils cherchaient un emploi de manière régulière, discutaient de plusieurs façons de communiquer avec les
employeurs. L'une des options qu'ils ont proposées était le SMS. En 2008, l'audience,
composée de personnes à hauts revenus âgées de 40 à 50 ans, a montré un fort mépris
par les SMS comme méthode de communication légitime. Pour eux, c'était quelque chose qu'ils faisaient leurs
enfants (et peut-être le feraient-ils avec leurs enfants), mais ce n'était certainement pas une manière "appropriée".
de réaliser une recherche d'emploi.

Sin embargo, para 2011, los mensajes SMS habían despegado en Estados Unidos. A
À mesure que la messagerie texte a gagné en acceptation dans la culture d'entreprise, les attitudes
de l'audience ont commencé à s'adoucir. Semaine après semaine, alors qu'ils s'asseyaient avec
Les demandeurs d'emploi ont commencé à voir des avis sur le changement de SMS. Le
l'équipe a constaté que les demandeurs d'emploi avaient beaucoup plus de chances d'utiliser les SMS
dans une recherche d'emploi à mi-carrière que ce qu'ils auraient fait quelques années auparavant.

L'équipe de TheLadders n'aurait jamais reconnu cela comme une tendance pour toute la
audience s'il n'y avait pas deux choses. D'abord, ils parlaient avec un échantillon de leur
audience, semaine après semaine. Cependant, de plus, l'équipe a adopté une approche
systématique pour enquêter sur les tendances à long terme. Dans le cadre de son interaction
régulier avec les clients, ils posaient toujours un ensemble régulier de questions de
établissement de niveaux pour capturer les "signes vitaux" de la recherche du demandeur
d'emploi, peu importe quelles autres questions, caractéristiques ou produits étaient
testant. En faisant cela, l'équipe a pu établir une base de référence et aborder les tendances
les plus importants au fil du temps. Les découvertes sur les SMS n'auraient pas changé le
compréhension de l'équipe de son public s'ils n'avaient représenté que certains points de
données anecdotiques. Mais agrégées avec le temps, ces points de données sont devenus
partie d'un ensemble de données très puissant.
Lors de la planification de votre recherche, il est important de prendre en compte non seulement les questions
urgentes, mais aussi les choses qu'il souhaite apprendre au cours des prochaines
semanas. También debe considerar las grandes preguntas. Aún debe planificar grandes
études indépendantes pour aborder certaines de ces questions. Mais avec un peu de
planification, devrait pouvoir incorporer beaucoup d'apprentissage à long terme dans ses études
hebdomadaires.

Teste ce que tu as

Pour maintenir une cadence régulière de tests utilisateurs, votre équipe doit adopter une
politique de "teste ce que tu as". Ce qui est prêt le jour de l'essai est ce qui est présenté
aux utilisateurs. Cette politique libère votre équipe de se précipiter vers les délais de
jour de l'épreuve ou, ce qui est pire, retarder les activités de recherche à la recherche d'un
moment "parfait" évasif. En revanche, lorsque vous adoptez une approche de "testez ce que
tienes", te encontrarás aprovechando tus sesiones de prueba semanales para obtener
informations sur ce qui est prêt, et cela créera des informations pour vous à chaque étape du
conception et développement. Cependant, il doit fixer des attentes de manière appropriée pour
el tipo de comentarios que podrá generar con cada tipo de artefacto.

Croquis

Les commentaires recueillis dans les croquis vous aident à valider la valeur de votre concept
(consulte laFigure 15-2Ce sont d'excellentes suggestions de conversation pour soutenir les
des entretiens et aident à concrétiser des concepts abstraits, ce qui aide à générer un
compréhension partagée. Ce que vous n'obtiendrez pas des croquis ce sont des commentaires détaillés
et étape par étape sur le processus, informations sur des éléments de conception spécifiques ou
y compris des commentaires significatifs sur les options de copie. Vous ne serez pas capable
d'apprendre beaucoup (s'il y a lieu) sur l'utilité de son concept.
Figure 15-2. Exemple d'un croquis qui peut être utilisé avec les clients.
Maquettes statiques

Afficher les trames filaires des participants à l'essai (Figure 15-3) vous permet de
évaluer la hiérarchie de l'information et le design de votre expérience. De plus, vous obtiendrez
commentaires sur la taxonomie, la navigation et l'architecture de l'information.

Recibirá los primeros comentarios sobre el flujo de trabajo, pero en este punto los
les participants du test se concentrent principalement sur les mots de la page et sur les
les choix qu'ils font. Les wireframes offrent une bonne opportunité pour
comenzar a probar las opciones de copia.
Figure 15-3. Exemple d'une structure filaire
Maquettes visuelles haute fidélité (clics non disponibles)

Pasando a activos de diseño visual de alta fidelidad, recibe retroalimentación mucho más
détaillée. Les participants au test pourront répondre à la marque, à l'esthétique et à la
hiérarchie visuelle, ainsi que les aspects des relations figure / fond, le regroupement de
éléments et la clarté de leurs appels à l'action. Les participants au test également
(quasi avec certitude) ils évalueront l'efficacité de leur palette de couleurs. (Voir la Figure 15-4.)

Les maquettes sur lesquelles on ne peut pas cliquer ne permettent pas encore à leurs clients
interactúen de forma natural con el diseño o experimenten el flujo de trabajo de su
solution. Au lieu de voir vos utilisateurs cliquer, toucher et glisser, vous devez leur demander quoi
ils attendraient et valideraient ensuite ces réponses avec leur expérience planifiée.
Figure 15-4. Exemple de maquette de Skype dans la salle de classe (design de Made By Many)
Maquettes sur lesquelles on peut cliquer

Maquettes cliquables, comme celle montrée à la Figure 15-

4Augmentez la fidélité de l'interaction en liant un ensemble d'actifs statiques dans
une simulation de l'expérience du produit. De nos jours, la plupart des
les outils de conception facilitent la liaison de plusieurs écrans statiques pour produire
ce type de maquettes. Visuellement, elles peuvent être de haute, moyenne ou même basse fidélité. Le
la valeur ici n'est pas tant le poli visuel que la capacité à simuler le flux de travail et
observer comment les utilisateurs interagissent avec leurs conceptions.

Les designers avaient souvent des options limitées d'outils pour créer des maquettes en
celles sur lesquelles on pouvait cliquer, mais ces dernières années, nous avons vu une grande prolifération
de outils. Certains outils sont optimisés pour faire des maquettes mobiles,
d'autres sont pour le web et d'autres sont neutres par rapport à la plateforme. La plupart n'ont pas de capacité
pour travailler avec des données, mais avec certains (comme Axure), vous pouvez créer des simulations de base
basadas en datos o basadas en lógica condicionada. Además, las herramientas de diseño
comme Figma, Sketch, InVision et Adobe XD incluent des fonctions de "miroir" avec lesquelles
vous pouvez voir votre travail de conception en temps réel sur des appareils mobiles et lier des écrans
pour créer des prototypes sans outils spéciaux de création de prototypes.

Prototypes codés

Los prototipos codificados son útiles porque tienen los mejores capacidad para ofrecer
haute fidélité en termes de fonctionnalité. Cela en fait la simulation la plus
proche de la réalité qu'elle peut présenter à ses utilisateurs. Réplique le design, le
comportement et le flux de travail de votre produit. Vous pouvez essayer avec des données réelles. Vous pouvez
s'intégrer à d'autres systèmes. Tout cela fait que les prototypes codés sont très
puissants; cela les rend également les plus complexes à produire. Mais en raison de ce que le
la rétroaction que vous obtenez est basée sur une simulation si proche, vous pouvez traiter cela.
rétroaction comme étant plus autorisée que la rétroaction que vous obtenez de
otras simulaciones .

Techniques de suivi pour la découverte continue et collaborative

Lors des discussions précédentes, nous avons analysé des manières d'utiliser la recherche qualitative
forme périodique pour évaluer ses hypothèses. Cependant, dès que vous lancerez votre
produit ou fonction, vos clients commenceront à vous donner des retours constants, et pas seulement
à propos de votre produit. Ils vous parleront d'eux-mêmes, du marché, de la concurrence. Ce
l'information est inestimable et arrive dans votre organisation de tous les coins. Cherchez
ces trésors d'intelligence des clients au sein de votre organisation et profitez-en pour
impulser sa recherche et son design de produits en cours, comme indiqué dans leFigure
15-5.
Figure 15-5. Les clients peuvent fournir des commentaires par le biais de nombreux canaux.
Servicio al Cliente

Les agents de service clientèle parlent à plus de clients quotidiennement par rapport à ce dont ils parleront.
dans le cadre d'un projet complet. Il existe plusieurs façons de tirer parti de votre
conocimiento:

• Communiquez-vous avec eux et demandez-leur ce qu'ils entendent des clients à propos de

sections du produit sur lequel il travaille.
• Organisez des réunions mensuelles régulières avec eux pour comprendre les
tendencias. ¿Qué les encanta a los clientes este mes? ¿Qué odian?
• Profitez de votre connaissance approfondie du produit pour apprendre comment
résoudraient les défis sur lesquels votre équipe travaille. Incluez-les dans
sessions de conception et révisions de conception.
• Incorporez vos hypothèses dans leurs scripts d'appel. L'une des façons les plus
économiques de tester vos idées est de les suggérer comme une solution aux clients qui
ils appellent avec des plaintes pertinentes.

Au milieu des années 2000, Jeff dirigeait l'équipe UX dans une technologie de
taille moyenne. entreprise à Portland, Oregon. Une des façons dont l'équipe a priorisé
el trabajo que realizaba fue controlando regularmente el pulso de la base de clientes. El
équipe a fait cela avec une réunion mensuelle permanente avec des représentants du service à
client. Chaque mois, le Service clientèle fournirait à l'équipe UX les
10 principales choses dont se plaignaient les clients. Ensuite, l'équipe UX a utilisé
cette information pour orienter vos efforts et ensuite mesurer l'efficacité de votre
trabajo. A finales de mes, la siguiente conversación con el Servicio de atención al cliente
il a donné à l'équipe une indication claire de si leurs efforts portaient leurs fruits ou non. Si le
le problème ne reculait pas dans le classement des 10 principaux, les solutions n'avaient pas
fonctionné.

Cette approche a généré un avantage supplémentaire. L'équipe du Service Client s'est rendu compte
de que quelqu'un écoutait ses idées et a commencé à partager de manière proactive
les commentaires des clients au-delà de la réunion mensuelle. Le dialogue qui s'est créé
a fourni à l'équipe UX un cycle de rétroaction continue pour informer et
tester des hypothèses de produits.

Enquêtes de commentaires sur place

Configurez un mécanisme de rétroaction dans votre produit avec lequel les clients
vous pouvez lui envoyer vos pensées régulièrement. Voici quelques options :

• Formularios de correo electrónico sencillos

• Forums de support à la clientèle
• Sites de communautés tierces

Vous pouvez réutiliser ces outils pour la recherche en faisant des choses comme les
suivants :

• Compter combien d'e-mails entrants vous recevez d'une section

particulier du site
• Participer à des discussions en ligne et tester certaines de ses hypothèses
• Explorer des sites de la communauté pour découvrir et recruter des types d'utilisateurs difficiles
de trouver

Ces canaux de rétroaction des clients entrants fournissent des retours d'information
du point de vue de ses clients les plus actifs et engagés. Voici quelques
tactiques pour obtenir d'autres points de vue.

Registres de recherche

Les termes de recherche sont des indicateurs clairs de ce que les clients cherchent dans
son site. Les modèles de recherche indiquent ce qu'ils trouvent et ce qu'ils ne trouvent pas
trouvent. Les consultations répétées avec de légères variations montrent le défi d'un
utilisateur pour trouver certaines informations.

Une façon d'utiliser les enregistrements de recherche pour la validation du MVP est de lancer
une page de test pour la fonction que vous envisagez. Après la recherche, les
Les enregistrements vous informeront si le contenu (ou la fonction) du test sur cette page satisfait les
besoins de l'utilisateur. Si les utilisateurs continuent à chercher des variations de ce contenu,
votre expérience a échoué.
Analyse de l'utilisation du site

Registres d'utilisation du site et packages d'analyse, notamment l'entonnoir Analyse :

ils montrent comment les clients utilisent le site, où ils l'abandonnent et comment ils essaient
manipuler le produit pour faire les choses qu'ils ont besoin ou qu'ils attendent qu'il fasse. Le
la compréhension de ces rapports fournit un contexte du monde réel pour les
décisions que l'équipe doit prendre.

De plus, utilisez des outils d'analyse pour déterminer le succès des expériences que
ont été lancés publiquement. Comment l'expérience a-t-elle changé l'utilisation de
produit ? Vos efforts atteignent-ils le résultat que vous avez défini ? Ces outils
fournissent une réponse impartiale.

Si vous commencez à créer un produit, intégrez l'analyse d'utilisation dès le départ.

[Link] produits de métriques de tiers, comme Kissmetrics et MixPanel, rendent que
implémenter cette fonctionnalité soit facile et économique, et fournir des informations inestimables
pour soutenir l'apprentissage continu.

Tests A / B

Le test A / B est une technique, développée à l'origine par des spécialistes du marketing,
pour évaluer lequel de deux (ou plusieurs) concepts relativement similaires atteint l'objectif
défini de manière plus efficace. Lorsqu'il est appliqué dans le cadre du Lean UX, les tests A
/ B deviennent un outil puissant pour déterminer la validité de vos
hypothèse. Appliquer les tests A / B est relativement simple après que vos idées
évoluez vers un code du travail. Voici comment cela fonctionne :

• Prenez la solution proposée et publiez-la auprès de votre audience. Cependant, au lieu de

laisser tous les clients le voir, publiez-le uniquement pour un petit sous-ensemble
des utilisateurs.
• Mesurez le rendement de votre solution pour ce public. Comparez-le à l'autre
groupe (son groupe de contrôle) et observez les différences.
• Votre nouvelle idée a-t-elle fait avancer les choses dans la bonne direction ? Si c'est le cas, vous avez une idée.
gagnante.
• Sinon, vous avez un public de clients qui pourraient être de bonnes cibles.
Pour une plus grande recherche. Que pensez-vous de la nouvelle expérience ? Aurait-elle
Est-il pertinent de les contacter pour réaliser une recherche qualitative ?

Les outils pour les tests A/B sont largement disponibles et peuvent être
économiques. Il existe des outils commerciaux tiers comme Optimizely. Aussi
il existe des cadres de test A / B open source disponibles pour toutes les plateformes
principales. Indépendamment des outils que vous choisissez, le truc consiste à
s'assurer que les modifications que vous apportez sont suffisamment petites et la
la population que vous sélectionnez soit suffisamment grande pour que tout changement
dans le comportement peut être attribué avec confiance au changement qu'il a effectué. Si
cela change trop de choses, tout changement de comportement ne peut pas être attribué
directement à son hypothèse exacte.

Terminant
Dans ce chapitre, nous couvrons de nombreuses façons de valider vos hypothèses. Nous analysons le
découverte collaborative et les techniques d'apprentissage continu. Nous discutons de la façon dont
construire un processus de test Lean hebdomadaire et couvrir ce qui doit être testé et à quoi s'attendre
de ces tests. Nous cherchons des moyens de surveiller l'expérience de vos clients dans un
contexte Lean UX et nous abordons le pouvoir des tests A / B.

Ces techniques, utilisées conjointement avec les processus décrits dans leChapitre 4et leChapitre
5, ils constituent le cycle complet du processus Lean UX. Leur objectif est de traverser ce cycle
aussi souvent que possible, en affinant sa pensée à chaque itération.

Dans la section suivante, nous nous éloignons du processus et jetons un œil à comment intégrer
Lean UX dans votre organisation. Nous couvrirons les changements organisationnels que vous devrez apporter.
pour soutenir l'approche Lean UX, que ce soit une startup, une grande entreprise ou un
agence numérique.
Chapitre 16. Intégration de Lean UX et
Agile
Demandez à n'importe quelle personne de n'importe quelle organisation quelle est la forme par défaut
de travailler est pour eux, et la réponse sera invariablement "Nous faisons
Agile!" Suivez cette question avec "Et comment cela fonctionne-t-il pour vous ?" et dans la plupart des cas
les cas seront levés la main et secouée d'un côté à l'autre dans le geste de 'meh, ça va'.

Agile est né des développeurs, en fait 17 d'entre eux, qui représentent des façons
émergentes de travail qui étaient nées de sa frustration avec les processus d'ingénierie
plus anciens et l'imprévisibilité du développement de logiciel. Lors d'une réunion de fin
semaine dans l'Utah en 2001, ces développeurs de logiciels ont réuni une série de
principes qui ont appelé Manifeste Agile.1Si vous ne l'avez pas lu (vous devriez le faire, c'est court),
vous serez surpris de découvrir qu'il n'y a pas beaucoup de "processus" prescrit dans le Manifeste
Agile. Il n'y a rien là qui dise : « Tu te lèveras tous les jours à 9h15 avec ton équipe »
Vous travaillerez par cycles de deux semaines appelés sprints. Ce sont des techniques tirées de
méthodes agiles spécifiques, comme Scrum et Extreme Programming (XP), méthodes qui
ils ont été inventés par de nombreuses personnes qui se sont réunies pour créer le Manifeste
Agile en soi. Au lieu de capturer des pratiques spécifiques, les auteurs du Manifeste
enumeraron valores y principios para el desarrollo de software altamente colaborativo y
centré sur le client. La phrase la plus convaincante de tout le manifeste, et à notre avis
la base de la vraie agilité est "[Nous valorisons] répondre au changement plutôt que de suivre"
un plan.

C'est là le cœur du problème, vraiment. S'il travaille d'une manière qui invite au
apprentissage, accepte cet apprentissage de manière humble et change son plan en fonction
de ce qu'il a appris, il est agile.

Au cours des 20 dernières années depuis la création du Manifeste, cette approche pour faire le
le travail est devenu la forme par défaut de travail dans la plupart des
organisations (ou du moins, l'aspiration par défaut). Ces idées agiles sont arrivées
bien au-delà des équipes de développement de logiciels et sont maintenant appliqués à
tout, de la planification stratégique et du leadership aux ressources humaines, les
finances, le marketing et, bien sûr, le design.

La forme la plus connue d'Agile est Scrum, un cadre léger principalement inventé par
Jeff Sutherland et Ken Schwaber au milieu des années 1990. (Oui, Scrum existe depuis)
depuis plus de temps que le Manifeste Agile). Et pourtant, malgré toute sa popularité,
Scrum n'a commencé récemment à réfléchir à la manière dont le design s'intègre dans le
[Link]'en novembre 2020,Le Guide Scrum , la documentation officielle de
Scrum, n'avait jamais mentionné l'expérience utilisateur ou le design de quoi que ce soit.
manière. Alors que le grand design et l'approche client deviennent des facteurs
de succès de plus en plus importants dans les produits technologiques, tant les designers
comment les professionnels de l'Agile ont lutté pour découvrir exactement comment s'intégrer
dans les processus Agile. Tandis que le reste de Lean UX décrit une manière agile de
travailler, ce chapitre aidera à répondre à certaines questions sur la façon dont Lean s'adapte
UX à la mécanique des méthodes agiles et, en particulier, nous nous concentrerons sur le design
dans le contexte de Scrum.
Faites vôtre le processus agile
On nous demande souvent comment les équipes agiles devraient fonctionner.
formés. Devrient-ils utiliser Scrum ? Devrient-ils travailler en sprints de deux semaines ? Que
Quel niveau de formalité doivent-ils mettre en œuvre pour réussir ? Avec tant d'histoires de
frustration avec les transformations agiles, les équipes et les leaders veulent bien faire
aussi rapidement que possible et minimiser la douleur, la frustration et la diminution de la
productivité. Vous pourriez passer les dix prochaines années à lire tous les livres sur
meilleures pratiques de Scrum, mais lorsqu'on le réduit à son noyau, il reste les suivants
des composants qui constituent un excellent point de départ pour toute équipe :

• Travaille par courts cycles.

• Livrez de la valeur à la fin de chaque cycle.
• Organisez une brève réunion de planification quotidienne (ou Scrum quotidien).
• Réalisez une rétrospective après chaque cycle.

Il peut passer beaucoup de temps à débattre de tous les autres composants de Scrum (ainsi que
les choses que les gens pensent faire partie de Scrum mais qui ne sont jamais mentionnées dans la
Guide de Scrum), mais ces quatre éléments de base fournissent tout ce dont vous avez besoin
pour augmenter l'agilité. de votre équipe. Une équipe avec un alignement dédié travaillera
ensemble pour découvrir ce qu'ils peuvent faire à chaque cycle. Ils se réuniront quotidiennement pour
déterminer quel est le prochain ensemble de choses les plus importantes à faire et,
de manière critique, ils réviseront l'efficacité de leur processus après chaque cycle.

En fait, il n'est pas exagéré de dire que les rétrospectives, lorsqu'elles sont utilisées correctement,
sont la clé pour construire une équipe agile cohésive et multifonctionnelle. Scrum ne vous dit pas
comment intégrer les designers ou le travail de design dans un sprint ou comment gérer le
travail de conception dans le backlog, mais si votre équipe essaie d'incorporer une méthode
conception dans le processus de Scrum, il l'exécute pendant un sprint ou deux, puis, des rétrospectives
pour déterminer à quel point cela a bien fonctionné, vous avez commencé le processus de devenir propriétaire de votre
processus Agile. Si vous éliminez l'esprit prescriptif de Scrum du processus et, à la place,
applique la lentille philosophique du Manifeste Agile, alors, en fait, elle répond à
changement au lieu de suivre un plan. Dans ce cas, le plan est la recette rigide du processus
Agile ; le changement auquel il répond est sa compréhension de combien cela a bien fonctionné
cette recette pour vous et votre équipe. Si ça fonctionne bien, fantastique ! Continuez à le faire. Mais si
no logró lo que esperaba, cambie de rumbo. Ahora estásserágil en lugar de
simplementehacerlo.

C'est pourquoi les rétrospectives sont si puissantes et sont le seul événement de Scrum qui
nous recommandons plus que tout autre. Les rétrospectives honnêtes et irréprochables
offrent à une équipe l'occasion régulière d'ajuster sa façon de travailler. Un
la rétrospective regarde en arrière sur le dernier cycle ou deux et demande : Qu'est-ce qui a fonctionné ?
Bien ? Qu'est-ce qui n'a pas bien fonctionné ? Qu'allons-nous changer à l'avenir ? Le meilleur
Une partie de l'approche d'un processus de cette manière est que le risque de changer votre processus est
minimum. Le plus que vous aurez à vivre avec un changement est la durée de votre sprint. Bien que
ce chapitre vous proposera de nombreuses façons de construire un processus intégré de Lean UX et
Scrum, quoi que vous fassiez, assurez-vous d'utiliser des rétrospectives pour examiner ce que vous faites. Si
les techniques que nous recommandons ne fonctionnent pas pour votre équipe, changez-les, mélangez-les et
combinez-les ou jetez-les. Votre version d'Agile (ou Scrum) sera différente de celle de quiconque
équipe. C'est bien. En fait, nous dirions que c'est l'objectif d'être agile.

Redéfinissant "Prêt"

Quand le logiciel est-il prêt ? Nous en avons parlé dans le Chapitre 3. Quand est-il prêt ?
travaillant pour créer un résultat, vous devez envoyer le logiciel (le résultat) puis voir
si crée le résultat que vous souhaitez. Vous ne pouvez pas envoyer de logiciel tant que vous n'avez pas "terminé". Mais
pas de haterminadorealmente jusqu'à ce que ce logiciel ait été "validé".

En Scrum, rien ne peut être transmis à un utilisateur tant que ce n'est pas "fini". Cela a beaucoup
sens. Vous devez vous assurer que le logiciel que vous lancez répond à certaines
normes de qualité partagés (ce que Scrum appelle "la définition de fait") et que
offre la fonctionnalité que vous et votre équipe avez planifiée (ce que Scrum appelle les
( critères d'acceptation ). La définition est en fait créée par l'équipe et les critères de
l'acceptation est généralement établie par le responsable produit ou le propriétaire du
produit. Ensemble, ces normes garantissent que chaque travail est complet, fonctionne
selon ce qui a été conçu, sans erreurs et assez stable pour passer à
production. Cependant, pour la plupart des équipes Scrum, c'est la fin de leur
participation avec ce logiciel. Ce point final, cependant, n'est pas fait
responsable des résultats et reflète une idée beaucoup plus ancienne de la nature du
logiciel.

Quand nous avons commencé nos carrières, le logiciel venait dans une boîte. Si cela vous semble
étrange, cela pourrait être encore plus étrange de savoir que lorsque Jeff était enfant, son père amenait à
casa les cartes perforées avec lesquelles venait le logiciel dans les années 1970. Dans les deux
casos, avec plus de 20 ans de différence, le logiciel était statique. Il avait un état
final. Nous pourrions l'emballer dans des boîtes ou sur des cartes en papier. Avancez rapidement de 20 autres
années, et ces concepts semblent ridicules maintenant. Le logiciel ne vient plus dans une boîte et ne...
il est statique. Aujourd'hui, nous construisons des systèmes qui se mettent continuellement à jour et qui peuvent
optimiser indéfiniment. De nos jours, il est facile de soutenir que le
softwarenuncahecho. Cela rend la question « Quand terminons-nous ? » difficile à
répondre. Mais nous devons y répondre car cela aide à répondre à d'autres questions encore plus.
importantes. Passons-nous à la fonction suivante ou non ? L'équipe est-elle récompensée ou
puni ? L'intéressé reçoit-il son bonus ?

Scrum, con sus conceptos de "criterios de aceptación" y "definición de hecho", les ha

donné aux équipes un ensemble clair d'objectifs à atteindre. Mais ces objectifs ne sont que
ils arrivent jusqu'à un certain point. Comme nous l'avons dit, ils s'assurent que le logiciel "fonctionne"
según lo diseñado".Pero “funciona según lo diseñado” solonos dice que el software hace
consistamment ce que nous lui demandons de faire. Malheureusement, cela n'est pas
suffisant. Nous avons également besoin de savoir si le logiciel a généré de la valeur. Quelqu'un a-t-il trouvé la
fonction que nous avons finide envoyer ? Le ont-ils essayé ? Ont-ils eu succès
l'utilisant ? Sont-ils revenus et l'ont-ils utilisé à nouveau ? Nous ont-ils payé pour cela ? En d'autres termes,
nous avons besoin de savoir s'il a généré un résultat.

Alors, comment nos équipes savent-elles quand le travail est terminé ? Quand
savez-vous quand passer à l'initiative suivante? Nous devons ajouter un concept ici : le
concept de "validé". Et la validation commence avec nos clients.
Nous validons notre travail après qu'il est "fait". Après qu'il soit
"accepté". Après qu'il soit entre les mains de nos clients. Nous faisons cela en mesurant
son comportement. Nous faisons cela en écoutant ses besoins et en évaluant si nos
les caractéristiques satisfont ces besoins, puis en itérant jusqu'à satisfaire ces
besoins. Encore et encore. Il s'avère que les designers sont très bons pour faire cela.
travail.

En élargissant notre idée de « fonctionne comme prévu » à « validé avec les

clients", nous nous dirigeons vers ce sur quoi travaillent les équipes Scrum. Au lieu de
se concentrer sur les fonctions d'expédition, ils se concentrent sur le fait de faire réussir les clients. Le
le design est une partie intégrante de cela, car le design fournit beaucoup des
outils nécessaires pour comprendre les clients et perfectionner les solutions pour
satisfaire mieux ses besoins. Si la définition de fait d'une fonction est reformulée
En conséquence, l'équipe n'a d'autre choix que de tester les premières versions de
votre idée, interagir avec les clients pour comprendre comment les choses peuvent être améliorées et
concevoir des versions optimisées de la fonction pour répondre aux besoins changeants.
besoins.

Voici un exemple. Critères d'acceptation exprimés traditionnellement pour un flux de

authentification par mot de passe :

• Requiert une saisie de mot de passe

• Le mot de passe respecte les lignes directrices des exigences de base
• Le mot de passe est entré correctement et l'utilisateur est vérifié dans le système.
• Le lien de récupération de mot de passe est actif
• Un message d'erreur apparaît lorsque le mot de passe est saisi incorrectement.
• Après trois tentatives infructueuses, l'accès est bloqué

Critères reformulés pour la même caractéristique :

• Le pourcentage d'utilisateurs qui s'authentifient avec succès dès la première tentative est de
99 % ou plus
• Le nombre de tentatives de récupération de mot de passe est réduit de 90 %
• Le pourcentage d'appels au centre d'appels demandant la réinitialisation de
le mot de passe a été réduit de 75 %

Dans l'exemple traditionnel, l'équipe crée et lance un ensemble de caractéristiques qui

fonctionnent comme prévu. Avec la deuxième définition, l'équipe ne termine pas tant que
le client a plus de succès qu'il n'en a aujourd'hui. Cette méthode reflète la nature moderne de
logiciel et nécessite l'intervention et l'inclusion de la recherche, de la découverte et du design
dans le processus Scrum. Ce recalibrage de l'objectif de l'équipe ne nie pas la valeur des
criterios de aceptación tradicionales. Todavía queremos enviar a producción código
stable, de haute qualité, haute performance et sûr. Cependant, ce n'est pas
suffisante. Ces attributs sont des paris sur la table. Rien de tout cela n'a d'importance si cela ne fait pas que le
le client ait plus de succès.

Nous faisons encore des sprints échelonnés. Pourquoi ?

En mai 2007, Desiree Sy a publié "Adaptation des recherches en matière d'utilisabilité"

pour un design agile centré sur l'utilisateur dans la Revue d'Études sur l'Usabilité.2Sy
c'est l'une des premières personnes à essayer de combiner Agile et UX, et beaucoup d'entre nous
nous étions enthousiasmés par les solutions qu'il proposait. Dans l'article de 2007, Sy
décrivez en détail votre idée d'une intégration productive du design agile et centré sur l'utilisateur
utilisateur. Elle l'a appelé cycle 0 (bien qu'il soit communément connu sous le nom de "sprint zéro" ou, à
fois, "sprints échelonnés".

En résumé, Sy, avec Lynn Miller, a décrit un processus dans lequel l'activité de
la conception a lieu un sprint avant le développement. Le travail est conçu et validé durant le
sprint de conception" et ensuite on passe au flux de développement pour être mis en œuvre pendant le
sprint de développement, comme illustré dans la Figure 16-1.

Figure 16-1. Modèle de "Sprints échelonnés" de Sy et Miller

Cependant, de nombreuses équipes ont mal interprété ce modèle. Sy a toujours plaidé pour
une étroite collaboration entre les concepteurs et les développeurs pendant les deux
diseñoycarreras cortas de desarrollo. Muchos equipos han pasado por alto este punto
critiques et, en revanche, ont créé des flux de travail dans lesquels les designers et
les développeurs communiquent par transfert, créant une sorte de processus de
mini cascade.

Pour les équipes qui effectuent la transition du modèle en cascade à Agile, travailler de cette manière
il a un avantage. Il vous apprend à travailler en cycles plus courts et à diviser votre travail en morceaux
séquentiels. Cependant, ce modèle fonctionne mieux comme transition. Ce n'est pas là où
il veut que je termine son équipe.

Voici pourquoi : il est très facile de créer une situation où toute l'équipe n'est jamais
travaillant sur la même chose en même temps. Il ne se rend jamais compte des avantages de la
collaboration multifonctionnelle parce que les différentes disciplines se concentrent sur des choses
différentes. Sans cette collaboration, aucun entendement partagé n'est créé, donc
termine dépend dans une large mesure de la documentation et des transferts pour la
communication.

Il y a une autre raison pour laquelle ce processus n'est pas idéal : il peut générer des déchets.
inutiles. Il perd du temps à créer de la documentation pour décrire ce qui s'est passé pendant
les sprints de design. Et si les développeurs n'ont pas participé au sprint de design,
ils n'ont pas eu l'occasion d'évaluer la faisabilité ou la portée du travail. Cela
la conversation n'a pas lieu jusqu'au transfert. Peuvent-ils vraiment construire les designs
spécifiés dans les deux prochaines semaines ? Si ce n'est pas le cas, le travail consacré à la conception de
ces éléments sont gaspillés.

Malgré ces inconvénients, de nombreuses équipes travaillent encore en sprints échelonnés

en la réalité. Dans notre expérience, il existe plusieurs causes fondamentales possibles
pour cela :

L'équipe de conception n'est pas intégrée dans le processus de "développement".

Dans de nombreuses entreprises, le design reste un service partagé qui fonctionne

comme une agence interne. Les designers ne sont pas assignés à une équipe Scrum
spécifique. Ils sont vus comme une dépendance pour que le travail commence.
développement de logiciels. En faisant travailler les concepteurs à pleine vitesse, le
Le travail de conception peut "nourrir la machine" du développement de logiciels.

Le développement de logiciels est sous-traité

Certaines organisations sous-traitent encore leur développement logiciel. Dans un monde

donde el software es el motor de los negocios y el crecimiento, este es un talón de
Achille incroyablement risqué. Cependant, si le codage est effectué par un
fournisseur externe, ils voudront voir les designs "finaux" avant d'estimer et de commencer
le travail. Les sprints décalés le rendent possible pour les équipes qui travaillent
avec des sous-traitants.
Agile de culte de cargaison

Certaines organisations ont intégré des processus agiles pour augmenter le

l'efficacité et la productivité du développement de logiciels, pas pour la capacité de
changer de cap en fonction de nouvelles connaissances et compétences. Dans ce
caso, l'organisation fonctionne comme une usine de logiciels, produisant des fonctions.
le plus rapidement possible. Bien que le travail puisse être divisé en sprints et le vocabulaire
Agile est utilisé dans toute l'organisation, la priorité reste simplement d'envoyer
fonctions. Ces organisations se concentrent généralement sur les délais et rarement
ils prennent le temps d'itérer et d'améliorer les caractéristiques grâce aux commentaires
et validations. Les sprints échelonnés fournissent à l'usine de
caractéristiques le matériel nécessaire à la production. La collaboration entre
les concepteurs et les développeurs est minimale, car les transferts et les
les livrables forment encore la base de la conversation entre eux.

Les sprints échelonnés sont un symptôme d'une organisation qui n'a pas adopté
complètement l'agilité. Son utilisation est un tremplin dans la bonne direction, mais un clair
indication que l'équipe n'est pas encore arrivée. Son objectif doit être de générer une plus grande
collaboration et transparence entre les concepteurs et les développeurs tout en réduisant le
destruction de livraisons de documents, révisions de design prolongées et
négociations de caractéristiques.

Agile à double sens

L'agilité à double sens est un modèle qui intègre la découverte de produits et la livraison.
je travaille sur un seul processus pour la même équipe. C'est le modèle le plus réussi que
nous avons vu jusqu'à présent comment mener à bien le travail Lean UX dans le processus Agile.
beaucoup de sens, l'Agile à double sens est ce que Sy et Miller essayaient de transmettre avec leur
modèle de sprint échelonné. Cependant, pour que l'Agile à double sens fonctionne, un
l'équipe doit réaliser les deux types de travail : découverte (Lean UX) et livraison.

Certains équipes interprètent Agile à double sens comme deux types de travail pour deux groupes.
séparés des personnes.

Nous n'aimons pas ce modèle principalement parce qu'il divise l'équipe de développement de
produits en escadrons plus petits (ou, pire encore, séparés) qui ensuite
inévitablement, ils doivent se réunir à nouveau pour construire une compréhension
partagé. Dans la pratique, nous avons vu les équipes se confronter aux suivants
problemas:

Équipes séparées de découverte et de livraison : un antipattern dont nous avons été

Les témoins plusieurs fois est que les équipes se divisent entre ceux qui font la découverte
et qui réalise la livraison dans son équipe. Souvent, le designer UX et/ou le responsable de
les produits assument la plus grande partie du travail de découverte. Les ingénieurs sont
délègue le travail de livraison anticipée. Cela recrée effectivement les mini cascades de
sprints échelonnés, comme décrit précédemment. La compréhension partagée se
rompe, ralentissant le rythme de la prise de décision et réduisant la cohésion, la
productivité et l'apprentissage de l'équipe.

Connaissance limitée de la façon de faire une découverte : La construction d'un

Le processus agile en double voie suppose que votre équipe sait comment faire des découvertes. Il y a
beaucoup d'outils que vous pouvez utiliser pour créer des cycles de rétroaction dans un
enregistrement de découverte. Sans une connaissance plus large de ces outils, les
Les équipes se tournent vers celles avec lesquelles elles sont plus familiarisées et choisissent souvent
tactiques suboptimales pour l'apprentissage. Si vous avez accès à des chercheurs, essayez
ajoutez-les à votre équipe. Au moins, demandez leur avis lorsque les nouvelles commencent.
initiatives de découverte. Les professionnels expérimentés peuvent vous enseigner à votre
équipe le meilleur méthode pour vos besoins et peuvent vous aider à planifier votre travail de
découverte.

Ne pas rétroalimenter la preuve du travail de livraison à l'accumulation de

découvertes : ce défi est symptomatique d'une organisation qui est encore
pensant de manière incrémentale. Une fois qu'une fonction passe de la découverte à la
la livraison, l'équipe l'implémentera comme cela a été conçu et l'enverra. Ce qui est bien avec cela, c'est que,
Dès qu'elle est disponible, cette nouvelle fonction commence à fournir un nouveau
ensemble de données sur le bon fonctionnement et où concentrer vos prochaines
activités de découverte. Il vous suffit de prêter attention et de faire en sorte que l'équipe
prête attention. Assurez-vous que votre équipe continue de recueillir des commentaires sur les
fonctions envoyées et utilisez ces informations pour évaluer périodiquement la priorisation
de son travail de découverte.

La double voie fonctionne lorsqu'il s'agit d'une seule équipe

La meilleure façon de penser au système à double voie est qu'il s'agit de deux types de travail
—découverte de produits et livraison de produits—réalisé par un
équipeFigure 16-2Le travail de découverte consiste en l'apprentissage actif à
à travers des activités de conception et de recherche, ainsi que l'apprentissage passif à travers
de l'analyse entrante des caractéristiques et des produits qui sont déjà sur le marché. Pour
construire une compréhension partagée, nous nous efforçons d'avoir le plus grand nombre
possible des membres de l'équipe qui participent à chaque activité. La quantité de travail
la découverte et la livraison fluctueront d'un sprint à l'autre. C'est normal et peut
l'anticiper pendant qu'il fait des plans.

Figure 16-2. Agile à double cadre fonctionne lorsqu'il s'agit d'une seule équipe. Concept de l'image :
Gary Pedretti et Pawel Mysliwiec

Si vous faites bien le travail de découverte, vous changez et potentiellement

tuant beaucoup d'idées. Nous ne faisons pas de travail de découverte simplement pour
valider chaque fonctionnalité que nous avons dans notre backlog. En revanche, nous sommes en train de tester
et en apprenant, cela signifie parfois que nous supprimons des fonctionnalités avant de les envoyer. Une
vois plus, c'est exactement la raison pour laquelle Agile a été conçu en premier
lieu. Sans travail de découverte, Agile finit par n'être que le moteur de l'usine de
logiciel.

Planification du travail à double sens

Au fil des années de pratique, nous avons essayé de nombreuses façons différentes de...
compte les deux types de travail dans le processus Scrum. Nous essayons de réserver une quantité
spécifique de temps à chaque sprint pour que le travail soit effectué
découverte, mais cela était insatisfaisant, car dans certains sprints il n'y avait rien que
hacer, mientras que en otros era la mayor parte del [Link] probado el enfoque de
Marty Cagan de diviser le travail entre les disciplines (le design et les gestionnaires de
les projets font la découverte, les ingénieurs font la livraison), mais les dépenses
générales des transferts, les négociations et les débats ont réduit la capacité du
équipe pour répondre au changement. En général, nous avons découvert que garantir que tout
l'équipe ajuste sa charge de travail en fonction des besoins du sprint actuel est la meilleure
option. En fait, c'est l'option la plus agile. Elle permet à l'équipe d'ajuster ses activités dans
fonction de ce qu'il apprend, assurant ainsi que le travail le plus important se déroule
à suivre. Parfois ce travail est une découverte et d'autres fois c'est un don.

Pour faire du double Agile un succès et pour intégrer Lean UX dans le flux de travail
le journal de son équipe Scrum, il existe certains éléments structurels qui sont critiques pour
que l'intégration apporte les résultats que votre équipe recherche.

Un designer dédié dans chaque équipe : ici il n'y a pas de compromis. Sans un designer
dédié à l'équipe de Scrum, ce qu'il a est une équipe d'ingénierie logicielle. Si
Bien, ce matériel offrira absolument une expérience utilisateur, il n'aura pas le même
niveau de qualité sans la participation d'un designer. De plus, cette équipe manquera de
compétences pour faire un bon travail de découverte : elles se concentreront exclusivement
en écrire du code. Comme nous l'avons mentionné précédemment, la production de code n'est plus le
L'objectif du grand développement des produits numériques est le moyen d'atteindre une fin. Le
l'objectif est de produire des changements significatifs dans le comportement de nos
clients. Sans une compréhension approfondie du client et de la meilleure façon de satisfaire ces besoins.
besoins, son produit échouera. Les designers apportent cela à l'équipe.

Le travail de design et de découverte est un citoyen de première classe de la

acumulación: enpocas palabras, una acumulación. El trabajo de desarrollo, el trabajo de
contrôle de qualité, le travail de conception, le travail de recherche, quoi que ce soit, tout va dans
un travail en attente, priorisé avec la même équipe qui fait tout ce travail. Si
dès que le travail est divisé entre plusieurs tâches en attente, l'équipe prendra en compte
un d'entre eux comme le "principal" et l'autre ou les autres resteront négligés. Cela peut et
doit avoir les deux pistes du travail gérées dans le même travail
pendiente. Ciertamente, puede diferenciar los diferentes tipos de trabajo en su backlog
(voir les histoires d'expériences, ci-dessous), mais tout doit se terminer de la même manière
outil de gestion de projet, peu importe s'il utilise un tableau Scrum physique
o JIRA ou quelque chose d'autre.

Utiliser un travail en attente et traiter tout le travail de la même manière garantit que le
l'équipe comprend que tous ces composants sont nécessaires au succès de son
produit. Visualisez le travail de Lean UX d'une manière qui le place au même niveau
que le travail de développement de logiciels (qui a toujours le poids le plus élevé dans notre
expérience). Il souligne également les compensations qui devront être réalisées pour que
réalisez le travail de découverte.

A menudo, cela entraînera des questions de vitesse. "Ne réduirons-nous pas notre
vélocité si nous faisons tout ce travail de découverte ? Si elle ne mesure que la
vitesse de livraison, la réponse est oui. Les équipes matures à double sens mesurent à la fois le
vitesse de livraison comme la vitesse de découverte (ou d'apprentissage). Ces équipes
Ils se rendent compte que, à mesure que la quantité de travail d'apprentissage augmente,
inévitablement la quantité de livraison sera réduite. Cela est dû au même groupe de
les personnes effectuent les deux types de travail. C'est aussi bien, car à la fin de la journée,
Nous essayons de maximiser l'efficacité de l'équipe, et nous le faisons en suivant les
résultats, sans suivre combien d'histoires complètes ou combien de logiciels créés.

Il existe plusieurs manières de représenter le travail Lean UX dans votre backlog. (Consultez leFigure
16-3.) Vous pouvez le représenter comme une histoire indépendante. (Le Guide Scrum appelle
articles du portefeuille de produits des histoires ou PBI). Ou vous pouvez intégrer le travail dans
l'histoire elle-même, en s'assurant qu'aucune fonction ne soit envoyée sans que cela soit réalisé
j'ai terminé le travail de découverte et de conception.
Figure 16-3. Modèles courants pour gérer le travail de l'UX dans le backlog

Participation multifonctionnelle aux activités d'apprentissage : Lean UX apporte avec lui

muchos tipos de actividades de aprendizaje. Estas actividades pueden ser dirigidas por
des designers ou des chercheurs ou même des chefs de produit, mais elles doivent être pratiquées
et pris en charge par toute l'équipe. Plus l'équipe peut apprendre ensemble, moins
du temps sera consacré à partager et débattre de l'apprentissage et plus de temps pourra être consacré à
décider quoi faire des choses que nous avons apprises. Cette dernière est une conversation et
un usage beaucoup plus productif du temps de l'équipe. Nous ne disons pas que tout le monde
les membres de l'équipe doivent participer à toutes les activités de
recherche. Nous pensons que tout le monde devrait participer jusqu'à un certain point et que la
La participation devrait être une partie régulière de votre activité professionnelle, pas un événement spécial.

Faites de la participation au processus de découverte le chemin le plus court.

résistance. Transmettez les conversations de vos clients en interne afin que d'autres
ils peuvent les voir depuis leurs bureaux. Si un collègue se sent mal à l'aise de parler avec un
client, apportez-le et transformez-le en annotateur. Mesurez ce que Jared Spool appelle "heures
de exposition".3 LasLes heures d'exposition sont une mesure de la quantité de temps que
Chaque membre de votre équipe est directement exposé aux utilisateurs. Assurez-vous que
chaque membre de son équipe passe au moins un bloc de temps de deux heures toutes les six
semaines en contact direct avec les clients. Cela pourrait être deux heures au centre de
appels en attente ou écoute d’appels. Cela peut être deux heures dans le magasin ou dans le
piso de la fábrica observando a los clientes y usuarios. O podría estar realizando ventas
face à face de son produit dans des environnements publics. Ces activités génèrent de l'empathie et cela,
à son tour, stimule la curiosité. Plus toute l'équipe a de curiosité à propos de si
réellement satisfont ou non les besoins du client, plus la probabilité que
les activités de Lean UX se terminent dans son portefeuille de commandes.

Exploiter les rythmes de Scrum pour

construire une pratique Lean UX
Au fil des ans, nous avons trouvé quelques façons utiles d'intégrer des approches Lean
UX avec les rythmes de Scrum. Jetons un œil à la manière dont vous pouvez utiliser la cadence de
réunions de Scrum et Lean UX pour construire un processus efficace.

Une approche que nous avons mise en place ensemble a été de demander aux équipes de cartographier les activités Lean UX
sur un diagramme du cadre Scrum pour les aider à se concentrer sur l'intégration des
pratiques. Nous partageons une tentative typique dans laFigure 16-4 . Nous pensons que c'est un
tentative assez bonne, mais nous vous recommandons de l'essayer avec votre équipe. Pendant ce temps,
vérifiez, rappelez-vous les avertissements suivants :

• Ce n'est en aucun cas une liste complète d'activités de conception. Il n'y a pas
suffisamment de Post-it (numériques ou d'un autre type) dans le monde pour couvrir cela.
• Nous utilisons le mot Design (souvent avec une majuscule) pour qu'il serve comme
terme général pour toutes les activités dans lesquelles des designers de tout type
réalisent ou participent normalement.

Comme pour toutes les recommandations de ce livre, ceci est un point de départ. Le
montre comment superposer les activités existantes sur Scrum. Essaie. Regarde ce que
fonctionne pour vous et votre équipe, puis ajustez-le en fonction de ce que vous décidez pendant vos
rétrospectives.

Figure 16-4. Cartographie des activités de Lean UX au cadre de Scrum

Objectifs de Sprint, Objectifs de Produit et Thèmes de Sprint Multiple

Supposons que votre organisation ait opté pour une approche stratégique pour les
prochains trimestres. Son équipe décide d'utiliser une hypothèse risquée comme première
essai pour atteindre la stratégie. Vous pouvez utiliser cette hypothèse pour créer un thème de sprints
multiples qui guideront le travail que vous effectuerez dans le prochain ensemble de sprints. Scrum appelle
à ces thèmes "Objectifs de produit". (Pensez à un objectif de produit comme un sujet
de multiples sprints qu'il utilise pour connecter une séquence de sprints). Ses mesures de
Le succès de votre sujet se mesure par les résultats, comme le montre la Figure 16-5.

Figure 16-5. Sprints liés à un thème ou un objectif de produit

Commencez le sujet avec un design collaboratif

Commencez à travailler sur chaque sujet en utilisant Lean UX Canvas et peut-être un exercice de
Studio de design.4(VerFigure 16-6) En fonction de l'étendue de l'hypothèse, la session
de design collaboratif peut être aussi courte qu'un après-midi ou aussi longue qu'une
semaine. Vous pouvez les faire avec votre équipe immédiate, mais vous devez inclure un groupe plus large
s'il s'agit d'un effort à plus grande échelle. L'objectif de ce début est de faire en sorte que tout le
équipe dessinez, idéé et parlez avec les clients ensemble, créant une accumulation d'idées à
à partir desquelles tester et apprendre. De plus, cette activité aidera à définir un peu
améliorer la portée de votre sujet, en supposant que vous ayez incorporé quelques boucles de
retroalimentación de los clientes.

Figure 16-6. Le Lean UX Canvas peut capturer votre thème de sprint

Una vez que haya comenzado sus sprints regulares, estará probando y validando sus ideas:
de nouvelles connaissances vont apparaître et vous devrez décider quoi en faire. Vous prenez ces
décisions exécutant des séances subséquentes de remue-méninges plus brèves et des activités
de découverte collaborative à mesure que chaque nouveau sprint commence (Figure 16-
7). Cela permet à l'équipe d'utiliser les informations les plus récentes pour créer le backlog pour
le prochain sprint.
Figure 16-7. Calendrier et portée des sessions de création de croquis et d'idées
Reunión de planificación de Sprint

Apportez votre Lean UX Canvas à la réunion de planification du sprint. Apportez le résultat de

son sprint de design aussi. Son désordre de notes autocollantes, croquis, wireframes, prototypes de
le papier et tout autre artefact peuvent sembler inutiles pour les observateurs externes, mais
sera significatif pour votre équipe. Ils ont fabriqué ces artefacts ensemble, et c'est pourquoi ils ont le
connaissance partagée nécessaire pour extraire des histoires d'eux. Utilisez-les lors de votre réunion
de planification pour rédiger des histoires d'utilisateurs ensemble et ensuite estimer et prioriser les
histoires. (Voir la Figure 16-8.)

Figura 16-8. Realice reuniones de planificación de sprints inmediatamente después de las

sessions de brainstorming
Histoires d'expérimentations

Alors qu'il planifie son itération, il peut y avoir plus de travail de découverte qui doit
se réaliser pendant l'itération qui n'a pas été couverte dans le sprint de conception ou dans les activités
de découverte collaborative. Pour intégrer cela dans sa cadence de sprint et capturer
tout le travail dans le même backlog, utilisez des histoires d'expériences. Capturées à l'aide de
la même méthode que ses histoires d'utilisateur, les histoires d'expériences ont deux
bénéfices distincts :

Visualisent le travail de découverte

Le travail de découverte n'est pas intrinsèquement tangible comme il peut l'être le

travail de livraison. Les histoires expérimentales résolvent cela en nivelant le terrain
de jeu. Tout ce sur quoi son équipe travaille, découverte ou livraison, est inclus
dans la liste des tâches à faire comme une histoire.

Obligent leur priorisation face au travail de livraison :

Une fois que ces histoires sont dans la liste des tâches en attente, vous devez les mettre
en ordre de priorité. Cela oblige à discuter de quand exécuter le
expérience et, ce qui est tout aussi important, sur quoi nous travaillerons pendant
ce même temps.

Les histoires expérimentales ressemblent aux histoires des utilisateurs, comme il est illustré dans
laFigura 16-9.
Figure 16-9. Histoires d'expériences

Les histoires expérimentales contiennent les éléments suivants :

• L'hypothèse que vous êtes en train de tester ou ce que vous essayez d'apprendre.
• Tactiques pour l'apprentissage (par exemple, interviews avec des clients, tests A/
B par prototypes)
• Qui va faire le travail
• Une estimation du niveau d'effort (s'il fait des estimations) du travail à fournir
attendre qu'il soit

Une fois écrites, les histoires d'expériences sont intégrées à sa liste de travaux
pendants. Quand son moment arrive dans le sprint, c'est le principal objectif de la
persona assignée. Lorsque l'expérience sera terminée, apportez les résultats à l'équipe de
immédiatement et en discuter pour déterminer l'impact de ces découvertes. Votre équipe doit
être prêt à changer de cap, même au sein du sprint actuel, si le résultat des
les histoires de l'expérience révèlent des informations qui invalident sa priorisation actuelle.

Conseil professionnel : parfois, nous savons qu'il y aura un travail de découverte par
faire, mais sa forme ou son format exact n'est pas clair au début d'un sprint. Pour
s'assurer que l'équipe ait la bande passante pour ce travail pendant le sprint,
Mettez une histoire d'expérience blanche dans votre backlog. Au fur et à mesure que le travail de
la découverte se révèle pendant le sprint, remplissez-le de détails et établissez les priorités
de manière appropriée. S'il se termine sans être utilisé, cela fait un peu plus d'espace pour respirer que
son équipe a pendant ce sprint. Tout le monde gagne.

Programme de validation des utilisateurs

Enfin, pour s'assurer d'avoir un flux constant de commentaires des clients

pour utiliser dans vos expériences, planifiez des sessions de recherche utilisateur chaque
semaine. (Consultez laFigure 16-10 ). De cette manière, votre équipe ne sera jamais à plus de
cinq jours ouvrables pour recevoir les commentaires des clients et aura suffisamment de temps pour
réagir avant la fin du sprint. Ce rythme de recherche hebdomadaire fournit
un bon rythme pour les histoires de ses expériences et un point d'apprentissage naturel dans
le sprint.

Utilisez les artefacts que vous avez créés lors des sessions d'idéation comme base pour vos
tests utilisateurs. N'oubliez pas que lorsque les idées sont brutes, vous testez leur valeur. (C'est
Dire, est-ce que les gens veulent utiliser mon produit à la place d'utiliser mon produit ? Une fois que
ils ont établi qu'il existe un désir pour leur produit, les tests ultérieurs avec
Des artefacts de plus haute fidélité révéleront si votre solution est utilisable.

Figure 16-10. Les conversations avec les utilisateurs ont lieu à chaque sprint
Les designers doivent participer à la planification

Les méthodes agiles peuvent créer beaucoup de pression temporelle sur les concepteurs. Certains
Les travaux s'intègrent facilement dans le contexte d'une histoire utilisateur. Un autre travail nécessite
plus de temps pour bien le faire. Les cycles de développement et de conception de deux semaines
simultanés offrent peu d'opportunités pour que les concepteurs réfléchissent sur
grands problèmes. Et bien que certaines méthodes agiles adoptent une approche plus flexible
de la notion d'un lot de travail de Scrum (par exemple, Kanban élimine le temps que
deux semaines et met l'accent sur le flux continu), la plupart des concepteurs ressentent
la pression de s'adapter à son travail. dans le cadre temporel du sprint. Pour cette raison, les
les designers doivent participer au processus de planification du sprint.

La principale raison pour laquelle les concepteurs ressentent une pression dans les processus agiles est que
ne participent pas (pour quelque raison que ce soit) pleinement au processus. En général, cela n'est pas
sa faute : lorsque l'Agile est compris simplement comme une façon de créer des logiciels, non
il semble n'y avoir aucune raison d'inclure des personnes qui ne sont pas technologiques dans le
processus. Cependant, sans la participation du designer, ses préoccupations et
les besoins ne sont pas pris en compte dans les plans du projet. En conséquence, beaucoup
Les équipes agiles ne font pas de plans qui permettent aux concepteurs de faire leur meilleur travail.

Pour que Lean UX fonctionne, toute l'équipe doit participer à toutes les activités (stand-
ups, rétrospectives, réunions de planification, sessions de remue-méninges), comme règle
normal, toutes nécessitent la participation de tous pour réussir. En plus de négocier la
complexité de certaines caractéristiques, la participation multifonctionnelle permet aux
designers et développeurs créer une priorisation efficace de l'accumulation.

Par exemple, imagine au début d'un sprint que la première histoire que l'on priorise un
l'équipe a un composant de conception lourd. Imaginez que le designer ne soit pas là.
là pour exprimer son inquiétude. Cette équipe échouera dès qu'ils se réuniront pour leur
stand-up le lendemain. Le designer dira que l'histoire n'a pas été conçue. Le
le designer dira qu'il faudra au moins deux ou trois jours pour compléter le design avant que le
l'histoire est prête pour son développement. Imaginez, en revanche, que le designer ait...
a participé à la priorisation du portefeuille de commandes. Sa préoccupation se serait
planteado en el momento de la planificación. El equipo podría haber seleccionado una
carte d'histoire qui nécessiterait moins de préparation de design pour travailler en premier, le
que lui aurait donné le temps dont il avait besoin pour terminer le travail.

L'autre victime de la faible participation se partage la compréhension. Les équipes prennent

décisions lors des réunions. Ces décisions sont basées sur des discussions. Même si 90 % de
une réunion n'est pas pertinente pour votre besoin immédiat, les 10% qui sont pertinents vous
cela vous fera économiser des heures de temps par la suite. La participation vous donne la possibilité de négocier le
le temps nécessaire pour faire son travail. Cela est vrai pour les designers UX
comme pour tous les autres membres de l'équipe.

Parties prenantes et panel de risques

Les contrôles de gestion sont l'un des plus grands obstacles à le maintien de l'élan.
équipe. Les designers sont habitués à faire des révisions de design, mais
malheureusement, les enregistrements ne s'arrêtent pas là. Les propriétaires de produits, les
les parties prenantes, les directeurs exécutifs et les clients veulent savoir comment se déroulent les
choses. Tout le monde veut bénir le plan du projet à l'avenir. Le défi pour les
les équipes axées sur les résultats sont que les plans de leurs projets dépendent de ce que
Ils sont en train d'apprendre. Ils sont réceptifs, donc leur plan typique ne prévoit que de petits lots.
de travail à la fois. Au maximum, ces équipes prévoient une ou deux itérations par
adelantado. Cette perception de "myopie" tend à ne pas satisfaire la majorité des
gestionnaires de haut niveau, ce qui peut conduire à la microgestion. Alors, comment maintenez-vous
les enregistrements sous contrôle tout en maintenant le rythme de vos processus Lean UX et Scrum ?

Deux mots : communication proactive.

Jeff a une fois dirigé une équipe qui a radicalement modifié le flux de travail d'un produit
existant qui avait des milliers de clients payants. L'équipe était si enthousiaste à propos des
changements qu'ils avaient réalisés et qui ont continué avec le lancement sans alerter personne
plus dans l'organisation. Une heure après le lancement du nouveau produit, le
la vice-présidente du service client était au bureau de Jeff, furieuse et exigeant
savoir pourquoi il n'a pas été informé de ce changement. Le problème était le suivant : quand les
les clients ont des problèmes avec le produit, ils demandent de l'aide. Les représentants du centre de
Les appels utilisent des scripts pour résoudre les problèmes des clients et
offrir des solutions, sauf qu'ils n'avaient pas un script pour ce nouveau
produit. Parce qu'ils ne savaient pas que cela allait changer.

Cette tranche saine de humble gâteau a servi de précieuse leçon. Si vous souhaitez que
ses parties prenantes, tant celles qui l'administrent que celles qui dépendent de vous, se
restez en dehors de leur chemin, assurez-vous qu'ils soient au courant de vos plans et de votre
progrès. Pendant que je travaillais en collaboration dans notre agence Neo, à notre collègue Nicole
Rufuku a eu l'idée d'un outil remarquablement simple et puissant pour faire
précisément ceci : le Panneau des Risques (Figure 16-11).
Figure 16-11. Le panneau des risques

Le Panel des risques n'est rien d'autre qu'un graphique à trois colonnes que vous pouvez créer dans
PowerPoint, Excel ou Google Docs.

• La première colonne énumère les principaux risques en cours associés à votre

initiative actuelle. Ce sont des choses qui sont fondamentales pour le succès
du produit.
• La colonne du milieu a une échelle de la gravité de ce risque et une
visualisation codée par couleurs de la tendance de ce risque. Est-ce que c'est quelque chose que
pourrait nécessiter une petite correction ? Ou est-ce essentiel au succès de
produit ? Notre travail de découverte nous dit que cela devient de plus en plus
possible ou pas si mauvais que nous le pensions ?
• La troisième colonne indique ce que nous faisons par rapport à ce risque.

Ce tableau est un document vivant utilisé pour communiquer avec ses parties prenantes
et clients sur l'état de leur projet. Utilisez ce tableau lors de vos réunions de
planification avec votre équipe. Utilisez-le dans vos démonstrations de sprint avec vos parties
intéressées à l'aider à prendre des décisions importantes. Ce faisant, il informe
ses parties prenantes sur :

• Comment avance le travail

• Ce que vous avez appris jusqu'à présent
• Sur quel risque te concentreras-tu ensuite ?
• Résultats (la tendance qu'il a vers son objectif), pas d'ensembles de
caractéristiques
• Départements dépendants (service client, marketing, opérations, etc.) et
leur besoin d'être au courant des prochains changements qui peuvent les affecter.
Souvent, il y aura un risque sur le plateau où la troisième colonne est vide. Ensuite, une
la partie intéressée demandera pourquoi nous ne faisons rien à ce sujet. Parfois, cela
c'est simplement une question de priorisation. Mais parfois, il se peut que cela se bloque.
progrès. Par conséquent, une question des parties prenantes vous offre l'opportunité
parfaite pour relever tout défi que je pourrais rencontrer en faisant le travail de
découverte, le prioriser ou obtenir un budget ou une approbation pour le faire. Avec le
Le panel des risques contextualise de manière efficace la découverte avec impact
commercial. L'impact commercial a tendance à résonner puissamment avec les parties
intéressées, ce qui en fait un outil efficace pour promouvoir un meilleur
intégration de votre travail Lean UX avec votre processus de livraison Agile.

Mapas de ruta basados en resultados

L'un des plus grands défis dans Agile est de planifier le travail de manière linéaire et
visuel. Bien sûr, nous avons eu des "feuilles de route" depuis longtemps, mais elles ne font pas un
très bon travail pour représenter la véritable nature du développement de logiciels. Le
Le développement de produits numériques n'est pas linéaire. C'est itératif. Nous construisons quelques
choses. Nous les envoyons. Nous voyons comment cela affecte le comportement du client. Nous les itérons.
et nous renvoyons à nouveau.

Le modèle de carte routière linéaire traditionnel, un dans lequel il y a un point de départ et un.
point final clair et spécifique de la fonction (presque toujours avec une date fixe), est
désactualisé. Il reflète un mode de fonctionnement d'une entreprise numérique centrée sur la
production. En revanche, comme nous l'avons discuté tout au long de ce livre, les organisations
Les initiatives réussies axées sur les produits se concentrent sur les résultats. Alors, comment
nous construisons des feuilles de route de produits dans un monde d'amélioration continue, d'apprentissage et
agilité ? Et comment ce type de visualisation peut-il garantir que Lean UX soit mis en œuvre ?
cabo dans notre processus Agile ? Nous utilisons des feuilles de route basées sur des résultats.

Voici à quoi devrait ressembler une feuille de route de produits agiles (Figure 16-12).
Figure 16-12. Une feuille de route des produits agiles

Vous remarquerez certains composants clés dans ce diagramme :

Thèmes stratégiques

Ce sont les stratégies de produits organisationnels établies par des leaders

les exécutifs qui orientent les équipes dans une direction spécifique. Celles-ci peuvent être
des choses comme « Élargir notre part de marché en Europe » ou
Profiter du temps sous-utilisé que notre flotte ne transporte pas de passagers
pour livrer d'autres biens et aliments". Il peut y avoir plusieurs sujets en cours d'exécution
en parallèle pour une organisation plus grande.

Objectifs trimestriels OKR

OKR, quand bien fait, utilise le comportement du client comme métrique dans
la partie "résultats clés" de l'équation. Ces objectifs de résultats
trimestriales sont où chaque équipe se concentrera sur un effort pour aider à réaliser
le thème stratégique. C'est l'objectif que les équipes s'efforcent d'atteindre. C'est
sa définition du succès et sa définition réelle en fait. Les équipes doivent travailler
avec le leadership pour garantir qu'ils soient alignés et nivelés
correctement.

Hypothèse de caractéristiques / produits

Voici les meilleures conjectures de chaque équipe sur la façon dont elles atteindront les
objectifs OKR de ce trimestre. En regardant un trimestre à l'avance, un
l'équipe peut faire des conjectures solides et bien informées sur quels produits ou
idées de caractéristiques qu'ils pensent atteindre leurs objectifs trimestriels. En regardant deux
trimestres à venir, ces conjectures deviennent moins sûres, donc les
les équipes feront moins de conjectures et moins d'engagements. En regardant trois et quatre
trimestres, les équipes n'ont vraiment pas d'idée sur ce qu'elles vont travailler, par
ce que ces conjectures sont de moins en moins. C'est exactement comme cela devrait être
ser. Les équipes apprendront au cours du prochain trimestre ou deux à quel point
ses idées ont fonctionné, ce qui fait avancer les aiguilles et ce qui devrait l'être
ses prochaines conjectures. Les cases pour Q3 et Q4 se rempliront au fur et à mesure que le
l'apprentissage de Q1 et Q2 se synthétise et se met en œuvre en conséquence.

Visualiser le travail de cette manière met immédiatement en évidence l'incertitude du développement

du logiciel au centre de la conversation. Lorsque les parties prenantes
Ils demandent : « Comment déterminerons-nous si ce sont les bonnes hypothèses à travailler maintenant ? »
et dans le futur ?" la réponse est Lean UX. Votre équipe travaillera pour incorporer le
apprentissage à chaque sprint pour s'assurer que vous travaillez toujours vers le sujet
stratégique et ne perdez pas de temps dans des initiatives qui ne vous rapprochent pas. Combinez cela avec les
les cadences agiles décrites précédemment et aura une recette puissante pour offrir
expériences précieuses à ses clients.
Fréquence de révision

Chaque équipe doit présenter ce type de carte de chemin basée sur les résultats pour son
révision au début d'un cycle annuel. Elle doit s'aligner sur les objectifs stratégiques que
le leadership a établi et s'est assuré que ses OKR utilisent des métriques qui permettent
atteindre ces objectifs.

Bien qu'il soit de la responsabilité de l'équipe d'exposer continuellement ce qu'elle fait,

apprenant et décidant, les contrôles officiels doivent être effectués trimestriellement. Les
les équipes se réunissent avec les dirigeants pour déterminer à quel point elles se sont orientées vers leurs
objectifs de résultats, ce qu'ils ont appris au cours du dernier trimestre et ce qu'ils prévoient
faire au cours du prochain trimestre. C'est une occasion parfaite de réaffirmer la pertinence
des objectifs de l'équipe pour l'avenir et d'apporter des ajustements basés sur de nouveaux apprentissages,
conditions du marché ou tout autre facteur qui aurait pu affecter la direction de
l'entreprise.

Medir el progreso

Il devrait être clair à ce stade que le progrès dans ce type de carte de chemin n'est pas mesuré
en la quantité de fonctions qui ont été livrées ou si elles ont été livrées à temps. En
le changement, le progrès se mesure en termes de combien nous avons amélioré le
comportement du client. Si nos idées n'ont pas propulsé le succès du client, nous tuons
ces idées et passons à d'autres nouvelles. L'apprentissage stimule des idées pour l'avenir
accumulations trimestrielles. Cela stimule également notre agilité en tant qu'équipe et
en tant qu'entreprise.

Estos mapas de carreteras son documentos vivos. No los arreglamos al comienzo de un

cycle annuel et nous les laissons comme s'ils étaient gravés dans la pierre. Il y a trop de
incertitude et complexité dans la livraison de produits et services numériques. Les
organisations axées sur les produits, celles qui se concentrent sur le succès du client avec
des équipes autonomisées travaillent pour s'assurer qu'elles pointent toujours dans la bonne direction
correcte. Cela signifie ajuster les cartes routières à mesure que la réalité change
sur le terrain. Les feuilles de route basées sur les résultats garantissent que les dirigeants et les
les équipes doivent être transparentes entre elles, réalistes sur leurs objectifs et, ce qui est le plus important
important, réalistes sur la façon dont ils mesurent le succès.

Lean UX et Agile dans l'entreprise

Beaucoup des tactiques couvertes dans ce livre se concentrent sur une équipe. Mais dans le monde
réel, les grandes organisations ont plusieurs équipes de développement de produits qui
travaillent en parallèle. Comment Lean UX se développe-t-il lorsque le nombre d'équipes augmente à
dizaines ou même des centaines de flux de travail simultanés ?

Ceci est une version de la question d'escalade, qui est en elle-même une question en
curso en la comunidad Agile. Dado que los métodos Lean y Agile se han convertido en
les formes de travail prédéfinies, beaucoup de personnes se sont concentrées sur cela
cuestión. Las grandes organizaciones tienen una necesidad legítima de coordinar la
activité de plusieurs équipes, et les processus qui adoptent l'incertitude et adoptent
l'apprentissage de son chemin à suivre représente un défi pour la plupart des
méthodes traditionnelles de gestion de projets.

Parlons de l'éléphant dans la pièce : le Scaled Agile Framework ou SAFe. Au moment de

écrire cet article, SAFe existe depuis 10 ans et, pour de nombreuses organisations
grandes, c'est la première option pour mettre en œuvre une approche d'agilité pour l'ensemble de
organisation. Si vous n'êtes pas familier avec cela, SAFe est un ensemble complet, détaillé et
hiérarchique de processus, diagrammes et vocabulaire qui sont conçus pour augmenter le
agilité des grandes organisations. Fonctionne de haut en bas pour diviser et
déléguer le travail à des "trains de lancement agiles" qui suivent un calendrier de lancement
rigide. Malheureusement, ces processus manquent en grande partie de commentaires ou
apprentissage des utilisateurs.

Il est possible que vous ayez été aussi surpris que nous d'apprendre que la version 4.5 de
marco SAFe incluait Lean UX. En raison de cela, nous avons reçu de nombreuses questions sur comment
faire Lean UX dans une entreprise qui a mis en œuvre SAFe. La réponse courte est la suivante :
tu ne peux pas. SAFe est conçu pour la production, pas pour la découverte. C'est
optimisé pour garantir un flux continu de résultats et minimiser les exigences de
changement des dirigeants. Cela crée une rigidité dans le processus de développement de logiciels
que donne comme résultat quelque chose qui ne peut, en aucun cas, être décrit comme agile.

SAFEN'ESTPASAGILE

Depuis le Scaled Agile Framework (SAFe pour abréger) a adopté Lean UX dans la version
4.5, nous avons reçu un flux constant de questions entrantes sur comment, exactement,
Il est censé que ces deux méthodes fonctionnent bien ensemble.

La réponse courte est que nous n'en avons aucune idée.

La réponse un peu plus longue est que tous les principes que nous avons incorporés dans
Lean UX ne semble pas exister dans SAFe.

L'apprentissage et l'amélioration continue, l'accent sur le client, l'humilité, la collaboration

interfonctionnel, la prise de décision basée sur des preuves, l'expérimentation, le design
et la correction du cours, pour en nommer quelques-uns, sont visiblement absents dans le
conversación de SAFe. En cambio, las organizaciones que adoptan esta forma de trabajo
se centrent sur des structures d'équipe rigides, des rituels et des événements stricts et une distribution
différent des exigences de changement de comportement selon à quel point il est élevé
s'asseoir un dans l'organisation.

En résumé, SAFe n'est pas agile.

Étant donné l'intense régime d'entraînement que les équipes doivent traverser pour obtenir
la "certification SAFe", il n'est pas surprenant qu'ils résistent au changement. Ils ont été formés
pour travailler d'une manière très spécifique, une manière axée uniquement sur la
livraison prévisible, pas dans l'apprentissage, pas dans la correction du cours et, certainement, pas
dans l'agilité. Les activités qui rendent les équipes véritablement agiles
exigent une flexibilité dans la planification. Exigent un alignement avec le succès du client,
pas un ensemble prédéterminé de caractéristiques. Ils nécessitent un processus de
découverte continue qui conduit inévitablement à des corrections de cap non
planifiées. Ces corrections "dérailleraient" un train de libération en peu de temps.

Les grandes organisations qui recherchent l'agilité réalisent l'incertitude que la

accompagne et s'accroche à la familiarité des processus en cascade. SAFe donne l'illusion de
"adopter de manière agile" tout en permettant aux processus de gestion familiale de rester
intacts. Dans un monde de changements rapides et continus, les modèles de consommation des
consommateurs en évolution, instabilité géopolitique et avancées technologiques
exponentiels, cette façon de travailler est insoutenable.

Si vous travaillez dans une grande organisation qui a adopté ou est en train de mettre en œuvre
SAFe, demandez-vous ce qui a changé pendant cette transition. Êtes-vous plus proche de vos
clients? Combien de temps faut-il pour savoir s'ils ont livré quelque chose de valeur ? Encore mieux,
Comment mesurez-vous la « valeur » ? Demandez-vous à quel point il serait facile de pivoter une initiative basée
dans une nouvelle découverte. Ensuite, comparez ces réponses avec la façon dont les choses étaient
avant de commencer à utiliser des termes comme "planification de salles grandes", "PI" et
ingénieur de trains de lancement

Élever toute forme de travail dans une grande organisation est compliqué et
desigual. Tenter d'appliquer un processus général à toute l'entreprise, un processus qui se concentre
strictement dans la livraison au lieu de la découverte continue et de la correction de
rumbo, seul endure les formes traditionnelles de travail. SAFe est convaincant parce que
semble offrir une recette unique pour l'agilité à grande échelle. En réalité, elle récompense la
prévisibilité, conformité et respect, tout en offrant aux dirigeants
une couverture pour la question "Comment devenons-nous plus agiles ?"

Une discussion complète sur comment créer une organisation véritablement agile et
ajustée est au-delà de la portée de ce lifrère.5Y, sincèrement, c'est un problème difficile
avec peu de réponses faciles. Cela nécessite un leadership pour repenser radicalement la façon dont
qui établit la stratégie, forme des équipes et planifie et assigne le travail. En essence, les
les organisations doivent réduire la quantité d'échafaudages qu'elles mettent en œuvre et permettre que
les équipes trouvent organiquement des manières d'utiliser les valeurs, les principes et les méthodes
basiques d'Agile pour les petites équipes pour établir une cadence de travail productive
et puis les adapter spécifiquement à l'organisation. aborder par petites étapes.

Dicho esto, existen algunas técnicas que pueden ayudar a Lean UX a escalar en entornos
entreprises agiles et même tirer parti de cette échelle. Nous présentons ci-après
certains problèmes qui ont tendance à surgir et des moyens de les résoudre.

Problème : les projets croissent, on leur attribue plus d'équipes. Comment s'assure-t-on que
tous les équipes soient alignées sur la même vision et n'optimisent pas localement ?

Approche de solution : le concept de gestion axée sur les résultats s'applique à un ensemble
d'équipes comme des individus. Pour s'assurer que toutes les équipes qui travaillent
dans le même projet, ayez une vision partagée, attribuez-leur la même métrique de succès,
expresada como resultado. Trabajando juntos, pueden definir los indicadores principales
que impulsent cette métrique et diviser ces métriques principales entre les équipes du
projet. Mais il ne faut pas permettre aux équipes de se concentrer sur les métriques principales
excluant le résultat le plus large : l'ensemble de l'équipe réussit seulement si
ils atteignent le résultat général ensemble.
Travailler ensemble de cette manière réduit le risque d'optimisation locale sans prendre en compte
les impacts ultérieurs de cette optimisation. Par exemple, si l'équipe de marketing est
travaillant pour atteindre ses objectifs de résultats d'acquisition, mais surutilise le
un courriel pour atteindre cet objectif peut nuire à l'objectif de rétention de
équipe produit. Si les deux équipes avaient les mêmes objectifs de résultats, un
combinación de adquisición y retención, trabajarían juntos para aprender a equilibrar sus
efforts et produits pour réussir.

Problème : Comment s'assurer que les équipes partagent ce qu'elles apprennent et

minimisez l'effort doublé pour apprendre les mêmes choses ?

Approche de la solution : bien qu'il n'existe pas de solution miracle pour résoudre ce problème.
problème, les pratiques réussies que nous avons observées incluent un outil central de
gestion des connaissances (comme un wiki), réunions périodiques de leadership d'équipe
(comme un Scrum de Scrums) et des outils de communication ouverts. qui se concentrent sur
la recherche (comme un canal dédié dans Slack ou votre outil de chat interne). Les
éléments de la culture d'étude, comme les sessions régulières de critique entre équipes,
ils peuvent aussi aider.

Problème : les dépendances entre les équipes peuvent ralentir les progrès.
lent. Comment maintenir un rythme régulier d'apprentissage et d'exécution dans un environnement de
équipements multiples ?

Enfoque de solución:cree equipos "full-stack" autosuficientes. Los equipos de pila

les membres de l'équipe disposent de toutes les compétences nécessaires pour faire leur travail. Cela
Cela ne signifie pas qu'ils ont besoin d'une personne de chaque département, juste qu'il y a quelqu'un dans le
équipe qui peut faire une ou plusieurs des choses que l'équipe pourrait avoir besoin. Les
disciplines spécifiques de l'équipe (designers, personnes de contenu, développeurs de
frontend, développeurs backend, chefs de produit) se coordonnent entre eux sur
réunions de disciplines spécifiques pour garantir qu'ils soient à jour dans leur pratique, mais
le travail s'effectue localement.

Terminant
Ce chapitre a analysé en détail comment Lean UX s'adapte à un processus
agile. De plus, nous analysons comment la collaboration multifonctionnelle permet à une équipe
avance à un rythme rapide et comment gérer les parties prenantes et les gestionnaires qui toujours
Ils veulent savoir ce qui se passe. Nous discutons de pourquoi il est fondamental que tout le monde
participez à toutes les activités et comment le modèle de sprint échelonné, une fois
considéré comme le chemin vers la véritable agilité, il a formé les racines de l'Agile à double sens,
que maintenant est le nouveau modèle cible pour la majorité des équipes. Nous couvrons également,
en détail, comment les artefacts et événements de scrum fonctionnent en votre faveur pour augmenter votre
vitesse d'apprentissage.

1“Manifeste pour le développement de logiciels agiles

2021[Link] .
2Desirée Sy, « Adaptation des recherches en matière d'ergonomie pour un design agile »
centré sur l'utilisateur”, Revue d'études d'usabilité 2, no. 3 (Mai 2007): 112-
132[Link] .

3OuiM. Spool, "Chemin rapide vers une grande expérience utilisateur - Augmentation des heures d'exposition", Center Center
UIE, 30 mars 2011[Link] .

4JeJe pourrais même utiliser un « sprint de design » à la manière de Google ici, un nom déroutant
Dans ce contexte. Dans ce cas, nous ne plaidons pas pour passer tout un sprint à faire
design. À la place, nous prônons le processus appelé "sprint de design", qui
nous décrivons dans le Chapitre 14.

5Ilj'aiécrit une description générale de haut niveau sur ce sujet dans notre
libroSense & Répondre (Harvard Affaires Révision Presse,
2017). (Voir[Link] .)
Partie IV. Lean UX dans votre organisation

Acerca de la Parte IV
Intégrer le design dans Agile n'est jamais facile. Cela cause parfois beaucoup de douleur et d'angoisse. Jeff
il a appris cela de première main lorsqu'il était chez TheLadders. Après avoir passé un certain
temps à essayer d'intégrer le travail de l'UX avec un processus agile, Jeff se sentait assez
bien, jusqu'à ce qu'un matin son équipe UX remette le schéma ci-dessous (Figure
IV-1). Ce diagramme a visualisé tous les défis auxquels l'équipe était confrontée pendant
ils essayaient d'intégrer leur pratique dans Agile. Au départ, cela a servi comme une grande tranche de
humble pastel. Cependant, en fin de compte, il a fourni le début de
conversations qui ont aidé Jeff, son équipe UX et le reste du personnel de
développement de produits de TheLadders pour construire une pratique intégrée et collaborative.
Graphique IV-1. L'équipe UX de TheLadders a exprimé ses sentiments sur nos efforts
d'intégration Agile / UX

Au cours des années écoulées depuis la création de ce diagramme, nous avons eu la chance de
travailler avec de nombreuses entreprises dans ce défi. Nous avons travaillé avec des entreprises qui
ils englobent un large éventail d'industries, de tailles d'entreprises et de cultures. Nous avons aidé
aux organisations médiatiques de découvrir de nouvelles façons de livrer et de monétiser leur
contenu. Nous avons créé de nouveaux outils de vente pour les appareils mobiles pour un
fabricant de meubles commerciaux. Nous avons consulté des détaillants de mode, des entreprises
de services automobiles et de grandes banques pour les aider à développer des pratiques Lean
UX. Nous avons travaillé avec des organisations à but non lucratif pour créer de nouvelles offres de
servicios. Y hemos entrenado a innumerables equipos.

Chacun de ces projets nous a donné un peu plus d'informations sur le fonctionnement.
Lean UX dans cet environnement. Nous utilisons ces informations pour faire en sorte que chaque projet ultérieur
beaucoup plus réussi. Nous avons accumulé un ensemble de connaissances au cours des
les cinq dernières années qui nous ont donné une idée claire de ce qui doit se passer, au niveau de
équipe et d'organisation, pour que Lean UX ait du succès. C'est l'approche de la Section
IV.

Dans leChapitre 17, Réalisation de changements organisationnels , nous approfondirons les

changements organisationnels spécifiques qui doivent être réalisés pour soutenir cette forme de
travail. Ce ne sont pas seulement les développeurs et les designers de logiciels qui ont besoin
trouver un moyen de travailler ensemble. Tout son moteur de développement de produits aura
que changer si vous souhaitez créer une organisation véritablement agile.

Dans leCapítulo 18, Lean UX dans une agence , nous discuterons des problèmes qui sont
exclusifs à la mise en œuvre de Lean UX dans le contexte d'une agence. Ayant
vivant ce défi nous-mêmes et travaillant pour former un nombre quelconque de
entreprises de conception et de développement de produits, nous avons compris certains de
les défis ici. Nous partagerons quelques-unes des choses clés que vous devrez considérer pour
que Lean UX ait du succès dans ce type d'entreprise.
Chapitre 17. Réalisation de changements
organisationnels
En baseball, tu ne sais rien.

Yogi Berra

Dans laPartie Ide ce livre, nous avons discuté des principes derrière Lean UX. Nous espérons que
Comprenez que Lean UX est une façon de penser. Dans lePartie II ,
nous avons discuté de certaines des méthodes clés de Lean UX, car Lean UX est aussi un
processus. Au fur et à mesure que nous travaillons avec des clients et enseignons ces méthodes aux équipes,
il est clair que Lean UX est également une méthode opérationnelle et de gestion. Pour cette raison,
vous devrez apporter quelques changements à votre organisation pour obtenir le maximum de bénéfice de
travailler de cette manière.

Les changements organisationnels ne sont pas faciles, mais ils ne sont pas optionnels. Le monde a
changé : nos organisations doivent changer avec lui. Toute entreprise de grande envergure (ou
tout business qui cherche à se développer) est, que cela nous plaise ou non, dans le domaine du
logiciel. Indépendamment de l'industrie dans laquelle votre entreprise opère, le logiciel se
est devenu quelque chose de fondamental pour offrir votre produit ou service.

C'est à la fois habilitant et menaçant. La capacité d'atteindre les marchés

mondiales, évoluer les opérations pour satisfaire la demande croissante et créer une
La conversation continue avec vos clients n'a jamais été aussi facile. Ce pouvoir est aussi un
arme à double tranchant : offre les mêmes opportunités aux concurrents plus petits que
n'auraient jamais pu concurrencer avant l'adoption généralisée du logiciel. Cela fait que
la nécessité d'adopter Lean UX est encore plus urgente.

De nombreuses organisations sont arrivées à cette conclusion et, en réponse, ont essayé
améliorer leurs équipes de développement de produits. Pendant ce temps, beaucoup ont
utilisé les rythmes centraux des techniques de développement de logiciels agiles pour
opérationnaliser le développement de produits logiciels. Malheureusement, beaucoup de
ces approches ne sont agiles que de nom. Elles n'adoptent pas les valeurs clés de l'Agile, qui
incluent la collaboration, la transparence et l'apprentissage continu. Ces approches
les opérations maximisent la vitesse de livraison, mais obligent les équipes de logiciels,
y compris les concepteurs de ces équipes, à entrer en mode de production. Comme
résultat, une grande partie de la valeur du design est perdue.

Lean UX est une manière de rompre avec le design en tant que production et de réaliser la valeur
total du design en équipes multifonctionnelles. Cela vous permet d'utiliser la puissance du logiciel
pour créer un cycle d'amélioration continue qui permettra à votre entreprise de rester en avance
de ses concurrents. C'est ce circuit qui propulse l'agilité organisationnelle réelle et permet
que su empresa reaccione a los cambios en el mercado a velocidades nunca antes posibles.

DESIGNOPSETLEANUX

Étant donné que les grandes organisations ont adopté la conception dans le contexte opérationnel des
équipes de développement de produits, nous avons vu l'émergence d'un mouvement
appelé DesignOps. DesignOps a pour objectif simplement l'opérationalisation
du design à l'échelle. C'est une façon de penser et de gérer les opérations de design à l'intérieur
des grandes organisations. Cela signifie que l'équipe DesignOps de votre organisation
doit devenir un acteur clé dans tout effort pour adopter le Lean UX.

Une note importante ici : DesignOps peut être une force pour adopter de nouvelles formes
de travailler, mais cela peut aussi être une force pour adopter des formes de travail
héritées. Beaucoup des formes traditionnelles de travail que a développées la
La communauté du design est merveilleuse, elle est pleine de sagesse et doit être
respectées. Mais certaines façons de travailler sont très spécifiques au travail de design que
nous avons fait avec des technologies et des modèles commerciaux plus anciens. BDUF (Big Design Up
Front) et le travail basé sur les livrables ne sont que deux exemples de méthodes de conception
traditionnels qui ne servent plus les meilleurs intérêts des designers qui cherchent le
maximum impact sur les équipes agiles. Tout en travaillant à forger un mouvement
dirigé par DesignOps dans votre organisation, faites attention aux solutions « les
les designers l'ont toujours fait de cette manière
de l'Agile et du Lean UX.

Les tournées
Lorsque nous formons les équipes, ils demandent parfois : "Comment pouvons-nous intégrer dans
pratiquez-vous ces méthodes ici ?" Et à ce stade, nous doutons toujours un peu. Bien que
nous sommes convaincus que la majorité des organisations peuvent résoudre ces
problèmes, nous sommes également conscients que chaque organisation est différente. Trouver
la solution adéquate nécessite beaucoup de travail rapproché et de collaboration avec ses collègues et
dirigeants.

Pour le préparer à ce travail, nous utiliserons ce chapitre pour partager quelques-uns des
changements que les organisations doivent effectuer pour adopter Lean UX. Ne le
nous allons dire comment faire ces changements ; C'est ton travail. Mais nous espérons que cette discussion
Je l'ai aidé à étudier le panorama afin de trouver les domaines qu'il souhaitera aborder.

Changement de culture

Al implementar Lean UX, considere estas dimensiones de la cultura:

• Sois humble.
• Adoptez de nouvelles compétences.
• Créez des espaces de travail ouverts et collaboratifs.
• Sans héros.
• Tombe amoureux du problème, pas de la solution.
• Développer la culture de l'agence.
• Soyez réaliste sur votre environnement.

Organisation changeante de l'équipe

Pour mettre en œuvre Lean UX, vous devrez également repenser la façon dont vous organisez les
equipos:
 • Pensez aux compétences concernant les rôles.
• Créez des équipes multifonctionnelles.
• Créez de petites équipes.
• Travaille avec des équipes distribuées.
• Génère de la flexibilité dans les relations avec les fournisseurs externes.

Processus de changement

Enfin, leurs processus de développement de produits changeront également :

• Planifiez le travail en utilisant des résultats, pas des produits.

• Faites attention aux BDUF qui s'infiltrent dans des environnements agiles.
• Adopte d'abord la vitesse, ensuite l'esthétique
• Aborde la dette de l'UX.
• Repensé les pratiques de documentation.
• Gestion vers le haut et vers l'extérieur.

Tour : Soyez humble

Imagine un instant que vous travaillez sur une ligne de montage. qui fabrique des voitures. L'état
la fin de votre produit est bien défini à l'avance. Le coût de production de ce produit est
Bien sûr. Le processus pour le créer a été optimisé et les manières dont les clients utiliseront cela
automobile, basées sur plus de cent ans d'observation, sont également claires. Dans
dans des situations comme celle-ci, l'attention se concentre sur la qualité, l'efficacité et le contrôle de
coûts.

Nous ne construisons pas de voitures.

Notre domaine est le logiciel et nos produits et services sont complexes et

imprévisibles. Ils n'ont pas d'état final. Nous pouvons continuer à concevoir, à construire,
opérant et optimisant nos produits numériques chaque fois que cela a du sens
économique à faire. Ce qui est le plus déconcertant, c'est que nos clients peuvent utiliser nos
services numériques de manières que nous n'avons jamais imaginées. Dans de nombreux cas, les meilleurs
les caractéristiques d'un système apparaissent avec le temps à mesure que les gens le
utilisent. (Le hashtag de Twitter est un excellent exemple de cela : les utilisateurs ont inventé cela
fonction, et ensuite Twitter a ajouté le support pour cela après coup). Avec tant de
incertitudes, il y a une quantité limitée de confiance que nous pouvons avoir dans l'étendue, la
feuille de route, la mise en œuvre, et le succès de notre produit. La bonne nouvelle est que
merci à l'essor des mouvements Agile et DevOps, nous pouvons nous éloigner des méthodes
de ligne de montage des générations passées et adopter des méthodes de production
Nous continuons. Lorsque nous combinons cette capacité avec Lean UX, nous obtenons la capacité de
apprendre très rapidement à quel point nos idées sont valides ou invalides.

Pour tirer le meilleur parti de ces nouvelles capacités, votre organisation doit adopter la
humilité. Son organisation doit accepter que, face à toute cette complexité et
incertitude, nous ne pouvons tout simplement pas prédire la forme exacte de notre service
vous devrez prendre pour réussir. Ce n'est pas une abdication de la vision.

En revanche, elle nécessite un avis ferme sur la forme que doit prendre le système, avec
avec la volonté de changer de cap si les preuves du marché révèlent que la vision
l'initial était incorrect. Adopter cette mentalité rend les équipes plus sûres
expérimenter, échouer et apprendre. C'est seulement à travers ce processus d'essai et d'erreur que
Lean UX peut prospérer. Si l'organisation ne laisse pas de place pour la correction de cap,
l'apprentissage continu promu par Lean UX sera, au mieux, comme
une distraction et, dans le pire des cas, comme une perte de temps.

Changement : Adoptez de nouvelles compétences

De nombreuses entreprises font appel à des designers pour obtenir les méthodes les plus tactiques
et capacités traditionnelles : wireframing, spécification, design d'UI, etc. Limitent sa
participation à un projet à la « phase de conception » de tout processus que l'entreprise
connecte aux designers à ces flux de travail existants limite leur
efficacité à limiter la portée de son travail, ce qui a l'effet secondaire de renforcer un
modèle d'équipement isolé.

Le succès d'une équipe collaborative exige plus. Bien que les équipes aient encore besoin
habilités de base en UX, les designers doivent ajouter la facilitation comme l'un de leurs
compétences de base. Cela nécessite deux changements significatifs dans la façon dont nous avons
travaillé jusqu'à ce jour :

Les designers doivent ouvrir le processus de conception

L'équipe, pas l'individu, doit être propriétaire du produit. conception. Au lieu de

se cacher derrière un moniteur pendant des jours consécutifs, les designers doivent
incorporer leurs équipes au processus de conception, solliciter leur avis et développer cela
informations dans la conception. Si cela se produit, cela commencera à briser les silos et à promouvoir une
conversation plus multifonctionnelle. Pour ce faire, les designers doivent utiliser une
large gamme de tactiques collaboratives et doivent être créatifs et profondément pratiques,
recherchant des tactiques qui répondent aux besoins de l'équipe, font progresser la
conversation et respecter les réalités de la capacité de l'équipe et le calendrier de
projet.

Les designers doivent assumer un rôle de leadership dans leur équipe

Vos collègues ont l'habitude de critiquer votre travail de design. Ce qu'ils ne sont pas
accoutumés à faire est de co-créer ce design avec toi. Le leadership de design et la
La facilitation d'activités de brainstorming en groupe telles que le Design Studio peut créer
forums sûrs pour que toute l'équipe conceptualise son produit et montre les
capacités de synthèse de l'équipe de design.

Turno : créer des espaces de travail ouverts et collaboratifs

Brisez les barrières physiques qui empêchent la collaboration. Localisez vos équipes et créez
espaces de travail pour eux qui maintiennent tout le monde visible et accessible. Faites de la place
pour que votre équipe mette son travail sur les murs et d'autres surfaces de travail. Rien
c'est plus efficace que de s'approcher d'un collègue, de lui montrer un travail, de discuter, de dessiner,
échanger des idées, comprendre les expressions faciales et le langage corporel, et parvenir à
une résolution sur un sujet épineux.
Lorsque vous placez des personnes, créez des regroupements de fonctions croisées. Cela signifie les retirer.
des commodités du "cachette" de sa discipline. Il est surprenant de voir comment même une
Un mur de cubicle peut entraver la conversation entre collègues.

Les espaces de travail ouverts permettent aux membres de l'équipe de se voir et de se

comuniquen fácilmente cuando surgen preguntas. Algunos equipos han ido tan lejos
comme pour mettre leurs bureaux sur roulettes afin de pouvoir se rapprocher des
membres de l'équipe avec lesquels ils collaborent ce jour-là en particulier. Agrandissez ces espaces
ouverts avec des salles de réunion où les équipes peuvent échanger des idées. Tableaux blancs
blanches de la taille d'un mur ou simplement peindre les murs avec de la peinture pour tableau noir
blanca fournit de nombreux pieds carrés d'espace pour la discussion. En résumé,
éliminez les obstacles physiques entre les membres de votre équipe. Il est possible que vos
les planificateurs d'espace ne les aiment pas au départ, mais leurs parties prenantes le font
agradecerán.

À mesure que les équipes distribuées et les situations de travail "hybrides" se

devenez plus courantes, n'oubliez pas de transférer ces qualités à ces situations
aussi. Assurez-vous que la collaboration et l'échange soient faciles et que vos équipes
Ayez les outils qui les rendent plus réussis plutôt que ceux que l'IT a choisis pour
eux.

Turno : Sans héros

À mesure que nous continuons à travailler avec une gamme plus large d'équipements, nous restons encore
Il y a de nombreux designers qui résistent à Lean UX. Une raison ? Beaucoup de designers
veulent être des héros.

Dans un environnement où les concepteurs créent de beaux produits, ils peuvent maintenir un
aura héroïque. Les exigences se trouvent à une extrémité de la machine de conception, et les œuvres de
des œuvres d'art magnifiques font leur apparition. Les gens disent "ooh" et "aah" lorsque le design est révélé. Les
les designers ont prospéré avec ces réactions (à la fois informelles et formalisées
comme des prix) pendant de nombreuses années.

Nous ne suggérons pas que tous ces designs soient superficiels. Éducation,
la formation formelle, l'expérience et une bonne dose d'inspiration se rencontrent dans chaque
document de Photoshop que créent les designers et, souvent, les résultats sont
intelligents, bien considérés et précieux. Cependant, ces résultats brillants peuvent
générer de mauvaises décisions d'entreprise ; elles peuvent biaiser le jugement spécifiquement parce que leur
la beauté est très persuasive. Les prix peuvent être basés sur l'esthétique des designs.
lugar del resultado que crea el diseño). Las decisiones de contratación se toman en
fonction de la netteté des wireframes, et la compensation peut dépendre des marques
associées à chacune des pièces du portefeuille.

Le résultat de cela est que les créateurs de ces documents sont annoncés comme
leaders d'opinion et élevés au sommet du domaine du design d'expériences. On les
reconnaître comme les personnes à qui il faut s'adresser lorsque le problème doit être résolu
rapidement. Mais, un seul héros du design peut-il être responsable du succès de la
expérience utilisateur, l'entreprise et l'équipe ? Une personne devrait-elle être considérée ?
comme la seule raison du succès d'une initiative ?
En résumé, non.

Para que Lean UX tenga éxito en su organización, todos los tipos de contribuyentes,
designers et non-designers doivent collaborer largement. Cela peut être un changement
difficile pour certains, en particulier pour les concepteurs visuels ayant de l'expérience en agence
interactives. Dans ces contextes, le directeur créatif est intouchable. En Lean UX, la seule chose
intouchable est la connaissance du client.

Lean UX littéralement n'a pas de temps pour les héros. Tout le concept de design comme
l'hypothèse détrône immédiatement les notions d'héroïsme ; en tant que designer, vous devez
attendre que beaucoup de ses idées échouent à l'épreuve. Les héros n'admettent pas le
échec. Mais les concepteurs de Lean UX l'adoptent comme partie du processus.

Change : Tombe amoureux du problème, pas de la solution

Lean UX nous pousse à poser des questions difficiles sur la nature de la qualité dans notre
travail de design.

Si vous êtes un designer qui lit ceci, vous vous êtes probablement posé une question qui à
Menudo surgit lorsque la vitesse triomphe de la perfection esthétique :

Si mon travail maintenant est de présenter des concepts et des idées plutôt qu'un travail terminé,
tout ce que je produis se sentira à moitié. J'ai l'impression que "je vise le bronze". Rien de ce que
produire ne finira jamais. Rien n'est indicatif du type de produits que je suis capable de
concevoir. Comment puis-je ressentir de la fierté et un sentiment d'appartenance pour des designs qui ne sont tout simplement pas là ?

faits ?

Pour certains designers, Lean UX menace ce qu'ils valorisent dans leur travail et met en danger
sa carrière. Elle pourrait même sentir que cela menace sa future employabilité. Ces émotions
se basent sur ce que de nombreux responsables de l'embauche ont évalué jusqu'à présent : produits
attractifs (c'est-à-dire, solutions). Les croquis, la "version un" d'un projet et d'autres
Les artefacts de basse fidélité ne sont pas la création d'un "excellent portefeuille". En se donnant
compte que les solutions logicielles continuent d'évoluer avec le temps, tout
cela est en train de changer.

Bien que votre organisation doive continuer à valoriser l'esthétique, le poli et l'attention à
détail, d'autres dimensions de la conception sont également importantes. La capacité de
comprendre le contexte d'un problème commercial, penser rapidement et développer un
la compréhension partagée doit obtenir une promotion. Les concepteurs peuvent
démontrer ses compétences en matière de résolution de problèmes en illustrant les chemins qu'ils ont empruntés
para pasar de la idea al aprendizaje validado a la experiencia. Al hacerlo, demostrarán su
une grande valeur en tant que designers. Les organisations qui recherchent et récompensent les
Les solveurs de problèmes attireront et se sentiront attirés par ces designers.

Changement : faire évoluer la culture de l'agence

Appliquer Lean UX dans une agence digitale n'est pas un défi mineur. La plupart des
les agences ont un modèle économique qui entre en conflit avec Lean UX. Le modèle de
Le modèle commercial traditionnel de l'agence est simple : les clients paient pour les livrables.
(designs, specifications, code, PowerPoint presentations), not by
résultats. Mais la culture de l'agence est aussi un grand obstacle. La culture de
la conception de héros est forte dans des endroits qui élèvent les personnes à des postes tels que directeur
créatif exécutif. La collaboration interdisciplinaire peut également s'avérer difficile dans les
grandes agences, où le besoin de maintenir une haute utilisation a conduit à
des processus qui favorisent les silos fonctionnels. Ceux-ci, à leur tour, conduisent à des "phases de
proyecto" que fomentan el trabajo centrado en los entregables.

Peut-être que l'obstacle le plus difficile est l'attente du client de « le jeter contre le mur »
à l'agence et ensuite voir les résultats quand ce sera prêt. La collaboration entre le client
et l'agence dans ces situations peut se limiter à une critique désinformée et
improductive basée sur des préjugés personnels, la politique et la dissimulation.

Pour que Lean UX fonctionne dans une agence, tous les impliqués dans un engagement
ils doivent se concentrer sur la maximisation de deux facteurs : augmenter la collaboration entre le client et le
agence, et travailler pour changer l'accent des produits vers les résultats.

Certaines agences essaient de se concentrer sur les résultats en expérimentant avec un

éloignement des contrats à portée fixe et basés sur des livrables. En revanche, leurs
Les engagements sont basés sur des accords simples de temps et de matériaux ou, de manière plus
radical, dans des contrats basés sur les résultats. Quoi qu'il en soit, les équipes deviennent plus
libres pour passer leur temps à itérer vers un objectif. Les clients renoncent à l'illusion de
contrôle qui offre un contrat basé sur des livrables, mais obtiennent la liberté de chercher
solutions significatives et de haute qualité qui se définissent en termes de résultats, pas de
listes de caractéristiques.

Pour augmenter la collaboration, les agences peuvent essayer de détruire les murs qui les
s'éloignent de leurs clients. Les clients peuvent participer au processus avant et avec plus de
fréquence. Les enregistrements peuvent être construits autour d'étapes moins formelles. Et se
ils peuvent organiser des sessions de travail collaboratif afin que l'agence ainsi que le
le client bénéficie de l'information supplémentaire, des commentaires et de la collaboration entre
eux.

Ce ne sont pas des transformations faciles, ni pour l'agence ni pour le client qui les engage, mais
c'est le modèle sous lequel les meilleurs produits sont construits.

Une note rapide sur les partenaires pour le développement. Dans les relations avec les agences, les
équipes de développement de logiciels (que ce soit à l'agence, chez le client ou en travaillant comme
un tiers) sont souvent traités comme des étrangers et sont souvent intégrés à la fin d'un
phase de conception. Il est impératif que cela change : les partenaires au développement doivent
participer tout au long de la vie du projet, et pas simplement en tant qu'observateurs
passifs. À la place, vous devez essayer de faire en sorte que le développement logiciel commence le plus tôt possible.
possible. Encore une fois, vous cherchez à créer une collaboration profonde et significative avec
tout l'équipe du projet, et pour cela, il doit travailler côte à côte avec les
développeurs.

Tour : Soyez réaliste sur votre environnement

Le changement fait peur. L'approche Lean UX apporte de nombreux changements. Cela peut
résulter particulièrement déroutant pour les gestionnaires qui ont été dans leurs postes
pendant un certain temps et se sentent à l'aise dans leurs fonctions actuelles. Certains managers
peuvent se sentir menacés par des propositions de travailler d'une nouvelle manière, ce qui pourrait
terminer ayant des conséquences négatives pour vous. Dans ces situations, essayez de demander
pardon au lieu de permission. Essayez quelques idées et démontrez leur valeur par un succès
quantifiable. Que ce soit en ayant économisé du temps et de l'argent sur le projet ou en ayant réalisé
une mise à jour plus réussie que jamais, ces réalisations peuvent vous aider à défendre votre
cas. Si votre responsable ne voit toujours pas la valeur de travailler de cette manière et que vous pensez que son
l'organisation progresse sur un chemin de "design aveugle" continu, peut-être que c'est le
moment de considérer un emploi alternatif.

Changement : Pensez aux compétences concernant les rôles

Dans la plupart des entreprises, le travail que vous effectuez est déterminé par votre poste de
travail. Ce titre de travail vient avec une description du travail. Avec trop de
fréquence, les personnes dans les organisations découragent les autres de travailler en dehors des
limites de vos descriptions de travail (par exemple, "Tu n'es pas un développeur, que
peux-tu en savoir plus sur JavaScript ?). Cette approche est profondément anticollaborative et laisse
sans utiliser l'ensemble complet des compétences, talents et aptitudes des personnes.

Décourager les contributions multifonctionnelles favorise les silos organisationnels. Plus...

Discret est le travail d'une personne, plus il devient facile de se retirer dans les confins sûrs.
de cette discipline. En conséquence, la conversation entre les disciplines s'estompe et grandit.
la méfiance, les accusations pointées du doigt et le comportement CYA (« couvre-toi le »
culo

Les silos sont la mort des équipes collaboratives.

Pour que Lean UX réussisse, votre organisation doit adopter un mantra de "compétences".
sur les rôles". Chaque membre de l'équipe possède une compétence centrale (design, développement
logiciel, recherche, etc.) et doit répondre à cet ensemble de compétences. Sans
embargo, les membres peuvent également posséder des compétences secondaires qui font que
l'équipe travaille de manière plus efficace.

Permettez à vos collègues de contribuer à toute discipline dans laquelle ils ont de l'expérience
vous découvrirez qu'il crée une équipe plus engagée qui peut compléter les
tâches de manière plus efficace. Vous constaterez également que cela crée de la camaraderie entre les titres
de travail, car les personnes avec différentes disciplines montrent de l'intérêt pour ce qu'elles sont
faisant ses collègues. Les équipes qui aiment travailler ensemble produisent un meilleur
travail.

Tour : créer des équipes multifonctionnelles

Pour de nombreuses équipes, la collaboration est une activité d'une seule discipline. Les
les développeurs résolvent des problèmes avec d'autres développeurs tandis que les concepteurs
Ils s'asseyent sur des sacs de haricots, allument les lampes à lave et 'imaginent' avec leurs frères.
en col roulé noir. (On rigole.) (Enfin ... juste un peu. Nous adorons les
designers).

Les idées qui naissent des collaborations d'une seule discipline ont une seule
facette. Ils ne reflètent pas la perspective plus large de l'équipe, qui peut éclairer une gamme
plus large des besoins, des opportunités, des risques et des solutions. Pire encore, travailler de
Cette méthode nécessite que des équipes basées sur la discipline expliquent leur travail. Avec
trop de fréquence, le résultat est une grande dépendance à la documentation
détaillée et un ralentissement du rythme d'apprentissage de l'équipe en général.

Lean UX requiere colaboración multifuncional. Al crear interacción entre gerentes de

producto, desarrolladores, ingenieros de control de calidad, diseñadores y especialistas en
le marketing, met tout le monde sur la même longueur d'onde. Tout aussi important : tu mets tout le monde au même niveau.
niveau. Aucune discipline individuelle n'en dicte une autre. Tous travaillent vers un
objectif commun. Permettez à vos concepteurs d'assister à des 'réunions de développeurs' et
viceversa. En fait, n'ayez que des réunions d'équipe.

Nous savons depuis longtemps à quel point la collaboration multifonctionnelle est importante.
temps. L'étude de Robert Dailey à la fin des années 1970 intitulée "Le rôle de
les caractéristiques de l'équipe et de la tâche dans la productivité et la résolution collaborative
de problèmes de l'équipe de R + D" a trouvé un lien entre la productivité de
résolution de problèmes d'une équipe et ce qu'il appelait "quatre prédicteurs", qui comprenaient
certitude de la tâche, interdépendance des tâches, taille de l'équipe et cohésion du
équipe1

Gardez votre équipe soudée en brisant les limites basées sur la discipline.

Tour : créer des petites équipes

Les groupes de personnes les plus nombreux sont moins efficaces que les plus petits. Cela
cela a du sens intuitif. Mais moins évident est ceci : une équipe plus petite doit travailler
en problèmes plus petits. Ce petit taille facilite la maintenance de la
discipline nécessaire pour produire des produits minimaux viables (MVP). Divisez vos grands
équipes que le fondateur d'Amazon, Jeff Bezos, a appelées "équipes de deux pizzas". Si
L'équipe a besoin de plus de deux pizzas pour faire un repas, c'est trop grand.

Si la tâche est grande, divisez-la en travaux connexes que plusieurs petites équipes.
puissent être gérés simultanément. Alignez ces équipements avec un seul résultat pour
réussir. De cette manière, tous travaillent vers le même objectif. Cela oblige
à ces petites équipes de s'autoorganiser et de communiquer de manière efficace en même temps
qui réduit le risque que chaque équipe optimise localement.

Turno : travailler avec des équipes distribuées

Comme la pandémie de COVID-19 nous l'a démontré, le placement n'est pas toujours une
option. Lors de la configuration d'équipes distribuées, fournissez-leur les outils dont ils ont besoin pour
communiquer et collaborer. Cela inclut des choses comme des logiciels de vidéoconférence (par
exemple, Zoom), services de communication en temps réel (par exemple, Slack),
outils de tableau en ligne (par exemple, Mural et Miro), logiciel simple pour
partager des fichiers (par exemple, Dropbox, Google Docs), logiciel de prise en main à distance
emparejamiento (p. ex., Screenhero) et toute autre chose qui peut faire que votre
la collaboration soit plus facile et productive.

Quand il est possible de voyager, n'oublie pas de temps en temps Les billets d'avion pour
se rencontrer en personne contribue grandement à maintenir la collaboration à long terme
distance. Peut-être la chose la plus importante à retenir si vous essayez de mettre en œuvre
Lean UX avec des équipes distribuées, c'est cela : les membres de ces équipes doivent être
éveillés en même temps. Il n'est pas nécessaire que le chevauchement couvre une journée
travail complet, mais il doit y avoir un bloc de temps chaque jour pendant lequel les
les collègues peuvent discuter et participer à des exercices collaboratifs.

Favorisez la flexibilité dans les relations avec les fournisseurs externes

Los proveedores de desarrollo de software de terceros plantean un gran desafío a los

méthodes Lean UX. Si une partie de votre travail est sous-traitée à un fournisseur externe,
indépendamment de l'emplacement du fournisseur, il est plus probable que le processus Lean
L'UX se rompt. Cela est dû au fait que la relation contractuelle avec ces fournisseurs peut
difficulté de la flexibilité requise par Lean UX.

Lorsque je travaille avec des fournisseurs externes, j'essaie de créer des projets basés sur le temps et
matériaux. Cela vous permettra d'établir une relation flexible avec votre partenaire de développement. Le
vous aurez besoin de répondre aux changements qui font partie du processus Lean
UX. Rappelez-vous, vous créez un logiciel pour apprendre et cet apprentissage fera que vos plans
cambien. Planifiez ce changement et structurez vos relations avec les fournisseurs autour de
à lui.

En sélectionnant des partenaires, rappelez-vous que de nombreux ateliers de développement sous-traités sont
orientés vers le travail de production et voient le retravail comme un problème plutôt que
comme une opportunité d'apprentissage. Lorsque je recherche des partenaires pour le travail Lean UX,
cherchez des équipes prêtes à adopter l'expérimentation et l'itération et qui
comprennent clairement la différence entre la création de prototypes pour apprendre et le
développement pour la production.

Tour : planifiez le travail en utilisant les résultats, pas les produits

Le chapitre 3 analyse le rôle des résultats dans Lean UX. Les équipes de Lean UX mesurent
son succès non en termes de fonctions complétées, mais en termes de progrès vers
résultats spécifiques. Déterminer les résultats est une activité de leadership ; c'est un dans
que de nombreuses organisations ne le font pas bien ou ne le font pas du tout. Avec trop de
fréquence, le leadership dirige l'équipe produit à travers une feuille de route de
produit centré sur les caractéristiques : un ensemble de résultats et de caractéristiques qui
exigent que l'équipe produit produise à une date spécifique.

Les équipes qui utilisent Lean UX doivent avoir la capacité de décider par elles-mêmes ce que
les fonctions créeront les résultats que nécessitent vos organisations. Pour ce faire, les
les équipes doivent changer leur conversation avec le leadership d'une basée sur des caractéristiques
une centrée sur les résultats. Ce changement conversationnel est radical. Les gestionnaires de
Le produit doit déterminer quelles métriques commerciales nécessitent plus d'attention. Quel effet
Ils essaient de créer ? Essaient-ils d'influencer le comportement du client ? Si
C'est comme ça, comment ? Essayent-ils d'augmenter les performances ? Si c'est le cas, dans quoi ?
mesure ? Ces métriques doivent être liées à un plus grand impact commercial.

Le leadership doit établir cette direction. Sinon, les équipes doivent leur exiger cela.
changement. Les équipes doivent se demander : "Pourquoi travaillons-nous sur ce projet ?" et
«Comment saurons-nous que nous avons bien travaillé ?» Les gestionnaires doivent revenir à
se former pour donner à ses équipes les réponses à ces questions. On doit leur donner la
liberté de travailler avec ses équipes pour déterminer quelles caractéristiques réalisent le mieux celles-ci
objectifs. Les équipes doivent passer des cartes routières de fonctionnalités aux accumulations
des hypothèses en attente de vérification. Le travail doit être priorisé en fonction du risque, le
viabilité et succès potentiel.

Attention aux BDUF qui s'immiscent dans les environnements agiles

Dans la communauté agile, on entend parfois les gens parler de Big Design Up Front ou
BDUF. Nous plaidons pour nous éloigner de BDUF depuis des années. Mais pas toujours
c'était ainsi.

Au début des années 2000, Jeff était designer UI chez AOL et travaillait sur un
nouveau navigateur. L'équipe travaillait pour trouver des moyens d'innover dans
ensembles de fonctions de navigateur existants. Mais ils devaient toujours attendre pour
implémenter quelque chose jusqu'à ce que Jeff crée les maquettes, spécifications et diagrammes de
flux appropriés qui décrivaient ces nouvelles idées.

Un développeur en avait assez d'attendre et a commencé à mettre en œuvre certaines de ces idées
avant que les documents ne soient complets. Jeff était furieux ! Comment a-t-il pu
avoir avancé sans une direction de design ? Comment pourrais-je savoir quoi
Construire ? Et si c'était mauvais ou que ça ne fonctionnait pas ? Je devrais tout réécrire !

Il s'avère que le travail qu'il a fait a permis à l'équipe de voir certaines de ces idées beaucoup
avant que auparavant. Ils ont donné aux membres de l'équipe une idée de l'expérience réelle du
produit et leur a permis d'itérer rapidement leurs conceptions pour qu'elles soient plus utilisables et
faisables. À partir de ce moment, ils ont assoupli les exigences de BDUF, en particulier
quand l'équipe a introduit des fonctionnalités nécessitant des animations et de nouveaux motifs de
interface utilisateur.

L'ironie de la dépendance aux documents de l'équipe et de l'"inspiration" qu'elle a déclenchée

Dans ce développement, il ne s'est pas perdu. En fait, à la fin du projet, Jeff a reçu un prix.
simulado ( Figure 17-1) pour inspirer une "créativité indocumentée" chez un collègue de
équipe.

Bien que la plupart des équipes agiles de nos jours disent qu'elles évitent le concept de
BDUF, nous avons observé un renouveau dans cette pratique dans des environnements soi-disant
ágiles. Cette nouvelle et discrète version du BDUF est parfois appelée Agilefall. (Ou Agile-
Scrum-Fall, Water-Scrum-Fall, ou Wagile. Tu comprends l'idée). Agilefall est la
combina une phase de conception initiale qui aboutit à un travail qui se
livraison, style en cascade, à une équipe d'ingénierie. puis se diviser en histoires et
se développer de manière "agile". L'argument en faveur de cette méthode de travail se concentre
dans le désir de l'équipe d'ingénierie de maintenir le cap pendant la mise en œuvre et
pouvoir prédire quand le travail sera envoyé avec un certain degré de confiance. Cela se fait
au nom de la prévisibilité et de l'efficacité.
Figure 17-1. Le "prix" de Jeff pour avoir inspiré la créativité non documentée chez les ingénieurs

Le problème, bien sûr, est qu'Agilefall élimine la collaboration entre le design et

l'ingénierie que Lean UX nécessite pour réussir. Cela finit par obliger les équipes à créer
une grande documentation pour communiquer le design, suivie de négociations encore plus
de longues distances entre les concepteurs et les développeurs. Ça sonne familier ? C'est BDUF avec un nouveau
déguisement. Le gaspillage créé avec Agilefall est un symptôme d'un problème de
administration plus large qui continue à pousser les équipes vers un champ d'application et
dépôts à terme. Les ingénieurs ressentent, à juste titre, que la seule façon dont ils peuvent
s'engager sur la portée et les délais, c'est s'ils ont une compréhension claire de ce que
il est nécessaire de développer, avec la promesse que rien ne changera. (Peu importe que
Agile consiste à adopter le changement !) Bien sûr, comme nous le savons déjà, le logiciel est
complexe et imprévisible et, même avec un design bloqué,

Si Agilefall est la façon dont votre équipe travaille, envisagez d'élargir la conversation sur
la gestion des résultats avec ses parties prenantes. En éloignant la conversation du temps et
la portée fixe et l'orienter vers le comportement du client comme mesure de succès,
les demandes pour faire tout le travail de conception depuis le début devraient commencer
à disparaître.

Shift : Adopte la vitesse d'abord, l'esthétique en second lieu

Jason Fried, directeur exécutif de Basecamp, a dit un jour : "La vitesse d'abord, le
esthétique après.
Je ne parlais pas de compromettre la qualité. Je parlais de modifier vos idées et
processus jusqu'à la moelle. Dans Lean UX, travailler rapidement signifie générer beaucoup
artefacts. Ne perdez pas de temps à débattre du type d'artefact à créer et ne perdez pas le
temps à les peaufiner à la perfection. À la place, demandez-vous la question suivante :

• Avec qui dois-je communiquer ?

• Que dois-je faire pour leur communiquer immédiatement ?
• Quelle est la moindre quantité de travail que je dois faire pour le lui communiquer ?

Si vous travaillez avec un développeur assis à côté de vous, un croquis au tableau.

peut être suffisant. Si un cadre pose des questions détaillées sur les produits, il est possible
que deba crear una maqueta visual. Los clientes pueden requerir prototipos. Cualquiera
que ce soit le scénario, créez l'artefact qui prendra le moins de temps. N'oubliez pas,
ces artefacts sont une partie transitoire du projet, comme une
conversation. Faites-le. Sortez-le là-bas. Discuter. Continuez.

L'esthétique, au sens du design visuel, est une partie essentielle d'un produit fini.
et une expérience. L'ajustement et la finition de ces éléments contribuent
fondamental à la marque, l'expérience émotionnelle et le professionnalisme. À l'étape de
raffinement de la conception visuelle du processus, faire l'effort de s'obséder avec cela
La couverture de présentation a beaucoup de sens. Cependant, mettre ce niveau de finition et
effort dans les artefacts de la phase initiale (maquettes, cartes du site, diagrammes de
Le flux de travail est (généralement) une perte de temps.

En sacrifiant la perfection des artefacts de design intermédiaires, votre équipe atteindra le

marché plus rapide et apprendra plus rapidement quels éléments de toute l'expérience
(design, workflow, copy, content, performance, value propositions, etc.)
fonctionnent pour les utilisateurs et lesquelles ne le sont pas. Et il sera plus disposé à changer et
réélaborer vos idées si vous avez mis moins d'efforts à les présenter.

Changement : aborder la dette de l'UX

Il arrive souvent que les équipes travaillant en processus agiles ne continuent pas à s'améliorer.
interface utilisateur du logiciel. Mais, comme aime à le dire notre ami Jeff Patton,
Ce n'est pas une itération si vous le faites une seule fois. Les équipes doivent s'engager avec la
amélioration continue, et cela signifie non seulement refactoriser le code et traiter la dette
technique, mais aussi réélaborer et améliorer les interfaces utilisateur. Les équipes doivent
adopter le concept de dette d'UX et s'engager dans l'amélioration continue de la
expérience utilisateur.

James O'Brien, un designer d'interaction qui travaille à Londres, décrit ce que

Cela s'est produit lorsque son équipe a commencé à suivre la dette UX de la même manière que le
L'équipe avait l'habitude de suivre la dette technique. "L'effet a été dramatique. Une fois que nous avons présenté
la réélaboration comme deude, toute opposition s'est évaporée. Il ne s'agissait pas seulement de
que la dette ne serait pas remboursée, mais qu'elle était constamment priorisée.2

Pour commencer à suivre la dette UX, vous pouvez créer une catégorie d'histoires dans votre
portefeuille de commandes appelé dette de UX. Parfois, cependant, les problèmes de
l'expérience n'est pas quelque chose qu'une seule équipe peut résoudre ; résoudre des problèmes majeurs
peut nécessiter l'effort coordonné de nombreux équipes. Pour ces efforts plus
grandes (expérimenter des problèmes qui couvrent de grands parcours d'utilisateurs), essayez-le
suivant :

• Cree un mapa del recorrido del cliente de la experiencia actual.

• Travaillez avec votre équipe pour créer une deuxième carte de voyage qui montre le
expérience idéale.
• Rendez ces deux artefacts clairement visibles (sur un mur) l'un à côté de l'autre.
de l'autre.
• Identifiez les équipes responsables de certaines parties de ce parcours client et
invitez-les au mur pour examiner l'écart entre les états actuels et désirés.
• Travaillez avec ces équipes pour rédiger des histoires de dettes UX pour continuer.
avec ses travaux en cours.
• Identifiez clairement sur les cartes de voyage quand l'expérience a été améliorée
actuel et qui travaille sur d'autres améliorations.

Tour : repenser les pratiques de documentation

Selon le domaine dans lequel vous travaillez, votre organisation pourrait imposer des règles strictes
normes de documentation conformes à la conformité réglementaire et interne. C'est
posible que estos documentos no agreguen mucho o ningún valor para el proyecto
pendant qu'il est en cours, mais l'équipe doit encore les créer. De nombreuses équipes se débattent
pour faire avancer leurs projets lorsqu'ils sont confrontés à ces réglementations. Ils attendent jusqu'à
que les documents soient complets avant de commencer la conception et la mise en œuvre du
travail, ce qui ralentit le progrès et l'apprentissage en équipe. Puis, quand les
les documents soient complets, il est déconseillé d'apporter des modifications au travail décrit dans ceux-ci
en raison de la surcharge de documentation que générera le changement.

Cette situation est exactement là où, en tant que designer et entraîneur, Lane Goldstone
peu de mots, "tu leads avec la conversation et continues avec la documentation".
les philosophies et concepts de base du Lean UX peuvent être appliqués dans ces environnements
(conversation, résolution collaborative de problèmes, croquis, expérimentation, etc.)
durant les premières phases du cycle de vie du projet. Au fur et à mesure que les tests seront effectués les
hypothèses et solidifient les directions de conception, effectuent la transition des pratiques de
documentation informelle à la documentation standard que votre entreprise exige. Utilisez
cette documentation pour la raison exacte que votre entreprise exige : capturer l'historique de
décisions et informer les futures équipes qui travailleront sur ce produit. Ne permettez pas que
cela l'empêche de prendre les bonnes décisions concernant le produit.

Turno : Gérer vers le haut et vers l'extérieur

Lean UX donne aux équipes beaucoup de liberté pour poursuivre des solutions. Cela le fait
s'éloignant d'une approche basée sur une feuille de route des fonctionnalités et, au contraire, permettant à
équipements découvrir les caractéristiques qu'ils pensent serviront le mieux à l'entreprise. Mais
abandonner la feuille de route des fonctionnalités a un coût : cela supprime un outil clé qui
l'entreprise utilise pour coordonner l'activité des équipes. Alors, avec la liberté de
suivre son agenda, il y a la responsabilité de communiquer cet agenda.

Vous devez communiquer constamment avec les membres de votre organisation qui ne sont pas.
impliqués actuellement dans leur travail pour qu'ils soient au courant de ce qui s'en vient. Cette
la communication te rendra également conscient de ce que les autres planifient et t'aidera à
coordonner. Les responsables du service client, les spécialistes du marketing, les unités
des affaires parallèles et les équipes de vente bénéficient de savoir ce que fait la
organización del producto. Al comunicarse con ellos de manera proactiva, les permite
faire mieux leur travail. En retour, ils seront beaucoup moins résistants au changement qu'ils ne le sont
faisant les designs de ses produits.

Voici deux leçons précieuses pour garantir des cycles de validation plus fluides :

• Il y a toujours d'autres départements qui sont affectés par votre travail. Ignorez-les.
sous votre responsabilité.
• Assurez-vous que les clients soient au courant des prochains changements importants
et leur offrir la possibilité de ne pas participer (du moins temporairement).

1RRobert C. Daley, « Le rôle de l'équipe et les caractéristiques de la tâche dans la productivité »

y la résolution de problèmes en équipe de R + D", Science de la Gestion 24, n° 15 (1 de
novembre 1978): 1557–1676,[Link] .

2James O'Brien, entretien avec Joshua Seiden et Jeff Gothelf, 2012.

Chapitre 18. Lean UX dans une agence
Une grande partie de l'approche de ce livre a été explicitement de faire fonctionner Lean UX
dans une entreprise de produits ou dans un groupe de produits au sein d'une
entreprise ou organisation plus grande. Bien que la plupart de ces conseils puissent être appliqués
Dans n'importe quel environnement, il vaut la peine de mentionner explicitement les différences nécessaires.
pour que Lean UX fonctionne dans une agence.

Pour les besoins de cette discussion, lorsque nous disons "agence", cela signifie toute organisation
qui vend des services à un client. Cela pourrait être un petit studio de design de quatre
personnes à Portland, Oregon, ou une agence de marketing de mille personnes à Londres. Le
ce qui rend Lean UX un défi unique dans cet environnement est, en un mot, les
clients. Il est difficile pour les agences d'apporter de nouvelles façons de travailler aux clients qui
ils trouvent ces formes de travail étrangères à leur culture. Maintenant, dans certains cas, cela sera
la raison exacte pour laquelle son agence a été engagée. Dans d'autres, ce sera une approche étrangère
continuément menacé par des anticorps corporels résistants à différentes formes de
travailler. De toute façon, ce sera difficile.

Dans ce chapitre, nous couvrirons cinq éléments clés à prendre en compte lorsque vous essayez d'apporter
formes modernes de travail à votre entreprise.

Dans quel secteur veux-tu être ?

Les agences sont presque toujours dans le secteur des livrables. On leur paie pour livrer.
un design, un prototype, une recherche ou un logiciel fonctionnel. Ce
le modèle économique entre en conflit avec Lean UX et son approche des résultats.

Le modèle commercial traditionnel de l'agence est simple : les clients paient pour les
livrables (conceptions, spécifications, code, présentations PowerPoint), pas par
résultats. L'autre partie du modèle commercial d'une agence est l'utilisation : elle doit
maintenir son personnel facturant. La nécessité de maintenir une haute utilisation peut
conduire à des processus qui favorisent les silos fonctionnels. Ceux-ci, à leur tour, mènent à des "phases
du projet" qui favorisent le travail axé sur les livrables. La vente de matériel
les multifonctionnels sont excellents tant que tous les membres de l'équipe sont
facturables à tout moment.

Si vous allez effectuer la transition de la façon de travailler de votre agence vers Lean UX, vous devez
considerar ambos desafíos. En primer lugar, ya no puede estar exclusivamente en el
negocio de los entregables. ¿Entregará wireframes, prototipos, investigación y software
fonctionnel ? Bien sûr que tu le feras. Mais ce ne peuvent pas être les mesures de son
succès. Ce ne peuvent pas être les critères qui déterminent s'ils vous paient ou non. À la place, considérez
transformar el negocio en un modelo de tiempo y materiales. No está vendiendo "una
application" ou "un design", mais qu'il collabore avec son client pour trouver une
solution à un client et un problème commercial que rencontre le client. Quelle est-elle ?
solution ? La réponse sincère est, il ne le sait pas. En revanche, il travaillera avec le client
pour découvrir quelle devrait être cette solution.
Pour garantir que l'utilisation reste élevée, vendez de petits équipements pour des périodes.
de tiempo finitos con cláusulas de renovación claras. En la agencia que dirigimos durante
quatre ans ensemble, nous proposerions une équipe de quatre personnes composée d'un
responsable produit, un designer et deux développeurs comme équipe initiale pour presque
tous les projets. Cette équipe avait un coût fixe par semaine et normalement
nous vendrions un contrat de trois mois renouvelable par blocs de trois mois. Cela nous
a aidé à renforcer le mantra des cycles courts parce que le client avait une option de sortie
ou renouvellement tous les trimestres. Cela a également réduit notre risque en nous donnant l'option de
renvoyer un client qui ne correspondait pas bien à la façon dont nous voulions
trabajar. También,

Déterminer votre modèle commercial avant un changement total vers un style de travail Lean
L'UX est importante car elle affectera également votre personnel actuel ainsi que les potentiels.
recrutements. Le seul actif qu'une agence a, c'est son personnel. Les designers,
les chefs de produit, les développeurs de logiciels, etc., viennent travailler pour vous
parce qu'il promet une certaine façon de travailler pour des types spécifiques de clients. S'il promet
une façon de travailler Lean UX et finit par embaucher des clients qui ne travailleront pas de cette façon
manière, son personnel ira finalement.

Vendre Lean UX aux clients concerne

établir des attentes
Vos clients travaillent avec des agences depuis des années. Beaucoup de clients s'attendent à "le jeter par"
le mur" à l'agence puis voir les résultats lorsqu'ils seront prêts. Dans ce cas, le
la collaboration entre le client et l'agence peut se limiter à une critique désinformée et
improductive qui est basée sur des préjugés personnels, la politique et le mensonge. Étant donné la nature
hautement collaborative de Lean UX, obviously this is not an acceptable relationship. What
puedes hacer para evitar esto?

Chaque point de contact que vous avez avec des clients actuels et potentiels est une opportunité
pour établir des attentes sur la façon de travailler avec vous, c'est différent. Cela commence avec votre
marque, son marketing, son positionnement et, ce qui est le plus tangible, son site web. Concevez et
écrivez-le de manière à ce qu'il n'y ait aucun doute qu'il travaille d'une manière qui le distingue
des agences traditionnelles. Augmentez ces attentes avec une production constante
de contenu dans les blogs, publications et réseaux sociaux. Assurez-vous que les gens soient au courant
son agence en tant que "les gens de Lean UX". La première fois que j'ai parlé à son client en
persona, repassez comment il travaille avec lui. S'il a la chance de les présenter, sa façon de travailler
Elle doit être claire et directe sur la plateforme de lancement.

Si vous progressez dans la planification des engagements, assurez-vous de bien comprendre comment vous travaillerez ensemble et pour
ce qui est si important pour créer une méthode de travail centrée sur le client. Si des problèmes surgissent
questions du client qui indiquent qu'il n'a pas complètement assimilé que son agence ne
il sera un partenaire de sous-traitance pour eux, arrêtez le processus et répétez le processus
à nouveau. Il est très important de communiquer cela tôt et fréquemment, car une
Une fois le contrat signé, tout changement radical dans les attentes pourrait entraîner
négatif pour son client.
Personne ne veut acheter des expériences
À mesure que vous établissez des attentes sur ce que sera le travail avec vous, rappelez-vous cela.
affirmation importante : personne ne veut acheter des expériences. Vos clients veulent
applications. Ils veulent des logiciels. Ils veulent du design. Ce qu'ils ne veulent sûrement pas
L'acheter est une expérience. Les expériences sont risquées et ont tendance à
échouer. En effet, ce ne sont pas des logiciels de production de niveau de marché qui aideront à
votre client doit augmenter sa part de marché ou sa rentabilité. Du moins c'est comme ça
vous le voyez.

Lorsque nous avons lancé notre agence pour la première fois, nous avons commencé avec l'idée d'expériences
dans notre processus de vente. Un client dirait : "J'ai 100 000 $ pour que vous créiez une
aplicación móvil para mi empresa".Y respondíamos: “¡Genial!Tomaremos $ 10,000 de
Cela et nous ferons des expériences pour découvrir exactement comment dépenser les autres 90 000 $.
.Sans faute, chaque client ayant reçu ce lancement dirait : « Non. Utilisez juste tout le
presupuesto para crear la aplicación. Conozco mi negocio y mis clientes. No necesitamos
expérimenter .

C'était un signe clair que nous ne nous étions pas suffisamment différenciés dans le
marché, nous n'avions pas établi les attentes correctes avec les prospects et
nous conduisions avec une tactique au lieu du résultat final souhaité.

Les expériences font partie de Lean UX, mais ce ne sont qu'une tactique. Elles font partie d'un
processus conçu pour générer de l'apprentissage, une bonne prise de décision et des résultats
positifs. Mener notre discours de vente avec le résultat (par exemple, "Notre
le processus garantit que nous prenions les meilleures décisions pour aider à résoudre votre défi
Le commerce mobile) s'est avéré être une forme de travail beaucoup plus réussie.

Vous avez fait la vente ! Maintenant, naviguez à travers les

acquisitions
Parfois, vous ferez tout correctement. Votre site web dira votre histoire. Votre argument de vente.
résonnera. Le client hochera la tête. Nous avons un accord pour nous ! Tu t'accordes une
petite tape dans le dos et tu commences à traiter la signature du contrat, juste pour entendre
cette phrase que tous les fournisseurs de services redoutent : "D'accord, laissez-moi que notre"
les personnes des achats s'occupent de cela.

Si vous avez déjà eu à faire avec le département des achats interne (ou, pire
encore, avec un tiers) d'une grande organisation, alors il sait comment cela se sent. Tout
le rapprochement que tu as fait avec le client ne signifie rien pour les personnes qui ont
que d'approuver le contrat et l'achat. Sans faute, la conversation recule instantanément
d'accord, alors nous donnons 100 000 $. Quels sont les livrables spécifiques que
Qu'obtiendrons-nous en retour ? Et à quelle date ?

C'est une autre partie de l'établissement des attentes qui doit se produire avec les clients
avec anticipation. À mesure que le contrat commence à se concrétiser, l'objectif est de s'éloigner de
les contrats à portée fixe et basés sur des livrables. Au lieu de cela, créez des contrats pour
engagements basés sur des accords simples de temps et de matériaux ou, de manière plus
radical, dans les contrats basés sur les résultats. Les contrats basés sur les résultats ou les
contratos de precios basados en valor son raros. Enumeran el pago como variable en
fonction de la quantité de résultats que l'agence peut générer. Souvent, c'est
trop de risque pour qu'un client (et des agences) l'assument sans une limite supérieure au
contrat.

Que vous choisissiez des contrats à temps et à matériaux ou des contrats basés sur des résultats, le
équipe de l'agence aura plus de liberté pour consacrer son temps à itérer vers un objectif
spécifique. Les clients renoncent à l'illusion de certitude qu'offre un contrat basé
en livrables, mais ils obtiennent la liberté de rechercher des solutions significatives et de haute
qualité qui se définit en termes de résultats, pas de listes de fonctions, et qui ont
plus de possibilités de rendre vos clients plus réussis.

Yano, tu es un partenaire de sous-traitance

Créer un processus Lean UX avec vos clients signifie que vous n'êtes plus leur agence de
sous-traitance. Vous êtes son partenaire de collaboration et travaillez à résoudre un problème
entreprise. Sa fonction n'est pas d'augmenter le personnel du client ou d'assumer une partie du
travail qu'ils ne peuvent pas réaliser en interne. Leur fonction est de faire du client un partenaire
l'actif de votre équipe. Votre client doit également comprendre cela. Ils viendront à la
arrêts. Ils participeront à la prise de décisions de façon régulière. Ils participeront aux
efforts de découverte de produits. Dans notre agence, nous prenons très peu
décisions de priorisation de l'accumulation de produits. C'était la responsabilité
explicite du client. La seule façon dont ils pouvaient le faire de manière efficace était d'être
présents lors des réunions quotidiennes, participer avec l'équipe à ses activités de
apprentissage et être présent lors des mises à jour de statut et des réunions de prise de décision
décisions. Nous l'avons poussé plus loin et insisté pour que le client s'installe dans notre
estudio durante la duración del compromiso. ¿Por qué? Para eliminarlos de las
distractions quotidiennes, placez-les dans un espace plus créatif et rappelez-leur que nous sommes
travaillant ensemble comme une équipe.

Ces attentes de relation doivent figurer dans votre contrat. Votre client doit s'engager
avec ce haut niveau d'engagement, Lean UX va fonctionner. N'oubliez pas que son objectif
il s'agit de développer une compréhension partagée. Si le client n'est pas présent pour le travail
de découverte, la synthèse et la prise de décision, alors vous devez commencer à
documenter tout pour lui, l'envoyer pour son approbation et attendre ce retour d'information
avant de continuer. Cela nous ramènerait au style de travail traditionnel des
agences.

Une fois, un client de services financiers a accepté tous nos termes pour travailler.
ensemble. Ils ont signé le contrat et se sont rapidement installés dans notre bureau. Ils ont apporté leurs
des machines avec Windows (hé, nous étions un magasin de Mac) et dès le début, ils ont essayé
recréer leur culture au sein de notre étude. Ils ont créé tous les obstacles possibles pour
éviter que nous nous réunissions avec ses clients. Ils ont limité notre accès aux serveurs de
mise en œuvre et nous ont essentiellement empêchés de faire le travail que nous avions convenu
dans le contrat. Huit semaines plus tard, nous levons la main pour arrêter le processus. Nous
nous nous sommes réunis avec le client et lui avons exposé sa préoccupation concernant les façons de travailler que
nous avions convenu qu'ils rencontraient une forte résistance. Le client nous a dit que non
ils ne pouvaient rien y faire. Nous avons terminé les choses soigneusement dans les prochains
deux semaines et nous avons dit au revoir à ce client. Ce n'est pas que nous ne pouvions pas continuer à travailler de
la forme qu'ils voulaient. C'était juste que si nous le faisions, nous risquions de perdre
notre équipe en raison du comportement du client. C'était inacceptable pour nous.

Une note rapide sur les partenaires de

desarrollo y proveedores externos
Dans les relations avec les agences, les équipes de développement de logiciels (que ce soit dans l'agence,
en tant que client ou travaillant comme tiers) sont souvent traités comme des étrangers et, souvent,
s'incorporent à la fin d'une phase de conception. Il est impératif que cela change : les partenaires
pour le développement, ils doivent participer tout au long de la vie du projet, et pas simplement
comme des observateurs passifs. Au lieu de cela, vous devez essayer que le développement de logiciels
Commencez le plus tôt possible. Encore une fois, vous cherchez à créer une collaboration profonde.
et significatif avec toute l'équipe du projet, et pour cela, il doit travailler côte à côte
codo avec les développeurs.

Les fournisseurs de développement de logiciels tiers représentent un grand défi pour

les méthodes Lean UX. Si une partie de votre travail est sous-traitée à un fournisseur externe,
indépendamment de l'emplacement du fournisseur, il est plus probable que le processus Lean
L'UX se rompt. Cela est dû au fait que la relation contractuelle avec ces fournisseurs peut
difficulté à la flexibilité requise par Lean UX.

Lorsque vous travaillez avec des fournisseurs externes, essayez de créer des projets basés sur le temps et
matériaux. Cela vous permettra de créer une relation flexible avec votre partenaire de développement. Le
il faudra pour répondre aux changements qui font partie du processus Lean
UX. Rappelez-vous, vous créez un logiciel pour apprendre et cet apprentissage fera que vos plans
cambien. Planifiez ce changement et structurez vos relations avec les fournisseurs autour
à lui.

En sélectionnant des partenaires, rappelez-vous que de nombreux ateliers de développement sous-traités sont
orientés vers le travail de production et voient le retravail comme un problème plutôt que
comme une opportunité d'apprentissage. Lorsque vous recherchez des partenaires pour le travail Lean UX,
cherchez des équipes prêtes à adopter l'expérimentation et l'itération et qui
comprennent clairement la différence entre la création de prototypes pour apprendre et le
développement pour la production.

Terminant
Travailler en tant que fournisseur de services crée différents défis pour mettre en œuvre le Lean
UX. Rappelez-vous que cela représente à la fois un changement culturel pour votre agence et un changement de
modèle commercial. Cela changera non seulement la façon dont il vend, mais aussi comment et à qui il embauche. C'est
impératif d'établir des attentes avec vos clients que votre façon de travailler défiera
sa notion de travailler avec une agence. Un peu de créativité et une pincée de confiance
ils peuvent rendre le processus de recrutement et d'acquisition plus réussi. Enfin,
un mauvais client est un mauvais client peu importe comment ils travaillent ensemble. Assurer
l'intégrité de votre équipe est votre priorité absolue.
Chapitre 19. Un dernier mot
Après le lancement de la première édition de Lean UX, nous avons été ravis de commencer à
recevoir des commentaires des lecteurs. Après tout, Lean UX consiste à écouter vos
utilisateurs, c'est pourquoi nous voulions comprendre ce que les "utilisateurs" du livre avaient à
dire. Les lecteurs avaient beaucoup à dire (merci !), mais un sujet est ressorti de tous les
et cela a été persistant au fil des ans. Ce sujet concerne
la nécessité de développer des organisations et des processus qui puissent réellement adopter cela
façon de travailler.

Nous savons que travailler avec Lean UX nécessite des changements. Ce que nous n'avons pas bien compris
jusqu'à ce que nous écoutions les lecteurs, les changements se divisent en deux catégories :
changements que les lecteurs peuvent faire eux-mêmes et changements qui exigent que les
des leaders s'impliquent, des leaders qui peut-être ne veulent pas changer, pour une raison quelconque.

Nos lecteurs nous ont dit : Regardez, nous pouvons faire certains types de changements nous-mêmes.
les mêmes, mais pour d'autres changements, nous devons avoir confiance dans le changement des attitudes de notre
leader. Nous devons changer les choses au-delà de nous-mêmes, nous avons besoin de
changer la façon dont fonctionne notre organisation.

Maintenant, changer une organisation, même une petite, est un grand défi. C'est un
défi que la plupart des designers et des gens de produits ont peu de formation
ou expérience à essayer de mettre en œuvre. Même les personnes expérimentées dans le domaine
du développement organisationnel savent que changer d'organisation est difficile. Alors
cela peut être écrasant. Et c'est ce que nous entendons de nos lecteurs. Ils voulaient
savoir comment changer et ne savaient pas par où commencer. Ils voulaient de l'aide.

C'est une sorte de gêne, n'est-ce pas ?

Eh bien, écoute : l'objectif de ce chapitre n'est pas de te faire sentir désespéré. Nous croyons
fermement que les personnes, les équipes et les entreprises peuvent changer. De plus,
nous pensons que vous pouvez utiliser Lean UX pour vous aider à apporter ces changements. En plus de
aider les équipes à apprendre le Lean UX, nous avons passé des années depuis sa sortie
première édition travaillant sur ce type de problèmes de transformation, et nous avons vu
de première main que le changement est possible.

Maintenant, les pourquoi, les comment et les où de la transformation organisationnelle sont

au-delà de la portée de ce livre, mais nous voulons vous offrir un point de départ.

Le produit qui fait le produit

Dans les mots de notre ami Barry O'Reilly, une organisation de développement de
Les produits sont "le produit qui fabrique le produit". En d'autres termes, cela peut aborder le
développement organisationnel en utilisant beaucoup des mêmes outils qu'il utilise pour
le développement de produits. Et nous croyons fermement qu'il peut utiliser les méthodes Lean
UX au service du développement organisationnel.
¿Qué cambio quieres hacer en tu organización? ¿Puede describir el cambio en términos
du résultat que vous recherchez ? Peut-être souhaitez-vous que la recherche soit plus collaborative. Votre
le résultat pourrait être : dans de futurs projets de recherche, assurez-vous que chaque
membre de l'équipe participe à au moins une session d'entretien direct avec le
client.O Ou peut-être que vous souhaitez changer la manière dont le travail est attribué à votre équipe. Votre
le résultat pourrait être : au cours du prochain trimestre, la moitié des épopées dans lesquelles
les travaux seront définis par un résultat de l'utilisateur plutôt que par une liste de
fonctions.

Devine quoi : tu utilises Lean UX ! Maintenant, comment vas-tu faire cela ?

changements ? Eh bien, il voudra essayer une série d'expériences jusqu'à ce qu'il trouve la manière
correcte d'atteindre son résultat. Pensez à ces expériences comme à un processus minimum
viable.

Donc, même s'il se peut que je n'aie pas l'autorité pour changer complètement la
forme dans laquelle fonctionne votre organisation, rien ne l'empêche de recruter un petit
groupe de collaborateurs prêts à utiliser les outils de Lean UX pour commencer à
créer l'organisation que vous souhaitez. Vous devrez commencer à concevoir de nouvelles choses (comme
processus de travail) pour de nouvelles personnes (parties prenantes, pairs, collaborateurs), mais
tu peux le faire, n'est-ce pas ? Oui, tu peux le faire.

Estamos muy contentos de ver a tantos equipos adoptar estos métodos a lo largo de los
des années, et nous sommes sûrs que vous pouvez également le faire. Et, comme toujours, nous sommes
éveillés de savoir de vous. Bonne chance dans votre voyage Lean UX et dites-nous comment vous
Va !

Comme nous l'avons dit au début de ce livre : restez en contact et partagez vos
pensé[Link] nous
enjeff@[Link] y josh@[Link] . Nous espérons toujours avoir de vos nouvelles
vous.