Le modèle Cynefin pour les designers

II – Comment peut-il nous aider, nous designers ?

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.

L’objectif n’est pas d’éstimer la résolution de problèmes via une notion temporelle, mais de l’exprimer via une échelle de complexité. Ce qui est plus pertinent.
En effet, 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 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 systèmes qui répondent à des besoins. 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 trop de 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, 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 utilisateur, 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. Elles permettent, via la compréhensions 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 petit 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à.

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 et 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 recherche utilisateur nous tombons aussi dans le domaine chaotique. Il n’y a ni contraintes ni des prédictibilités des résultats. Nous sommes dans une optique de compréhension et de questionnement.

Il y a aussi 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é ou 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 pour en faire un outil commun.