On risque de vous en apprendre une bonne, mais la protection de notre environnement est aujourd'hui un enjeu planétaire.  Nous aimerions que tous se mettent à agir, sans vraiment savoir sur quoi et pour quels impacts ? Si la sensibilisation se généralise sur ces sujets, le passage à l'action l'est beaucoup moins, car il semble hors de notre portée. Bien que ce soit en partie vrai, il semble toutefois possible d'effectuer une multitude de petites actions, ayant des impacts forts, si elles se généralisent au plus grand nombre.

Alexandre est venu nous voir avec cette conviction, déterminé à créer une application au service de cet enjeu. Son objectif ? Modifier les comportements en agissant sur les habitudes pour encourager un passage à l'action sur le plan écologique, tout ça de manière pratique et ludique.

Alexandre est Lauréat Frenchtech, son idée a donc été retenue et lui a permis d'obtenir un financement pour aller un peu plus loin et réfléchir, concevoir et tester son concept sur un maximum de personnes. Il avait une idée précise sur le fond de l'application, beaucoup moins sur la forme et comment rassembler ses idées, les adapter, les lier entre elles, les concevoir et les tester.

Protos-personas et parcours utilisateurs en main, Alexandre nous a donc confié cette mission afin que nous puissions l'accompagner sur ce projet passionnant. Le contexte du projet, notre volonté d'engagement, le niveau de réflexion ainsi que les grosses contraintes temporelles et budgétaires nous ont orientés vers une solution UX plus qu'adaptée : le Design Sprint.

❓ Le Design Sprint, Quésaco ? c'est une méthodologie novatrice popularisée par Jake Knapp, John Zeratsky et Braden Kowitz au sein de Google Ventures et aujourd'hui utilisée dans de nombreuses entreprises ! Merci les gars 💪

Le design sprint propose plusieurs avantages :

La possibilité de définir ensemble la problématique à résoudre,

Tester le potentiel du produit et obtenir du feedback utilisateur sans investir dans le code,

Booster la créativité et l'intelligence collective ainsi que limiter les risques liés au projet,

Pouvoir rapidement pivoter en cas d'écart avec le marché et les besoins utilisateurs.

Nous savions que l'enthousiasme d'Alexandre, son niveau de maturité et d'avancement, notre investissement, et l'intelligence collective de toute l'équipe mobilisée, nous permettraient d'obtenir en 3 jours des réponses pertinentes aux problématiques déjà identifiées du projet. D'en avoir une vision plus claire, en créant une base de départ solide pour continuer de développer le projet. Ou pas.

Le début du projet est boosté par la présentation des expertises de l'équipe, et leurs complémentarités, et une session de questions-réponses amenant sur la définition d'un objectif à long terme qui orientera toute la suite du projet. Après de longues minutes d'échanges sur les visions à moyen et long terme, l'objectif est né :

"Nous voulons identifier les freins et comprendre les conditions de motivation nécessaires pour initier la modification des comportements & des habitudes sur le sujet de la transition écologique par le développement d'un parcours numérique et ludique."

Bien évidemment c'est beau sur le papier mais soyons raisonnable, il est impossible de répondre à une dizaine de questions en 3 jours. Nous avons donc déterminé les questions précises auxquelles le sprint devait répondre.

L'application va-t-elle permettre de changer les comportements ?

Comment accompagner les utilisateurs dans la mise en application de leurs actions virtuelles dans la vie réelle ?

La première impression va-t-elle être claire/positive et motivante ?

Les utilisateurs vont-ils se sentir valorisés/engagés ?

Les utilisateurs vont-ils ressentir leur impact concret dans le monde réel ?

Quelles hypothèses pour quels parcours ?

L'objectif du jour 1 visait dans un premier temps à créer la User Journey des personas. Avec de légères incertitudes qui laissent place à beaucoup d'hypothèses ! 3 jours c'est court, nous avons donc utilisé les livrables très qualitatifs déjà fournis par Alexandre : les personas et les parcours utilisateurs.

Connaître nos utilisateurs nous a permis de facilement identifier les différents profils, parcours et atteintes d'objectifs. Nous avons également opté pour la création d'une feuille de route, donnant naissance à de nouvelles idées, que ce soit sur le périmètre de la solution ou même sur le périmètre fonctionnel.

Face à nos utilisateurs et leurs parcours grossièrement formalisés sur la feuille de route, nous avions de nombreuses questions en suspens ! Nous avons donc fait un tour de table relatant les étapes de la feuille de route, en posant des questions à chacun. Pendant ce temps, nous notions également les réponses en les transformant en questions sous la forme "Comment pourrions-nous..."

De nombreuses questions ont été soulevées, nous les avons catégorisées selon des problématiques et les objectifs suivants : favoriser le passage à l'action, divers, rendre visible et valoriser.

Nous n'avions pas de réponse claire à apporter à ces nombreuses questions. Le temps étant compté, le vote a été la solution qui nous a permis de sélectionner les HMW prioritaires.

Comment pourrions-nous valoriser l'action positive auprès des autres utilisateurs ?

Comment pourrions-nous expliquer les initiatives ?

Comment pourrions-nous guider l'utilisateur dans le processus de transition ?

Comment pourrions-nous nous assurer que l'utilisateur se sente flatté par son initiative et son impact et se sente valorisé ?

Comment pourrions-nous traduire les impacts au travers d'une histoire et expliquer la suite ?

Comment pourrions-nous faire pour que l'application ait un impact concret dans la vie "réelle" et ce ne soit pas seulement perçu comme un jeu ou une application ?

Les grandes questions sont posées ! Mais à quels moments vont-elles impacter le projet et le parcours de l'utilisateur ?

Nous avons positionné les HMW sélectionnés sur chaque étape où elles rentrent en interaction et sont susceptibles de changer l'expérience des utilisateurs. La magie opérante, nous avons pu ainsi identifier le parcours prioritaire ou nous allions consacrer tout le reste de notre temps.

L'intelligence collective permet de libérer l'esprit et d'aider à la créativité pour arriver à des résultats souvent étonnants mêlant l'intelligence, la logique et la créativité de chacun. Pour répondre aux HMW, quoi de mieux que de les formaliser selon la vision de chacun ? Nous avons donc réalisé un atelier de co-conception, le CRAZY 8.  Nous avions une multitude d'écrans et de nombreuses idées pour le lendemain matin.

Cette journée commence par la prise de connaissance des croquis de chacun. Prendre les meilleures idées, s'inspirer des autres pour ensuite redéfinir sa propre vision ! Avec un nouvel objectif :  Réduire le nombre d'écrans de 8 à 3 ! Ce long atelier créatif a débouché sur une présentation chronométrée des idées. S'en est suivie une petite phase de critique afin que chacun donne son point de vue, pour ou contre, sur les idées des autres (bien évidemment dans un échange constructif et objectif).

Et que fait-on de ces petits brouillons ? Il y avait 60 croquis, représentant des dizaines d'idées ! Un vote, assez personnel, a été effectué et nous a permis de retenir les idées les plus intéressantes à retenir, à creuser ou à garder en tête.

Avant de passer à la conception de l'interface (le design UI), nous avons, tels de vrais réalisateurs inspirés, créé le storyboard du prototype afin de donner du sens au parcours que nous devions représenter, dans l'objectif d'apporter des réponses à nos questions.

Pas besoin d'être un artiste ! Le but est que tout le monde soit finalement d'accord et comprenne. Cette étape est déterminante, car elle précède la concrétisation de tout le travail accompli en une interface et de futurs tests utilisateurs. Nous avons limité ce storyboard à 15 écrans, gros challenge quand on sait qu'il ne nous restait qu'une après-midi pour tout réaliser et le lendemain pour réaliser les tests !

Le prototype a été effectué sur un outil de conception UI, de manière interactive, permettant de pouvoir passer facilement d'écran en écran et permettant de tester le prototype en conditions quasi réelles.

Après-midi très intense, surtout pour notre designer, Manu, qui a dû sortir 15 écrans en un temps très très limité ! Concentration et rigueur au programme. C'est tout de même stimulant de voir cette idée prendre vie. Et pendant ce temps, le reste de l'équipe réalise les scénarios des tests utilisateurs prévus le lendemain.

La réalisation de la maquette a pris plus de temps que prévu ! (En réalité on s'en doutait). La nuit porte conseil et également son lot d'imagination. Finir les derniers écrans, amener plus de détails sur certains, l'ensemble des prototypes interactifs était prêt en milieu de matinée !

La structure des tests a beaucoup d'importance ! C'est la seule occasion du sprint pour apprendre de tout ce qui a été produit et répondre aux grandes interrogations du début de sprint. On valide l'idée ? On y apporte des évolutions ? On pivote et on s'adapte ? On jette tout ?

C'était le moment de tout découvrir ! Pour des questions de temps et de logistique, nous avons organisé des tests à distance sur un outil dédié en ligne.

Vous avez une idée de projet, c'est bien. Mais comment répondre à des questions complexes et apporter une solution plus ergonomique à vos utilisateurs ?

Comment répondre à des questions complexes et précises ? Pour développer une application web plus en phase avec vos utilisateurs. Le sprint design est l'une des méthodes UX utilisées par Uxer pour accompagner les projets web confiés.

Un sprint design par Uxer, ça donne quoi ? 🤨

Les projets digitaux ne se passent pas toujours comme prévu ou comme espéré. Ils peuvent être semés d'embûches et difficiles à gérer si des erreurs sont commises, notamment en début de projet. Et nous en savons quelque chose ! Pas parce que nous enchaînons les erreurs, mais parce que lorsque que l'on travaille sur un projet de l'idée à son développement, nous devons anticiper chaque potentiel problème.

Il nous paraît donc intéressant de vous partager l'une de nos expériences projet, qui a connu un certain nombre d'erreurs et de rebondissements inattendus. Cela pourra vous permettre, vous, lecteurs avertis, d'éviter de faire les mêmes erreurs pour votre projet, et pour nous, de faire en quelque sorte une catharsis et de nous améliorer.

Ah oui, avant de commencer : ne vous en faites pas, le projet se porte bien et s'est finalement terminé sans trop d'encombres. 🙏

En 2018, nous avons commencé à concevoir une application destinée à la gestion de maintenances et des dépannages sur des systèmes de génie climatique. Pendant 2 ans, nous avons enchaîné les phases de conception, de design et de développement, un lot après l'autre et une fonctionnalité après une autre fonctionnalité. En ce début de novembre 2020, le projet voit enfin le jour, et commence à être utilisé. Hip hip hip !

Attendez, pas si vite. L'application est bel et bien disponible et opérationnelle, mais nous nous sommes aussi rendus compte qu'elle n'est finalement pas complètement adaptée à la réalité du terrain et des usages de ses utilisateurs, et que des ajustements sont encore nécessaires.

"Mais qu'est-ce que vous avez fait pendant 2 ans ?! Personne ne s'est rendu compte plus tôt que ça n'allait pas ? Vous êtes pourtant extrêmement professionnels, un phare dans la nuit des agences digitales !"

Il est vrai. Mais la réponse est toujours plus compliquée qu'il n'y paraît. Laissez-nous vous expliquer modestement et en toute transparence les raisons qui ont amené à ce constat.

Au début, tout allait bien. En y repensant, si ça ne va pas au début, c'est mauvais signe. Toujours est-il que ça allait bien, très bien même ! La prise de besoin était claire, synthétisée dans un cahier des charges rédigé par notre product owner et le responsable des équipes de notre client. Plusieurs réunions de cadrages ont été réalisées pour organiser, planifier et gérer les détails de départ du projet.

Les besoins exprimés étaient claires : "Mes techniciens doivent pouvoir ajouter des équipements !", "L'application doit pouvoir s'utiliser hors connexion", "Je veux que l'application place automatiquement des maintenances", et bien d'autres fonctionnalités et contraintes établies clairement en amont de la conception et du développement web. Tout. Allait. Bien. 🙃

En fait, non : loin de là. Mais nous ne le savions pas encore. En effet, si tout paraissait se dérouler comme on peut s'y attendre pour un projet de ce type, il y avait un grand absent de ce début de conception. Une idée ? Voilà un indice : ils utilisent l'application.

Ça peut paraître bête, mais c'est finalement ce qui se passe dans une grande majorité des projets digitaux qui sont réalisés aujourd'hui dans le monde. On crée avec et surtout pour un chef d'équipe, un responsable marketing, un directeur, une cible marketing. Mais trop rarement pour les utilisateurs finaux et réels de l'application. Oups.

Comment concevoir une application sans leur demander ce dont ils ont besoin, sans valider ensuite nos hypothèses, sans regarder comment ils travaillent et sans comprendre pourquoi et comment ça pourrait les aider ? Nous nous demandons encore comment nous avons pu commencer à travailler en passant à côté de ces questions pourtant essentielles. Nous avons bien tenté de pousser à notre client une étude utilisateur en début de projet, mais n'avons vraisemblablement pas été assez bons pour le convaincre de l'importance capitale qu'elle représente. Ce fut notre première erreur.

La recherche utilisateur pour comprendre les besoins 🙋‍♀️

Vous l'avez donc compris, l'erreur est de ne pas avoir réalisé de recherche et de tests utilisateur afin de connaître et comprendre les utilisateurs finaux de la solution. C'est finalement aussi simple que ça.

Ce n'est pourtant pas compliqué à mettre en place ! Nous aurions pu commencer par nous entretenir avec eux, écouter leurs besoins, leurs attentes, leurs frustrations actuelles et l'apport que nous aurions pu apporter face à la demande du client. Les entretiens permettent aussi de découvrir de nouveaux éléments et questionnements, insoupçonnés, qui peuvent nous permettre d'en apprendre plus et de toujours tendre vers une conception "parfaite".

L'observation est également très importante pour comprendre des besoins et mécaniques de fonctionnements des utilisateurs. Nous aurions dû aller sur le terrain, autant avec les techniciens qu'avec les administrateurs pour comprendre comment ils fonctionnent aujourd'hui réellement et non à travers un cahier des charges de plusieurs dizaines de pages. Après tout, nous ne sommes pas des techniciens experts en génie climatique, mais de modestes artisans du web. Un grand homme a dit un jour : “L’observation recueille les faits ; la réflexion les combine ; l’expérience vérifie le résultat de la combinaison”. Et croyez-nous, avec du recul : c'est vraiment ça (on y croit vraiment, et on n'a pas attendu de taper "Citation observation" sur Google pour s'en rendre compte 👌).

Il aurait également été intéressant de formaliser toutes ces données sous forme d'expérience map afin d'identifier de nouveaux points de friction ou les anticiper et y trouver des opportunités d'améliorations. Il faut bien comprendre que la conception centrée sur l'utilisateur peut-être longue, et qu'elle intervient à chaque étape de la conception, mais qu'elle permet de concevoir utilement et de répondre à de réels besoins.

Pas de place au bullshit. C'est certain, nous ne répèterons plus la même erreur, celle de foncer tête baissée en ayant pour seul interlocuteur un non-utilisateur final de la solution, quelqu'un qui ne sera finalement jamais en interaction avec le système, malgré toute son expérience et sa bonne volonté.

Je poursuis. Une fois notre mauvais travail de préparation effectué, une autoroute se traçait dans nos esprits. Il ne nous restait plus qu'à abattre les nombreuses vues de l'application dans notre logiciel de design d'interface favoris, et à les faire valider au plus vite pour passer au développement et voir le résultat de notre dur labeur.

Deux erreurs ici. La première, c'est d'avoir voulu tout faire d'un coup. Une application de cette envergure pouvait sembler très complexe à réaliser si on réfléchit d'un point de vue global, et elle l'était. Une manière simple et efficace d'aborder le problème aurait été de découper cette application en plusieurs lots plus petits et plus faciles à appréhender. Mieux : de réfléchir au socle de l'application, avec quelle(s) fonctionnalité(s) l'application ne peut pas fonctionner ? Et à partir de cette réflexion, de travailler sur un MVP : Minimum Viable Product. Une version simplifiée de l'application, permettant d'avoir une base que l'on va pouvoir par la suite faire évoluer. Mais c'est un concept que nous aborderons plus en détail une autre fois. 🦦

La seconde erreur a été de ne pas présenter notre travail aux techniciens et administrateurs, futurs utilisateurs de l'application. Certes, un prototype interactif très détaillé a été réalisé, mais nous ne l'avons présenté qu'au chef d'équipe. Nous avons évidemment pu obtenir des retours de ces présentations, et pu faire des ajustements pertinents, mais ce n'est rien par rapport à ce que l'on aurait dû et pu avoir de la part des équipes sur le terrain. Tout ce que nous souhaitions, c'est entendre ces doux mots : "C'est validé !"

Ces deux mots prononcés par un client déclenchent souvent un branle-bas de combat général. On pourrait presque entendre le chef de projet crier : "Développeeeeeeeeez !" dans l'open space, et les développeurs se mettre en rang sur leurs machines et taper frénétiquement sur leurs claviers pour pousser des fonctionnalités les unes après les autres.

D'une manière générale : même si vous pensez avoir pensé une application à toute épreuve, pensez à nouveau : il est presque toujours bénéfique de faire tester un prototype quand on est encore en phase de conception et que tout peut encore changer de manière assez flexible. Nous disposons aujourd'hui de tellement d'outils permettant de créer un prototype interactif à partir de simples maquettes qu'il serait trop bête de se lancer dans des semaines de développement onéreuses, sans avoir fait tester le résultat de son travail préliminaire. Et ne nous forcez pas à ressortir une citation !

Même si nous vous l'avons ici présenté comme une série d'erreurs, ce projet n'est pas un échec. D'abord parce qu'il a vu le jour, et qu'il fonctionne aujourd'hui parfaitement (Yayy ! 👏). Mais surtout parce qu'il a été une vraie source d'expérience et de remise en question, pour le mieux.

Si nous accordons autant d'importance à vos utilisateurs, ce n'est pas pour surfer sur des termes à la mode et essayer de faire comme tout le monde. C'est parce qu'il n'y a rien de plus frustrant que de se rendre compte, après beaucoup d'efforts, que le résultat n'est pas à la hauteur de ce qu'il aurait pu être et que cela aurait pu être évité en travaillant pas nécessairement plus, mais plus intelligemment et surtout plus humainement.

Nous espérons que cette (vraie) histoire vous a plu. Peut-être vous êtes-vous retrouvé ou identifié dans ce récit, que ce soit d'un côté comme de l'autre. Si c'est le cas, n'hésitez pas à nous envoyer un message, nous adorerions écouter vos déboires digitaux. ✌️

Pas entièrement, mais c’est toujours dommage. On vous explique ce qu’on a appris de tout ça !

L'histoire de nos péripéties lors d'un de nos projets

Design, code & vied’une agence bordelaise