¿Qué hace Exploración de Diseño UI?
Produce una dirección de diseño utilizable para la tarea indicada. Inspecciona las pantallas, componentes, tokens, densidad, contenido y convenciones de interacción existentes antes de generar alternativas. Preserva la identidad del producto a menos que se solicite un rediseño.
Usar evidencia de referencia
Cuando referencias externas informen la tarea, usa design-reference-research si está disponible o inspecciona directamente las fuentes relevantes proporcionadas o predeterminadas. Consume su cobertura de fuentes, captura IDs, observaciones e incertidumbres. No rehagas investigación ya completada ni trates un mood board no inspeccionado como evidencia. La disponibilidad de referencias no hace que la investigación sea obligatoria para una tarea pequeña ya fundamentada en el producto.
Traduce principios útiles en alternativas originales utilizando la identidad del producto existente. Explica cómo cada elección relevante sigue la tarea del usuario y la evidencia. Resuelve patrones conflictivos según la plataforma, la tarea y las restricciones; no mezcles sistemas de navegación incompatibles ni copies la marca de otro producto. Transfiere estados de interacción desconocidos como preguntas a verificar, en lugar de inventar silenciosamente el comportamiento observado.
Enmarcar las alternativas
Aclara solo las elecciones que cambien materialmente el resultado. Identifica la tarea del usuario, la jerarquía de contenido, los estados aplicables, las restricciones de accesibilidad y las superficies objetivo. Haz que las alternativas difieran en estructura o interacción relevantes, no solo en color. Usa un número pequeño proporcional a la solicitud; no siempre generes tres ni requieras agentes paralelos.
Mantén los artefactos exploratorios separados del código de producción a menos que ya se haya solicitado la implementación. Usa datos realistas, etiquetas largas, estados vacíos/de error y diseños responsivos cuando cambien la elección. Muestra qué mejora cada alternativa y qué costo tiene. Una sola captura de pantalla no especifica el enfoque, la navegación ni la persistencia.
Usar capacidades de diseño disponibles
Usa componentes nativos del repositorio y herramientas de previsualización/diseño disponibles. Un entregable utilizable puede ser HTML local, un canvas de diseño existente o un visual anotado; no necesita depender de un proveedor alojado. No afirmes que un diseño fue renderizado o probado sin esa evidencia.
Para una integración de Superdesign explícitamente configurada, lee hosted-design.md. El flujo de trabajo debe seguir funcionando cuando ese servicio no esté disponible. No descargues una CLI más reciente, crees una cuenta ni subas código fuente como requisito previo implícito para el trabajo de diseño.
Entregar una dirección
Compara las alternativas con la tarea y las restricciones. Si el usuario solicita selección, presenta las alternativas reales para esa decisión. Si te autoriza a elegir, recomienda y procede con razones en lugar de introducir otra puerta de aprobación.
Proporciona el artefacto seleccionado, los tokens/componentes reutilizados, las reglas de diseño, los cambios responsivos, el comportamiento de interacción/enfoque, los estados significativos, los activos y las decisiones no resueltas. Vincula los criterios de aceptación y las desviaciones intencionales a los IDs de evidencia de referencia cuando estén disponibles; una alternativa que no fue seleccionada no es un requisito de implementación. Distingue un diseño seleccionado de una implementación funcional. Enruta la implementación autorizada a frontend-ui-engineering y la crítica a plan-design-review cuando estén disponibles, sin requerir que ninguna esté instalada.
Lee provenance.md para la fuente y aviso del flujo de trabajo ascendente.