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

Quand la pause déjeuner arrive, dans beaucoup d'entreprises, chacun part souvent de son côté, réchauffe sa gamelle, va manger à l'extérieur, va faire du shopping ou encore traîne devant son écran sur Facebook, Netflix ou Youtube. Chez Uxer, on essaye de changer ça ! 🤜🤛

L'idée étant que ce moment de la journée ne soit pas qu'une simple période où on mange rapidement avant de se remettre au travail. Ici, on prend le temps de : se reposer avec une petite sieste (surtout Manu, tout le temps 😴) ou simplement de discuter ensemble (attention à ne pas lancer Boris sur certains sujets, on vous aura prévenu). Mais plus spécialement, nous avons instauré depuis maintenant 1 an une sorte de rendez-vous quotidien sacré (et je pèse mes mots !) : la partie de jeu de société du midi 🎲.

Et ce petit rituel apporte son lot de bénéfices ! Il permet de se couper du travail, échanger et partager un moment de complicité et de jeu avec ses collègues, permet de libérer la pression, de resserrer les liens de l'équipe, et de revenir avec le plein d'énergie pour l'après-midi. Et il existe tellement de jeux différents qu'il y en a pour tous les goûts et tous les états d'esprit : aventure, rapidité, WTF, stratégie, simple, complexe... Ce qui permet de varier les plaisirs et que tout le monde ait envie chaque jour de participer à cet instant privilégié : parce que c'est le but avant tout, on ne force personne (sauf Manu, qui préfère souvent dormir et qu'il faut motiver !).

Mais il y a tout de même un jeu qui revient très souvent chez nous. Un jeu auquel certains vouent un véritable culte, comme Guillaume, qui a acheté l'édition collector et qui exhibe la boite comme objet de décoration dans les bureaux. Et ce jeu, c'est Bang. Un shérif, son adjoint, des hors-la-loi, des pistolets : vous voyez le topo. Stratégie, mensonges et coopération (ou pas) vous permettront de gagner la partie, ou de perdre lamentablement. En plus, ça permet de révéler les traits de personnalité de tout le monde et de mieux se connaître (pour le meilleur et pour le pire).

Petit tour d'horizon des personnalités plus ou moins appréciables de l'équipe.

Boris, le grand stratège 🤴 : prêt à tout pour gagner, il arrive souvent à ses fins. Mieux vaut être avec lui que contre lui.

Manu, le comédien 🎭 : menteur dans l'âme, adepte du jeu d'acteur et de la poker face, vous ne connaitrez son rôle et sa stratégie qu'à la fin de la partie.

Benoit, le kamikaze 🧨 : efficace, il gagne ou perd très rapidement (durée de vie moyenne : 4 minutes).

Guillaume, le lobbyiste 🔫 : addict du Bang, ne lui dîtes surtout pas qu'il ne peut pas jouer à midi ou qu'on change de jeu, il le vivra très mal.

Romain, le motivé 🧩 : toujours le premier à motiver les troupes et à installer le plateau de jeu, il veut jouer, jouer et encore jouer.

Claire, la tête en l'air 🤷‍♀️ : ne connaît toujours qu'une version approximative des règles, même après des mois de jeu

Virginia, la dresseuse 🐶 : passe autant de temps à jouer au jeu qu'à jouer avec Fryda, chien et mascotte de l'agence

Laure, la force tranquille 🌊 : méfiez-vous de l'eau qui dort, elle saura dégainer au bon moment.

Et c'est une habitude qui prend bien, puisque certains clients se mettent même à jouer avec nous quand ils sont de passage, ou à nous offrir de nouveaux jeux (Merci Alexandre !). Bref, on vous encourage à essayer ! Et vous, à quoi vous jouez ?

Et vous, comment passez-vous votre pause déjeuner ?

Comment l'équipe Uxer s'occupe-t-elle à la pause déjeuner et comment votre équipe pourrait en bénéficier !

Blog Uxer - Nous on s'entretue le midi, et vous ?

Dans l'ancien temps - comprendre, il y a 10 ou 15 ans - la gestion de projet était bien différente des méthodes que l'on peut utiliser aujourd'hui. Le personnage principal de cette histoire : le chef de projet, homme (ou femme) à tout faire, garant du bon déroulement des missions, du respect du planning et de la communication entre l'agence et le(s) client(s).

Souvent enseveli sous une montagne d'emails, il n'en sortait généralement que pour faire face aux menaces d'un designer mécontent que son précieux bouton ait été déplacé d'un pixel par rapport à sa maquette, d'un développeur web fatigué de ne pas se faire comprendre de ses semblables. Et pour essuyer la goutte qui se met à couler sur son front lorsque les clients souhaitent modifier tout le périmètre projet, pour le lendemain.

Et c'était bien dommage, parce que la gestion de projet est bien LA prestation qui revient dans chaque projet, et qui peut faire la différence entre un échec misérable ou une glorieuse réussite. Souvent mécomprises, variant très souvent d'une structure à l'autre, nous allons essayer de vous expliquer comment cette partie de notre travail est gérée chez Uxer.

Pratique agile et méthode SCRUM, quésaco ?

Fini les périodes de projets sur 6 mois, où l'on a l'impression, au début, de rentrer dans un long tunnel au bout duquel on croit apercevoir une minuscule lumière, qui se rapproche petit à petit au fur et à mesure que les semaines passent, tout ça pour espérer trouver à la sortie ce qu'on était parti chercher plusieurs mois plus tôt, si l'on ne l'a pas oublié en chemin.

Le but de la pratique agile en résumé : c'est d'être souple, flexible et rapidement opérationnel. Nous nous organisons donc autour de la méthode SCRUM - qui est une pratique agile parmi les plus utilisée - avec des périodes de production de 15 jours, aussi appelées des Sprints. Cela nous permet de définir, toutes les deux semaines, une série d'objectifs clairs à atteindre, et un certains nombre de livrables à réaliser.

Cela permet, pour nous, de se concentrer sur des missions précises et bien identifiées et de ne pas s'éparpiller. Et, pour le client, de suivre l'avancement du projet étape par étape et d'ajuster certains aspects du projet au fur et à mesure que les lots sont livrés.

Est-ce que vous préférez : être certains de recevoir un billet de 10 € chaque semaine, ou espérer toucher un plus gros chèque tous les 6 mois ? Parce que c'est là tout l'intérêt de la méthode : permettre les ajustements aux bons moments et garder le contrôle sur le projet, afin qu'il ne parte pas dans une spirale inarrêtable qui pourrait aboutir sur un échec total par manque de vision et de retours réguliers sur le terrain.

Excellente question Bobby. La méthode que nous utilisons chez Uxer s'articule autour de différentes étapes :

C'est bien beau de découper un projet sous la forme de sprints de 15 jours. Encore faut-il faire ça intelligemment : les étapes doivent s'enchaîner de manière logique, en prenant en compte les prérequis, la logique et les contraintes de chaque projet et du client. Vous avez besoin d'un prototype pour de nouvelles fonctionnalités qui définira l'avenir tout entier de votre société et peut être de l'humanité tout entière (qui sait ?) ? Nous pouvons anticiper ça, et articuler notre travail pour sortir une version prototype, testable auprès de vos utilisateurs, au bon moment, et sauver l'espèce humaine. De rien.

Planifier les périodes de travail. Check. Faut-il encore que les missions à effectuer pendant chaque sprint soient réalisables. Il ne s'agirait pas de retomber dans nos vieux écueils, de promettre monts et merveilles pour la semaine suivante, tout ça pour se rendre compte que la charge de travail a été "légèrement" sous-estimée. Pour cela, nous passons du temps à découper, étudier et évaluer chacune des missions à venir pour noter leur complexité, et estimer la charge qui va pouvoir être réalisée, de manière réaliste. Et tout le monde met la main à la patte ! Développeurs, designers, illustrateurs. Chacun participe à l'évaluation des missions, car en discuter en équipe permet très souvent de soulever des problématiques qui vont pouvoir être anticipées, d'être plus réaliste face aux missions à réaliser, et de trouver des solutions en mettant à contribution tous les corps de métiers.

Tous les jours, à midi pile, toute l'équipe se regroupe et communique sur ce que chacun a fait la veille, sur les difficultés qu'il rencontre, et sur ce qu'il prévoit ensuite. Le but est ici d'avoir une bonne vision des missions de chacun, et d'identifier d'éventuels points de blocage pour trouver très rapidement une solution. C'est aussi l'occasion de valider les missions déjà effectuées, qui sont systématiquement revues par une deuxième personne.

Que ce soit en gestion de projet, en amour ou en géopolitique : une bonne communication assure 90% de la résolution des problèmes et tout autant de la qualité.

Décidément, Bobby, tes questions visent dans le mille aujourd'hui. Cette méthode est plus que bénéfique pour le client, et un client séduit, grossit la trésorerie.

À l'inverse d'une méthode purement verticale où il faut attendre plusieurs mois pour avoir un aperçu ne serait-ce que de premiers écrans pour se rendre compte que finalement le logo est à l'envers, et que le designer est peut-être daltonien, cette méthode agile permet d'avoir rapidement et régulièrement des livrables pertinents, testables et utilisables directement.

Le client a également une vision en temps réel de l'avancement des tâches, grâce à un accès au backlog du projet (ce sera une leçon pour une prochaine fois), et au fur et à mesure que le projet avance, peut demander à changer les priorités ou à ajuster certaines choses.

Vous l'aurez compris, l'idée générale de cette méthode, que nous pratiquons depuis plus de 3 ans, est de travailler de manière plus humaine et plus logique, tout simplement.

Découvrez le premier article de notre série “Ok, boomer” qui vulgarise les concepts de nos métiers avec ce premier épisode sur notre méthodologie de travail en équipe

On vous explique comment l'agence Uxer organise son équipe et ses projets grâce aux méthodes agile et SCRUM

Blog Uxer - Ok, boomer : la méthode agile & SCRUM

Design, code & vied’une agence bordelaise