Chez BNP Paribas Cardif, le portail d'activation dont j'ai développé le front-end a remplacé un processus manuel passant par le centre d'appels et a réduit les coûts opérationnels de 30 %. Chez Wonderlabs, un flux d'onboarding redesigné pour une PWA de carte de crédit a augmenté l'engagement utilisateur de 15 %. Chez Strongest Families, la refonte d'une plateforme de santé mentale que j'ai dirigée a amélioré les scores d'utilisabilité de 25 % et a soutenu une levée de fonds de 2 M$. Je ne partage pas ces chiffres pour impressionner : je les partage parce que des chiffres comme ceux-là sont ce qui garde le travail de design financé. Sans un changement quantifié, les résultats restent invisibles pour le business et le design reste un centre de coûts plutôt qu'un levier de croissance.
La plupart des équipes de design perdent l'argumentaire des métriques parce qu'elles amènent des chiffres de craft dans une conversation financière. La traduction entre résultats UX et langage business, c'est le travail qui vaut aux designers une place à la table des décisions de budget.
Pourquoi la plupart des équipes UX mesurent les mauvaises choses
Les métriques UX les plus courantes que je vois rapportées en sprint review sont les scores de satisfaction de tests d'utilisabilité, les chiffres NPS et le temps passé sur la page. Ceux-ci ne sont pas inutiles, mais ils sont fréquemment mal interprétés. Un score de satisfaction élevé d'un test d'utilisabilité signifie que les participants ont aimé l'expérience dans une session contrôlée avec un observateur présent. Ce n'est pas la même chose que des utilisateurs complétant avec succès de vraies tâches dans de vraies conditions.
Le temps passé sur la page est encore plus trompeur en isolation. Pour un article éditorial, un long temps sur la page est bon : les utilisateurs lisent. Pour un flux de soumission de réclamation d'assurance, un long temps sur la page est mauvais : les utilisateurs galèrent. La métrique ne signifie rien sans le contexte du comportement attendu.
Le framework auquel je reviens est HEART, développé chez Google par Kerry Rodden, Hilary Hutchinson et Xin Fu. Happiness, Engagement, Adoption, Retention, Task Success. Chaque dimension correspond à des métriques spécifiques et chacune peut être connectée à un signal (qu'observons-nous ?) et une métrique (comment la quantifions-nous ?). Je n'utilise pas toujours les cinq dimensions : je choisis les deux ou trois plus pertinentes pour les objectifs actuels du produit.
Les cinq métriques qui comptent vraiment
Ce sont les métriques que j'ai utilisées le plus systématiquement pour démontrer l'impact UX. Ce ne sont pas les seules métriques. Mais ce sont celles qui sont le plus directement traçables jusqu'au comportement utilisateur et aux résultats business.
1. Taux de succès de tâche
Le taux de succès de tâche est le pourcentage d'utilisateurs qui complètent une tâche définie avec succès. C'est la mesure la plus directe de si votre design fonctionne. Pour un formulaire, le succès signifie soumission sans erreur. Pour un flux d'onboarding, le succès signifie activation de compte. Pour une interface de recherche, le succès signifie arriver à un résultat pertinent.
Chez BNP Paribas Cardif, le portail d'activation dont j'ai développé le front-end a remplacé un processus manuel passant par le centre d'appels. Chaque client qui complétait son activation en libre-service, c'était un appel de moins pour un agent humain, et c'est de là que venait la réduction de coûts de 30 %. Mon rôle là-bas était le développement front-end, pas la recherche. Mais le chiffre qui comptait pour le business n'était pas un score d'utilisabilité. C'était le volume du centre d'appels.
2. Temps sur la tâche
Le temps sur la tâche mesure combien de temps il faut aux utilisateurs pour compléter un workflow spécifique. Plus court est mieux pour les tâches transactionnelles. Cette métrique est précieuse parce qu'elle se traduit directement en coût dans tout workflow où du temps humain est impliqué, et en conversion dans tout flux générant des revenus.
3. Taux d'erreur
Le taux d'erreur suit la fréquence à laquelle les utilisateurs font des erreurs. Un taux d'erreur élevé est souvent le signal d'un étiquetage peu clair, d'un guidage insuffisant, ou d'un décalage entre le modèle mental de l'utilisateur et le modèle de l'interface. Réduire le taux d'erreur réduit les coûts de support, l'abandon de formulaires et améliore la confiance.
4. Métriques d'engagement (rétention et profondeur)
Chez Wonderlabs, l'augmentation de 15 % d'engagement venait d'un flux d'onboarding redesigné sur une PWA de carte de crédit avec plus de 50 000 utilisateurs. L'engagement est un indicateur retardé : il répond à l'expérience cumulative, pas aux interactions individuelles. Il est plus difficile à attribuer à un seul changement de design mais c'est la métrique dont le leadership produit se soucie le plus.
5. Net Promoter Score et CSAT
NPS et les scores de satisfaction client sont des métriques attitudinales : elles capturent comment les utilisateurs se sentent. Elles sont utiles comme indicateurs de tendance et pour le benchmarking contre les concurrents mais elles sont faibles pour diagnostiquer des problèmes spécifiques. Je les utilise comme indicateurs avancés : une baisse de NPS signale que quelque chose ne va pas avant que vous ne le voyiez dans les données comportementales.
Instrumenter les designs pour la mesure
La mesure ne fonctionne que si vous instrumentez pour elle au moment du design, pas après coup. Ça signifie identifier les tâches clés dans votre flux avant de construire, définir à quoi le succès et l'échec ressemblent pour chaque tâche, et s'assurer que l'implémentation capture les événements nécessaires.
- Définir la tâche : quelle action spécifique constitue le succès ? Être précis : 'l'utilisateur complète le paiement' est mieux que 'l'utilisateur est content du paiement'
- Identifier l'événement de début : quelle action utilisateur marque le début de la tâche ?
- Identifier l'événement de succès : quel événement backend ou frontend marque la complétion ?
- Identifier les signaux d'échec : erreurs, pressions du bouton retour, timeouts, abandons
- Spécifier les étapes de l'entonnoir : chaque point de décision entre le début et la complétion qui devrait être suivi
- Documenter les exigences d'analytique dans vos specs de design : ça fait de l'instrumentation une tâche de développement, pas une réflexion après coup
// Analytics service in Angular, typed events for a specific flow
import { Injectable } from '@angular/core';
type OnboardingStep = 'personal-info' | 'identity-verification' | 'account-setup' | 'confirmation';
type OnboardingEvent =
| { event: 'onboarding_step_viewed'; step: OnboardingStep }
| { event: 'onboarding_step_completed'; step: OnboardingStep; duration_ms: number }
| { event: 'onboarding_step_error'; step: OnboardingStep; error_code: string }
| { event: 'onboarding_abandoned'; step: OnboardingStep; reason: 'timeout' | 'back' | 'exit' }
| { event: 'onboarding_completed'; total_duration_ms: number };
@Injectable({ providedIn: 'root' })
export class OnboardingAnalyticsService {
private stepStartTime = new Map<OnboardingStep, number>();
track(event: OnboardingEvent): void {
// Send to your analytics platform (Segment, GA4, Amplitude, etc.)
console.log('[Analytics]', event);
// analyticsClient.track(event.event, event);
}
startStep(step: OnboardingStep): void {
this.stepStartTime.set(step, performance.now());
this.track({ event: 'onboarding_step_viewed', step });
}
completeStep(step: OnboardingStep): void {
const start = this.stepStartTime.get(step);
const duration_ms = start ? Math.round(performance.now() - start) : 0;
this.track({ event: 'onboarding_step_completed', step, duration_ms });
}
recordError(step: OnboardingStep, error_code: string): void {
this.track({ event: 'onboarding_step_error', step, error_code });
}
recordAbandon(step: OnboardingStep, reason: 'timeout' | 'back' | 'exit'): void {
this.track({ event: 'onboarding_abandoned', step, reason });
}
completeFlow(flowStartTime: number): void {
const total_duration_ms = Math.round(performance.now() - flowStartTime);
this.track({ event: 'onboarding_completed', total_duration_ms });
}
}Construire l'argumentaire pour l'investissement UX
L'erreur classique quand on présente un argumentaire pour un investissement design significatif, c'est de commencer par la justification d'expérience utilisateur : modèles mentaux, charge cognitive, réponse émotionnelle. La direction écoute poliment et le budget ne bouge pas. Ce qui fonctionne, c'est de commencer par un chiffre : le taux de complétion d'onboarding est bien en dessous du benchmark du segment, et chaque demande abandonnée a une valeur en revenu qu'on peut estimer. Présenté comme du revenu annualisé à risque, le même investissement design devient une approbation bien plus facile.
La structure que j'utilise pour les argumentaires UX a quatre composants : la métrique d'état actuel, le benchmark ou objectif, l'impact estimé en termes business, et l'investissement proposé. Tout est quantifié. Tout trace vers du revenu, du coût ou du risque.
- État actuel : que montrent les données en ce moment ? Taux de succès de tâche, taux d'erreur, volume de tickets de support liés au problème
- Benchmark : à quoi ressemble le bon ? Données d'industrie, recherche concurrentielle, ou baseline interne d'un produit plus performant
- Impact projeté : quel est le changement attendu ? Être conservateur : les dirigeants se méfient des projections optimistes
- Investissement : heures de design, heures de développement, temps de test, coûts d'outillage
- ROI ou période de retour : même un calcul approximatif rend l'argumentaire concret
- Risque d'inaction : quel est le coût de ne pas investir ? Utile pour les cas poussés par la conformité
Le problème d'attribution
Un défi honnête avec les métriques UX est l'attribution. Disons que la conversion augmente de 18 % après un redesign. Ce chiffre est illustratif, ce n'est pas l'un des miens. Est-ce le redesign, la campagne marketing qui tournait en même temps, le prix promotionnel, ou la saisonnalité ? L'attribution propre est rare. Les approches qui fonctionnent sont les tests A/B (séparer le groupe de changement et un groupe de contrôle), les déploiements échelonnés (publier à 10 % d'abord et mesurer), et l'analyse avant/après avec un groupe témoin. Les trois demandent une infrastructure de déploiement et d'expérimentation derrière elles.
Cette infrastructure est la barrière, et la plupart des équipes ne l'ont pas. Sans elle, on ne peut pas faire de séparation propre, alors le repli est la mesure avant/après avec un snapshot clair pris avant le début du travail. C'est la version que j'ai réellement pratiquée : établir la ligne de base de la métrique d'abord, mesurer la même métrique ensuite, et être explicite sur tout le reste qui a changé pendant la fenêtre. La clé est le baselining : vous ne pouvez pas prouver d'impact si vous n'avez pas mesuré avant.
Vous n'avez pas besoin d'une attribution parfaite pour construire un argumentaire convaincant pour l'investissement design. Vous avez besoin d'une histoire crédible soutenue par des données qui bougent dans la bonne direction, au bon moment, d'un montant significatif.
Le design est le plus efficace quand il est traité comme une discipline avec des résultats mesurables, pas comme une fonction de service qui produit des livrables. Les équipes avec lesquelles j'ai travaillé qui ont eu le plus d'impact étaient celles qui possédaient leurs métriques, les rapportaient en termes business, et les utilisaient pour piloter la priorisation. Commencez par le taux de succès de tâche. Mesurez-le avant de changer quoi que ce soit. Rapportez le delta. La conversation avec le business change immédiatement.
Références
- Google HEART Framework (Rodden, Hutchinson, Fu, CHI 2010). https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/
- Nielsen Norman Group. Success Rate: The Simplest Usability Metric. https://www.nngroup.com/articles/success-rate-the-simplest-usability-metric/
- Amplitude. Product Metrics. https://amplitude.com/blog/product-metrics