Diseños gráficos
Diseño de especificación de producto de autenticación
Una propuesta de autenticación de dos factores de Northwind vincula responsables, alcance, historias de usuario, cuatro objetivos de ejemplo, fases de lanzamiento y decisiones sin resolver.
Casos de uso de especificaciones de producto
- Autores de especificaciones de productoConvierten los requisitos de autenticación en un documento de entrega ordenado.
- Equipos de plataformas de identidadConectan los controles de seguridad, las fases de lanzamiento y las decisiones de implementación sin resolver.
- Responsables de producto y diseñoAlinean los responsables, el alcance, las métricas y las prioridades de autenticación orientadas al usuario.
- Equipos de preparación empresarialPlantean los bloqueos de seguridad de los clientes junto con las consideraciones de adopción y soporte.
Aspectos destacados del documento de autenticación
- Planteamiento del problemaRelaciona los bloqueos de las revisiones empresariales con la carencia de autenticación.
- Alcance explícitoSepara los objetivos propuestos para el lanzamiento del trabajo aplazado intencionadamente.
- Objetivos del lanzamientoRelaciona los resultados previstos con objetivos de ejemplo y cuatro fases de lanzamiento.
- Preguntas asignadasMantiene visibles las decisiones de política sin resolver, con responsables y fechas.
La especificación de producto, sección por sección
1 / 6
Documento de 2FA de Northwind
Este ejemplo oficial de OpenDesign es una especificación de producto ilustrativa para la autenticación de dos factores en la aplicación de Northwind. Su apertura establece el documento como Draft v0.4, identifica al responsable, la fecha de actualización y a cuatro revisores, y después presenta la propuesta: añadir factores TOTP y de clave de seguridad al flujo de inicio de sesión.
La composición visual sitúa esa solicitud antes de los detalles de planificación. Una fila de metadatos identifica a Identity Platform como el equipo, a Priya Banerjee como responsable de ingeniería, a Sasha Lin como responsable de diseño, un lanzamiento objetivo de End Q4 (Dec 18) y un esfuerzo estimado de ~6 eng-weeks. Ese orden permite entender los responsables y la presión de entrega antes de leer el problema.
La sección Problem da después una razón de ser a la propuesta. Describe que tres de las últimas seis revisiones de seguridad empresarial señalaron la ausencia del segundo factor, seguida de una cita separada de Maya Reddy, de Pioneer Robotics. La cita hace visible la presión comercial sin sustituir el argumento de seguridad más amplio.
Tres perspectivas de autenticación
La sección de ejemplo User Stories presenta tres tareas: un administrador del espacio de trabajo quiere exigir 2FA para un objetivo de revisión de controles concreto; un miembro del día a día quiere inscribirse en TOTP en menos de dos minutos; y un ingeniero de soporte quiere una vía de recuperación que no omita el segundo factor. Estos son requisitos de planificación del documento, no pruebas de que la autenticación funcione ni de que se haya logrado el cumplimiento.
Estas historias se presentan como tres filas horizontales numeradas, con la frase de la persona enfatizada dentro de cada oración. Esa estructura repetida facilita comparar las diferencias de responsabilidad, mientras que la cláusula “so that” conserva la razón operativa de cada solicitud.
El orden también expone una decisión de diseño. La administración aparece primero porque la aplicación obligatoria en el espacio de trabajo define la superficie de políticas; la inscripción le sigue porque es la acción inmediata del miembro; y el soporte de recuperación queda al final porque describe la vía de excepción. Por tanto, el documento trata la seguridad como un sistema compartido y no solo como una pantalla de inicio de sesión.
Administrador del espacio de trabajo
Exige 2FA a todos los miembros para respaldar una revisión de controles.
Miembro del día a día
Inscribe rápidamente una aplicación TOTP sin abandonar el trabajo habitual.
Ingeniero de soporte
Ayuda con la recuperación sin debilitar el control de seguridad añadido.
Objetivos, métricas y fases
La secuencia central del documento pasa del alcance a la evaluación y después a la entrega. “Goals & non-goals” utiliza símbolos de marca de verificación y multiplicación para distinguir TOTP, WebAuthn, la aplicación obligatoria en el espacio de trabajo, los códigos de recuperación y las entradas de auditoría del trabajo excluido, como SMS, la sustitución de SSO, la autenticación adicional por acción y el tono de marca personalizado para despliegues de marca blanca.
Esta división resulta útil porque evita que la propuesta trate cada solicitud de autenticación como parte de este lanzamiento. La compatibilidad indicada con Authy, 1Password y Google Authenticator establece un límite concreto para el objetivo TOTP, mientras que WebAuthn se limita a los planes Enterprise. La decisión de alcance es deliberada: la especificación obtiene una primera versión explícita y mantiene separado el trabajo de identidad adyacente.
La tabla Success Metrics contiene cuatro filas de planificación de ejemplo: acuerdos desbloqueados (3 de 3), adopción en espacios de trabajo de pago (al menos 60%), incidentes de toma de control en los últimos 30 días (como máximo 1) y carga de soporte de recuperación (menos del 1.5% de los tickets). Son objetivos, no resultados medidos. Su fórmula de adopción cuenta eventos de inscripción sobre DAU sin definir la deduplicación de miembros únicos, mientras que la línea base de incidentes indica “4 last quarter”. Habría que reconciliar los periodos y las reglas de recuento antes de que esta tabla pudiera medir un lanzamiento real.
Rollout Milestones convierte esas métricas en cuatro fases señalizadas: inscripción en TOTP, flujo de inicio de sesión, WebAuthn con aplicación obligatoria por parte del administrador y GA más comunicaciones. Cada fase enumera una estimación de esfuerzo y contenidos concretos, de modo que el lector puede ver qué decisiones afectan a la configuración, el inicio de sesión, las políticas y los materiales de soporte.
| Métrica | Línea base | Objetivo (90D) | Método de medición |
|---|---|---|---|
| Acuerdos empresariales desbloqueados al resolver la carencia de 2FA | 0 de 3 | 3 de 3 | Notas del proceso comercial + recuento de contratos firmados |
| Adopción de 2FA por los miembros (espacios de trabajo de pago) | n/a | ≥ 60% | eventos auth.factor_enrolled / DAU |
| Incidentes de toma de control de cuentas (últimos 30 días) | 4 el último trimestre | ≤ 1 | Registro de incidentes de seguridad (SEV-3+) |
| Carga de soporte por recuperación de 2FA | n/a | Menos del 1.5% de los tickets | auth-2fa etiquetado en Zendesk |
Decisiones aún abiertas
La sección final mantiene visible la incertidumbre en lugar de presentar la especificación como una implementación terminada. Tres preguntas se asignan a Devon Park, Priya Banerjee y Sasha Lin los días 28, 29 y 30 de octubre: si los miembros eligen entre TOTP y las claves de seguridad, cuánto debería durar la cookie de dispositivo de confianza y dónde puede ver un administrador el estado de 2FA de un miembro.
Esto complementa de forma significativa la secuencia de hitos. El lanzamiento menciona una cookie de dispositivo de confianza y la aplicación obligatoria por parte del administrador, pero las preguntas abiertas muestran que los detalles de sus políticas aún no están establecidos en el documento. Mantener esas preguntas junto a responsables y fechas proporciona al equipo una cola de decisiones conectada con la fecha límite indicada del 31 de octubre.
Elección del factor
Decidir si los miembros eligen un factor o reciben el más sólido disponible.
Dispositivo de confianza
Resolver la política de duración de la cookie de dispositivo de confianza.
Visibilidad del administrador
Elegir entre el estado en la lista de usuarios y la visibilidad en el registro de auditoría.
Cómo crear un diseño de especificación de producto de autenticación en OpenDesign
Plantear el problema de autenticación
Comienza con la solicitud de producto, la audiencia afectada y la presión concreta de seguridad o comercial. Incluye una fila compacta de responsables con el equipo, los líderes, el lanzamiento objetivo y el esfuerzo cuando esos detalles se conozcan.
Definir el alcance y las métricas
Separa los objetivos propuestos para el lanzamiento de los objetivos excluidos y añade después las líneas base, los objetivos y los métodos de medición. Mantén diferenciados los valores de planificación de los resultados verificados y alinea los periodos de informe y el recuento de usuarios únicos antes de adaptar las fórmulas de ejemplo.
Prompt sugeridoCrea una especificación de producto de autenticación de dos factores al estilo de Northwind con un encabezado de borrador, una fila de responsables, las secciones Problem, Goals and Non-goals, una tabla de Success Metrics de cuatro columnas, tres User Stories numeradas, cuatro Rollout Milestones con fecha y Open Questions asignadas. Muestra TOTP, Enterprise WebAuthn, la aplicación obligatoria en el espacio de trabajo, los códigos de recuperación, las entradas de auditoría y los límites de capacidad indicados; no des a entender que existen servicios activos ni resultados medidos.
Comprobar la secuencia de decisiones
Revisa el documento como una ruta de planificación: problema, alcance, métricas, historias de usuario, hitos y preguntas abiertas. Confirma que cada hito tenga contenidos concretos y que los detalles de política sin resolver sigan visibles, en lugar de presentarse como comportamientos establecidos.
Exportar y obtener un enlace para compartir
Exporta tu diseño terminado y luego usa Compartir en OpenDesign para obtener un enlace. Abre el enlace en una ventana del navegador independiente y comprueba que la versión prevista y sus recursos estén disponibles antes de enviarlo.
Diseño de póster editorial sobre flujos de trabajo con IA
El diseño de póster editorial sobre flujos de trabajo con IA presenta seis afirmaciones sobre los flujos de trabajo, con capítulos numerados, ejemplos concretos de prompts y acentos tipográficos color óxido sobre un fondo crema.
Diseños gráficos
Diseño de carrusel social sobre flujos de trabajo con IA
Siete tarjetas verticales utilizan encabezados chinos sobredimensionados, hábitos numerados, campos de color cambiantes y una declaración final para explicar los flujos de trabajo de edición con IA.
Diseños gráficos
Diseño de shader Aurora Field
Un campo de ruido azul verdoso animado automáticamente aporta atmósfera a un hero WebGL, mientras un titular fijo y una pequeña insignia local de frecuencia de fotogramas anclan la escena.
Diseños gráficos
Diseño de shader Aurora Veil
Aurora Veil es una composición de shader interactiva que convierte la luz en capas, las estrellas y el movimiento del cursor en un hero atmosférico de WebGL.
Diseños gráficos