Pourquoi confronter les constats utilisateurs au code avant de construire ?

Parce qu’une étude mêle de vrais défauts à des souhaits et à des choses qui marchent déjà. Cinq constats sur dix-sept sont tombés à la vérification, et les bâtir aurait coûté du temps et dégradé l’interface.

Quelle différence entre un design system et une bibliothèque de composants ?

La bibliothèque, ce sont les composants. Le système, ce sont les règles qui décident de ce qui a le droit d’exister : quelles couleurs existent, quels espacements sont permis et ce qui se passe quand une chose manque. Les règles tiennent un produit qui grandit vite.

Pourquoi OKLCH comme espace colorimétrique ?

OKLCH est perceptuellement uniforme, donc une échelle à pas réguliers paraît régulière et le contraste se calcule. Une variante sombre devient une redéfinition de la clarté dans le même système.

Que veut dire qu’un état vide donne une direction ?

Que la surface explique à quoi elle sert et propose une étape suivante quand il y a zéro ligne à montrer. Un nouvel arrivant trouve une consigne, et la recherche et les filtres restent masqués jusqu’à ce qu’il y ait matière à chercher.

Pouvez-vous bâtir un design system pour notre produit existant ?

Oui. Le travail commence par un inventaire des valeurs déjà en usage, les rassemble en un jeu de jetons, puis migre vue par vue. Le système est livré comme du code dans votre dépôt et comme une référence écrite.

Combien de vues le travail d’interface a-t-il couvert ?

Une quarantaine de vues réparties entre le chat, les documents, les signaux, les tâches, les espaces de travail et une partie entretiens publique. Toutes partagent le même jeu de jetons et la même bibliothèque de composants.

Réalisations

voxcog : un design system en code et des tests utilisateurs

Torn StudioClient: voxcogLivré 2026-08-26

La relation du studio au client

voxcog est un produit que Torn Studio a construit et dans lequel le studio détient une participation. Le studio a assuré la direction produit, l’architecture et la réalisation jusqu’à la livraison en août 2026.

Réponse courte

Torn Studio a posé l’interface de voxcog sur un design system en code, avec des jetons en OKLCH et un jeu de règles documenté. Une étude utilisateurs a produit dix-sept constats ; onze ont tenu, un en partie et cinq sont tombés à la confrontation au code. Douze changements sont partis en production.

La commande

voxcog avait besoin d’une interface cohérente sur une quarantaine de vues construites par une seule personne en quelques mois, et devait savoir lesquels des problèmes remontés étaient réels avant de refaire quoi que ce soit.

Ce qui rendait la tâche difficile

Une interface construite à vive allure par une seule personne dérive visuellement dès que chaque vue choisit ses propres couleurs et ses propres espacements.
Une étude utilisateurs livre de vrais défauts mêlés à des souhaits, et bâtir tout ce qui remonte est le chemin le plus court vers les mauvaises choses.
Le produit devait être prêt au lancement, ce qui exige que les états vides et les surfaces juridiques soient du travail achevé.

Des chiffres vérifiables

17constats dans une étude utilisateurs: Onze ont tenu, un en partie, cinq sont tombés face au composant qu’ils désignaient. L’évaluation reste dans le dépôt avec le motif de chaque rejet.
12changements livrés depuis cette étude: Les cinq rejetés restent dans le document avec leur motif, si bien que le lecteur suivant voit ce qui a été testé puis écarté.
373fichiers de test: Placés à côté du code qu’ils couvrent. Les évaluations de l’agent figurent parmi eux et s’exécutent comme des commandes propres.
300lignes de plafond par fichier: La règle qui garde les composants divisibles. Elle figure dans le fichier de consignes du dépôt et vaut pour tout le neuf.

Comment cela a été fait

Les jetons comme unique source visuelle

Couleur, typographie, rayons et ombres sont déclarés comme jetons en OKLCH et utilisés par variables. La règle a été consignée comme référence propre, si bien qu’une vue nouvelle hérite du système et y puise ses valeurs.

Chaque constat confronté au code d’abord

Les dix-sept constats de la campagne d’avril 2026 ont été lus un à un face au composant que chacun désignait. Onze ont tenu, un a tenu en partie, et cinq décrivaient en réalité une chose qui marchait déjà ou une fonction inexistante.

Des états vides qui donnent une direction

Les états vides trop maigres ont été réécrits en guides courts qui expliquent à quoi sert la surface et proposent une étape suivante. Les barres d’outils restent masquées tant qu’une liste est vide, si bien qu’un nouvel arrivant trouve une consigne.

La récupération de données comme un seul motif

Toute la lecture côté client est passée sur une couche de cache commune avec fabrique de clés et gestion d’erreurs partagée. Les boutons de rafraîchissement ont pu disparaître, car les listes savent désormais d’elles-mêmes quand elles sont périmées.

Technologies

React 19
Next.js 16
Tailwind CSS v4
shadcn/ui
OKLCH
TanStack Query
Playwright

Jusqu’où va cette preuve

Ceci montre une interface cohérente et une méthode qui sépare les vrais problèmes des souhaits. Sur la conversion, cela ne montre rien : voxcog a été livré avant le lancement, il n’existe donc aucun trafic à mesurer.

Preuves

Sur quoi repose cet article — une mesure que nous avons faite, une source datée ou une décision et son coût.

Mesure2026-04-09
Combien des dix-sept problèmes d’interface remontés étaient réels
Objet mesuré: l’application voxcog, rapport de recherche du 2 avril 2026
Méthode: Chaque constat a été lu face au composant qu’il désignait avant toute ligne de code, et le résultat noté comme tient, en partie ou tombe.
Résultat: 11 ont tenu, 1 en partie, 5 sont tombés
Décision2026-04-09
Les cinq constats rejetés ont été consignés avec le motif du rejet.
Ce qu’elle a coûté: La campagne a livré douze changements là où dix-sept étaient demandés, et les idées de fonctionnalités du rapport sont restées dehors comme hypothèses.
Décision2026-03-22
Tout le visuel s’exprime en jetons OKLCH et s’utilise par variables.
Ce qu’elle a coûté: Un coût unique au démarrage et une règle à tenir : une couleur nouvelle réclame un jeton nouveau avant tout usage.

Questions fréquentes

Pourquoi confronter les constats utilisateurs au code avant de construire ?: Parce qu’une étude mêle de vrais défauts à des souhaits et à des choses qui marchent déjà. Cinq constats sur dix-sept sont tombés à la vérification, et les bâtir aurait coûté du temps et dégradé l’interface.
Quelle différence entre un design system et une bibliothèque de composants ?: La bibliothèque, ce sont les composants. Le système, ce sont les règles qui décident de ce qui a le droit d’exister : quelles couleurs existent, quels espacements sont permis et ce qui se passe quand une chose manque. Les règles tiennent un produit qui grandit vite.
Pourquoi OKLCH comme espace colorimétrique ?: OKLCH est perceptuellement uniforme, donc une échelle à pas réguliers paraît régulière et le contraste se calcule. Une variante sombre devient une redéfinition de la clarté dans le même système.
Que veut dire qu’un état vide donne une direction ?: Que la surface explique à quoi elle sert et propose une étape suivante quand il y a zéro ligne à montrer. Un nouvel arrivant trouve une consigne, et la recherche et les filtres restent masqués jusqu’à ce qu’il y ait matière à chercher.
Pouvez-vous bâtir un design system pour notre produit existant ?: Oui. Le travail commence par un inventaire des valeurs déjà en usage, les rassemble en un jeu de jetons, puis migre vue par vue. Le système est livré comme du code dans votre dépôt et comme une référence écrite.
Combien de vues le travail d’interface a-t-il couvert ?: Une quarantaine de vues réparties entre le chat, les documents, les signaux, les tâches, les espaces de travail et une partie entretiens publique. Toutes partagent le même jeu de jetons et la même bibliothèque de composants.

Dites-nous ce que vous voulez construire

Trente minutes, sans frais, et une réponse franche sur le fait que nous soyons ou non le bon studio.

Réserver un échange Voir les tarifs