mingdui/AI-Product-Skills

Compétence : Prototype Haute-Fidélité Front-End pour Chef de Produit

I. Objectif

Créer un prototype haute-fidélité, cliquable et isolé de l'entrée métier réelle, sur la base du code source existant d'un projet front-end, afin que le chef de produit puisse rapidement visualiser, présenter et discuter des solutions produit.

Priorités :

• Cohérence avec le style existant du projet.
• Pages qui ressemblent à un vrai produit, pas à une démo temporaire.
• Utilisation de données simulées cohérentes avec le métier.
• Parcours principaux cliquables.
• Interactions utilisables pour une revue des besoins.
• Pages faciles à modifier par la suite.
• Fonctionnement immédiat en local, avec prévisualisation.
• Par défaut, ne pas impacter les pages métier et les routes en cours d'utilisation.

Sauf demande explicite de l'utilisateur, ne pas considérer la tâche comme une refonte complète du système à partir de zéro.

Lorsque l'objectif est un prototype haute-fidélité, ne pas prioriser le développement d'interfaces backend, de flux de données de production ou d'architectures complexes.

Convention d'isolement par défaut : Réutiliser d'abord le code source, la mise en page, les composants et les règles visuelles existants du projet, puis implémenter le prototype dans des pages, routes ou répertoires de fonctionnalités prototypes indépendants. Ne pas modifier par défaut les pages métier en cours d'utilisation, les entrées de production ou les appels d'interface existants ; cela n'est autorisé que si l'utilisateur demande explicitement de « présenter directement sur la page existante » ou de « remplacer la page existante par le prototype ».

---

II. Scénarios d'application

Utiliser cette compétence lorsque l'utilisateur demande :

• Créer des pages ou routes prototypes indépendantes à partir du code source d'un projet existant (React, Vue, HTML, etc.).
• Présenter les interactions du prototype directement dans les pages produit existantes (sur demande explicite).
• Ajouter des pages d'administration, CRM, SaaS, back-office ou plateforme de travail.
• Transformer des pages statiques en prototypes cliquables.
• Ajouter des données simulées et des états interactifs plus réalistes.
• Ajouter ou optimiser des tableaux, formulaires, filtres, onglets, panneaux latéraux, modales, graphiques, pages de détail ou processus métier.
• Étendre de nouvelles fonctionnalités en suivant le style existant du projet.
• Créer une démo haute-fidélité pour revue, sans développer le backend.
• Optimiser la hiérarchie visuelle, la densité d'information, la réactivité ou les retours interactifs.

Expressions courantes :

• Ajouter une page de liste de clients dans le back-office existant.
• Ajouter un tableau de bord de données opérationnelles selon le style actuel du projet.
• Ajouter un module de suivi historique dans une page de détail existante.
• Compléter cette page pour en faire un prototype cliquable.
• Ajouter des interactions de recherche, filtre, changement d'état, panneau latéral et modale.
• Optimiser cette page existante sans changer le style général du système.

---

III. Scénarios non applicables

Ne pas utiliser cette compétence par défaut dans les cas suivants :

• L'utilisateur souhaite créer un tout nouveau produit à partir d'un répertoire vide.
• L'utilisateur a uniquement besoin d'un site web marketing ou d'une page d'atterrissage.
• L'utilisateur demande le développement d'interfaces backend, de bases de données ou de services de production.
• L'utilisateur a besoin d'une documentation d'architecture technique, pas d'un prototype.
• L'utilisateur demande uniquement la génération d'images visuelles ou de captures d'écran statiques.
• La tâche actuelle est principalement une analyse des besoins ou la rédaction d'un PRD.

Si le répertoire actuel est vide, expliquer que cette compétence est destinée aux projets existants et utiliser de préférence la « Compétence de prototype haute-fidélité HTML à partir de zéro ».

---

IV. Principes fondamentaux

1. Analyser le projet avant de concevoir

Ne pas écrire de code immédiatement après avoir reçu le besoin.

Rechercher d'abord dans docs/product/ la ligne directrice d'expérience produit correspondant au projet actuel et à la partie front-end concernée (c-end/ ou admin/). Si elle existe, lire la terminologie produit, la navigation, les modèles de page et les règles visuelles et interactives ; elle complète les conventions techniques du code source du projet, mais ne remplace pas la bibliothèque de composants, le routage et l'architecture des données.

Si l'utilisateur lance la première version des besoins, ou si la fonctionnalité actuelle révèle des règles produit récurrentes non encore définies, il est recommandé d'utiliser d'abord « product-experience-foundation ». Un prototype de fonctionnalité unique ne doit pas créer ou réécrire une ligne directrice produit globale sans autorisation.

Analyser d'abord dans le projet existant :

• Pages adjacentes.
• Cadre de mise en page des pages.
• Structure de routage.
• Répertoire des composants.
• Hooks et fonctions utilitaires publics.
• Variables CSS.
• Fichiers de thème.
• Tokens de conception.
• Utilisation des icônes.
• Style des tableaux.
• Style des formulaires.
• Style des modales et panneaux latéraux.
• Style des messages et notifications.
• Méthode actuelle de gestion d'état.

Comprendre du projet existant :

• Densité d'information.
• Espacement entre les pages.
• Hiérarchie typographique.
• Taille des coins arrondis.
• Utilisation des couleurs.
• Structure de navigation.
• Méthode d'appel des composants.
• Stratégie responsive.

Les nouvelles pages doivent ressembler à une extension naturelle du système existant, et non à un système complètement nouveau.

2. Privilégier la réutilisation, ne pas réinventer la roue

Privilégier la réutilisation de ce qui existe déjà dans le projet :

• Boutons.
• Tableaux.
• Formulaires.
• Listes déroulantes.
• Sélecteurs de date.
• Onglets.
• Modales.
• Panneaux latéraux.
• Pagination.
• Étiquettes d'état.
• Messages d'alerte.
• Composants de mise en page de page.
• Icônes.
• Fonctions utilitaires.
• Hooks.
• Tokens de conception.

Si le projet existant dispose déjà des capacités correspondantes, ne pas créer un deuxième système de composants.

3. Isoler par défaut l'entrée du prototype

Le prototype doit être implémenté sur la base du code source existant, et non en copiant un site web statique distinct du projet ; il doit également être isolé par défaut de l'entrée métier réelle.

Choisir de préférence l'une des méthodes suivantes, prises en charge par les conventions existantes du projet :

• Route prototype indépendante, par exemple /__prototype/<fonctionnalité> ou une convention de route de démo existante dans le projet.
• Page prototype indépendante ou répertoire de fonctionnalités, exposé uniquement dans l'environnement de développement/prévisualisation.
• Entrée prototype explicite qui ne modifie pas le comportement par défaut de la page originale, par exemple un paramètre de requête, un menu de développement ou un élément de navigation temporaire.

L'entrée du prototype doit pouvoir réutiliser l'enveloppe et les composants de la page réelle, mais ne doit pas par défaut remplacer l'entrée en ligne, modifier les données métier existantes ou impacter d'autres fonctionnalités. Si le projet a déjà des conventions pour les prototypes, elles doivent être respectées ; sinon, choisir la méthode qui a le moins d'impact sur le code de production et qui est la plus facile à supprimer, et indiquer l'emplacement de l'entrée dans la réponse finale.

4. Traiter la tâche comme un prototype produit, pas une refonte officielle

Prioriser :

• La revue produit.
• La démonstration métier.
• La discussion sur les besoins.
• L'alignement entre la conception et le développement.
• L'itération rapide.

Utiliser de préférence des méthodes d'implémentation directes et faciles à modifier.

Sauf si le projet existant utilise déjà le modèle correspondant, ne pas introduire :

• Une refonte globale à grande échelle.
• Une nouvelle couche d'architecture.
• Des dépendances lourdes.
• Une abstraction excessive.
• Des machines d'état complexes.

5. Utiliser des données simulées, ne pas se précipiter sur le backend

Sauf demande explicite de l'utilisateur, ne pas :

• Se connecter à des interfaces réelles.
• Concevoir des API backend.
• Créer une couche de service.
• Gérer les flux de données de production.

Placer si possible les données simulées près de la page ou de la fonctionnalité actuelle, pour faciliter leur ajustement par le chef de produit.

Utiliser l'état local pour simuler :

• Création.
• Modification.
• Suppression.
• Recherche.
• Filtrage.
• Tri.
• Changement d'onglet.
• Sélection.
• Changement d'état.
• Ouverture du panneau latéral.
• Ouverture de la modale.
• Soumission de formulaire.
• Double confirmation.
• Message de succès.
• Message d'erreur.

6. Le prototype doit être cliquable

En plus du flux principal, compléter selon les besoins les états que le chef de produit doit examiner lors de la revue :

• Recherche.
• Filtrage.
• Onglets.
• Sélection.
• Consultation des détails.
• État vide.
• État de chargement.
• Validation de formulaire.
• État désactivé.
• Double confirmation.
• Retour de succès.
• Retour d'erreur.
• Chemin de retour.
• Navigation multi-étapes.

Si le besoin comprend plusieurs étapes, le processus doit pouvoir être entièrement parcouru, sans laisser plusieurs pages statiques non liées.

7. Ne pas transformer un système métier en site marketing

Lorsque l'utilisateur a besoin d'une application, d'un outil, d'un back-office, d'un CRM, d'un système d'exploitation ou d'une plateforme de travail :

• Ne pas créer un grand titre de première page.
• Ne pas prioriser une composition visuelle marketing.
• Ne pas utiliser de dégradés décoratifs excessifs ni d'arrière-plans comme élément visuel principal.
• Ne pas réduire considérablement la densité d'information pour l'effet visuel.
• Ne pas remplacer les contrôles métier réels par des cartes marketing.

---

V. Analyse à effectuer avant le codage

Avant de commencer à écrire du code, extraire des besoins et du projet :

• Objectif produit.
• Utilisateur ou rôle cible.
• Tâches principales que l'utilisateur doit accomplir.
• Pages à ajouter ou modifier.
• Pages existantes similaires.
• Entrée de la page.
• Parcours utilisateur principal.
• Champs nécessaires.
• États nécessaires.
• Différences de droits selon les rôles.
• Interactions à implémenter.
• Besoins en données simulées.
• Hypothèses produit.
• Règles métier non encore clarifiées.

Ne pas demander à nouveau des informations déjà fournies par l'utilisateur.

Si seuls des détails de la couche de présentation manquent, des hypothèses raisonnables peuvent être utilisées.

Ne pas ajouter de règles métier fondamentales qui modifieraient le périmètre du produit.

---

VI. Processus de vérification du projet

Première étape : Identifier la stack technique

Confirmer :

• Framework front-end.
• Outil de build.
• Méthode de routage.
• Bibliothèque de composants UI.
• Bibliothèque d'icônes.
• Solution de style.
• Méthode de gestion d'état.
• Conventions de requêtes de données.
• Méthode de test ou de prévisualisation.

Deuxième étape : Rechercher des pages similaires

Rechercher en priorité :

• Pages de liste du même type.
• Pages de détail du même type.
• Formulaires du même type.
• Tableaux de bord du même type.
• Modales ou panneaux latéraux du même type.
• Processus métier du même type.
• États vides, de chargement et d'erreur du même type.

Utiliser ces pages comme référence pour implémenter les nouvelles pages.

Troisième étape : Identifier les éléments réutilisables

Lister ce qui doit être réutilisé pour cette tâche :

• Composants.
• Hooks.
• Tokens de conception.
• Fonctions utilitaires.
• Mise en page de page.
• Méthodes d'interaction.

Éviter de réimplémenter des capacités déjà existantes.

Quatrième étape : Comprendre le système visuel existant

Vérifier :

• Largeur de page.
• Padding intérieur des zones de contenu.
• Espacement entre les modules.
• Hiérarchie typographique.
• Style des boutons.
• Densité des formulaires.
• Densité des tableaux.
• Couleurs d'état.
• Style des bordures.
• Utilisation des ombres.
• Points de rupture responsives.

Cinquième étape : Définir le périmètre du prototype

Clarifier :

• Où placer l'entrée du prototype et comment elle est isolée de l'entrée réelle.
• Pages ou modules prototypes à ajouter.
• Si l'utilisateur demande explicitement de modifier des pages métier existantes.
• Quelles interactions doivent être cliquables.
• Quelles données utiliser comme données simulées.
• Quels états doivent être représentés.
• Quelles hypothèses produit sont nécessaires.
• Quels modèles de page au niveau produit sont réutilisés par la fonctionnalité actuelle.
• Quels nouveaux modèles sont limités à la fonctionnalité actuelle et lesquels pourraient être candidats à une généralisation ultérieure.

---

VII. Standard des données simulées

Les données simulées doivent utiliser un langage métier réaliste.

Éviter d'utiliser :

• Utilisateur Test.
• Lorem ipsum.
• Société A.
• Exemple de données.
• Utilisateur 001.

Les données simulées doivent si possible couvrir :

• Différents états.
• Texte long.
• Valeurs manquantes.
• Messages d'avertissement.
• Données limites.
• Différentes décisions d'utilisateurs.
• Différentes étapes du métier.
• Résultats vides.
• Actions désactivées.

Le rôle des données simulées n'est pas de remplir la page, mais d'aider le chef de produit à identifier les problèmes de page et d'interaction.

---

VIII. Règles pour les hypothèses produit

L'IA peut raisonnablement compléter les détails de la couche de présentation, par exemple :

• Noms d'exemple.
• Dates d'exemple.
• Données de liste d'exemple.
• Texte pour l'état vide.
• Messages de succès et d'erreur.
• Conditions de filtrage courantes.
• Méthodes d'interaction conformes aux habitudes du projet existant.

L'IA ne doit pas ajouter silencieusement la logique métier fondamentale suivante :

• Nouveaux états métier.
• Nouveaux droits par rôle.
• Nouvelles règles d'approbation.
• Nouvelles méthodes de calcul métier.
• Nouveaux modules d'administration.
• Nouveau périmètre produit.
• Nouvelles dépendances à des systèmes externes.

Si des hypothèses sont nécessaires pour la démonstration, les indiquer clairement dans la réponse finale.

Si une nouvelle interaction entre en conflit avec la ligne directrice d'expérience produit, ne pas la remplacer silencieusement. Suivre la ligne directrice confirmée, ou indiquer la divergence et la nécessité éventuelle de « réécrire la ligne directrice » comme point à confirmer.

---

IX. Standard UI et interactions

1. Architecture de l'information

Prioriser :

• Hiérarchie claire.
• Regroupement pertinent.
• Sélection efficace des champs.
• Actions principales bien visibles.
• Densité d'information stable.
• Page facile à parcourir visuellement.

2. Choix des contrôles

Privilégier les contrôles familiers à l'utilisateur :

• Actions d'outils avec boutons d'icônes.
• Changement de mode avec contrôle segmenté.
• Paramètres binaires avec interrupteur ou case à cocher.
• Paramètres numériques avec champ de saisie, curseur ou stepper.
• Options multiples avec menu ou liste déroulante.
• Vues de même niveau avec onglets.
• Tâches secondaires avec panneau latéral ou modale.

3. Utilisation des cartes

Ne pas créer de cartes imbriquées dans d'autres cartes.

Les cartes conviennent pour :

• Éléments de liste répétés.
• Modales.
• Panneaux latéraux.
• Outils indépendants.
• Groupes de données nécessitant un encadrement clair.

Ne pas transformer chaque bloc de page en carte.

4. Contrôle des décorations

Éviter :

• Dégradés décoratifs lumineux.
• Sphères flottantes.
• Effets de bokeh.
• Décorations SVG sans signification.
• Arrière-plans purement ambiants.
• Première page marketing.
• Page presque entièrement remplie d'une seule teinte.

Après implémentation, vérifier le CSS ; si la page ne contient presque qu'une seule gamme de couleurs, ajuster en conséquence.

Éviter particulièrement :

• Grande zone de dégradé violet ou bleu-violet.
• Grande zone beige ou sable.
• Grande zone bleu foncé ou gris-bleu.
• Grande zone marron ou orange.

5. Stabilité du texte et de la mise en page

Assurer l'adaptabilité du texte dans :

• Boutons.
• Cellules de tableau.
• Cartes.
• Barres latérales.
• Panneaux latéraux.
• Modales.
• Conteneurs mobiles.

Utiliser selon les besoins :

• Retour à la ligne automatique.
• Troncature du texte.
• Largeurs minimale et maximale.
• Grille stable.
• aspect-ratio.
• Dimensions relatives au conteneur.

Ne pas redimensionner dynamiquement la police en fonction de la largeur de la fenêtre.

Sauf si le système de conception existant l'exige, conserver l'espacement des caractères à 0.

6. Ne pas expliquer le prototype dans l'interface produit

Ne pas afficher les explications suivantes dans la page :

• Comment ce prototype a été réalisé.
• Quelles solutions temporaires ont été utilisées.
• Comment l'évaluateur doit comprendre la page.
• Quelles interactions sont simulées.

Ajouter des explications dans l'interface uniquement si le produit lui-même a besoin de contenu d'aide.

---

X. Périmètre responsive

Système back-office de bureau

Si le projet est clairement un back-office de bureau :

• Prioriser une bonne version de bureau.
• Maintenir une densité d'information stable.
• S'assurer que l'affichage ne soit pas complètement dégradé sur petit écran.
• Éviter que des actions clés soient inaccessibles.
• Éviter autant que possible le défilement horizontal inutile.

Mobile ou produit grand public

Si le produit est destiné aux consommateurs, mobile-first, ou si l'utilisateur demande explicitement une version mobile :

• Concevoir également la mise en page et les interactions mobiles avec soin.
• Vérifier la taille des zones cliquables.
• Vérifier le rognage des contrôles.
• Vérifier les éléments positionnés en fixe.
• Vérifier les espacements de sécurité.
• Vérifier le comportement du clavier et des formulaires si nécessaire.

Toutes les pages doivent être vérifiées

• Chevauchement de texte.
• Rognage des contrôles.
• Masquage des points d'entrée d'action.
• Points de rupture de la navigation.
• Débordement horizontal.
• Tableau illisible.
• Panneau latéral ou modale inutilisable.

---

XI. Processus d'implémentation

Première étape : Lire le projet existant

Vérifier la structure du projet et les pages similaires concernées.

Deuxième étape : Définir l'entrée du prototype et son périmètre

Organiser :

• Emplacement des pages, routes ou répertoires de fonctionnalités du prototype.
• Méthode d'isolement par rapport à l'entrée métier réelle.
• Pages ou modules existants à modifier uniquement sur demande explicite de l'utilisateur.
• Parcours utilisateur principal.
• Interactions à implémenter.
• États des données simulées.
• Composants réutilisables.

Troisième étape : Suivre les méthodes existantes du projet pour implémenter le prototype indépendant

Conserver :

• Cadre technique.
• Système de composants.
• Méthode de style.
• Méthode de routage.
• Icônes.
• Fonctions utilitaires.
• Habitudes de gestion d'état.

Quatrième étape : Ajouter des données simulées et des interactions

Utiliser l'état local pour implémenter le processus complet nécessaire à cette revue.

Cinquième étape : Ajouter les états nécessaires

Ajouter uniquement les états liés à la fonctionnalité actuelle :

• État vide.
• État de chargement.
• État de validation.
• État désactivé.
• État de succès.
• État d'erreur.
• Double confirmation.
• État sans autorisation.
• État de données indisponibles.

Sixième étape : Exécuter réellement le projet

Démarrer le service de développement local existant si nécessaire.

Ne pas déclarer la tâche terminée tant que le projet n'est pas prévisualisable.

Septième étape : Effectuer une vérification visuelle et interactive

Vérifier :

• La page n'est pas vide.
• Les styles se chargent correctement.
• Les icônes et ressources s'affichent normalement.
• Le texte ne déborde pas visiblement.
• La mise en page ne saute pas anormalement.
• Les interactions principales sont utilisables.
• La navigation n'a pas d'impasse.
• Le comportement responsive est acceptable.

Si possible, utiliser l'inspection du navigateur ou des captures d'écran pour vérifier.

---

XII. Livrables finaux

En fonction de la situation réelle de la tâche, le livrable final doit inclure :

• Code source front-end ajouté ou modifié.
• Pages, répertoires de fonctionnalités ou routes prototypes indépendants, avec indication de l'entrée.
• Pages métier existantes modifiées uniquement sur demande explicite de l'utilisateur.
• Composants communs réutilisés.
• Données simulées locales.
• Interactions cliquables principales.
• États vides, de chargement, de validation, désactivés, de succès et d'erreur pertinents.
• Navigation de page fonctionnelle.
• Instructions pour exécuter ou prévisualiser le projet.
• Explication des hypothèses produit.
• Liste des règles métier non encore clarifiées.
• Si un demo.md est créé, y consigner les conclusions de la revue et les points en suspens ; il sert uniquement de jalon de transfert, ne remplace pas les artefacts techniques du projet.

Ne pas créer de documents ou de fichiers d'architecture supplémentaires inutiles, sauf s'ils aident à l'exécution ou à la revue.

---

XIII. Critères d'achèvement

Le prototype est considéré comme terminé lorsqu'il remplit les conditions suivantes :

• Les pages ou modules prototypes existent dans le projet actuel et sont isolés de l'entrée métier réelle (sauf si l'utilisateur demande explicitement de remplacer l'entrée d'origine).
• Le style visuel est cohérent avec le projet existant.
• Les composants existants et les tokens de conception ont été réutilisés de manière appropriée.
• Le parcours utilisateur principal peut être effectué du début à la fin.
• Chaque action principale a un retour clair.
• La navigation n'a pas d'impasse.
• Les données simulées peuvent être mises à jour après une action clé.
• Les états de page pertinents sont représentés.
• Le texte ne déborde pas visiblement.
• Le projet peut être exécuté localement sans erreur bloquante.
• Le périmètre produit déjà confirmé n'a pas été élargi sans autorisation.
• La réponse finale explique clairement les hypothèses produit et les règles en suspens.

---

XIV. Exigences pour la réponse finale

Après avoir terminé, expliquer d'une manière compréhensible pour le chef de produit :

• Quelles pages, modules et processus ont été ajoutés ou modifiés.
• L'emplacement de l'entrée du prototype et comment elle est isolée de l'entrée métier réelle.
• Quelles interactions sont désormais cliquables.
• Quelles données simulées et quels états de page ont été ajoutés.
• Quels composants existants et quelles normes du projet ont été réutilisés.
• Quelles hypothèses produit ont été faites.
• Quelles règles métier restent à confirmer.
• Comment exécuter ou prévisualiser le prototype.
• Quelles vérifications visuelles et interactives ont été effectuées.
• Quelles lignes directrices d'expérience produit ont été réutilisées ; si un nouveau modèle récurrent apparaît, indiquer s'il n'est qu'un candidat et ne pas l'ériger en règle globale avant confirmation.
• Après validation de la revue, le développement implémentera selon le prototype ; ne pas fabriquer d'artefacts d'ingénierie au stade du prototype, ni implémenter de code de production sans autorisation.

La réponse finale doit être concise et se concentrer sur les éléments que le chef de produit doit examiner.