Sergio Hurtado

01 · Projets

Client confidentiel

Streaming – Plateforme par abonnement

2025 · Plateforme de streaming par abonnement · Design system

La demande

Une plateforme de streaming vidéo par abonnement de taille moyenne : 495 000 abonnés en France et dans plusieurs pays européens, sur web, mobile, tablette et Smart TV. Elle refondait son produit, sans langage visuel arrêté ni bibliothèque, pour convertir plus, réduire le churn et fidéliser. Mission de sept mois, en tant que seul designer, sous accord de confidentialité.

La solution

Dès les premiers écrans, j'ai proposé de construire un design system en même temps que les maquettes, avec les contraintes WCAG portées par les tokens. J'ai livré un kit Figma, des guidelines en PDF et un skill Claude qui contrôle les interfaces développées. Six mois après la refonte, la conversion passe de 2,8 % à 4,1 % et le churn mensuel de 7,2 % à 4,9 %.

Méthodologie

  • Audit ergonomique de l'existant
  • Benchmark
  • Animation de groupes de conception pluridisciplinaires
  • Modélisation des parcours utilisateurs
  • Hiérarchisation de l'information
  • Proposition de solutions en wireframes
  • Analyse des indicateurs d'usage et des objectifs métier
  • Design system construit avec les maquettes, tokens WCAG
  • Responsive design, du mobile 390 px à la Smart TV 1920 px
  • Guidelines et contrôle qualité des interfaces

Audit de l'existant

L'audit de l'ancienne version a relevé les points de friction des deux parcours qui faisaient abandonner : la création de compte et la souscription. Pour chacun, l'écran avant et l'écran retenu.

Parcours 1 · Création de compte

Objectif : créer un compte vite pour accéder au service.

Avant

Avant

Après

Après

1.1Formulaire trop long

Avant : nom, prénom, date de naissance, adresse, téléphone et e-mail exigés avant tout accès.

Après : un seul champ obligatoire, l'e-mail.

1.2Pas de connexion simplifiée

Avant : inscription par formulaire uniquement.

Après : « Continuer avec Apple / Google » en premier : compte créé en un geste.

Avant

Avant

Après

Après

1.3Règles de mot de passe opaques

Avant : 12 caractères, majuscule, chiffre et caractère spécial exigés, sans règles affichées.

Après : règles visibles et cochées en direct, mot de passe affichable, option sans mot de passe.

Avant

Avant

Après

Après

1.4Vérification qui fait quitter le site

Avant : code à chercher dans sa messagerie puis à ressaisir, compte bloqué en attendant.

Après : code saisi sur la même page, rempli automatiquement sur mobile, vérification non bloquante.

Avant

Avant

Après

Après

1.5Message d'erreur incompréhensible

Avant : « Une erreur est survenue (Error 403) ».

Après : ce qui s'est passé, quoi faire, un bouton d'action. La saisie est conservée.

Parcours 2 · Souscription

Objectif : choisir une formule et payer.

Avant

Avant

Après

Après

2.1Offres difficiles à comprendre

Avant : trois formules aux différences floues.

Après : une offre complète, seule la durée change, économie affichée.

2.2Conditions cachées

Avant : fin de l'essai et engagement découverts trop tard, en petits caractères.

Après : essai, date et montant du premier paiement affichés dès le choix.

Avant

Avant

Après

Après

2.3Paiement trop complexe

Avant : nombreux champs, carte saisie deux fois, pas de paiement express.

Après : Apple Pay, Google Pay, PayPal ou carte en trois champs.

2.4Prix qui change au paiement

Avant : 7,99 € annoncés, un autre montant au moment de payer.

Après : prix TTC final affiché dès le choix et repris à l'identique.

Avant

Avant

Après

Après

2.5Refus de paiement sans explication

Avant : « Carte refusée », sans motif.

Après : motif en clair, aucun montant débité, autre moyen de paiement sur place.

Avant

Avant

Après

Après

2.6Échéances non rappelées

Avant : aucune échéance rappelée après la souscription.

Après : prochaines étapes datées, rappel avant le premier paiement, résiliation en un clic.

Écrans « avant » reconstitués en wireframe d'après l'audit. Écrans « après » issus de la refonte.

Responsive design

Conception mobile d'abord, sur six paliers. Les mêmes composants se réorganisent d'un appareil à l'autre.

Mobile
Mobile · 390 px
Base. Une colonne, barre d'onglets en bas.
Large mobile
Large mobile · 600 px
Grilles de cartes plus larges, même navigation.
Tablette
Tablette · 768 px
Trois cartes par rangée, barre d'onglets conservée.
Laptop
Laptop · 1024 px
Navigation en haut, barre d'onglets retirée.
Desktop
Desktop · 1440 px
Recherche dans l'en-tête, cinq cartes par rangée.
Smart TV
Smart TV · 1920 px
Navigation à la télécommande, zone de sécurité.

Smart TV

  • Lecture à 3 mètres : textes et éléments agrandis.
  • Navigation à la télécommande (D-pad) : état focus toujours visible, pas de survol.
  • Zone de sécurité de 5 % (96 × 54 px) contre les bords rognés par certains téléviseurs.
  • Conçu en 1920 × 1080, exportable en 3840 × 2160 (4K).
  • Inscription et paiement sur le téléphone par QR code : rien à taper à la télécommande.
Smart TV
Inscription : un QR code ouvre le parcours sur le téléphone, la TV avance seule.
Smart TV
Offre : trois cartes parcourues avec ◀ ▶, conditions affichées en permanence.

Ce que le client attendait

Six objectifs business : convertir plus de visiteurs, réduire les résiliations, fidéliser, augmenter l'engagement et le revenu par abonné, et se démarquer des grandes plateformes. Les problèmes relevés avant la refonte expliquaient une bonne partie des pertes :

  • interface surchargée, recherche et recommandations peu pertinentes : trouver quoi regarder prenait du temps ;
  • fiches vidéo trop pauvres, d'où une hésitation avant de lancer la lecture ;
  • inscription trop complexe, souvent abandonnée avant la conversion ;
  • reprise de lecture peu visible et expérience différente d'un appareil à l'autre ;
  • gestion de l'abonnement peu claire, qui poussait vers la résiliation.

Les résultats, six mois après

Conversion visiteur → abonné

4,1 %

avant 2,8 %

Churn mensuel

4,9 %

avant 7,2 %

Rétention à 3 mois

79 %

avant 68 %

Net Promoter Score

+38

avant +12

IndicateurAvantAprès
Abandon de l'inscription56 %34 %
Clics sur les recommandations12 %24 %
Durée d'utilisation par semaine4 h 206 h 10
Vidéos regardées jusqu'au bout42 %61 %
Satisfaction (CSAT)68/10084/100
Renouvellement annuel61 %74 %
Abonnés actifs495 000575 000
Revenu mensuel estimé4,60 M€5,38 M€
Mesures relevées six mois après la refonte.

Deux niveaux de tokens, pas un

Les valeurs brutes, couleurs, espacements, rayons, vivent dans une collection de primitives. Une seconde collection, sémantique, nomme les intentions : surface, bordure, texte, état. Les composants ne consultent que cette seconde couche. C'est ce qui permet de changer une couleur de marque sans ouvrir un seul composant, et de discuter avec le client en termes de rôles plutôt que de codes hexadécimaux. La même logique vaut au-delà de la couleur : typographie, espacements, rayons, épaisseurs de bordure, durées d'animation et points de rupture sont eux aussi des variables.

PrimitivesCouleur, espace, rayonSémantiquesSurface, bordure, texteComposantsVariants, étatsPatternsAssemblages d'écranLes composants ne pointent jamais sur une primitive : ils passent par le niveau sémantique.
Primitives, sémantiques, composants, patterns : chaque niveau ne connaît que le précédent.
À gauche les primitives, des valeurs brutes nommées par palier. À droite la couche sémantique : bg/base pointe sur color/ink/900, border/accent sur color/fuchsia/500. Changer le fond du produit revient à déplacer ce lien, pas à ouvrir les écrans.

Un token sémantique donne un nom à une intention. C'est ce nom, et non la couleur, que le développeur retrouve dans le code.

Du token au composant

Les composants sont construits en auto layout, avec variants et component properties, et remplis uniquement par des tokens sémantiques. Quand on sélectionne une modale et qu'on lit bg/overlay dans son remplissage plutôt qu'un code couleur, c'est le signe que le système tient : aucune valeur n'est posée en dur dans un composant.

Toasts, modale et menu déroulant. Dans l'inspecteur, le remplissage de la modale est bg/overlay, un token et pas une couleur.

Ce qui a été livré

  • un kit Figma : les tokens sous forme de variables, les composants et les patterns publiés en bibliothèque d'assets ;
  • des guidelines en PDF : anatomie, états, règles d'usage, contraintes d'accessibilité ;
  • un skill Claude de contrôle : il relit les interfaces développées et signale les écarts aux guidelines.

Le contrôle qualité fait partie de la livraison

Un design system se dégrade au moment où il quitte Figma. Le développeur interprète, les cas non documentés s'inventent, et six mois plus tard le produit ne ressemble plus à la bibliothèque. Le troisième livrable répond à ça. Le skill relit les interfaces produites, les confronte aux guidelines et renvoie les écarts. Le contrôle devient une étape du développement, au lieu d'une revue de design qu'on repousse.

Kit FigmaVariables, assets, PDFDéveloppementNouvelles interfacesSkill ClaudeContrôle des guidelinesÉcarts renvoyés au développement
Le kit alimente le développement ; le skill referme la boucle en renvoyant les écarts.

Accessibilité

Les contraintes WCAG sont portées par les tokens sémantiques : un couple texte/surface est validé une fois, au niveau du système, et tout composant qui l'emploie hérite du contraste. Vérifier un écran revient alors à vérifier qu'il n'a pas contourné le système.