Construire votre méthode design e3

Savoir construire une méthode, c’est aussi être capable demain de créer une roadmap Design.

2 définitions au terme roadmap:

• une carte, une “représentation schématique des axes routiers destinée principalement aux automobilistes pour trouver leur itinéraire”;

• une feuille de route, une “représentation graphique simplifiée permettant de communiquer et de partager efficacement une intention stratégique afin de mobiliser, d’aligner et de coordonner les efforts des parties prenantes pour atteindre un ou plusieurs objectifs.”

Chaque personne qui design devrait essayer, à mon avis, d’être capable de visualiser son projet comme un objet.
Elle devrait tourner autour pour en voir toutes les perspectives. Elle devrait le tenir dans sa main, le peser et tester sa cohérence ; elle devrait le manipuler pour vérifier sa facilité d’utilisation et son accessibilité ; elle devrait le scanner et vérifier toutes les connexions et enfin le poser sur la table et le documenter.

Le Design n’est pas une méthode linéaire, c’est une approche méthodologique holistique, voir un domaine en soit.
Cette approche doit prendre en compte toutes les perspectives. Pour aligner et coordonner les efforts des parties prenantes, la personne qui design devra souvent parcourir les différentes routes de la carte, vérifier qu’il n’y a pas d’empêchement à la bonne circulation de l’information et assurer les jonctions entre les routes, mais plus largement elle devra relier tous les itinéraires de tous les autres types de transports.
La roadmap Design ne devrait pas être une feuille de route, mais un des livrables, une carte.

Pour créer cette carte, il faut savoir construire son framework et/ou sa méthode et ses process en utilisant l’ensemble des méthodologies à disposition. Voici donc notre sujet ;-)

Design, une approche méthodologique.

Pour les designers, la discovery est la méthode la plus connue. Que ce soit en Scale ou en Focused, en continu ou en dual track, il existe beaucoup de moyens de cadrer cette discovery.
Mais il est rare qu’une méthode universelle corresponde au contexte d’un pôle ou d’une équipe Design.
Le contexte, c’est la maturité de chaque acteur, la maturité du projet et/ou produit, et la maturité de l’organisation. C’est aussi la distribution des fonctions entre les acteurs (product managers, designers, développeurs, …).
Pour adapter une méthode universelle ou en créer une, il faut en comprendre sa structure et l’origine de ses outils, canvas & pratiques.

Chaque étape commence avec un entrant nécessaire qui est le sortant nécessaire (livrable) de l’étape précédente. Il peut y avoir plusieurs entrants et sortants à chaque étape et des variations plus complexes qu’un entrant = un sortant, mais c’est une base saine pour faciliter une chaîne de production.

Processus = séquence d’activités interconnectées transformant des entrées en sorties : description claire des rôles et des responsabilités.

• Méthodes et processus sont interconnectés ;

• le processus est le quoi qui peut être représenté par un flux de travail (workflow / opération flow);

• la méthode est son comment.

“Les développeurs n’avaient pas vu tous les problèmes de faisabilité à la première lecture des maquettes !”
“Une nouvelle fonction prioritaire est demandée par le business owner !”
“Les maquettes ne sont pas respectées !”
“Comment choisit-on son panel ?”
“Comment rassurer les stakeholders sur leur contrôle du produit ?” Tous ces points, et bien d’autres, dépendent du process.

Le process, souvent considéré comme une grosse machine non-nécessaire par les stakeholders, s’avère souvent vital pour les équipes dans leurs échanges opérationnels en guidant leur chemin.

1.2. Méthodologie

Méthodologie = choix et agencement des Méthodes et d’actions adaptés au problème pour mise en oeuvre de l’approche.

Le Design Playbook contient ici les pratiques et outils disponibles dans le Framework. Vous comprendrez mieux.

Si c’est la méthodologie qui permet de choisir les pratiques à mettre en place dans une méthode, c’est bien l’approche méthodologique (voir plus bas) qui déterminera le Framework et son Design Playbook.

La méthodologie découpe en phases une méthode longue pour révéler ses grands principes.

1.3. Framework

Plus le cadre de travail sera simple et linéaire, plus il sera réplicable et plus il pourra être rendu systématique. Ce qui facilitera la collaboration des acteurs du projet grâce à une routine connue.
La mise en place de ce cadre linéaire fonctionne lorsque toutes les fonctions sont tenues (rôles et responsabilités inclus) et que la fonction principale du produit est bien ancrée.
Les organisations travaillant en feature teams ou en squad peuvent facilement basculer sur ce type de méthode.

2. Vue globale

2.1 Approche Méthodologique

Approche = la manière d’aborder l’objectif selon des grands principes et des concepts.

Le Design Playbook contient un certain nombre d’outils et pratiques qui peuvent être utilisés selon le contexte. Le terme “Design Playbook” ne sous-entend pas que ces pratiques sont du champ du Design à l’origine. C’est même rarement le cas. La prochaine note de cette série reviendra sur les champs méthodologiques (hors design) qui contribuent au design par l’approche méthodologique.

exemple d’un ensemble des pratiques choisies pour créer une méthode

2.2 Design Roadmap

Quand on ne confond pas roadmap et méthode, on pense souvent à une Roadmap Design Teams en parlant de Roadmap Design

Roadmap Design Teams = planning a venir des différentes équipes par domaines (interactive, content, user) ou par features.

Design Roadmap = chemin à parcourir pour obtenir les livrables nécessaires afin de tisser les liens d’un collectif d’experts et ainsi assurer le lien entre organisation et opération. Favoriser la création et l’industrialisation du produit et son innovation

2.3 Exemple de Roadmap contextuelle

Ci-dessus l’exemple d’une roadmap pour la construction d’un site de vente de services.
Le client avait une maturité digitale faible et une forte expertise ‘“métier”.
Le but était aussi de l’accompagner dans une roadmap après sortie du site.

Pour ces raisons, j’ai proposé un atelier Matrice de Qualité (Quality Function deployement, j’en parle ici) pour :

• prioriser les fonctions essentielles

• définir les KPIs

• identifier les adhérences dans les fonctions

• estimer la charge technique et métier par fonction

• comparer selon benchmark

Retro-analyser le besoin d’information
Pour faire cette matrice de qualité, nous devions récupérer en amont un certain nombre d’informations que l’on retrouve dans un Business Model Canvas. Pour compléter le Business Model Canvas, nous avions besoin du Value Model Canvas qui lui-même nécessite les cartes d’empathie, …
Vous l’aurez compris, c’est bien le livrable final et la présence des informations qui a conditionné cette roadmap.

J’ai la conviction que construire une roadmap Design peut encore être facilité si on travaille en mode atomic (boilerplate) et que l’on travaille ces types de plaques routières (“plates). C’est un autre sujet ;-)

Créer sa roadmap peut également permettre à votre design de se libérer en proposant des pratiques créatives plus intuitives et personnelles pour porter une vision singulière… Vous en pensez quoi ?

Cette note fait partie d'une série : Design, d'holistique à systémique

1. Opérationnel

1.1 Méthode et process

Méthode = composition de phases, d’outils et de pratiques établies pour obtenir un livrable; descriptions des fonctions des acteurs du projet.