Choisir le moment que l’application doit faciliter
Une idée d’application commence souvent par une liste qui grandit vite : un tableau de bord, des filtres, des statistiques, des préférences. Dans mes projets personnels, je trouve plus utile de revenir à un moment précis. Qui ouvre l’application ? Qu’est-ce que cette personne essaie de faire ? Que doit-elle retrouver ensuite ? Ces questions donnent un point de départ plus concret qu’une collection de fonctions intéressantes. Elles permettent aussi de remarquer les informations qui manquent encore avant de réfléchir à la disposition de l’écran.
DevFlow Studio et Practicora explorent des besoins différents, mais ce retour à l’usage reste utile dans les deux cas. Retrouver ses tâches et le contexte d’un projet ne demande pas le même parcours que consigner une journée de stage. Le premier écran doit rendre ce besoin compréhensible. Il n’a pas à présenter toute l’application : il doit donner une prochaine action claire et montrer ce que cette action permettra de conserver ou de retrouver.
Écrire un petit parcours avant de dessiner toute l’application
Pour prendre un exemple imaginé, une personne pourrait vouloir noter une journée de stage avant d’en oublier les détails. Un premier parcours peut tenir en quelques étapes : ouvrir la saisie, renseigner la date et les heures, décrire le travail, enregistrer, puis retrouver la journée. Cette description fait apparaître des décisions que le mot « journal » cachait encore. Faut-il tout remplir pour garder une note ? Comment distinguer un brouillon d’une journée prête à figurer dans un bilan ?
Je cherche alors à formuler un résultat observable. Après l’enregistrement, la journée doit apparaître au bon endroit avec les informations saisies. Si un champ empêche de continuer, le message doit expliquer comment le corriger. Cela donne un cadre à la première version et à sa vérification. Les rapports détaillés, les tableaux comparatifs ou les réglages plus fins peuvent attendre tant que le parcours de base ne permet pas encore de conserver quelque chose d’utile.
Suivre la donnée au-delà du formulaire
Un formulaire visible ne suffit pas à rendre un parcours fonctionnel. Il faut savoir ce que représente chaque valeur, où elle sera conservée et comment elle reviendra à l’écran. Une date peut désigner une journée de travail ou le moment d’une modification ; un total peut venir des éléments saisis ou d’un calcul. Clarifier ces différences tôt évite de construire plusieurs écrans autour de significations différentes. Je préfère pouvoir suivre une information de sa saisie jusqu’à sa prochaine lecture.
Le contexte du projet compte dans ces décisions. Le cœur de DevFlow Studio conserve ses données dans le navigateur avec IndexedDB et Dexie, tandis que Practicora s’appuie sur Supabase et des relations entre journées, objectifs et rapports. Ces choix ne sont pas interchangeables. Même pour un premier écran, il faut regarder ce qui appartient à la personne, ce qui peut être modifié et ce qui doit rester cohérent lorsqu’on change de vue ou que l’on reprend son travail.
Prévoir autre chose que l’écran déjà rempli
La capture la plus agréable est souvent celle où toutes les données sont présentes. Le premier usage commence pourtant parfois par une liste vide. Cet état doit aider à comprendre quoi faire, sans obliger à deviner le rôle d’un bouton. Une recherche sans résultat pose une autre question : comment revenir à la liste ? Une sauvegarde en cours ou un message d’erreur doit également laisser une suite possible. Ces états font partie du parcours dès le départ.
Je regarde aussi la place que prennent les mots. Un libellé ambigu ajoute une hésitation ; une phrase trop longue peut cacher l’action sur un petit écran. Le clavier, le focus visible et l’ordre des éléments servent à parcourir l’interface autant que les espacements. Une première version peut rester sobre tout en tenant compte de ces détails. Ils permettent de vérifier l’usage avec quelque chose de proche du quotidien, au lieu d’un écran qui fonctionne seulement dans une situation idéale.
Comparer le résultat au besoin de départ
Quand le parcours est disponible, je reviens à sa description initiale. Est-il possible de commencer, de terminer l’action et de retrouver le résultat ? Je vérifie aussi quelques situations voisines : une valeur manquante, un retour en arrière, une recherche effacée ou le rechargement de la page. Le choix des vérifications dépend du changement. Un test utile doit répondre à une question sur le comportement, et une inspection du parcours reste nécessaire pour voir les hésitations que les assertions ne décrivent pas.
Ce premier essai peut montrer que le problème était mal formulé. Peut-être qu’un champ demande une information indisponible à ce moment, ou que l’enregistrement mène à une vue qui ne montre pas ce que l’on vient de faire. Reprendre cette étape fait partie du développement. Je préfère garder une trace de l’écart observé et ajuster une petite partie : cela rend plus facile de comprendre ce que le changement suivant améliore réellement.
Laisser la prochaine étape venir de l’essai
Un premier écran qui fonctionne ne prouve pas que toute l’idée est prête. Il donne plutôt un appui pour choisir la suite. Si les données sont difficiles à retrouver, une vue de consultation sera peut-être plus utile qu’un nouveau graphique. Si la saisie demande trop d’effort, simplifier le formulaire peut passer avant une autre fonctionnalité. La prochaine étape devient plus précise quand elle répond à une difficulté observée dans le parcours.
C’est ce que je cherche dans mes projets : passer d’une intention assez large à une action que l’on peut essayer, puis laisser cet essai éclairer les décisions. Une note sur le besoin, quelques limites explicites et une vérification concrète suffisent déjà à rendre le travail plus facile à reprendre. L’application peut grandir ensuite, avec un point de départ que l’on sait expliquer et un premier parcours sur lequel revenir.