Prompt
Vous êtes un prototypeur front-end. Construisez un prototype cliquable autonome, en un seul fichier, pour que je puisse tester la sensation d'un parcours. Parcours : {{flow_description}}. Contraintes de design (couleurs, échelle typographique, espacement, composants clés) : {{design_constraints}}. États à inclure : {{states}}.

Exigences :
- Un seul fichier : HTML avec CSS intégré et JavaScript vanilla minimal, sans dépendance externe, exécutable en l'ouvrant simplement dans un navigateur.
- Accessibilité intégrée : HTML sémantique, champs de formulaire correctement libellés, ordre de titres logique, pleine opérabilité au clavier, états de focus visibles, et contraste de texte d'au moins 4,5:1.
- Contenu de remplissage réaliste mais clairement fictif — jamais de vraies données utilisateurs ni de vrais noms.
- Rendez le parcours principal cliquable de bout en bout ; simulez les actions secondaires avec une mention visible « non construit dans le prototype ».

Contraintes : ne construisez que les écrans et champs que j'ai décrits — n'inventez ni fonctionnalités, ni parcours, ni texte supplémentaires. Il s'agit d'un prototype jetable pour des tests d'utilisabilité, pas de code de production, donc privilégiez la clarté à l'ingéniosité. Après le code, listez les choix d'accessibilité que vous avez faits et les points que je devrais vérifier manuellement avant de tester.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

Ce que vous obtenez (extrait)

Livré un seul fichier index.html avec un paiement en trois étapes (panier, livraison, confirmation), navigable au clavier, avec des anneaux de focus visibles et une palette conforme à vos tokens avec un contraste de 4,5:1. Comprend les états panier vide, chargement et carte refusée ; l'action « appliquer un code promo » est simulée avec une mention « non construit dans le prototype ». **Choix d'accessibilité :** éléments de formulaire et de libellé sémantiques sur chaque champ, une zone aria-live pour l'erreur, titres dans l'ordre. **À vérifier avant de tester :** l'ordre de tabulation sur le menu déroulant personnalisé, et si l'état d'erreur porte un indice autre que la couleur (il utilise une icône plus du texte en plus du rouge).

Le flux de travail complet

  1. Décrivez le parcours, les contraintes de design et les états que vous voulez tester.
  2. Générez le prototype et ouvrez-le dans un navigateur.
  3. Effectuez un contrôle d'accessibilité (clavier, contraste, lecteur d'écran) et corrigez les manques avant de tester.
  4. Testez avec des utilisateurs, puis affinez le prompt pour peaufiner le parcours.
  5. Transmettez des spécifications vérifiées à l'ingénierie — ne mettez jamais en production le code du prototype jetable sans revue.

Attention à

Les interfaces générées par IA échouent régulièrement aux WCAG — contraste insuffisant, texte alternatif vague, balisage non sémantique — et les outils d'IA ne sont pas des outils d'accessibilité. La responsabilité légale au titre de l'ADA, de la Section 508 et des WCAG reste la vôtre, donc examinez chaque écran généré.

Le code du prototype est jetable, fait pour apprendre, pas pour être mis en production ; le déployer sans revue d'ingénierie expose à des problèmes de sécurité, de performance et de maintenabilité.

Ne collez jamais de designs confidentiels ou non annoncés, ni de vraies données utilisateurs, dans des outils d'IA grand public — utilisez du contenu de remplissage fictif dans les prototypes.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les designers UX en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les designers UX

← Les 6 cas d’usage : comment les designers UX utilisent l’IA