Créations graphiques
Conception d’une spécification produit d’authentification
Une proposition Northwind d’authentification à deux facteurs relie responsabilités, périmètre, récits utilisateurs, quatre objectifs d’exemple, phases de déploiement et décisions non résolues.
Cas d’usage des spécifications produit
- Auteurs de spécifications produitTransformez les exigences d’authentification en brief de livraison structuré.
- Équipes de plateforme d’identitéReliez les contrôles de sécurité, les phases de déploiement et les décisions d’implémentation non résolues.
- Responsables produit et conceptionAlignez les responsabilités, le périmètre, les mesures et les priorités d’authentification visibles par les utilisateurs.
- Équipes de préparation à l’entrepriseCadrez les obstacles de sécurité client avec les enjeux d’adoption et de support.
Points forts du brief d’authentification
- Cadrage du problèmeRelie les blocages des revues d’entreprise à la lacune d’authentification.
- Périmètre expliciteSépare les objectifs de lancement proposés du travail volontairement reporté.
- Cibles de déploiementAssocie les résultats visés à des cibles d’exemple et à quatre phases de déploiement.
- Questions attribuéesMaintient visibles les décisions de politique non résolues, avec leurs responsables et leurs dates.
La spécification produit, section par section
1 / 6
Brief Northwind 2FA
Cet exemple officiel OpenDesign est une spécification produit illustrative pour l’authentification à deux facteurs dans l’application Northwind. Son ouverture établit le document comme Draft v0.4, identifie le responsable, la date de mise à jour et les quatre réviseurs, puis énonce la proposition : ajouter des facteurs TOTP et de clé de sécurité au parcours de connexion.
La composition visuelle place cette demande avant les détails de planification. Une ligne de métadonnées indique Identity Platform comme équipe, Priya Banerjee comme responsable de l’ingénierie, Sasha Lin comme responsable de la conception, une date de lancement cible End Q4 (Dec 18) et un effort estimé de ~6 eng-weeks. Cet ordre permet au lecteur de comprendre les responsabilités et la pression de livraison avant d’aborder le problème.
La section Problem donne ensuite une raison d’exister à la proposition. Elle indique que trois des six dernières revues de sécurité d’entreprise ont signalé l’absence du second facteur, puis présente une citation distincte de Maya Reddy, de Pioneer Robotics. Cette citation rend la pression commerciale compréhensible sans remplacer l’argument de sécurité plus large.
Trois parcours d’authentification
La section User Stories de l’exemple décrit trois besoins : un administrateur d’espace de travail veut imposer la 2FA pour répondre à un objectif précis de revue des contrôles ; un membre au quotidien veut inscrire son TOTP en moins de deux minutes ; et un ingénieur support veut un parcours de récupération qui ne contourne pas le second facteur. Ces éléments sont des exigences de planification du document, et non la preuve que l’authentification fonctionne ou que la conformité a été obtenue.
Ces récits sont présentés sous la forme de trois lignes horizontales numérotées, avec la formulation de la persona mise en évidence dans chaque phrase. Cette structure répétée facilite la comparaison des responsabilités, tandis que la proposition introduite par « so that » conserve la raison opérationnelle de chaque demande.
L’ordre fait également apparaître un compromis de conception. L’administration vient en premier, car l’application des règles à l’espace de travail définit le périmètre de la politique ; l’inscription suit, car elle constitue l’action immédiate du membre ; le support à la récupération arrive en dernier, car il décrit le parcours d’exception. Le document traite ainsi la sécurité comme un système partagé plutôt que comme une simple interface de connexion.
Administrateur de l’espace de travail
Impose la 2FA à tous les membres pour accompagner une revue des contrôles.
Membre au quotidien
Inscrit rapidement une application TOTP sans interrompre son travail habituel.
Ingénieur support
Aide à la récupération sans affaiblir le contrôle de sécurité ajouté.
Objectifs, mesures et phases
La séquence centrale du document passe du périmètre à l’évaluation, puis à la livraison. « Goals & non-goals » utilise des symboles de validation et de multiplication pour distinguer TOTP, WebAuthn, l’application de règles à l’espace de travail, les codes de récupération et les entrées d’audit du travail exclu, comme les SMS, le remplacement du SSO, le step-up par action et le ton de marque personnalisé pour les déploiements white-label.
Cette séparation est utile, car elle empêche la proposition de traiter chaque demande d’authentification comme faisant partie de ce lancement. La prise en charge indiquée d’Authy, 1Password et Google Authenticator donne un périmètre concret à l’objectif TOTP, tandis que WebAuthn est limité aux forfaits Enterprise. Le compromis est une couverture volontaire : la spécification gagne une première version explicite tout en laissant séparé le travail adjacent sur l’identité.
Le tableau Success Metrics contient quatre lignes de planification d’exemple : contrats débloqués (3 sur 3), adoption dans les espaces de travail payants (au moins 60 %), incidents de prise de contrôle sur une période glissante de 30 jours (au plus 1) et charge du support liée à la récupération (moins de 1,5 % des tickets). Il s’agit de cibles, et non de résultats mesurés. Sa formule d’adoption compte les événements d’inscription sur la DAU sans définir la déduplication des membres uniques, tandis que la valeur de référence des incidents indique « 4 last quarter ». Les fenêtres temporelles et les règles de comptage devraient être harmonisées avant que ce tableau puisse mesurer un lancement réel.
Rollout Milestones transforme ces mesures en quatre phases signalées : inscription TOTP, parcours de connexion, WebAuthn avec application des règles par l’administrateur, puis GA et communications. Chaque phase indique une estimation d’effort et des contenus concrets, afin que le lecteur voie quelles décisions affectent les paramètres, la connexion, la politique et les supports d’accompagnement.
| Indicateur | Valeur de référence | Cible (90J) | Méthode de mesure |
|---|---|---|---|
| Contrats d’entreprise débloqués par la résolution de la lacune 2FA | 0 sur 3 | 3 sur 3 | Notes du cycle commercial + nombre de contrats signés |
| Adoption de la 2FA par les membres (espaces de travail payants) | n/a | ≥ 60 % | événements auth.factor_enrolled / DAU |
| Incidents de prise de contrôle de compte (30 jours glissants) | 4 au dernier trimestre | ≤ 1 | Suivi des incidents de sécurité (SEV-3+) |
| Charge du support liée à la récupération 2FA | n/a | Moins de 1,5 % des tickets | auth-2fa marqué dans Zendesk |
Décisions encore ouvertes
La dernière section maintient l’incertitude visible au lieu de présenter la spécification comme une implémentation terminée. Trois questions sont attribuées à Devon Park, Priya Banerjee et Sasha Lin les 28, 29 et 30 octobre : les membres choisissent-ils entre TOTP et les clés de sécurité, combien de temps un cookie d’appareil approuvé doit-il rester valide, et où un administrateur peut-il voir le statut 2FA d’un membre ?
Cette section constitue le pendant utile de la séquence des jalons. Le déploiement mentionne un cookie d’appareil approuvé et l’application des règles par l’administrateur, mais les questions ouvertes montrent que les détails de leur politique ne sont pas établis dans le document. Conserver ces questions à côté des responsables et des dates donne à l’équipe une file de décisions reliée à l’échéance annoncée du 31 octobre.
Choix du facteur
Décider si les membres choisissent un facteur ou reçoivent le facteur disponible le plus robuste.
Appareil approuvé
Définir la politique de durée de validité du cookie d’appareil approuvé.
Visibilité pour l’administrateur
Choisir entre le statut dans la liste des utilisateurs et la visibilité dans le journal d’audit.
Créer une spécification produit d’authentification dans OpenDesign
Cadrer le problème d’authentification
Commencez par la demande produit, le public concerné et la pression concrète exercée par la sécurité ou l’activité commerciale. Ajoutez une ligne synthétique sur les responsabilités, avec l’équipe, les responsables, la date de lancement cible et l’effort lorsque ces informations sont connues.
Définir le périmètre et les mesures
Séparez les objectifs proposés pour le lancement des éléments hors périmètre, puis ajoutez les valeurs de référence, les cibles et les méthodes de mesure. Distinguez les valeurs de planification des résultats vérifiés, et harmonisez les fenêtres de reporting ainsi que le comptage des utilisateurs uniques avant d’adapter les formules d’exemple.
Invite suggéréeCréez une spécification produit Northwind pour l’authentification à deux facteurs, dans le style Northwind, avec un en-tête brouillon, une ligne de responsabilités, une section Problem, les sections Goals et Non-goals, un tableau Success Metrics à quatre colonnes, trois User Stories numérotées, quatre Rollout Milestones datées et des Open Questions attribuées. Présentez TOTP, Enterprise WebAuthn, l’application de règles à l’espace de travail, les codes de récupération, les entrées d’audit et les limites de capacité indiquées ; ne laissez pas entendre qu’il existe des services en production ou des résultats mesurés.
Vérifier l’enchaînement des décisions
Relisez le document comme un parcours de planification : problème, périmètre, indicateurs, récits utilisateurs, jalons et questions ouvertes. Vérifiez que chaque jalon comporte des éléments concrets et que les détails de politique non résolus restent visibles au lieu d’être présentés comme des comportements établis.
Exporter et obtenir un lien de partage
Exportez votre design finalisé, puis utilisez Partager dans OpenDesign pour obtenir un lien de partage. Ouvrez le lien dans une fenêtre de navigateur distincte et vérifiez que la version souhaitée ainsi que ses ressources sont disponibles avant de l'envoyer.
Conception d’affiche éditoriale sur les workflows IA
Cette affiche éditoriale sur les workflows IA présente six affirmations, organisées en chapitres numérotés, avec des exemples concrets de prompts et des accents typographiques rouille sur un fond crème.
Créations graphiques
Conception d’un carrousel social sur les workflows IA
Sept cartes verticales utilisent des titres chinois surdimensionnés, des habitudes numérotées, des aplats de couleur changeants et une conclusion pour expliquer les workflows d’édition avec l’IA.
Créations graphiques
Conception de shader Aurora Field
Un champ de bruit bleu-vert animé automatiquement donne son atmosphère à un hero WebGL, tandis qu’un titre fixe et un petit indicateur local de fréquence d’images ancrent la scène.
Créations graphiques
Conception du shader Aurora Veil
Aurora Veil est une composition shader interactive qui transforme des lumières superposées, des étoiles et les mouvements du curseur en un hero WebGL atmosphérique.
Créations graphiques