Des parcours testés, pas supposés
Nous partons de ce que les gens viennent faire, observé ou raconté par ceux qui répondent au téléphone. Une hypothèse validée avant l’intégration coûte cent fois moins qu’après.
Des interfaces que vos utilisateurs
traversent sans y penser.
Une interface réussie ne se remarque pas. Nous concevons des parcours et des écrans à partir de vos usages réels et de vos vrais contenus, sur un site à créer comme sur un produit déjà en service.
UX/UI design
D’abord ce que les gens viennent faire, ensuite à quoi l’écran ressemble.
Bénéfices
Trois écarts qui coûtent cher et que la conception évite
Les problèmes d’interface se paient au développement, quand il faut refaire. Voici les trois qui reviennent le plus souvent.
Des maquettes sur vos contenus
Un écran dessiné sur du texte de remplissage se déforme au moment de la vraie saisie. Nous utilisons vos titres, vos photos et vos libellés, y compris les plus longs.
Un système, pas des écrans
Chaque composant est décrit une fois, avec ses états et ses variantes. La page suivante se compose au lieu de se redessiner, et l’ensemble reste cohérent en évoluant.
Notre méthode
Quatre étapes, et des décisions qui se justifient.
Chaque livrable sert à trancher quelque chose. Rien n’est produit pour remplir une phase.
- (01)
Comprendre les usages
Entretiens avec vos équipes, lecture des demandes entrantes, des statistiques et des retours clients. On en sort avec les tâches que l’interface doit rendre faciles, classées par fréquence.
- (02)
Structurer les parcours
Arborescence, enchaînement des écrans, points de décision et cas d’erreur. C’est l’étape la moins spectaculaire et la plus rentable, parce qu’elle se corrige en une heure.
- (03)
Dessiner et éprouver
Maquettes sur vos contenus réels, en mobile d’abord. Les écrans sont mis entre les mains de quelques utilisateurs avant d’être validés, pas après la mise en ligne.
- (04)
Livrer un système
Composants, états, espacements et règles typographiques sont remis documentés. Les développeurs intègrent des règles, pas des captures d’écran à interpréter.
Cas d’usage
Système
Une bibliothèque de composants, pas une collection d’écrans.
Un projet livré en maquettes isolées se dégrade dès la première page ajoutée par quelqu’un d’autre. Un système décrit les briques et leurs règles, ce qui permet à vos équipes de composer de nouvelles pages sans nous, et sans que l’ensemble se disloque.
- Composants avec leurs états et variantes
- Échelles typographiques et d’espacement
- Contrastes et tailles de cibles vérifiés
- Documentation remise aux développeurs
Cas client
Comeet, un outil de suivi devenu un poste de pilotage.
Une plateforme de wedding planning dont les données étaient justes mais illisibles. Nous avons repensé la logique fonctionnelle, puis conçu une interface où chaque utilisateur retrouve ses tâches, son budget, ses invités et son avancement, sans avoir à les chercher.
÷2
sur le temps de gestion des projets
0
double saisie et erreur de suivi
Temps réel
pour la synchronisation de chaque module
Nos engagements
Des critères vérifiables, pas des intentions.
Ces quatre engagements se contrôlent sur les maquettes livrées. L’adoption d’une interface dépend aussi de vos utilisateurs, nous ne la promettons pas.
AA
Le niveau de contraste visé sur chaque texte et chaque état.
44 px
La taille minimale des éléments à toucher, sur mobile.
0 lorem
Aucune maquette validée sur du texte de remplissage.
Mobile d’abord
Les écrans étroits sont dessinés en premier, pas adaptés ensuite.
Questions fréquentes
Avant de commencer.
Quelle différence entre UX et UI ?
L’UX décide de ce que l’interface permet de faire et dans quel ordre. L’UI décide de son apparence et de son comportement. Les deux se font ensemble, mais la première commande la seconde : un bel écran sur un parcours mal posé reste difficile à utiliser.
Peut-on intervenir sur un produit déjà en ligne ?
Oui, et c’est fréquent. On part alors de ce qui existe, des statistiques d’usage et des retours du support, pour traiter d’abord les écrans où les gens échouent. Une refonte totale n’est pas toujours la bonne réponse.
Faites-vous des tests utilisateurs ?
Oui, à petite échelle et tôt. Cinq à six personnes sur un prototype suffisent à faire remonter la majorité des blocages. Ce n’est pas une étude statistique, c’est un moyen de ne pas développer une hypothèse fausse.
Quels livrables recevons-nous ?
Les parcours, les maquettes des écrans clés dans leurs états, la bibliothèque de composants et ses règles, plus la documentation d’intégration. Les fichiers sources vous appartiennent.
Pouvez-vous travailler avec nos développeurs ?
Oui. C’est même le cas de figure où le système de composants sert le plus, puisqu’il donne à votre équipe des règles à appliquer plutôt que des écrans à deviner.
Commençons par ce que vos utilisateurs viennent faire.
Un échange pour cadrer les usages, le périmètre et les écrans à traiter en premier, puis une proposition chiffrée.
Parler de mon projet