Design UI/UX pour les produits web, mobiles et SaaS

Si le produit n’est encore qu’une idée, cela commence par de la recherche UX et du wireframing — des parcours et des boîtes grises, où se tromper coûte une après-midi. Si les écrans existent et que quelque chose ne fonctionne pas, cela commence par un audit, car une refonte est une façon coûteuse de découvrir quelles parties allaient bien.

Si les décisions sont déjà arrêtées et que vous avez besoin que l’interface soit conçue, cela commence par le design d’UI web, d’application mobile ou de produit SaaS selon ce qui est construit. Les design systems interviennent dès que plus d’une personne va construire des écrans.

Les écrans qui font échouer un design ne sont jamais ceux de la présentation. Ce sont l’état vide avant qu’aucune donnée n’existe, le nom trois fois plus long que le texte de substitution, la session expirée, la permission qu’un utilisateur n’a pas, l’erreur qui arrive après l’envoi du formulaire.

Ceux-là sont conçus ici plutôt que laissés à celui qui construit. C’est l’essentiel de la différence entre un design qui survit à l’implémentation et un design qui se fait silencieusement réinterpréter au moment de la construction.

Chaque livrable de design est structuré pour le handoff : des composants plutôt que des groupes détachés, de l’auto layout qui se comporte comme le fait le CSS, des tokens de couleur, de typographie et d’espacement, et des états montrés plutôt que décrits.

C’est une habitude qui vient du fait de construire des front ends autant que de les concevoir : le fichier est écrit pour la personne qui doit le transformer en code, parce qu’assez souvent cette personne, c’est moi.