Mon process en 6 étapes
Définir le problème
Avant de prototyper quoi que ce soit, je passe du temps à comprendre qui est l'utilisateur et pourquoi son problème mérite d'être résolu. Je pose trois questions : Qui ? Quoi ? Pourquoi ?
Saisir les données statisques durant un match n'est jamais une partie de plaisir. Sur les applications disponible, c'est tout à fait possible de le faire. Mais en analysant des
Définir les métriques de succès
Avant de coder une seule ligne, je définis comment je vais mesurer le succès. Pas des vanity metrics (nombre d'utilisateurs), mais des indicateurs qui montrent que le problème est vraiment résolu.
Pour Tournament, ma métrique clé était : "Temps moyen pour créer un tournoi complet" (cible : moins de 5 minutes). Pas "nombre de tournois créés". Ça m'a forcé à simplifier l'UX plutôt qu'à ajouter des features.
Prototyper rapidement
Le prototype le plus simple et rapide qui permet de tester l'hypothèse. Souvent, c'est juste un wireframe cliquable ou même du papier. L'objectif : confronter l'idée à la réalité le plus vite possible.
Pour SlashType, j'ai d'abord créé un simple fichier texte avec des raccourcis clavier. Pas d'extension Chrome, pas de UI sophistiquée - juste la mécanique de base pour valider que "taper /email" pour insérer un template avait du sens. Prototype en 2 heures, validation en 1 journée.
Tester avec de vrais utilisateurs
Le prototype dans les mains d'utilisateurs réels le plus rapidement possible. J'observe sans intervenir : où ils bloquent, ce qu'ils comprennent intuitivement, ce qui les frustre. Les retours les plus précieux viennent du silence et des hésitations.
Pour l'aérateur de vin Calice, j'ai fait tester 15 prototypes imprimés 3D à des amateurs de vin. Le feedback critique : "C'est beau, mais je ne vois pas où verser le vin." Ça nous a fait retravailler tout l'ergonomie de l'embout. Sans ces tests, on aurait fabriqué 5000 unités inutilisables.
Itérer et améliorer
Prendre les retours, analyser les patterns, prioriser les changements. Je ne fais pas tous les ajustements demandés - je cherche les problèmes récurrents qui bloquent vraiment l'usage. Puis je recommence le cycle : prototype → test → itération.
Après la réalisation d'une première version prototype utilisable, il était de confronter le produit aux utilisateurs. Le produit a été laissé à plusieurs personnes pendant un mois pour l'utiliser en autonomie. Les défauts et détails d'amélioration ont été remontés. Cela a permis d'amémiorer grandement le côté pratique du produit, et son côté compact.
Lancer et développer
Une fois la solution validée et le problème vraiment résolu, on peut passer au développement produit complet. À ce stade, je connais mes utilisateurs, je sais ce qui marche, j'ai des métriques claires. Le développement devient une exécution, pas une exploration.
Tournament a été développé en 2 semaines. Pourquoi si rapide ? grâce aux discussions préalables, aux recherches et itérations rapides avec des testeurs.
