Design UX et UI
Un design livré sous forme d’images contient toujours des décisions qui ne survivent pas à la construction. Non par négligence du designer, mais parce qu’une image n’a qu’un état à montrer, alors qu’un logiciel doit tous les gérer : vide, en chargement, trop long, en erreur, hors ligne, et celui où le nom de l’utilisateur fait quarante caractères.
Nous concevons aux côtés de l’ingénierie plutôt qu’en amont. Le livrable est un système qui fonctionne plutôt qu’une image de système.
Comment nous travaillons
Les jetons
Couleur, typographie et espacements décidés avant le premier écran.
Les vrais états
Vide, chargement, erreur et trop de données, conçus exprès.
Le clavier d’abord
Clavier et lecteur d’écran conçus, pas testés à la fin.
La livraison
Un dépôt de code, pas un document qu’on n’ouvre plus.
Les jetons avant les écrans
Nous fixons tôt la couleur, l’échelle typographique, les espacements et les états sous forme de jetons nommés, et chaque écran est ensuite assemblé à partir d’eux. Cela semble bureaucratique et c’est l’inverse : c’est ce qui rend un design cohérent sans que personne n’ait à le surveiller, et ce qui fait d’un changement de palette une modification d’une ligne plutôt qu’une semaine à chercher chaque endroit où une couleur a été saisie à la main.
Le contraste est vérifié au moment où les jetons sont choisis, pas après la validation. Sur ce site, chaque jeton de couleur porte son rapport mesuré en commentaire à côté, y compris ceux qu’il a fallu relever par rapport à la remise initiale et de combien. Un jeton choisi pour une raison devrait dire laquelle.
De vrais états, pas seulement le chemin heureux
Pour chaque composant nous spécifions son apparence à vide, en chargement et en erreur, plus le focus et l’état désactivé. L’essentiel des frictions ressenties dans un logiciel vit exactement dans ces états, et ce sont ceux qu’un développeur invente dans l’urgence en fin d’itération si un designer ne les a pas tranchés.
Le clavier et le lecteur d’écran font partie du design
L’ordre de focus, sa visibilité et ce qu’un contrôle annonce sont des décisions de design, pas des détails d’implémentation. Si une fenêtre modale piège mal le focus ou qu’une liste déroulante personnalisée ne s’utilise pas au clavier, c’est un design qui n’y a pas pensé et non un bug apparu à la construction.
Nous concevons aussi pour le sens droite à gauche comme direction à part entière. L’hébreu n’est pas une version miroir de la mise en page anglaise : cela change où se placent les icônes, comment se comporte un texte mêlant latin et hébreu dans une même ligne, et quelles parties d’une interface ne doivent pas être inversées du tout.
La livraison est un dépôt, pas un document
Quand nous construisons, le livrable est le code. Quand une autre équipe construit, nous transmettons des jetons, des composants et les spécifications d’états plutôt que des exports à plat, et nous restons disponibles pendant la construction, parce que les questions qui comptent arrivent toujours pendant l’implémentation.
Ce que nous ne faisons pas
Nous ne créons pas d’identité de marque à partir de zéro : nommage, systèmes de logo, stratégie de marque. Nous travaillons avec la marque que vous avez, ou aux côtés du studio qui l’a faite. S’il vous faut créer une marque, il vous faut un studio de marque, et nous travaillerons volontiers à partir de ce qu’il produira.
Nous ne produisons pas non plus de design déconnecté de la construction. Si vous voulez des écrans à confier à un développeur que vous n’avez pas encore choisi, nous sommes probablement le mauvais prestataire : la valeur que nous ajoutons est dans les décisions qui n’apparaissent que lorsque quelqu’un doit construire la chose.
De la recherche, à proportion
Nous faisons la recherche dont la décision a réellement besoin. Pour un tunnel de commande emprunté par des milliers de personnes par jour, ce sont des tests d’utilisabilité avec de vrais utilisateurs et cela se rembourse. Pour un outil interne utilisé par neuf personnes, c’est parler aux neuf personnes, ce qui prend un après-midi et se révèle plus juste que n’importe quel substitut.
Ce que nous évitons, c’est le théâtre de la recherche : un mois d’ateliers produisant des artefacts qui n’informent rien, sur un projet dont les vraies contraintes étaient connues dès le premier jour.
À voir aussi
Design et construction ensemble, c’est généralement du développement web ou une plateforme sur mesure. Quand l’interface est la vitrine d’une boutique, voir l’ingénierie e-commerce.
Questions fréquentes
Pouvez-vous travailler à partir de notre charte existante ?
Oui, c’est le cas normal. Nous signalerons les endroits où la charte ne survit pas au contact d’une interface, le plus souvent le contraste des couleurs sur petit texte et les états que la marque n’a jamais eu à définir, et nous proposerons le plus petit changement qui corrige cela plutôt qu’une refonte.
Travaillez-vous sur Figma ?
Oui, et nous le traitons comme un outil de travail plutôt que comme le livrable. Le livrable est le système construit.
Peut-on refondre sans tout reconstruire ?
Généralement oui. Un changement au niveau des jetons de couleur, de typographie et d’espacement peut déplacer un produit très loin visuellement sans toucher à sa structure, et c’est nettement moins cher qu’une reconstruction. Nous vous dirons quand la structure est réellement le problème.
Comment traitez-vous l’accessibilité dans le design ?
Le contraste est vérifié au choix des jetons. Les états de focus sont spécifiés par composant. Les parcours clavier et les annonces font partie de la spécification. Le faire ici ne coûte presque rien ; le découvrir au lancement, c’est refondre.
Et si nous avons déjà un développeur ?
Très bien, et c’est courant. Nous transmettons des jetons, des composants et des spécifications d’états plutôt que des fichiers à plat, et nous restons joignables pendant la construction. Nous préférons répondre aux questions pendant que la chose se fait plutôt que la relire ensuite en listant ce qui a dérapé.
Plus de services
La suite
Dites-nous ce que vous construisez, ou ce qui casse.