Illustration article OKR

Méthode OKR : Le guide pratique

by Faciliation

Des objectifs concrets, inspirants et axés sur l’action

Les OKR, abréviation d’Objectifs et Résultats Clés, constituent un cadre incontournable pour définir, suivre et atteindre les objectifs organisationnels. Leur avantage majeur réside dans leur capacité à offrir une vision claire aux équipes sur leurs priorités et sur la façon de mesurer le succès de leurs initiatives.

Pour des résultats concrets, les objectifs doivent être des énoncés concis, inspirants et engageants. Ils doivent définir des objectifs significatifs, concrets et orientés vers l’action. L’objectif idéal ne se contente pas d’inspirer, il trace également une voie claire.

Des résultats clés : des mesures tangibles pour progresser

Les Résultats Clés sont des indicateurs quantifiables du progrès vers l’objectif. Ils servent de jalons nécessaires pour atteindre l’objectif. Un bon résultat clé est mesurable, que ce soit de manière binaire (oui ou non) ou en pourcentage de progrès de 0 à 100%.

Déroulé d’un atelier OKR efficace

L’atelier, d’une durée d’environ 2 heures, implique de 3 à 10 participants, idéalement représentant ceux qui exécutent et gèrent les objectifs. Il comprend une introduction aux OKR, la co-création d’objectifs et de résultats clés, un vote pour définir les trois principaux OKR, et se conclut par la définition des prochaines étapes.

Exercice 1 : Générer des objectifs

En 10 minutes, les participants génèrent un maximum d’objectifs, mettant l’accent sur la quantité. Les facilitateurs guident les participants avec des exemples, assurant la clarté sur l’objectif de l’exercice.

Exercice 2 : Vote sur les objectifs

Un vote élimine les trois meilleurs objectifs parmi la multitude générée. Chaque participant dispose de trois points de vote, favorisant la sélection d’objectifs clairs, réalistes et bénéfiques.

Exercice 3 : Vote du décideur

Le décideur, responsable de la décision finale, prend en compte le vote de l’équipe, mais peut choisir ultimement des objectifs en fonction de son jugement. La discussion est encouragée, permettant la contribution de l’équipe avant de finaliser les trois principaux objectifs.

Exercice 4 : Générer des résultats clés 

Les participants créent des résultats clés pour les trois principaux objectifs, en mettant l’accent sur la quantité. L’objectif est d’avoir des résultats clés mesurables, spécifiques et ambitieux.

Exercice 5 : Vote sur les résultats clés

Les participants votent sur les principaux résultats clés, en utilisant trois points de vote par personne. Les résultats clés doivent être mesurables, spécifiques et contribuer à la valeur.

Exercice 6 : Deuxième vote du décideur

Le décideur prend la décision finale sur les trois principaux résultats clés par objectif, la discussion est bien sûr toujours encouragée entre les participants.

Exercice 7 : Décider du suivi

L’équipe discute de la fréquence de la revue des OKR pour assurer un succès continu. Un calendrier est établi en tenant compte des besoins et des résultats clés liés au temps.

Conclusion et prochaines Étapes

L’atelier se termine par un rappel à communiquer les OKR au sein de l’équipe et de l’organisation. En suivant ce guide, les équipes peuvent efficacement mettre en œuvre les OKR, favorisant la définition, de mesure et d’accomplissement des objectifs.

Cet article vous a plu ? Vous voulez en savoir plus sur les OKR ou vous souhaitez être formé(e) pour savoir mettre en place ce type d’atelier dans votre entreprise ?

Contactez nous
Vous avez un projet ?
Product Delivery UX

Qu’est-ce que la phase de delivery ?

by Faciliation

La phase opérationnelle d’un projet Agile

L’objectif est d’imaginer et créer les solutions imaginées lors de la phase de découverte. C’est la phase opérationnelle de votre projet qui va donner vie au produit final.

Cette phase vise à produire les livrables suivants : 

  • Une cartographie des parcours utilisateurs, des wireframes fonctionnels et l’User Interface finale basée sur le Design System créé en amont.
  • Un Minimum Viable Product, une version à fort impact utilisateur et business de la solution avec un minimum d’effort (développement). Ce livrable permet de tester rapidement et de valider des hypothèses en minimisant la prise de risques.
  • Un dispositif d’amélioration continue sous la forme d’une Product Map qui s’appuie sur de la donnée et sur l’expérience utilisateur pour aider les équipes à identifier de nouvelles opportunités d’amélioration.

La phase de delivery, ou livraison, est l’une des phases clés du processus de développement de logiciels agile.

C’est la phase où les équipes de développement livrent les fonctionnalités développées aux clients ou utilisateurs finaux. Cette phase est cruciale, car elle permet aux équipes de développement de concrétiser les idées et les conceptions en produits concrets. 

La phase de delivery dans un environnement agile se concentre sur la livraison de fonctionnalités à court terme et incrémentale. Cette approche permet aux équipes de développement de livrer rapidement des fonctionnalités utilisables aux clients et de recevoir des commentaires réguliers. La méthode agile favorise une approche itérative, dans laquelle des fonctionnalités sont livrées à chaque itération ou sprint.

Double Diamant UX Design Paris

Pour faciliter la phase de delivery, les équipes de développement doivent s’assurer qu’elles ont une infrastructure solide pour la gestion de code source, la gestion de versions, la gestion de configuration et le déploiement. Ces outils permettent de gérer efficacement les changements et de livrer rapidement des versions stables.

L’automatisation est également cruciale pour la livraison continue dans un environnement agile. Les outils tels que Jenkins, Ansible et Puppet sont souvent utilisés pour l’automatisation des processus de livraison.

S’assurer de la qualité des livrables.

Lors de la phase de delivery, les équipes de développement doivent aussi s’assurer que les fonctionnalités livrées sont de haute qualité et répondent aux besoins des clients. Des tests de qualité doivent être effectués à chaque itération pour garantir que le produit livré est sans bugs et répond aux normes de qualité. Les tests unitaires, les tests d’intégration et les tests d’acceptation sont habituellement utilisés pour assurer la qualité de la livraison.

Les équipes de développement doivent par ailleurs tenir compte de l’aspect technique de la livraison. Les fonctionnalités livrées doivent être faciles à intégrer dans l’architecture existante et compatibles avec les technologies utilisées par les clients. 

La documentation doit également être fournie pour aider les clients à intégrer les fonctionnalités dans leur environnement. Enfin, les équipes de développement doivent être prêtes à recevoir des commentaires des clients. Les commentaires des clients doivent être considérés comme des opportunités d’amélioration et de croissance pour le produit.

En conclusion

La phase de delivery est une étape essentielle du processus de développement agile. Elle permet aux équipes de développement de livrer des fonctionnalités rapidement et régulièrement tout en assurant une qualité et une compatibilité élevées avec les environnements existants. 

La méthode agile encourage une approche itérative et l’automatisation pour une livraison continue de qualité. En gardant à l’esprit les commentaires des clients, les équipes de développement peuvent s’assurer que le produit livré est adapté aux besoins des clients et continue de s’améliorer au fil du temps.

Vous avez un projet ?
Outils du Design Sprint

Comment se déroule un Design Sprint ?

by Faciliation

Qu’est-ce que le Design Sprint ?

C’est un framework, un process de travail bien séquencé qui permet d’avoir des réponses concrètes sur la viabilité d’un produit/d’une solution imaginée par les équipes projet.
Le but est donc de partir d’une idée, d’un concept et en fin de semaine d’obtenir un prototype testable et mesurable.

Ce process permet de tester et de mesurer une solution en 4 jours grâce à un prototype fonctionnel qui sera testé auprès de vrais utilisateurs.

Leurs retours permettront de valider, ou non, les hypothèses de départ, avoir des réponses rapides aux différentes questions que l’on se pose et de faire les itérations nécessaires avant la mise en production (développement et intégration technique de la solution).

Ce framework permet surtout de poser un cadre de travail pour aider les équipes à mieux réfléchir, co-construire et de s’aligner sur une vision claire du projet.

Une semaine de 4 jours pour valider un concept

Planning du Design Sprint 2.0

Qui sont les participants au Design Sprint ?

Le Décideur : la personne qui aura le dernier mot pour la prise de décision.

Les Experts : tous les autres participants qui vont partager leurs connaissances sur le sujet (Product Owner, Data Analyst, Marketing & Communication, Devops, UX Designer, Business Owner, Sales…).

Le Facilitateur : la personne qui sera en charge d’animer l’atelier, structurer les discussions, mettre en place les différents exercices, surveiller le temps et s’assurer que l’atelier avance vers la bonne direction.

Le Design Sprint peut se dérouler sur site ou à distance si les équipes sont situées dans différents lieux géographiques.

Avant le jour J, il est important d’envoyer aux participants un email avec le détail des activités (déroulé de la semaine, objectifs, attendus et next steps).

La semaine de Design Sprint est intense, mais va permettre d’embarquer les équipes dans une réelle démarche collaborative où tout le monde aura le sentiment de participer activement et de contribuer à l’élaboration d’une solution testable et mesurable.

Comment se déroule la semaine concrètement ?

Jour 1 :

Planning du jour 1 du design sprint 2.0

Le Design Sprint démarre par un entretien/discussion entre les différents experts et le facilitateur sur la problématique a cracker, les problèmes rencontrés par les utilisateurs, les objectifs, challenge, enjeux business…
Pendant cet entretien l’objectif est de capturer en séance les différentes opportunités sous forme de questions HMW (Comment pourrions nous ?) sur des post it qui nous permettront par la suite de mieux réfléchir aux solutions potentielles.
Un système de vote permettra de prioriser les opportunités les plus pertinentes à traiter dans le sprint.
 
Une fois la bonne problématique identifiée, le groupe va définir l’objectif à long terme ( c’est à dire dans 2 ans si tout se passait pour le mieux, quel serait le scénario idéal ? « North Star », quelle serait la vision idéale).
Un système de vote permettra de s’aligner sur la vision du projet et en cas d’égalité, la décision finale reviendra au Décideur.
 
Le groupe va maintenant être un peu plus pessimiste et réfléchir aux différents obstacles qui les empêcheraient d’atteindre cet objectif.
« qu’est ce qui nous empêcherait d’atteindre notre objectif ? ».
Ces idées devront être reformulées sous forme de questions.
 
Ex. Des concurrents déjà très bien implantés sur le marché
 
Question : Pouvons-nous nous créer une solution différenciante et unique qui nous permette de nous démarquer de la concurrence ?
 

Map et Sketching

Vient ensuite l’exercice de cartographie dont l’objectif est d’identifier l’étape clé du parcours qu’il faudra repenser en priorité.
 
Les participants vont maintenant chercher des exemples de solutions, différentes inspirations ailleurs et pas forcément dans le même secteur d’activité pour la réalisation de leurs concepts.
 
Après avoir fait cet exercice de benchmark, les participants vont pouvoir créer un concept avec des idées qu’ils souhaitent voir dans le prototype final grâce à un exercice de sketching papier.
 

Jour 2

Planning du jour 2 du design sprint 2.0
Sur la journée de mardi, l’équipe va surtout se concentrer sur les éléments, concepts, idées à intégrer dans le prototype final.
Il y a à cette étape du sprint toute une série de votes pour les prises de décisions mais encore une fois, ce sera au Décideur de trancher.
Parfois les choix du Décideur peuvent aller à l’encontre du groupe mais n’oubliez pas que la solution finale sera testée auprès de vrais utilisateurs et les résultats des tests permettront de voir concrètement si le concept est viable ou pas.
 
Les participants vont placer leurs votes sur les différents concepts qui ont été élaborés la veille.
Le groupe va pouvoir mieux visualiser les concepts gagnants grâce aux clusters qui vont se former naturellement avec les votes de chaque participant.
Chacun vote à nouveau mais cette fois-ci sur la meilleure idée à développer.
 
Vient ensuite l’étape du storyboarding, ou appelé encore le « User Test Flow » où les participants vont utiliser 6 post it pour illustrer chaque étape clé du parcours idéal. (Liste des 6 actions principales de l’utilisateur).
 
Aperçu du mur de post it comme l’écran ci-dessous :
 
Une autre session de votes permet de sélectionner le parcours qui sera prototypé.

Jour 3 & 4

Planning du jour 3 du design sprint 2.0
Cette journée est dédiée à la réalisation du prototype.
L’objectif est de monter un prototype HD le plus réaliste possible de sorte que les utilisateurs aient l’impression d’interagir avec la vraie interface développée (aussi proche que possible).
 
La journée de prototypage est souvent très intense, c’est pourquoi il faut parfois plusieurs UX Designers pour faire ce travail pour s’assurer que rien ne manque le jour des tests utilisateurs (différents états, micro interactions).
 
Il faudra recruter des utilisateurs et rédiger un protocole de test clair avec les opportunités à tester sur le prototype.
En gardant en tête l’objectif de ces tests, les questions doivent être orientées de manière à confirmer ou infirmer les différentes hypothèses de départ et non d’obtenir une approbation sur la qualité visuelle du prototype.
 

Les résultats du Design Sprint

Après la journée de tests, beaucoup de matières et d’informations seront récoltées qu’il faudra trier puis catégoriser.

Ce travail permettra d’avoir une liste de recommandations / fonctionnalités qui sera présentée aux équipes et qui devra être priorisée en fonction de la valeur et de l’effort (Matrice Impact/Effort).

Cette liste permettra d’alimenter la roadmap et le backlog des équipes avec les différents sujets identifiés.
 
La semaine de Design Sprint s’achève avec les tests utilisateurs.
Les tests se font généralement auprès de 5-8 utilisateurs mais des études montrent qu’avec 3 tests, vous commencerez à observer les mêmes retours d’un utilisateur à un autre.
Après avoir testé la solution auprès de 5 utilisateurs, vous commencez à identifier ce qui a marché ou non ainsi que les hypothèses à revoir ou à affiner.
 
Le protocole de test sera orienté de manière à obtenir des réponses concrètes aux questions que le groupe s’est posé lors du sprint.
Poser des questions ouvertes pour inciter les utilisateurs à s’exprimer fait partie des bonnes pratiques à adopter.
Demander leur avis ou opinion sur ce qu’ils voient, ce qu’ils s’attendent à voir en cliquant sur un bouton par exemple, capturer ce qui n’est pas clair, avoir leur retour d’expérience sur la solution…
 
Il est aussi très important de mettre l’utilisateur à l’aise avant de démarrer l’interview.
L’utilisateur fera de son mieux pour vous faire son meilleur retour d’expérience en s’exprimant librement s’il se sent à l’aise.

Serait-il possible d’obtenir le même résultat sans utiliser le Design Sprint ?

La réponse est oui mais pas aussi rapidement et de façon aussi efficace.
L’élément important à garder en tête avec un Design Sprint, c’est le fait de réunir plusieurs expertises dans une réelle démarche collaborative et d’aligner tout le monde sur une vision commune.
La communication et le partage d’informations est nettement plus efficace et l’implication de tous les participants dans le projet est indéniable.
 
Un Design Sprint permet concrètement aux équipes d’accomplir en 4 jours ce qu’ils feraient en temps normal sur 6 mois. 

Cet article vous a plu ? Vous voulez en savoir plus sur le design sprint ou vous souhaitez être formé(e) pour le mettre en place dans votre entreprise ?

Contactez nous
Vous avez un projet ?
UX_Research

Qu’est-ce que la phase de discovery ?

by Faciliation

Le lancement d’un nouveau produit ou service est très souvent en décalage avec la réalité du marché lorsque les équipes ne prennent pas le temps nécessaire pour étudier de façon plus approfondie les réels besoins et attentes de leurs clients (Cas d’usage, études quali/quanti, objectifs…).

Après quelques focus groups et des études rapides de la concurrence, les équipes vont très rapidement passer à la phase de conception et prototypage.

Avec suffisamment de budget, les entreprises lancent alors le produit sur le marché et se rendent compte qu’il y a un gap entre la réalité du terrain et leurs hypothèses de départ.

« Si vous pensez qu’un beau design est cher, vous devriez évaluer le coût d’un mauvais design. » Ralf Speth – PDG de Jaguar.

Avant même le développement du produit, l’une des étapes les plus importantes, c’est la phase de discovery.

C’est un process qui permet de valider une idée (marché, fonctionnalité, besoin, opportunité) avant de la mettre en œuvre.

Cette étape permet de mieux comprendre, cerner vos clients et utilisateurs pour développer un produit ou service qui répondra au mieux à leurs attentes.

La discovery permet aux équipes d’identifier les opportunités potentielles, de développer des produits qui ont de la valeur (business, utilisateur) et faisables techniquement.

Ce process évite surtout à l’entreprise de gaspiller des ressources inutilement sur un produit dont personne ne veut.

La product discovery permet de décider ce qu’il sera développé en s’appuyant sur de la data.

La discovery se décompose en 2 grandes étapes :

La phase exploratoire et la phase de validation

Phase exploratoire : cette étape implique différentes activités comme l’identification des problèmes / opportunités, des ateliers / entretiens avec les stakeholders, audit de l’existant.

Phase de validation : Avant la phase de conception, une série d’études et activités vont permettre de confirmer ou d’infirmer les différentes hypothèses émises lors de la phase exploratoire. (données quantitatives/qualitatives…).

La discovery va permettre aux équipes d’y voir plus clair, de poser une vraie vision produit et de faire les bons choix en termes de développement.

Pour être efficace, les équipes doivent élargir le champ des possibles et mettre en place des exercices pour ensuite valider les meilleures solutions à mettre en place.

Quand doit-on faire de la discovery ?

Cette étape est cruciale lorsque les équipes projet n’ont pas d’objectifs bien définis et une vision claire du projet ou de la solution à développer (objectifs, proposition de valeur, marché, audience, OKR…).

Quelles questions doit-on se poser ?

  • Quelle est l’ambition de votre projet ? Vos objectifs ?
  • Quel(s) problème(s) spécifique(s) votre produit ou service va-t-il résoudre ? (Proposition de valeur)
  • Qui sont vos utilisateurs, quels sont leurs besoins et attentes ? (Audience)
  • Comment pouvez-vous considérer votre projet comme une réussite ? (KPI)
  • Quelles sont les solutions alternatives sur le marché ? (Concurrents actuels)
  • En quoi votre produit est-il différent ? (Avantage concurrentiel)
  • Quand souhaitez-vous lancer le produit ? (Time to market)
  • Comment est-ce que vous allez le lancer ? (Stratégie Marketing, communication)
  • Quels sont les leviers pour faire de votre projet un succès ?
Toutes ces questions vont vous aider à avoir une vision plus claire de votre produit ou service.
 

Quels sont les attendus de la discovery ?

Ce process permet non seulement de valider une idée, mais aussi de collecter des données quantitatives et qualitatives importantes qui vont guider les équipes dans le développement du produit. Elles vont les aider à prioriser, choisir les meilleures solutions, faciliter la prise de décision, établir un plan d’action, etc.
 

En intégrant la discovery dans vos phases d’étude, vous allez donc pouvoir obtenir en sortie :

La liste des problèmes majeurs à traiter
Des objectifs clairs et précis
La proposition de valeur business
La liste des besoins réels et attentes utilisateurs
Une cartographie des différents parcours utilisateurs (scénarios, cas d’usage)
La liste de fonctionnalités à prioriser
Des wireframes & prototypes fonctionnels

Vous avez un projet ?
Atelier UX avec l'équipe de designers

Pourquoi organiser un atelier plutôt qu’une réunion ?

by Faciliation

La différence entre un atelier et une réunion, c’est que pendant une réunion les participants vont naturellement communiquer de façon libre avec des discussions ouvertes où beaucoup d’idées, avis sont partagés et sans structurer ou cadrer un minimum les échanges entre 5,6,7 participants, ça devient très vite le chaos.

De plus, chacun a sa manière de prendre des notes, tout le monde ne capture pas les mêmes infos, la perception d’une information peut varier d’une personne à une autre.

À l’issue de la réunion, rien de concret n’en ressort et aucune décision n’a été prise.

Résultat : la vision produit n’est PAS CLAIRE

L’atelier contrairement à une réunion va permettre de poser un cadre de travail en structurant les discussions. C’est ici qu’intervient le FACILITATEUR qui va devoir proposer cet environnement de travail au groupe en structurant les discussions grâce à des exercices séquencés.

Ces exercices vont permettre au groupe d’avancer vers un objectif précis qui a été fixé en début d’atelier. Il est donc important de bien préparer l’atelier, définir puis partager l’ordre du jour à l’avance.

Lors d’une réunion contrairement à un atelier, personne n’a été désigné spécifiquement pour animer les discussion et faire avancer le groupe.

Qu’est qu’un facilitateur ?

Il accompagne les équipes de travail (souvent pluridisciplinaires et donc complémentaires) dans la résolution de problèmes, l’identification des objectifs, des enjeux d’un projet et facilite les prises de décisions (priorisation des tâches, plan d’action).

Le facilitateur pose un cadre de travail pour faire collaborer les équipes plus efficacement, aligner la vision grâce à la mise en place d’ateliers collaboratifs privilégiant l’intelligence collective.

Tout le monde participe et chacun devient acteur en étant “force de proposition” lors des ateliers.Le facilitateur n’est pas là pour trouver la solution mais pour aider le groupe à avancer vers la solution.

Il fait quoi concrètement ? quel est son rôle ?

Avant l’atelier :

  • S’entretenir avec les experts en amont pour avoir le contexte
  • Bien comprendre l’objectif de l’intervention
  • Identifier les participants de l’atelier
  • Prendre connaissance du contexte sans être expert sur le sujet
  • Préparer le déroulé de l’atelier (méthodes et outils d’animation qui vont être utilisés ainsi que le support)

Pendant l’atelier :

  • Rappeler les objectifs, le cadre…
  • Donner les instructions claires sur le déroulé de l’atelier
  • Structurer et séquencer les discussions
  • Guider le groupe en aidant les participants à prendre de la hauteur
  • Élever le débat quand c’est pertinent
  • Assurer la bonne dynamique du groupe en s’assurant que chacun puisse s’exprimer
  • Minuter chaque exercice et le temps de parole
  • S’assurer que l’atelier avance bien et éliminer toute discussion ou débat sans lien direct avec l’ordre du jour
  • Capturer tout ce qui est partagé en séance et regrouper les idées communes
  • Reformuler ce qui est dit pour s’assurer que tout le monde a compris la même chose
  • Définir les next steps

Après l’atelier :

  • Synthétiser tout ce qui a été partagé en séance dans un format clair et digeste
  • Transmettre la synthèse et /ou faire la restitution aux équipes
  • Lister puis prioriser les opportunités / axes de travail avec d’autres ateliers
  • Identifier les équipes impactées et proposer un plan d’action
  • Prévoir les prochaines étapes
  • Animer d’autres ateliers si besoin

Un facilitateur est une aide précieuse lorsque les équipes :

  • Développent une solution sans avoir identifié clairement les objectifs et les enjeux
  • Ont une problématique à résoudre qui nécessitent l’intervention d’au moins 3 participants

Avantages d’un atelier : Interactif & Collaboratif

  • Tout centraliser sur un seul support et non de façon éparse (data, études quali, objectifs, ambition, CVP, OKR, inspirations, challenges, utilisateurs, cas d’usage, pain points, opportunités)
  • Espace d’échange live et asynchrone
  • Structurer & Séquencer les discussions (importance d’avoir un facilitateur, ne pas sortir du cadre ex. : Commencer à discuter des solutions possibles alors qu’on est en train de définir la problématique)
  • Visualiser les discussions avec une prise de note standardisée (voir les post its sur un board permet de mieux capturer les idées puis surtout de tout centraliser au même endroit, continuer à contribuer même après l’atelier, permet de mieux prioriser avec le système de vote)
  • Tout le monde participe activement : Générer des idées individuellement puis les partager au groupe. Chacun donne son avis sans cet effet de groupe où très souvent le plus extraverti ou le plus haut dans la hiérarchie va driver les réflexions du groupe.
    Les plus introvertis qui habituellement sont plus en écoute lors des réunions traditionnelles vont pouvoir donner leur avis et contribuer
  • Définition des next steps (décider des prochaines actions en attribuant les responsabilités/tâches à chaque équipe impactée).

Vous avez un projet ?