Prioriser dans un projet design

Rosalie Bourgeois de Boynes
7 min readJun 7, 2022

Prioriser pour savoir dans quel ordre on travaille

Dans un projet, il est important pour les équipes design de savoir ce qui est prioritaire à développer, pour travailler en fonction, avec bon sens, car « un bon tien vaut mieux que deux tu l’auras ». Autrement dit, mieux vaut une application avec une bonne fonctionnalité bien développée dans ses moindres détails que des milliers de fonctionnalités mal développées. Pour illustrer, pour un site internet visant à promouvoir une entreprise qui vend des sacs, mieux vaut un site internet qui permet correctement d’ajouter des sacs à un panier d’achat et un tunnel d’achat qui permet de finaliser la transaction, qu’un site internet qui permet de chatter avec un conseiller mais qui ne permet pas de finaliser l’achat des sacs. Ainsi, lors de la refonte de l’application SNCF vers France Connect en 2022, la note moyenne de l’application est passée de 4,6/5 à 1,9/5. Et les conséquences économiques de ne pas soigner les fonctionnalités prioritaires de son application peuvent être désastreuses. La SNCF a ainsi vu son concurrent direct, Trainline augmenter de +28%, ses nouveaux clients et +50% ses ventes de billets, comparé à la moyenne des 3 semaines précédent le lancement de la nouvelle application France Connect.

L’impossible priorisation des clients

Pourquoi on en arrive là, puisque c’est le sens commun que de dire qu’on doit commencer par le plus important ? Partie de la réponse réside dans le fait que les donneur d’ordre/ les clients/ les personnes dépositaires de la gestion des sites internet et des applications ont peur du manque. Quand on leur demande : qu’est-ce qui est le plus prioritaire ? Tout est prioritaire. Quand on demande : qu’est-ce qui est le moins important ? Tout est important. Qu’est-ce qui est obligatoire et nécessaire ? Tout est obligatoire : le prestataire, le designer UX, le designer UI, doit développer toutes les fonctionnalités, c’est dans le contrat. Or quand ledit contrat est négocié à la baisse et que les délais sont impossible à tenir, alors pour cocher les cases du contrat, on livre 40 fonctionnalités mal faites, plutôt qu’une seule bien faite.

Le travail bien fait

Au coeur du sujet se trouve la définition de la qualité. The Definition of done d’un point de vue design. Les critères d’acceptabilité.

Non, le design ne traite pas des opinions subjectives

« Le design, c’est le choix des couleurs des boutons, c’est donc une affaire de préférences subjectives, complètement relatif » Non, premièrement le design, ce n’est pas le choix des couleurs des boutons. Le design, c’est l’organisation des informations dans l’espace : c’est la priorisation et la bonne présentation du contenu, adapté à un coeur de cible étudié par de la recherche utilisateur en amont de la conception.

Ok. Donc, comment on priorise ?

Avant de prioriser : listons ce qu’on doit prioriser

Premièrement, il convient de faire une liste MECE (Mutually Exclusive ; Collectively Exhaustive) des items à évaluer. Concrètement, soit on liste les besoins sous lesquels on a pris le soin de subsumer la liste des fonctionnalités dépendantes et relatives ; soit on liste directement les fonctionnalités.

Par exemple : au besoin « En tant que jeune femme de 26 ans, je souhaite acheter un sac d’été pour aller avec mes vêtements » on subsumera les fonctionnalités « Panier », et « Tunnel d’achat » qui sont indirectement exprimés dans le besoin, mais aussi des considérations de connexion et de sécurité qui sont impliqués et implicitement présents également.

Si on liste directement les fonctionnalités, sans les relier au besoin, on risque de passer à côté de liens de dépendances, et on complexifie la lecture de notre projet. Par exemple : comment doit-on interpréter que le panier soit plus prioritaire que le tunnel d’achat ? Et comment interpréter l’inverse ?

Secondement, il convient d’écrire et de regrouper les différents degrés de résolution de chaque histoire.

Par exemple, le besoin d’aide d’un utilisateur peut être satisfait à des degrés divers, selon les choix de design, par une FAQ plus ou moins dynamique, un chatbot, un chat en temps réel avec un humain ou un centre d’appel dédié.

Prioriser par critères

Importance / Difficulty Matrix

Un modèle simple consiste à prioriser ses idées sous deux axes : l’importance et la difficulté.

Importance/Difficulty Matrix

Avantage : la représentation est simple, et la lecture l’est aussi

Inconvénient : dans l’ « importance », on mélange tout : la rentabilité, la satisfaction client, l’image de marque, la compétitivité, etc. De sorte que l’évaluation n’est pas toujours très bien faite, et qu’on ne résout pas vraiment notre sujet. En outre, la « difficulté » est aussi un mélange de coûts, de temps, de faisabilité technique, si bien que l’évaluation relative n’en est guère plus aisée.

Mise en situation de l’évaluation de l’importance et de la difficulté de différents degrés de résolution de user stories

Un tableau Excel avec toutes les variables ?

Cette méthode consiste à détailler ce qu’on ne pouvait pas détailler dans la formalisation précédente selon nos critères : le temps (temps de développement, date d’arrivée sur le marché), l’argent (le coût induit par le développement, la rentabilité, la profitabilité), l’impact stratégique imaginée et désirée par les décideurs, la satisfaction client (le potentiel qu’a la fonctionnalité de réjouir le client, de lui procurer une expérience agréable qui lui fera avoir une image positive de la marque, lui donnera envie d’acheter, le persuadera, etc.), la faisabilité technique (la difficulté et la charge de montée en apprentissage des équipes dev).

Exemple de carte de scores avec pondération

Concrètement, chaque item sera évalué sur 5 par exemple, et l’on peut donner des coefficients aux différentes famille de critères.

Avantages : on comprend sur quelle base on évalue, cette méthode paraît scientifique, et peut faire autorité.

Inconvénients : 1. ces critères sont parfois un mélange de bénéfices recherchés et de contraintes à intégrer. 2. Or suivant les profils, les évaluateurs sous-évaluent toujours la rentabilité qui se cache derrière la satisfaction client. Ils voient d’abord la contrainte technique et dépriorisent l’ambition stratégique. 3. Au moment de donner un coefficient plus important à la satisfaction client, il n’y a plus personne, personne ne comprend le calcul et tout est remis en question.

Exemple d’évaluation avec des tailles de t-shirt

Repartir du brief

Parfois, on peut évaluer par objectifs à long terme. Par exemple, une mission avait pour objectif de « augmenter les ventes », « améliorer l’image de marque », « améliorer l’ergonomie », « réduire les coûts de maintenance », et le développement des fonctionnalités a donc été évalué pour répondre à la question « quelle est la probabilité pour que le développement de cette fonctionnalité nous fasse atteindre notre objectif ? »

Évaluation en repartant des objectifs macro de la mission

Intégrer le ROI indirect du design sans le mettre en compétition avec les considérations de faisabilité technique

Critères design : utilité, désidérabilité, accessibilité, crédibilité, trouvabilité, facilité d’utilisation, compréhensibilité, charge mentale, intuitivité, logique ;

Critères expérientiels & design : connexion émotionnelle, rythme et musicalité, beauté esthétique, liens avec des tendances mode ;

Critères marketing : originalité, humanisme et inclusivité, logique-portfolio, logique culturelle, mémorabilité, potentiel de laisser une impression à long terme, différenciation marketing, avantage compétitif.

Évaluation pré-conception selon des critères design
Évaluation pré-conception selon des critères de design expérientiel et de marketing

Ou à l’inverse, on pourrait évaluer les idées de développement par leur capacité de ne pas tomber dans des écueils : potentiel de fatigue, de frustration, d’énervement, d’ennui, d’agacement, etc.

Critères négatif : éviter de créer de nouveaux problèmes

Au-delà des critères : bousculer les jeux de langage pour forcer le classement

Une seconde façon de prioriser consiste à obliger les décideurs à se positionner sur la question initialement posée : qu’est-ce qui est le plus prioritaire ? Qu’est-ce qui est le moins important ? Qu’est-ce qui est obligatoire et nécessaire ? Mais de tourner la question à la négative et de donner un score de survivalisme. Quels sont les fonctionnalités sans lesquelles l’utilisateur ne peut pas survivre ? Quels besoins faut-il satisfaire, coûte que coûte, car dépend la survie du site internet/ de l’application en dépend ?

Par exemple, le besoin « En tant que jeune femme de 26 ans, je souhaite acheter un sac d’été pour aller avec mes vêtements » et ses fonctionnalités « Panier » et « tunnel d’achat » aura un score maximum ; par comparaison aux efforts à fournir pour la FAQ, et la page « qui sommes-nous ? », car dans notre cas d’usage, nous sommes intéressé par la rentabilité de notre site internet.

Concrètement, comment on fait ?

Plutôt que d’évaluer les items un à un, partons du classement final auquel nous souhaitons arriver. Plaçons une ligne temporelle de conception, et plaçons le développement de telle ou telle fonctionnalité (par bloc-besoin).

Score de survivalisme : les panneaux “attention” indiquent le chemin critique de survie, et donc, en creux, définissent le MVP (Minimum Valuable Product) du site

--

--

Rosalie Bourgeois de Boynes

I am a French AI enthusiast, looking forward to discovering the new developments of AI that would be closer to the way human brain functions.