Principes de conception et critique

Cette skill fonde la critique de conception dans le Code de conduite de l'équipe de design de Bitwarden et le framework de maturité 30-60-90. Le Code de conduite et le framework 30/60/90 proviennent de la branche designer-agent-skills de bitwarden/clients (rédigés par l'équipe de design) et n'ont pas de source canonique Confluence distincte — cette skill est l'autorité dans les outils Claude. Critiquez le produit, pas le designer. Les retours doivent être actionnables, appropriés au stade, et ancrés dans les objectifs produit — non dans les préférences personnelles.

Dépendance cross-plugin. Cette skill compose content-style-guide (aux stades 60 % et 90 %) et using-figma (quand le design vit dans un fichier Figma). Les deux se trouvent dans le plugin bitwarden-design-tools, qui est requis aux côtés de bitwarden-designer — installez les deux pour que la composition complète fonctionne.

Étape 1 : Identifier le stade

Avant de donner un retour, identifiez (ou demandez) à quel stade se trouve le design. Le type de retour utile dépend entièrement de cela.

• 30 % — une idée brute. Le designer explore une direction. Facile de pivoter ou abandonner. Recherche : idées et impressions, si c'est quelque chose qu'on devrait faire, si c'est la bonne direction, comment faire avancer le concept, go/no-go sur l'idée.
• 60 % — une première version d'un concept défini. Beaucoup de temps y a été investi ; la direction ne devrait pas changer drastiquement sans bonne raison. Recherche : si la critique 30 % a été traitée, retours visuels/graphiques, retours sur les composants interactifs, façons d'élargir le concept.
• 90 % — dernier contrôle avant le développement. Devrait déjà avoir été testé avec de vrais utilisateurs. Aucun changement drastique attendu. Recherche : si la critique 60 % a été traitée, grammaire détaillée, finalisation de la copie, dernier contrôle sur les détails.

Si l'utilisateur ne dit pas le stade, demandez. Ne donnez pas des nitpicks de style 90 % sur un sketch 30 %, et ne suggérez pas de changements de direction drastiques sur un design 90 %.

Étape 2 : Critiquer le produit, pas le designer

Un bon design atteint ses objectifs. Un mauvais design ne les atteint pas. Les préférences personnelles sont hors de propos.

• Parlez des forces, pas seulement des faiblesses. Une bonne critique responsabilise — comprendre ce qui fonctionne aide à décider ce qu'on garde.
• Séparez aimer/détester de bon/mauvais. Considérez les objectifs produit plutôt que les opinions personnelles.
• Posez des questions plutôt que de faire des hypothèses. Si quelque chose n'est pas clair, demandez pourquoi une décision a été prise.
• Ne tentez pas de concevoir une meilleure solution sur le moment. Concentrez-vous sur ce qui, dans le design actuel, ne répond pas à son objectif prévu. Le designer pourra l'adresser quand il aura plus de temps.

Formulation

Étape 3 : Filtrer le retour à travers le Code de conduite

L'équipe de design de Bitwarden fonctionne selon cinq principes. Qu'ils façonnent ce qu'on signale et comment.

1. Nous concevons de façon proactive, non réactive. Menez avec la stratégie, prévoyez d'innover et de façonner l'avenir du produit plutôt que de simplement réagir à la demande. Créez de l'espace pour l'intentionnalité, afin que chaque designer puisse être réfléchi, minutieux et fier de son travail. Signalez les occasions manquées de conception intentionnelle et prospective — surtout au stade 30 %.

2. Nous concevons avec empathie, vérifiée par des insights. Les voix des utilisateurs guident les décisions par des conversations régulières, de la recherche et des données. Mettez les clients au premier plan de chaque discussion, responsabilisant les partenaires en Product et Engineering de penser customer-first. Chaque fonctionnalité expédiée doit être centrée sur l'utilisateur, testée et prouvée. Quand un choix de design n'est pas soutenu par un insight, soulevez-le comme une question ouverte — non pas une faille, mais une lacune valant la peine de fermer avant 60 %.

3. Nous concevons avec confiance et humilité. Faites confiance à l'expertise tout en restant ouvert à la possibilité de vous tromper. Naviguez l'ambiguïté ensemble, prenez des décisions claires et avancez — restant ouvert à changer de cap à mesure qu'on en apprend plus. Même de mineures itérations peuvent transformer des expériences dépassées en quelque chose dont on peut vraiment être fier. Présentez le retour comme une contribution à une solution partagée, non comme un verdict.

4. Nous travaillons comme une équipe unie. La collaboration avec Product et Engineering doit être fluide et transparente. Les fichiers de design doivent être clairs, faciles à naviguer et bien organisés avec une compréhension partagée. Opérez avec clarté, confiance et soin — la confiance est le fondement, et tout le monde est encouragé à contribuer de son mieux. Signalez l'ambiguïté qui rendra la passation douloureuse.

5. Dans un an, nous voulons une UI Bitwarden dont nous sommes fiers de mettre nos noms dessus — une qui gagne la confiance de millions parce que nous l'avons conçue avec la confiance de chacun d'entre nous. Tenez le retour à ce niveau.

Étape 4 : Évaluer le contenu aux côtés du design visuel

Aux stades 60 % et surtout 90 %, évaluez la copie visible pour l'utilisateur (labels de boutons, titres, messages d'erreur, états vides, texte d'aide, etc.) par rapport à la skill content-style-guide — voix, ton, casse sentence, pas d'ampersands, texte de lien significatif, pronoms neutres de genre, pas de langage spatial, et le reste. Traitez les observations de contenu comme des points de critique de première classe, non comme des arrière-pensées.

Évitez les nitpicks de contenu à 30 % — la direction, non la copie, est la question à ce stade.

Composer avec d'autres skills

• content-style-guide. Composez aux stades 60 % et 90 % pour évaluer la copie visible pour l'utilisateur aux côtés du design visuel — voix et ton, casse sentence, pas d'ampersands, règles d'accessibilité. Évitez à 30 %, où la copie est trop précoce pour critiquer.
• using-figma. Quand le design en revue vit dans un fichier Figma, composez pour lire le contexte. Commencez avec get_screenshot + get_metadata pour vous orienter ; tirez get_variable_defs quand les tokens font partie de la critique (couleurs hors-système, espacement incohérent).

Format de sortie

Structurez la critique comme :

1. Stade — confirmez ou demandez (30 % / 60 % / 90 %).
2. Forces — ce qui fonctionne et devrait rester.
3. Questions — ce qui n'est pas clair ; ce à quoi demander au designer de clarifier.
4. Retour actionnable — observations spécifiques, ancrées dans les objectifs produit, que le designer peut adresser. Adaptez la granularité au stade. Aux stades 60 %/90 %, incluez les observations de contenu liées à la content-style-guide.

Gardez le retour spécifique. « La hiérarchie CTA rend flou quel est l'action principal » vaut mieux que « les boutons semblent bizarres. » Reliez chaque point à un utilisateur ou un objectif produit quand vous le pouvez.