Le modèle Cynefin pour les designers

En tant que designers, notre mission principale consiste à résoudre des problèmes. Nous devons accompagner la conception de solutions produisant un résultat pertinent et efficace d’un point de vue utilisateur, business et technique. Les problèmes rencontrés sont de nature et topologies diverses, et peuvent être plus ou moins complexes, et prendre plus ou moins de temps à résoudre.

Nous nageons souvent dans l’inconnu, ne sommes jamais à l’abri d’appliquer l’effort de conception au mauvais endroit et/ou au mauvais moment. Ce qui peut rendre difficile la mesure et la communication de notre travail, trop souvent abordé par une valeur temporelle, aussi floue soit-elle.

En effet, cette mesure de la complexité est difficile car de nombreux aléas peuvent fausser la réponse, notre travail possède une dynamique qui nous fait jongler entre plusieurs niveaux de difficultés, ce qui rend difficile le chiffrage. Un test utilisateur qui invalide l’idée sélectionnée, un retour métier qui ajoute une contrainte supplémentaire, une atelier qui ne donne aucun résultat, une urgence etc…. C’est justement ce sujet que nous allons aborder. Comment percevoir notre travail de designer sous le prisme de la complexité ?

I – Le framework Cynefin, quésaco ?

Avant toute chose, découvrons ce qu’est le framework Cynefin. Le modèle Cynefin (à prononcer kuh-nev-in) est un modèle conceptuel construit début 2000 par Dave Snowden lorsqu’il travaillait pour IBM Global Services.

C’est un modèle créateur de sens (Sense Making). Son but est de nous aider à catégoriser une situation pour définir comment l’aborder et comment résoudre le problème donné. Avoir une bonne solution à un problème est formidable, mais l’appliquer dans la mauvaise situation ou dans le mauvais contexte peut conduire à des résultats plus compliqués ou nuisibles.

Le modèle est construit en partant du fait qu’il existe 3 types de systèmes primaires dans la nature :

• Systèmes ordonnés : Il y a un niveau de contrainte très élevé. Le comportement des agents (éléments qui agissent dans ou sur le système) est contrôlé et prédictible.
  
  Les systèmes ordonnés sont divisés en évident et compliqué.
  
• Systèmes complexes : Les contraintes sont flexibles et négociables. Les agents modifient le système par leur interaction avec lui et entre eux. On peut dire qu’ils co-évoluent.
  
• Systèmes chaotiques : Il n’y a pas de contraintes, les agents sont indépendants les uns des autres.

De plus, un système a été rajouté, le désordre.

Domaine Evident ou Simple

Il y a une relation de causes à effets qui est prédictible, prévisible et peut être déterminée à l’avance.
Le modèle décisionnel est le suivant : Sense – Categorize – Respond (Sentir – Catégoriser – Répondre). Nous sommes dans des Best Practices, des standards.

Par exemple : changer une ampoule. Il n’y a pas 200 façons de changer une ampoule, c’est simple, clair, limpide. Tout le monde est capable de le faire !

Domaine Compliqué

Il y a une relation de causalité, mais elle n’est pas évidente et nécessite de l’expertise.

Le modèle décisionnel est le suivant : Sense – Analyze – Respond (Sentir – Analyser – Répondre). Nous sommes ici dans des Good Practices, il y a plusieurs façons de faire les choses, toutes aussi valables et légitimes.

Prenons comme exemple une panne de voiture. Vous êtes sur le bas côté de la route et votre voiture fume. Vous allez en chercher la cause, mais comme vous n’êtes pas mécanicien, vous ne pourrez pas la réparer. Vous avez besoin d’un “expert”, votre action sera donc d’appeler un garagiste.

Domaine Complexe

La relation de causalité ne sera déduite que rétrospectivement. Il n’y a pas de bonne réponse, pas de prévisibilité sur les résultats.
L’approche est la suivante : Probe – Sense - Respond (Sonder – Sentir – Répondre). Ici nous sommes dans la découverte, dans un domaine ou des pratiques émergent au fur et à mesure de l’avancée.

Pour illustrer le domaine complexe, prenons le monde culinaire. Vous souhaitez réaliser un nouveau plat. Vous n’avez pas la possibilité de savoir si votre essai sera fructueux ou non. Vous allez devoir le cuisiner, le goûter, apprendre du résultat, améliorer et ainsi de suite jusqu’à avoir le résultat souhaité. Vous ne pouvez pas prédire le goût final de votre nouveau plat sans l’avoir réalisé.

Domaine Chaotique

Dans le chaos, il n’y a aucune relation de causalité. C’est une zone de turbulences où la seule chose à faire, c’est agir pour en sortir le plus vite.

L’approche est la suivante : Act – Sense - Respond (Agir – Sentir – Répondre). Nous sommes dans le domaine de l’innovation. Tout ce qui en sortira sera nouveau au vu du fonctionnement actuel.

Un bon exemple pour expliquer cette étape est un bateau qui est en train de couler suite à un trou dans la coque. Il n’y a pas le temps de se poser pour réfléchir à une stratégie de réparation ou de chercher à comprendre pourquoi il y a un trou, il faut le colmater le plus vite possible pour éviter que le bateau ne sombre.

Le Désordre, la partie centrale

Le désordre est l’espace au milieu. Cette catégorie s’applique aux situations que vous n’arrivez pas à positionner, que vous n’arrivez pas à ressentir. Une façon d’aborder le désordre est de commencer à décomposer la situation en problèmes plus petits. Ensuite, appliquez les problèmes à l’une des quatre catégories et travaillez sur une solution.

Se déplacer dans les domaines

A mesure que nos connaissances augmentent, il y a une sorte de dérive du chaotique au complexe et du compliqué à l’évident.

Dans certains cas, un mouvement anti-horaire peut se produite. Par exemple, un membre de votre équipe qui est le seul à posséder une compétence clé quitte votre entreprise. Il n’y aura plus personne avec cette expertise et donc les problèmes nécessitant cette compétence ne feront plus partie du domaine évident/facile. De même, une complaisance ou une accumulation de biais peuvent provoquer un mouvement de l’évident au chaotique.

II – Comment peut-il nous aider ?

Ce qui est très intéressant avec ce modèle, c’est qu’il nous aide à percevoir les situations et à nous questionner sur une difficulté relative. De plus, nous travaillons souvent en équipe avec d’autres corps de métiers, et avons aussi des échanges avec les utilisateurs finaux. Ce qui ajoute de la complexité et de l’imprévu : en effet, qui peut-être sûr du résultat d’une interview ?L’objectif n’est pas d’estimer la résolution de problème via la notion temporelle, mais de l’exprimer via une échelle de complexité. Ce qui est plus pertinent, car une valeur temporelle n’indique pas efficacement la difficulté d’un problème. Elle représente essentiellement votre temps d’occupation sur un planning. Vous pouvez être face à un problème évident, mais qui nécessite une grande période temporelle. D’autre part, avec la popularisation des méthodes agiles, nous sommes confrontés au besoin de chiffrer l’effort dans la réalisation de notre travail. Hors un chiffrage (qu’il soit en taille de t-shirt ou basé sur la suite de Fibonacci) représente une complexité et non une durée. Pour certaines méthodes comme le SCRUM, la période temporelle est découpée en sprints, donc l’Intérêt de chiffrer en temps est peu pertinent.

Notre rôle de designer – dans le digital – consiste à construire des interfaces qui répondent à des besoins utilisateurs et/ ou business. Il n’est pas rare d’avoir envie de réinventer la roue à chaque nouveau projet. De passer trop de temps sur un formulaire, de dépenser du budget sur des tests utilisateurs, de remettre en question des best practices ou tout simplement, avoir du mal à mesurer une tâche. C’est pourquoi utiliser ce modèle en début de projet est vraiment utile. Premièrement pour se questionner sur la nature du problème à résoudre, sur comment l’aborder, sur l’outillage nécessaire à sa résolution, la méthode à mettre en place, etc… Puis ensuite pouvoir le positionner dans un domaine et appliquer le bon mode d’action.

Les problèmes tombant dans le domaine évident/ simple sont assez clairs, assez simples pour pouvoir passer en production, rentrer dans un sprint. Ils ne nécessitent pas (ou peu) d’échanges. On prend la Best Practice et on l’applique. Par exemple ,votre produit contient un système de réinitialisation de mot de passe. Il existe des Best Practices fiables et éprouvées. Il n’y a aucun intérêt à réinventer la roue ou d’en discuter avec toutes les parties prenantes. On prend et on applique.

Ceux liés au domaine compliqué sont légèrement différents car vous avez plusieurs résultats possibles. Par exemple un menu principal, cela paraît simple à première vue, mais il y a besoin d’une analyse pour le faire. Faire du tri par cartes auprès de vos utilisateurs, réfléchir à sa structure, la hiérarchie de contenu, sa représentation graphique, etc.. Il n’y a pas une façon de faire un menu principal, il y en a plusieurs, certaines excellentes, d’autres non. Le problème à résoudre n’est, en soit, pas difficile, mais il y a un travail itératif qui nécessite une cohésion et des échanges entre plusieurs experts.

Alors qu’un problème tombant dans le domaine complexe nécessite des méthodes et outils pour baisser en complexité. C’est dans ce domaine que nous, designers, avons une réelle valeur ajoutée et non dans la déclinaison de Best Practices. Pour cause, nous avons diverses méthodes – comme le Design Thinking – qui font leurs preuves dans ce domaine complexe. Ils permettent, via la compréhension des utilisateurs, l’idéation et la co-construction, de mieux cerner le problème et de trouver LA solution la plus pertinente. Le problème traité dans ce domaine doit à la fin pouvoir être découpé en problèmes plus petits pour pouvoir passer dans les domaines compliqués/ évidents.

Le chaos, parlons-en. Qui n’a jamais connu de réunion de présentation d’un prototype où un retour sans aucun fondement sort d’un chapeau et casse tout le travail accompli ? Mais malheureusement, il n’y a pas de négociation possible, il faut le faire, point. Ca devient le problème urgent à régler, il ajoute tout un lot de complexité à ce qui existe déjà. Autre exemple, un écosystème ou chaque designer travaille dans son coin sans communiquer. Nous sommes dans le domaine du chaos. Il faut absolument l’éviter !

Dans le domaine du design, nous avons cette chance de pouvoir aller intentionnellement dans le domaine chaotique. C’est le cas des ateliers d’idéations/ de brainstorming, où on lève les contraintes pour trouver de nouvelles idées, de nouvelles façons de faire. On quitte le domaine complexe le temps d’un ou plusieurs ateliers pour sombrer dans le chaos, puis nous revenons dans le complexe pour creuser les idées soulevés. Lors de phases de recherches utilisateurs nous tombons aussi dans le domaine chaotique. Il n’y a pas de contraintes et pas de prédictibilités des résultats. Nous sommes dans une optique de compréhension et de questionnement.

Il y a une chose importante à garder en tête : la complexité d’un problème est relative à votre équipe, votre entreprise et votre produit. Par exemple, si votre valeur ajoutée se trouve être dans l’innovation du système de login, cette problématique tombera dans le domaine complexe. Dans le cas contraire, elle se trouvera dans les domaines évident/ compliqué car “il suffit” de reprendre des patterns & best practices éprouvées. En ce sens, il est important de s’approprier le modèle pour jauger où mettre l’effort.

Pour finir, ce modèle apporte aussi une aide précieuse dans la communication autour de notre travail de designer. En effet, dans notre métier il y a cette particularité où tout le monde à un avis sur ce que l’on fait. On parle souvent de “challenger” notre le travail, ce qui peut ajouter une complexité là où il n’est pas censé en avoir. Dans ce sens, populariser ce modèle conceptuel est une aide précieuse car il aide à faire comprendre pourquoi débattre et chercher à “innover” sur certains sujets est une perte de temps et d’énergie. Ou a contrario expliciter pourquoi tel problème est plus complexe en réalité qu’en apparence. J’ajouterais qu’une échelle de complexité partagée permet d’avoir un vocabulaire commun qui aide à mieux communiquer et à mieux comprendre pourquoi certaines équipes ont besoin de plus de “temps” que d’autres. Il est donc important de le communiquer auprès des équipes et d’en faire un outil commun.

III – Pour conclure

Le modèle Cynefin, outil d’analyse de prise de décisions, est un excellent modèle pour nous aider à prendre la bonne décision méthodologique en fonction du type de système présent. Mais il permet aussi d’aider à se focaliser là ou se trouve la valeur ajoutée du produit.

Appliqué au design, cet outil nous permet de visualiser plus facilement où nous devons mettre le plus d’effort en conception. Il nous aide à voir quelles features nécessitent une démarche de design poussée. C’est aussi un puissant outil de communication qui permet de créer un vocabulaire commun à toutes les équipes. Il est un outil efficace.

Écrit par Grégory Buron

En savoir plus

Présentation du Framework par le père du modèle sur Cognitive Edge
Origine du nom Cynefin
Template Miro du Framework
Un des premiers article sur le framework Cynefin
Webinar “Complexity-based Design Thinking”