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

Vous lancez un produit ? Un nouveau service ? Vous entamez une refonte de votre solution digitale ou de votre site web ? Que ce soit dans le digital ou tout autre domaine, il sera conçu et utilisé par des humains. Ce sont ces humains que nous appelons vulgairement les "utilisateurs". Ces utilisateurs sont ceux qui vont utiliser le produit au quotidien, nous aider à le concevoir et le faire évoluer.

Pourquoi intégrer vos utilisateurs dans votre projet ? 

Lorsque l'on conçoit une expérience utilisateur (ce que l'on appelle l'UX design), notre objectif est de rendre la solution utilisable, simple, agréable, ainsi que de donner toutes les possibilités aux utilisateurs de réaliser leurs actions facilement et rapidement, en prenant en compte leurs habitudes, comportement et besoins. 

Dans une conception centrée sur l'utilisateur, il semble donc évident que la première étape est de connaitre et comprendre les humains qui utiliseront la solution 👋 . C'est le point de départ, la base et l'essentiel ! 

"Je préfère mettre du budget dans mes maquettes que dans cette recherche", "Mais on sait déjà ce qu'ils veulent", "Nos utilisateurs on les connaît", "Après tout ils prendront ce qu'on leur donne car on ne l'a pas pensé comme ça", "On a l'habitude et puis ils sont comme vous et moi"

Vous avez déjà entendu ou prononcé ces phrases ? Notre vision et expérience nous obligent à vous dire que c'est faux ! Sans prétention aucune, je vous assure que vous ne savez pas tout et que vous avez encore beaucoup à apprendre des gens qui utilisent votre solution.

La recherche utilisateur - user research - s'inscrit dans une phase de conception permettant de découvrir qui sont nos utilisateurs en les identifiant, en observant leurs comportements, pensées et leurs émotions : Pourquoi tel ou tel choix ? Pourquoi telle ou telle réaction ? Quelles sont vos habitudes ? Que craignez-vous ? Quels sont vos besoins ? Dites nous vos attentes précises ? Voici de petits exemples des axes de recherche à explorer 🙂

Dès le début ! (Le tout début même). Il faut intégrer les utilisateurs le plus tôt possible dans le cycle de conception, ce sont eux qui ont les réponses à vos questions & hypothèses, ce sont eux qui sont confrontés aux problèmes. Ils représentent le coeur même du projet. Nous allons concevoir pour eux, et encore mieux, nous allons concevoir avec eux 🤝

Sachez qu'il n'est jamais trop tard pour intégrer vos utilisateurs à votre projet ! Nous vous recommandons de le faire dès le début mais si c'est trop tard, pensez-y pour la suite du projet qui sera de toute manière amené à évoluer avec ces derniers.

Vous vous demandez surement comment connaitre ses utilisateurs et les intégrer au projet ? Je vais vous parler de 3 méthodes de recherche UX indispensables et complémentaires, la base dans le processus de conception centré sur l'utilisateur. 

🎙 Les entretiens utilisateurs. Nous nous entretenons avec les utilisateurs pour échanger sur des thématiques en lien avec le projet, sur leurs habitudes, craintes et potentiels problèmes rencontrés lors d'une précédente interaction. Ces entretiens qualitatifs permettent de générer de précieuses données sur les motivations, objectifs, craintes, besoins & désirs. Nous utilisons ensuite ces données pour dresser le profil des groupes d'utilisateurs, que nous appelons personas.



👀 Les observations. Les observations sont complémentaires aux entretiens utilisateurs. On apprend facilement lorsque l'on interview une personne, mais quoi de mieux que de l'observer en interaction avec la solution, dans son contexte d'utilisation naturel ? L'observation permet d'identifier ce que pensent les gens, ce qu'ils disent, ce qu'ils voient et ce qu'ils font réellement. Nous allons donc observer des utilisateurs en interaction avec la solution, les laisser en autonomie et relever les moments positifs et négatifs dans leurs expériences.



🧪 Les tests utilisateurs. Ces tests sont primordiaux. Il nous arrive souvent de voir et de lire des articles impliquant les tests utilisateurs en fin de projet. Oui c'est vrai, mais nous vous recommandons de tester la solution avec de réels utilisateurs dès le début ! Chez Uxer, lorsque nous le jugeons nécessaire, nous proposons le test utilisateur au début du projet. C'est un excellent complément des deux méthodes précédentes. L'objectif de réussite d'un projet, d'un point de vue client, est souvent de "faire mieux", d'améliorer les conversions, de fidéliser. Pour cela il faut savoir où sont les problèmes actuels et la cause de ces problèmes. Lorsqu'une solution est déjà existante, nous la mettons donc entre les mains de vos utilisateurs afin de les faire tester ! Ces derniers réalisent des scénarios permettant de valider ou non nos hypothèses et nous permettre de prendre des décisions éclairées.

Et si on n'a ni le temps ni le budget nécessaire ? 

La stratégie de conception centrée sur l'utilisateur est établie sur mesure. Elle répond à vos besoins dans le cadre ou elle intègre les réels besoins et attentes de vos utilisateurs et donc permet de créer une expérience globale positive. Il existe aujourd'hui de nombreuses façons de réaliser des entretiens, observations et tests utilisateurs, en fonction des contraintes temporelles, budgétaires et matérielles.

Gardez en tête qu'il vaut mieux réaliser cette recherche en l'adaptant avec les moyens que vous avez plutôt que de ne rien réaliser du tout. Il est d'ailleurs tout à fait possible de récolter certaines données et de les formaliser avec des hypothèses établies au préalable par les équipes. Il est certain que le résultat ne sera pas le plus optimal mais qu'il sera quand même une bonne base, amenée à évoluer tout au long du projet via de nombreux apprentissages. Si vous avez une certaine culture du risque, il est donc tout à fait possible d'avancer avec plus d'incertitude. Sachez que si vouliez être accompagné par Uxer, nous nous adaptons à vos contraintes et vous aidons à rester le plus qualitatif possible.

À quels risques je m'expose si je ne réalise pas de recherche utilisateur ?

Les risques sont nombreux, et non sans conséquence (😱)! Le premier qui me semble être le plus important, est celui de véhiculer une mauvaise expérience. Aujourd'hui les exigences sont de plus en plus nombreuses dans le digital : temps de chargement trop longs, informations peu explicites, architecture trop compliquée.. il existe des dizaines de raisons pour un utilisateur de vivre une mauvaise expérience. Cette dernière entraine fatalement une baisse du nombre d'utilisateurs, utilisateurs qui auraient pu devenir fidèles. Il y aurait donc 2 perdants : l'utilisateur et le client. La suite vous la connaissez, du budget investit dans un produit final qui ne correspond pas - on ne vous le souhaite pas - aux besoins utilisateurs. 

Ces phases de recherche sont souvent longues. Elles demandent un certain temps de préparation, passation puis d'analyse et formalisation sous forme de livrables à partager à toutes les parties prenantes. 

Vous pouvez penser qu'il s'agit d'une perte de temps et qu'il est possible de s'en passer. Mais notre constat sur le terrain est très souvent inverse à ces croyances, car le gain d'une démarche centrée sur les utilisateurs se retrouve logiquement sur le budget et le résultat final de votre produit. En lien direct avec sa pertinence et sa capacité à répondre aux attentes des utilisateurs et ainsi à améliorer le rapport entre l'investissement financier et la valeur d'usage du produit conçu. 🙂

Pourquoi intégrer les utilisateurs finaux le plus tôt possible dans la conception de l'expérience utilisateur ?

Bien que souvent négligée, la recherche utilisateur reste essentielle dans la conception d'une expérience utilisateur. Connaître et surtout comprendre nos utilisateurs, mais aussi les impliquer dans la conception, il s'agit de la base dans une conception centrée sur l'utilisateur.  

La recherche utilisateur par Uxer - Blog Uxer 

Pourquoi intégrer nos utilisateurs, on les connaît et on sait ce qu'ils veulent !

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 ? 🤨

Design, code & vied’une agence bordelaise