Design UI/UX

Un design d'interface qui résiste au contact des vrais utilisateurs

Nous concevons des interfaces à partir de preuves : ce que les gens cherchent à faire, là où ils échouent aujourd'hui, et ce que la réalisation peut raisonnablement porter.

Les refontes qui changent tout et n'améliorent rien

Une refonte commence généralement parce que le site ou le produit fait daté. Elle se termine par un nouveau langage visuel, un nouveau jeu de composants, et un taux de conversion à peu près là où il était — parfois plus bas, parce qu'une interface familière a été remplacée par une interface inconnue sans que personne n'ait mesuré ce qui fonctionnait.

La raison en est que l'apparence constituait le brief. Personne n'a établi à quelle étape les gens échouaient, ce qu'ils cherchaient à accomplir, ni quels éléments de l'ancienne interface portaient le résultat. Les décisions de design se sont donc prises au goût, ce qui est indiscutable et par conséquent intestable.

L'autre échec courant est l'inverse : de superbes fichiers de design impossibles à construire tels quels, ou décrivant quarante variantes de bouton sans aucun système derrière. Un design qui ignore la réalisation devient une négociation pendant le développement, et cette négociation est généralement remportée par ce qui va le plus vite.

Ce que le travail produit

Une recherche proportionnée à la décision

Revue des statistiques, enregistrements de sessions, tickets de support et quelques conversations avec des utilisateurs. Pas un programme de recherche pour lui-même — assez de preuves pour savoir quel problème mérite d'être résolu avant que quiconque n'ouvre un outil de design.

Les parcours avant les écrans

Les chemins que les gens empruntent dans le produit, y compris les erreurs et les cas limites que l'on découvre habituellement en cours de développement et que l'on conçoit dans l'urgence. Un parcours juste élimine la plupart des écrans que vous croyiez nécessaires.

Wireframes et prototypes

Basse fidélité d'abord, pour arrêter la structure sans discuter de couleurs, puis des prototypes interactifs pour les parcours qui portent un vrai risque. Tester un prototype coûte infiniment moins cher que tester une réalisation.

Un design system, pas un tas d'écrans

Tokens, composants et états documentés comme un système. C'est ce qui maintient la cohérence du produit à mesure qu'il grandit, et ce qui permet aux développeurs de construire de nouveaux écrans sans réclamer un nouveau design à chaque fois.

L'accessibilité conçue dès l'origine

Contraste des couleurs, ordre de focus, taille des cibles, étiquetage des formulaires et parcours clavier traités dans le design plutôt que soulevés lors d'un audit ultérieur. Rattraper l'accessibilité coûte considérablement plus cher que la concevoir.

Une spécification exploitable par les développeurs

Comportement responsive, états, règles d'espacement et détail des interactions spécifiés. Parce que nous développons aussi, la passation tient compte de ce qu'il est réaliste d'implémenter — et nous restons disponibles pendant la réalisation au lieu de disparaître à la livraison.

Les technologies que nous employons

Design

  • Figma
  • Design tokens
  • Bibliothèques de composants

Recherche

  • Revue analytique
  • Rejeu de session
  • Tests d'utilisabilité

Passation

  • Prototypes interactifs
  • Spécification
  • Implémentation Tailwind

Normes

  • WCAG 2.2 AA
  • Design responsive
  • Documentation du design system

Nous choisissons parmi celles-ci selon les besoins du projet et selon ce que votre équipe saura maintenir après la livraison — et non selon nos préférences. Lorsqu'une pile technique est déjà en place et saine, nous travaillons avec elle.

Quand faire intervenir le design

Avant la réalisation, pas pendant

Arrêter la structure et les parcours avant le début du développement est le moment le moins cher pour changer d'avis, et cela supprime les décisions de design prises en cours de route par celui qui écrit le code ce jour-là.

Quand une métrique précise est bloquée

Un travail ciblé sur un tunnel, une inscription ou une commande, où il existe un chiffre défini à faire bouger et où le changement peut être mesuré.

Quand un produit est devenu incohérent

Des fonctionnalités ajoutées au fil des ans par différentes personnes, chacune introduisant des motifs légèrement différents. Un design system les consolide et arrête la dérive.

Mise en conformité d'accessibilité

Lorsqu'un audit a produit des constats, ou qu'un acheteur public ou grand compte exige une déclaration de conformité.

Les questions qu'on nous pose à ce sujet

Pouvez-vous concevoir sans développer ?

Oui. Nous livrons un design system documenté et une spécification prête à construire pour vos propres développeurs, et nous pouvons rester disponibles pendant la réalisation pour répondre aux questions et confronter le résultat au design.

Quelle quantité de recherche est nécessaire ?

Moins que ce que les agences vendent souvent, et plus que zéro. Pour la plupart des projets, quelques jours de revue analytique, de lecture des tickets de support et cinq ou six conversations avec des utilisateurs font remonter les problèmes significatifs. Des programmes de recherche plus lourds se justifient quand le coût de concevoir la mauvaise chose est élevé.

Une refonte améliorera-t-elle la conversion ?

Seulement si elle vise la raison pour laquelle les gens partent aujourd'hui. Une refonte entreprise pour l'apparence seule modifie le résultat de façon imprévisible, dans un sens comme dans l'autre. Si la conversion est l'objectif, nous commencerions par mesurer où le tunnel perd les gens et concevrions contre cela, puis nous vérifierions le changement au lieu de le supposer.

Travaillez-vous avec notre charte graphique ?

Oui, couramment. Nous traduisons les éléments de marque existants en un design system numérique fonctionnel — ce qui revient généralement à trancher des questions auxquelles une charte print ne répond pas, comme les états d'interaction, les vues de données denses et les paires de contraste accessibles.

Comment traitez-vous l'accessibilité ?

Nous concevons selon le WCAG 2.2 AA comme socle : contraste, visibilité du focus, taille des cibles, étiquetage des formulaires et utilisation au clavier. Nous vérifions avec des outils automatisés et des contrôles manuels au clavier et au lecteur d'écran. Pour une déclaration formelle de conformité, nous recommanderions un audit indépendant en complément de notre travail.

Un projet de design ui/ux ?

Envoyez-nous le problème et les contraintes que vous connaissez déjà. Nous reviendrons vers vous avec ce que nous pensons qu'il exige, une approche et un ordre de grandeur réaliste — ou pour vous dire que ce n'est pas un travail pour lequel nous sommes les bons.

Démarrer la conversation