L’UX/UI externalisé sur un produit

Confier la conception d’une interface est plus délicat que confier un visuel. Une interface encode des décisions de produit : ce qu’on met en avant, ce qu’on cache, ce qu’on rend facile ou difficile.

Déléguer sans le voir revient à laisser quelqu’un décider de votre produit.

À retenir

Le design d’interface se compose de deux choses qu’on nomme ensemble à tort. L’UX est un travail de conception qui suppose de connaître les utilisateurs et les objectifs. L’UI est un travail de mise en forme qui s’exécute à partir de décisions prises. Le second se délègue très bien, le premier demande un cadre solide.

UX UI externalisé

Ce que recouvrent les deux lettres

L’UX concerne le fonctionnement : quels écrans, dans quel ordre, quelles informations à quel moment, comment un utilisateur atteint son objectif. Elle produit des parcours, des schémas, des arbitrages.

L’UI concerne l’apparence et le détail d’interaction : à quoi ressemble l’écran, comment sont hiérarchisées les informations, quels états, quelles animations.

La confusion coûte cher dans les deux sens. Confier une refonte de parcours à quelqu’un qui ne connaît ni vos utilisateurs ni votre modèle produit une interface jolie qui ne règle rien. À l’inverse, occuper un profil senior à ajuster des espacements est un gaspillage.

Ce qui se délègue très bien

Les maquettes à partir de parcours définis. Vous savez ce que doit faire l’écran, le designer le met en forme. C’est le cas le plus favorable.

La déclinaison responsive. Adapter une interface conçue pour un écran aux autres tailles. Travail méthodique et volumineux.

Les états et les cas limites. Erreurs, chargements, listes vides, contenus très longs. Ce sont eux qui font la qualité perçue d’un produit, et ils sont systématiquement oubliés faute de temps. Un profil dédié les traite bien.

La production de composants. Traitée dans le guide consacré au design system.

Les vérifications d’accessibilité. Contrastes, tailles de cible, navigation au clavier. Contrôlable objectivement.

Ce qui demande un cadre

Les décisions de parcours. Elles engagent le produit et le modèle économique. Elles peuvent être préparées à l’extérieur, elles se tranchent chez vous.

La priorisation. Quelle fonctionnalité mérite d’être visible, laquelle peut être enterrée dans un menu. C’est une décision produit déguisée en décision de design.

La recherche utilisateur. Elle se délègue sur la logistique (recrutement des participants, passation, retranscription) mais l’interprétation gagne à impliquer ceux qui décideront ensuite.

Ce qu’il faut fournir à un designer externe

Sans ces éléments, il concevra à partir d’hypothèses, et elles seront raisonnables mais fausses.

Qui sont les utilisateurs et ce qu’ils viennent faire. Pas des personas fictifs : des situations réelles.

Les contraintes techniques. Ce que le produit peut faire et ne peut pas faire. Une maquette irréalisable fait perdre deux cycles.

Les données réelles. Des exemples de contenus vrais, avec leurs longueurs et leurs cas moches. Une maquette conçue sur des contenus idéaux s’effondre en production.

Les décisions déjà prises et pourquoi. Rien n’est plus coûteux qu’un designer qui rouvre un arbitrage tranché il y a six mois.

Les indicateurs. Ce que le produit cherche à améliorer. Sans cela, le design se juge au goût.

Le mode d’échec le plus fréquent

Le designer produit des maquettes magnifiques, l’équipe technique les trouve infaisables ou trop coûteuses, et un compromis dégradé est implémenté sans que personne ne l’ait conçu.

Trois précautions l’évitent.

Impliquer un développeur dès la conception, même brièvement. Une remarque de dix minutes évite trois jours de travail inutile.

Concevoir à partir de ce qui existe déjà dans le produit plutôt qu’en repartant de zéro.

Valider la faisabilité avant la finition, pas après.

Travailler à distance sur un produit

Le rythme compte plus que les outils.

Un point court et fréquent vaut mieux qu’une revue longue et espacée : sur un produit, les questions arrivent en continu et une question bloquée trois jours arrête le travail.

Les maquettes doivent être consultables par tous, avec des commentaires posés directement dessus. Les retours par message perdent le contexte.

Enfin, versionnez. Sur un produit qui évolue, savoir quelle maquette correspond à quelle version évite des malentendus coûteux au moment du développement.

FAQ

Questions fréquentes

Peut-on externaliser tout le design produit ?

La production, oui. Les arbitrages, seulement si le prestataire est intégré durablement et connaît le produit. Un prestataire ponctuel ne peut pas porter ces décisions.

Faut-il un designer dédié ou une agence ?

Sur un produit qui évolue en continu, la connaissance accumulée fait la différence, ce qui plaide pour un profil dédié. Sur une refonte ponctuelle, une agence spécialisée apporte des moyens.

Comment juger une proposition de design ?

Sur les objectifs, pas sur le goût. Demandez pourquoi tel élément est mis en avant, ce que cela cherche à produire.

Le designer doit-il savoir coder ?

Non, mais il doit comprendre les contraintes techniques. Un designer qui ignore ce que coûte une animation propose des choses irréalisables.

Pour aller plus loin

Le système de composants est traité dans le design system, à quoi il sert et quand. L’organisation des retours relève du guide sur les cycles de validation à distance.

Rouge Hexagone fournit des profils dédiés à la conception d’interface. Voir la fiche designer UX/UI.

Un projet à externaliser ?

Parlons de votre besoin — devis gratuit, réponse en moyenne sous quelques heures.