Pourquoi cette séance maintenant?

• Vous êtes en Sprint 1 : conception du prototype.
• La semaine prcohaine vous remettez un prototype basse fidélité.
• Un wireframe réduit le risque : on valide l'usage avant de coder.
• C'est un livrable d'équipe qui aligne UX, science et développement.

Résultat attendu en fin de séance

À la fin, votre équipe doit avoir :

• un parcours utilisateur principal,
• 3 à 6 écrans wireframes,
• des annotations fonctionnelles,
• une logique de navigation cohérente,
• une liste d'améliorations pour Sprint 2.

Wireframe : définition simple

• Un wireframe est un plan d'interface, pas un design final.
• Il montre la structure : zones, contenus, actions, transitions.
• Il permet de discuter de fonctionnement, pas de couleurs ou de police.
• Il sert à tester vite et corriger tôt.

Wireframe, maquette, prototype

• Wireframe : basse fidélité, structure et flux.
• Maquette : haute fidélité visuelle, identité graphique.
• Prototype interactif : navigation cliquable, comportement simulé.

Le lien avec votre problème scientifique

Votre interface doit rendre visible :

• l'entrée scientifique (données, paramètres, hypothèses),
• le traitement (simulation, calcul, modèle),
• la sortie (résultats, visualisations, interprétation),
• la validation (comparaison, plausibilité, limites).

Méthode en 6 étapes

1. Clarifier l'utilisateur cible et son besoin.
2. Écrire le parcours principal (début -> action -> résultat).
3. Lister les écrans minimums pour ce parcours.
4. Faire un croquis des écrans en basse fidélité.
5. Ajouter des annotations de comportement.
6. Tester le flux avec une autre équipe et itérer.

Bonnes pratiques de wireframing

• Une idée principale par écran.
• Navigation constante (retour, suivant, état courant).
• Texte court et actionnable sur les boutons.
• Hiérarchie visuelle claire (titres, blocs, priorités).
• États essentiels : vide, succès, erreur.

Erreurs fréquentes à éviter

• Se perdre dans l'esthétique trop tôt.
• Oublier les cas d'erreur et de données invalides.
• Multiplier les écrans sans lien de navigation.
• Ne pas relier l'interface à la validation scientifique.

Annotations minimales à ajouter

Sur chaque écran, précisez :

• ce que l'utilisateur fait,
• ce que le système calcule ou affiche,
• ce qui déclenche la transition vers l'écran suivant,
• quelle donnée est nécessaire,
• comment l'utilisateur sait que c'est correct.

Critères de qualité

• Le parcours principal est compréhensible en 30 secondes.
• Les écrans couvrent entrée -> traitement -> sortie.
• Les décisions UX sont justifiées par l'objectif scientifique.
• Les actions critiques sont explicites.
• Le prototype peut guider directement la réalisation du MVP.

Outils recommandés

• Papier + crayon : le plus rapide pour démarrer.
• Excalidraw : simple, collaboratif, efficace en équipe.
• Figma : utile si vous voulez un prototype cliquable ensuite.
• Balsamiq : excellent pour basse fidélité assumée.

Choisissez l'outil qui favorise la vitesse de feedback.

Format du livrable semaine 4

Remettez un dossier court (ou section dans votre dossier de conception) avec :

• 3 à 6 wireframes annotés,
• le parcours utilisateur principal,
• la logique de navigation,
• les hypothèses UX à valider,
• les priorités pour Sprint 2 sous forme de récits utilisateurs

Structure suggérée de votre dépôt

• docs/wireframes/README.md : contexte et parcours.
• docs/wireframes/ecran-01-accueil.png
• docs/wireframes/ecran-02-parametres.png
• docs/wireframes/ecran-03-resultats.png
• docs/wireframes/notes-validation.md

Atelier guidé

1. Choisissez un cas d'usage prioritaire.
2. Dessinez 3 à 6 écrans du flux principal.
3. Ajoutez les annotations à chaque écran.
4. Faites un test croisé avec une autre équipe.
5. Notez 2 améliorations immédiates.

Mini grille de feedback croisé

• Comprend-on le but de l'application rapidement?
• Le chemin vers le résultat est-il évident?
• Les entrées sont-elles suffisantes et réalistes?
• Le résultat affiché aide-t-il à prendre une décision?
• Qu'est-ce qui reste ambigu après 2 minutes?

À retenir

• Le wireframe sert à réduire l'incertitude, pas à faire du visuel final.
• Un bon prototype basse fidélité accélère un MVP pertinent.
• Plus vous testez tôt, plus vous économisez du temps de développement.

Prochaine étape : transformer vos wireframes en backlog Sprint 2.