Faire construire un écran conforme à sa description

Quand l’employer

À employer quand l'écran a été spécifié par écrit et qu'il faut le construire. À ne pas employer sans description écrite : vous obtiendriez un écran plausible, et vous n'auriez rien pour le refuser.

Les 4 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{DESCRIPTION_DE_LECRAN}

Quelle description écrite fait foi, et où se trouve-t-elle ?

Pourquoi ce trou existe. Un écran construit de mémoire ne peut pas être comparé à quoi que ce soit, donc ne peut pas être refusé.

Si vous ne savez pas répondre. Écrivez la description d'abord. Une heure de description écrite évite trois cycles de correction sur l'écran.

{SOURCE_DES_DONNEES}

D'où viennent les informations affichées, et que voit l'utilisateur pendant qu'elles arrivent ?

Pourquoi ce trou existe. Sans réponse, l'agent invente des données de démonstration, et l'écran paraît fonctionner alors qu'il n'est branché sur rien.

Si vous ne savez pas répondre. Si la source n'existe pas encore, dites-le et exigez que l'écran affiche son état vide, pas des données inventées.

{REGLES_DAFFICHAGE}

Quelles règles gouvernent ce qui s'affiche : ordre, filtrage, mise en forme des montants et des dates ?

Pourquoi ce trou existe. L'ordre et le format ne sont jamais neutres : un montant mal formaté ou une date ambiguë produisent des erreurs de décision réelles.

Si vous ne savez pas répondre. Tranchez au moins l'ordre par défaut, le format des dates et le format des montants avec leur devise. Ces trois-là se remarquent immédiatement.

{CONVENTIONS_DU_PROJET}

Quelles conventions visuelles et techniques le projet impose-t-il déjà ?

Pourquoi ce trou existe. Un écran qui ignore les conventions du projet oblige à tout refaire ensuite, et l'écart se voit immédiatement pour l'utilisateur.

Si vous ne savez pas répondre. Désignez un écran existant qui fait autorité et demandez que le nouveau lui ressemble en tout point non spécifié.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es développeur d'interface. Ton mandat est de construire un écran conforme à une description écrite qui fait foi. Tu n'améliores pas la description, tu n'ajoutes pas d'élément, tu ne changes pas l'ordre des blocs.

## 2. CONTEXTE FACTUEL

Description qui fait foi : {DESCRIPTION_DE_LECRAN}
Source des données et comportement pendant le chargement : {SOURCE_DES_DONNEES}
Règles d'affichage : {REGLES_DAFFICHAGE}
Conventions déjà en vigueur dans le projet : {CONVENTIONS_DU_PROJET}

Si la description est muette sur un point, tu suis les conventions du projet. Si les conventions sont muettes aussi, tu poses la question au lieu de choisir.

## 3. DEMANDE BORNÉE

Construis cet écran, conforme à la description.

Ce que je veux :
1. l'écran, avec ses quatre états : chargement, contenu, vide, erreur ;
2. les textes visibles repris mot pour mot de la description, sans reformulation ;
3. le branchement sur la source de données indiquée, ou l'état vide si la source n'existe pas ;
4. la liste des points où la description était muette, avec la convention que tu as suivie ;
5. la marche à suivre pour voir chacun des quatre états, y compris l'état d'erreur ;
6. la liste des fichiers créés et modifiés.

Ce que je ne veux pas : de données de démonstration présentées comme réelles, un élément absent de la description, une reformulation des textes, une bibliothèque nouvelle, une modification d'un autre écran.

## 4. FORMAT DE SORTIE EXIGÉ

Les quatre états sont livrés ensemble, jamais l'état de contenu seul. La marche à suivre indique comment provoquer l'état vide et l'état d'erreur, sans quoi je ne peux pas les vérifier. Tout texte visible qui ne vient pas de la description est signalé ligne par ligne.

Ta réponse est refusable si un état manque, si un texte a été reformulé, ou si des données inventées sont affichées sans être signalées comme telles.

Ce que vous devez recevoir

• Les quatre états livrés ensemble : chargement, contenu, vide, erreur.
• Les textes visibles repris mot pour mot de la description.
• Un branchement réel sur la source indiquée, ou l'état vide assumé.
• La liste des points muets de la description et la convention suivie pour chacun.
• Une marche à suivre indiquant comment provoquer l'état vide et l'état d'erreur.
• La liste des fichiers créés et modifiés.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• L'écran ne présente que son état de contenu, les trois autres états manquant.
• Des données inventées sont affichées sans être signalées, ce qui fait croire à un écran branché.
• Un texte visible a été reformulé au motif qu'il sonnait mieux.
• Un élément absent de la description a été ajouté, fût-il utile.
• La marche à suivre ne permet pas de provoquer l'état d'erreur, donc de le vérifier.
• Une bibliothèque a été ajoutée pour un besoin d'affichage que les conventions couvraient déjà.

Selon pour qui vous construisez

Pour moi.

Vérifiez l'écran sur le matériel de vos utilisateurs réels, pas sur le vôtre. Un écran validé sur grand moniteur ment sur téléphone.

Pour un client.

Faites valider les quatre états par le client, pas seulement l'état de contenu. C'est l'état vide qui fait la première impression, le jour de la mise en service.