El diseño de productos sin Figma funciona cuando un producto ya tiene un sistema de diseño maduro. Mi flujo de trabajo de diseño de productos con IA utiliza tres habilidades de agente: ui-design explora nueve direcciones, ui-implement convierte la dirección seleccionada en el producto, y ui-walkthrough revisa cada estado a través del Agent Browser incorporado. Yo sigo tomando las decisiones; el agente se encarga de la producción y verificación repetitiva.
La mayoría de las funciones del producto no comienzan desde una página en blanco. Una vez que un producto ha estado presente durante un tiempo, sus decisiones de diseño básicas ya existen en el código. Botones, entradas, tarjetas, navegación, espaciado, colores, texto, estados al pasar el cursor y comportamiento en dispositivos móviles ya han sido definidos. Reconstruir esas piezas en Figma a menudo significa arrastrar los mismos componentes a otro lienzo antes de reconstruirlos nuevamente en el producto.
El diseñador todavía toma las decisiones sobre el producto. El agente elimina gran parte del montaje y la verificación repetitivos. Esto funciona porque Zero ya tiene un sistema de diseño razonablemente maduro.
1. Comience el diseño del producto sin Figma con un sistema de diseño
Trabajar sin Figma no significa trabajar sin reglas de diseño. Requiere reglas más claras.
Para Zero, el agente puede inspeccionar:
- Componentes existentes para botones, entradas, desplegables, tarjetas, diálogos y navegación
- Espaciado, tipografía, colores, bordes y radios de las esquinas establecidos
- Estados existentes de hover, seleccionado, deshabilitado, vacío y móvil
- Copiar convenciones como el uso de mayúsculas en las oraciones y etiquetas breves dirigidas al usuario
- Pantallas reales que muestran cómo se combinan estas piezas
Estas referencias responden preguntas de diseño comunes. Una nueva entrada debería parecerse a las entradas que ya se entregan. Una nueva tarjeta debería usar la misma superficie y radio que la tarjeta existente más cercana. Un botón de icono debería tener la misma retroalimentación al pasar el cursor que otros botones de icono.
Esto le da al agente un límite. Puede explorar la estructura de una característica sin inventar un nuevo lenguaje visual para cada pantalla.
Figma sigue siendo útil cuando un equipo está creando una nueva marca, un nuevo sistema de componentes o una interacción que no tiene una referencia cercana al producto. Pero una vez que el sistema está maduro, el producto en funcionamiento puede convertirse en la principal superficie de diseño. Esta es la versión a escala de funciones del flujo de trabajo de diseño como código que utilizamos para reconstruir Zero.
2. Usa ui-design para explorar nueve direcciones de diseño de producto
Cada característica todavía necesita exploración. No quiero que un agente tome mi primera frase y la convierta inmediatamente en código.
Comienzo con ui-design. Le doy al agente la pantalla actual, el problema del usuario, el objetivo y las principales restricciones. El agente lee los patrones de producto existentes y devuelve una dirección recomendada más nueve alternativas.
En lenguaje sencillo, la habilidad captura la pantalla actual, crea una dirección recomendada, explora nueve alternativas distintas, presenta las compensaciones y espera una elección humana.
El pensamiento de diseño dentro de esta instrucción
Esta instrucción no es solo una lista de reglas visuales. Convierte el proceso normal de un diseñador en una secuencia repetible:
- Entiende antes de proponer. Captura la pantalla actual y lee el producto circundante antes de hacer cualquier cosa.
- Piensa en sistemas. Trata los componentes existentes, las páginas plantilla, los patrones de interacción y las reglas de texto como el material de partida.
- Evita la reinvención. La IA tiende a crear un nuevo patrón cuando la indicación es vaga. La instrucción le indica que encuentre el componente o página enviada más cercana y lo reutilice en lugar de aproximarse desde la memoria.
- Explora antes de elegir. El ancla After ofrece una dirección plausible. Las nueve variantes abren diferentes decisiones sobre el diseño, la jerarquía, la densidad, el punto de entrada y la divulgación.
- Separe la exploración del compromiso. El agente se detiene después de presentar las opciones. Un humano compara las compensaciones y elige antes de que comience el código.
- Revisa toda la experiencia. El texto, la retroalimentación al pasar el cursor, los estados, el comportamiento en móvil y la consistencia visual son parte del diseño, no de la limpieza después de la implementación.
Ese es el pensamiento sistemático que quiero de la habilidad: entender el producto existente, explorar dentro de él y luego tomar una decisión explícita.
Aquí está la instrucción original completa, reproducida literalmente del flujo de trabajo en vivo:
Instrucción original completa de ui-design
# vm0 / Zero Reglas de Diseño de UI
## Flujo de trabajo: primero los visuales, luego el código
**No saltes directamente al código.** Cuando se invoca esta habilidad, el primer entregable siempre es un conjunto de maquetas renderizadas para que Ming las vea. La implementación ocurre solo después de elegir una dirección.
### Paso 1 — Captura el "antes"
- Si una pantalla ya existe, representa su estado actual como la imagen de **antes** (toma una captura de pantalla de la aplicación en ejecución o representa el componente existente como una vista previa estática).
- Si la solicitud es para una pantalla completamente nueva, el "antes" es o la pantalla existente más cercana o un estado en blanco; haz esto explícito en el pie de foto.
### Paso 2 — Produce un solo ancla "después"
- Un modelo que represente tu interpretación más aproximada de la solicitud, cumpliendo plenamente cada regla a continuación (componentes, uso de mayúsculas en las oraciones, entradas/desplegables de detalles del agente, radios de las tarjetas del compositor de chat, botón de agregar horario, efectos hover en IconButton, superficies gris-50).
- Empáralo con el **antes** lado a lado. Etiquétalos claramente: `Before` / `After`.
### Paso 3 — Generar 9 exploraciones variantes
Después del par de antes/después, produce **9 maquetas variantes distintas** para la misma pantalla. Cada variante debe explorar un eje de diseño significativamente diferente, no solo 9 ajustes de color. Cubre un rango como:
1. Diseño — columna única vs. dividida / barra lateral / cuadrícula
2. Densidad — compacto vs. espacioso
3. Jerarquía — qué elemento lidera visualmente
4. Tratamiento de superficies: planas vs. agrupadas por tarjeta vs. secciones divididas
5. Punto de entrada: acción en línea vs. CTA dedicado vs. héroe en estado vacío
6. Enmarcamiento del texto publicitario — instructivo vs. mínimo vs. conversacional
7. Divulgación — todo visible vs. revelación progresiva / acordeones
8. Composición — guiada por el contenido vs. guiada por el control
9. Una dirección deliberadamente poco convencional / 'comodín' que vale la pena ver una vez
Cada variante todavía debe respetar los elementos no negociables (mayúscula inicial en las oraciones, reutilización de componentes, estilo de entrada/desplegable de detalles del agente, radios del compositor de chat, botón agregar horario, hover de IconButton, neutros gris-50). Las variantes exploran *diseño y énfasis*, no "qué pasaría si ignoráramos el sistema de diseño."
### Paso 4 — Presentar, luego esperar
- Muestra todas las imágenes a Ming en un solo mensaje: primero el par `Before / After`, luego las 9 variantes numeradas del 1 al 9 con un pie de foto de una línea cada una describiendo el eje que se está explorando.
- Pregunta qué dirección (o qué mezcla) seguir.
- No comiences la implementación hasta que Ming elija una dirección.
### Renderizando las imágenes
- Ruta preferida: construir vistas previas estáticas en HTML/React que usen tokens reales de Tailwind de `turbo/apps/platform`, tomarles capturas de pantalla y subirlas vía `okou web upload-file`.
- Para una exploración rápida: la habilidad `v0` puede generar maquetas variantes a partir de un prompt, pero el prompt debe enumerar explícitamente las reglas a continuación (mayúscula inicial en las frases, entradas de detalles del agente, radio del compositor de chat, etc.) para que la v0 no produzca una UI genérica de SaaS.
- Si la generación de imágenes no está disponible para la sesión, utiliza como alternativa wireframes ASCII / textuales claramente etiquetados para los 11 cuadros (antes, después, 9 variantes) y señálalo — nunca omitas silenciosamente el paso de los visuales.
---
# Reglas de diseño
Estas son las convenciones de diseño innegociables para cualquier nueva interfaz de usuario que se implemente dentro de la plataforma vm0 (`turbo/apps/platform`). Aplícalas antes de escribir componentes y audita las solicitudes de extracción existentes en función de ellas durante la revisión.
## Principios fundamentales
1. **Reutiliza, no reinventes.** Siempre verifica los primitivos existentes en `turbo/apps/platform/src/components/` y los patrones a nivel de vista bajo `src/views/` antes de introducir un nuevo componente. Si una interacción similar ya se ofrece en el detalle del agente, el horario o el compositor de chat, copia ese patrón en lugar de diseñar uno paralelo.
2. **Coincide con el lenguaje de diseño Zero.** Superficies suaves, grises neutros, radios generosos, bordes sutiles, sin sombras fuertes. La referencia visual es "tranquilo, con opinión, ligeramente editorial" — nunca predeterminado de SaaS.
3. **Habla desde el lugar del usuario.** El texto debe describir lo que *ellos* están a punto de hacer o ver, no lo que el sistema está haciendo. Manténlo breve: normalmente una sola oración, máximo dos.
## Patrones de referencia (cópialos directamente)
| Elemento | Fuente de referencia | Por qué |
|---------------------|---------------------------------------------------|-----|
| Entrada de texto / área de texto | Entrada de página de detalles del agente (`src/views/agent-detail/`) | Relleno establecido, borde, estado de enfoque, tratamiento de marcador de posición |
| Desplegable / seleccionar | Desplegable de la página de detalles del agente | Estilo de activador establecido, radio del menú, desplazamiento del ítem, colocación de la marca de verificación |
| Radio de la tarjeta/panel | Tarjeta de compositor de chat (busca los componentes `composer`) | Establece el radio de la tarjeta canónica y el estilo de la superficie en toda la aplicación |
| Botón principal de la página | Botón "Agregar horario" en la página de horarios | El primario neutral-oscuro usado en todas partes *fuera* de los modales |
| Botón principal modal | El color primario de la marca (solo dentro de diálogos/ventanas emergentes) | Los modales conservan el color primario de la marca; las páginas no |
| Botón solo de icono | IconButton existente con fondo al pasar el cursor | Cada ícono clicable debe tener un estado visible al pasar el cursor |
En caso de duda, abre el componente de referencia en la base de código, lee sus props y nombres de clase, y refléjalos. No aproximes de memoria.
## Directrices de redacción
- **Redacción desde la perspectiva del usuario.** "Conecta tu bandeja de entrada" es mejor que "Se requiere conexión de la bandeja de entrada". "Aún no hay agentes" es mejor que "La lista de agentes está vacía".
- **Brevedad sobre completitud.** Una línea corta supera a una oración completa. Recorta el relleno ("simplemente", "por favor", "en orden").
- **Uso de mayúscula inicial solo en la primera palabra de todo.** Etiquetas, encabezados, botones, elementos del menú, columnas de tablas: todo en mayúscula inicial solo en la primera palabra (“Proveedores de modelos”, “Claves API”, “Agregar horario”). Nunca en mayúsculas en cada palabra. Nunca `uppercase` mediante CSS en los encabezados de sección. Si encuentras una etiqueta en mayúscula en cada palabra o en mayúsculas completas, corrígela.
- **No uses etiquetas “decorativas” con mayúscula inicial** sobre los campos o secciones; parecen de formulario y anticuadas. Usa una etiqueta normal o omite la etiqueta si el campo es evidente por sí mismo.
- **No usar puntuación al final** en etiquetas o botones independientes. Los puntos se usan en el texto principal y en el texto de ayuda.
- Al renombrar una cadena, busca en el código la cadena antigua y pruébala: las etiquetas se mencionan en las pruebas y traducciones.
## Componentes y estructura
- Siempre construya páginas a partir de componentes existentes (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitivas de diálogo, etc.). Los nuevos componentes son un último recurso y requieren una justificación.
- Busca un diseño/plantilla existente (página de configuración, página de lista, página de detalle) y hereda su estructura básica. No vuelvas a derivar la estructura de la página.
- Al agregar a una página de estilo de configuración, coincida con el espaciado de las secciones, el tratamiento de los divisores y el ancho de las filas de formulario utilizados por las secciones vecinas.
## Botones
- **Page principaly** (el principal CTA en una página) → coincidir con el botón "Añadir horario" en la página de horarios. Este es el primario neutro oscuro/sólido usado en los diálogos externos de toda la app.
- **Modal primario** (el botón de confirmar dentro de cuadros de diálogo/popovers) → usa el color primario de la marca. Las páginas no.
- **Botones secundarios / fantasma** → reutiliza las variantes existentes; no inventes nuevas.
- **Botones de íconos** → deben tener un fondo al pasar el cursor (generalmente `hover:bg-gray-50` o el token de hover de IconButton establecido). Nunca publiques un ícono desnudo sin efecto hover como objetivo de clic.
- Todos los botones deben respetar los tokens de altura existentes; no introduzcas tamaños únicos.
## Campos de entrada
- Refleja la entrada de detalles del agente: mismo relleno, mismo borde, mismo anillo de enfoque (o la falta del mismo — verifica la referencia antes de agregar un anillo de enfoque), mismo color del marcador de posición.
- Multilínea: use el patrón de área de texto de detalle del agente (auto-creciente o filas fijas como en la referencia).
- No pongas dos puntos al final de las etiquetas de los campos.
- Texto de ayuda debajo del campo de entrada, en gris apagado, línea única.
## Desplegables / selectores
- Reflejar el desplegable de detalles del agente: misma apariencia del disparador, mismo radio del menú, mismo relleno de los elementos, mismos estados al pasar el cursor/seleccionados.
- El menú no debe ser más ancho que su disparador a menos que el contenido lo requiera.
- Evita los submenús anidados a menos que un desplegable existente ya los utilice.
## Tarjetas y superficies
- El radio de la tarjeta y el estilo de la superficie coinciden con la tarjeta del compositor de chat. No introduzcas un radio más pequeño o más grande sin una razón.
- Los bordes son sutiles (una línea fina en el token de borde existente). No hay sombras proyectadas a menos que el compositor de chat use una.
- Superficies neutras en móvil / rellenos gris claro (fondos de píldoras activas, rellenos de contenedores de iconos, etc.) → `bg-gray-50`. `gray-100` y `gray-200` se han considerado repetidamente demasiado oscuros — comenzar con `gray-50`.
## Enfoque e interacción
- No agregues sombras de caja o contornos personalizados `:focus-visible` a los elementos de navegación/marketing; en su lugar, reutiliza el cambio de color al pasar el cursor. (La misma restricción generalmente se aplica dentro de la plataforma a menos que un componente de referencia tenga un anillo de enfoque explícito.)
- Cada elemento interactivo (botón, botón de ícono, fila, enlace) necesita un estado visible al pasar el cursor. Prueba pasando el cursor sobre cada uno antes de considerar el diseño terminado.
- Los estados deshabilitados usan los tokens deshabilitados existentes; no inventes un color desvanecido.
## Lista de verificación de revisión
Antes de declarar una interfaz de usuario lista, repasa:
1. ¿Reutilicé componentes existentes en lugar de construir otros nuevos?
2. ¿Hice coincidir una plantilla / diseño de página existente?
3. ¿Son los inputs visualmente idénticos a los inputs de detalle del agente?
4. ¿Son los menús desplegables visualmente idénticos a los menús desplegables de detalles del agente?
5. ¿Las tarjetas coinciden con el radio y la superficie del compositor de chat?
6. ¿Está cada etiqueta en mayúscula y minúscula normal? ¿Queda alguna en Mayúsculas Iniciales o en MAYÚSCULAS COMPLETAS?
7. ¿Es el texto breve y escrito desde la perspectiva del usuario?
8. ¿Es la página principal el botón de estilo "Agregar horario"? ¿Se utiliza la marca principal solo dentro de los modales?
9. ¿Cada botón de ícono tiene un fondo al pasar el cursor?
10. ¿Pasé el cursor por cada elemento interactivo para confirmar la retroalimentación?
Si alguna respuesta es "no", arréglalo antes de abrir el PR.
## Cuando tengas dudas
- Abre el componente de referencia, lee su fuente y copia la estructura.
- Si dos componentes de referencia no coinciden, prefiera el que se haya enviado más recientemente (verifique el registro de git).
- Si el diseño realmente necesita un nuevo primitivo, coméntalo con Ming antes de construirlo: el trabajo de rediseño incluido debe estar en un solo PR con él como revisor.
No es necesario que las nueve opciones sean nueve diseños terminados. Su trabajo es darme suficiente alcance para ver el problema de manera diferente y avanzar en la dirección correcta. Si un concepto queda fuera del producto actual, un prototipo independiente React aún puede ayudar. Para esta función, me quedé dentro del sistema del producto real.
Un ejemplo real: la navegación de Zero
Zero originalmente tenía una barra lateral de 300 píxeles que contenía destinos de productos, agentes anclados e hilos de chat. Estaba realizando tres tareas a la vez. Quería separar esas tareas sin cambiar el área de conversación.
El resumen del producto para la exploración fue:
/ui-designReproduce la fase de diseño de la navegación de tres regiones de Zero desde la base histórica real. Separe los destinos de productos, agentes y conversaciones en regiones más claras sin cambiar el área de conversación. Use tokens, íconos y componentes reales de Zero. Produzca un Antes fiel a la fuente, un Después sólido y nueve variantes genuinamente diferentes. No edite el código del producto ni presente un maqueto como evidencia del navegador.
La primera exploración fue demasiado cautelosa. Varias opciones cambiaron anchos y estilos de selección, pero todavía parecían la misma barra lateral. Rechacé ese conjunto y le pedí al agente que hiciera visibles las diferencias a nivel de arquitectura de la información.
La segunda ejecución devolvió nueve direcciones genuinamente diferentes. Las agrupé en una tabla de 3 × 3 para que sea fácil compararlas sin convertir el artículo en una larga tira de imágenes. Cada miniatura se abre en el visor de imágenes del blog.
| 1. Navegación superior | 2. Cajón plegable | 3. Hilo primero |
|---|---|---|
 |  |  |
| Mover los destinos encima de la conversación | Ocultar destinos hasta que sea necesario | Haz de las conversaciones el objeto principal de navegación |
| 4. Primero el agente | 5. Conversación primero | 6. Lanzador de comandos |
 |  |  |
| Elige un agente antes que sus hilos | Coloca los agentes fijados sobre la conversación activa | Abrir destinos desde un menú buscable |
| 7. Riel extensible | 8. Entrada del tablero | 9. Barra inferior |
 |  |  |
| Expande un riel estrecho solo cuando sea necesario | Comienza desde el trabajo reciente | Mover los destinos al fondo |
No elegí uno de estos marcos exactamente como se dibujó. Los usé para decidir qué debía permanecer y qué debía cambiar. La dirección final utilizó un riel de destino estrecho, un riel de chat separado, cinco agentes fijados visibles y el área de conversación existente.
La salida importante de ui-design no fue solo la imagen. Fue un breve registro de decisión:
- Mantén un riel de destino de 68 píxeles y un riel de chat de 300 píxeles
- Mostrar cinco ranuras de agentes fijados
- Mantén la selección silenciosa pero legible
- Mostrar la guía de reordenamiento solo mientras se arrastra
- Mantén la conversación y el cajón móvil existente sin cambios
Eso fue suficiente para comenzar la implementación.
3. Utiliza ui-implement para convertir el diseño seleccionado en código
Después de que elijo una dirección y conecto la base de código del producto, el agente trabaja directamente en el código. No vuelvo a dibujar el marco seleccionado en Figma primero.
En lenguaje sencillo, ui-implement omite la exploración porque la dirección ya ha sido elegida. Encuentra los componentes reales y la estructura de la página más cercanos, construye con ellos, audita el resultado y verifica la función en un navegador.
Lo que protege esta instrucción
- La dirección elegida no debe ser rediseñada durante la implementación.
- El agente debe comenzar con el componente existente más cercano y la página de plantilla.
- Reutilizar gana sobre un componente nuevo a menos que el producto tenga una brecha real.
- La autoauditoría y la verificación del navegador detectan copias, estados e interacciones inconsistentes.
- Si una decisión sobre el producto aún no se ha resuelto, el trabajo vuelve a
ui-design.
Así es como el sistema de diseño se mantiene activo durante la implementación. No es un documento que el agente lea una sola vez. Moldea qué componentes elige y cómo verifica la experiencia terminada.
Aquí está la instrucción original completa, reproducida literalmente del flujo de trabajo en vivo:
Instrucción original completa de ui-implement
# vm0 / Zero Reglas de Implementación de UI
## Flujo de trabajo — implementar directamente
Cuando se invoque esta habilidad, **omite la fase de maqueta y exploración de variantes**. Comienza a implementar inmediatamente en `turbo/apps/platform`, aplicando todas las reglas de diseño a continuación.
### Paso 1 — Localiza los componentes de referencia
Antes de escribir una línea, abre los componentes de referencia que vas a reflejar:
- Entrada / área de texto → `src/views/agent-detail/` entrada
- Desplegable / seleccionar → `src/views/agent-detail/` desplegable
- Radio de tarjeta/panel → tarjeta del compositor de chat
- Botón primario de la página → botón "Agregar horario" en la página de horarios
- Botón solo con ícono → `IconButton` existente con fondo al pasar el cursor
Lee sus props y nombres de clase. Haz un espejo de ellos — no los aproximes de memoria.
### Paso 2 — Encuentra la plantilla de página existente más cercana
Abre la página existente más cercana del mismo tipo (configuración, lista, detalle) y hereda su estructura: espaciado de secciones, tratamiento de divisores, ancho de filas de formulario. No vuelvas a derivar la estructura de la página.
### Paso 3 — Construir, luego autoauditarse
Implementa la pantalla con los primitivos existentes de `turbo/apps/platform/src/components/`. Cuando creas que está lista, recorre la **lista de verificación de revisión** al final de esta habilidad antes de reportar. Corrige cada respuesta 'no' antes de declarar el trabajo completo.
### Paso 4 — Verificar en el navegador
Para cualquier trabajo de interfaz de usuario, inicia el servidor de desarrollo y prueba la función en un navegador antes de reportar la tarea como completada. Pasa el cursor sobre cada elemento interactivo, prueba el camino principal y los casos límite, y observa posibles regresiones en las pantallas vecinas. La verificación de tipos y las pruebas verifican el código, no la corrección de la función; si no puedes abrir el navegador, dilo explícitamente.
### Cuándo recurrir a ui-design
Si la solicitud es abierta («diseñar una página de configuración para X») sin una dirección elegida, detente y ejecuta la habilidad `ui-design` en su lugar; el antes/después + 9 variantes existen exactamente para ese caso. `ui-implement` es para cuando la dirección ya está decidida.
---
# Reglas de diseño
Estas son las convenciones de diseño no negociables para cualquier nueva interfaz de usuario que se implemente dentro de la plataforma vm0 (`turbo/apps/platform`). Aplícalas al construir y revisa tu propio diff contra ellas antes de abrir el PR.
## Principios fundamentales
1. **Reutiliza, no reinventes.** Siempre verifica los primitivos existentes en `turbo/apps/platform/src/components/` y los patrones a nivel de vista bajo `src/views/` antes de introducir un nuevo componente. Si una interacción similar ya se ofrece en el detalle del agente, el horario o el compositor de chat, copia ese patrón en lugar de diseñar uno paralelo.
2. **Coincide con el lenguaje de diseño Zero.** Superficies suaves, grises neutros, radios generosos, bordes sutiles, sin sombras fuertes. La referencia visual es "tranquila, con opinión, ligeramente editorial" — nunca predeterminado de SaaS.
3. **Habla desde el lugar del usuario.** El texto debe describir lo que *ellos* están a punto de hacer o ver, no lo que el sistema está haciendo. Manténlo breve: normalmente una sola oración, máximo dos.
## Patrones de referencia (cópialos directamente)
| Elemento | Fuente de referencia | Por qué |
|---------------------|---------------------------------------------------|-----|
| Entrada de texto / área de texto | Entrada de página de detalles del agente (`src/views/agent-detail/`) | Relleno establecido, borde, estado de enfoque, tratamiento de marcador de posición |
| Desplegable / seleccionar | Desplegable de la página de detalles del agente | Estilo de activador establecido, radio del menú, desplazamiento del ítem, colocación de la marca de verificación |
| Radio de la tarjeta/panel | Tarjeta de compositor de chat (busca los componentes `composer`) | Establece el radio de la tarjeta canónica y el estilo de la superficie en toda la aplicación |
| Botón principal de la página | Botón "Agregar horario" en la página de horarios | El primario neutral-oscuro usado en todas partes *fuera* de los modales |
| Botón principal modal | El color primario de la marca (solo dentro de diálogos/ventanas emergentes) | Los modales conservan el color primario de la marca; las páginas no |
| Botón solo de icono | IconButton existente con fondo al pasar el cursor | Cada ícono clicable debe tener un estado visible al pasar el cursor |
En caso de duda, abre el componente de referencia en la base de código, lee sus props y nombres de clase, y refléjalos. No aproximes de memoria.
## Directrices de redacción
- **Redacción desde la perspectiva del usuario.** "Conecta tu bandeja de entrada" es mejor que "Se requiere conexión de la bandeja de entrada". "Aún no hay agentes" es mejor que "La lista de agentes está vacía".
- **Brevedad sobre completitud.** Una línea corta supera a una oración completa. Recorta el relleno ("simplemente", "por favor", "en orden").
- **Uso de mayúscula inicial solo en la primera palabra para todo.** Etiquetas, encabezados, botones, elementos de menú, columnas de tablas: todo en mayúscula inicial solo en la primera palabra ("Proveedores de modelos", "Claves API", "Agregar horario"). Nunca usar mayúsculas en cada palabra. Nunca `uppercase` mediante CSS en los encabezados de sección. Si encuentras una etiqueta en mayúsculas iniciales o completamente en mayúsculas, corrígela.
- **No uses etiquetas “decorativas” con mayúscula inicial** sobre los campos o secciones; parecen de formulario y anticuadas. Usa una etiqueta normal o omite la etiqueta si el campo es evidente por sí mismo.
- **No usar puntuación al final** en etiquetas o botones independientes. Los puntos se usan en el texto principal y en el texto de ayuda.
- Al renombrar una cadena, busca en el código la cadena antigua y pruébala: las etiquetas se mencionan en las pruebas y traducciones.
## Componentes y estructura
- Siempre construya páginas a partir de componentes existentes (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitivas de diálogo, etc.). Los nuevos componentes son un último recurso y requieren una justificación.
- Busca un diseño/plantilla existente (página de configuración, página de lista, página de detalle) y hereda su estructura básica. No vuelvas a derivar la estructura de la página.
- Al agregar a una página de estilo de configuración, coincida con el espaciado de las secciones, el tratamiento de los divisores y el ancho de las filas de formulario utilizados por las secciones vecinas.
## Botones
- **Page principaly** (el principal CTA en una página) → coincidir con el botón "Añadir horario" en la página de horarios. Este es el primario neutro oscuro/sólido usado en los diálogos externos de toda la app.
- **Modal primario** (el botón de confirmar dentro de cuadros de diálogo/popovers) → usa el color primario de la marca. Las páginas no.
- **Botones secundarios / fantasma** → reutiliza las variantes existentes; no inventes nuevas.
- **Botones de íconos** → deben tener un fondo al pasar el cursor (generalmente `hover:bg-gray-50` o el token de hover de IconButton establecido). Nunca publiques un ícono desnudo sin efecto hover como objetivo de clic.
- Todos los botones deben respetar los tokens de altura existentes; no introduzcas tamaños únicos.
## Campos de entrada
- Refleja la entrada de detalles del agente: mismo relleno, mismo borde, mismo anillo de enfoque (o la falta del mismo — verifica la referencia antes de agregar un anillo de enfoque), mismo color del marcador de posición.
- Multilínea: use el patrón de área de texto de detalle del agente (auto-creciente o filas fijas como en la referencia).
- No pongas dos puntos al final de las etiquetas de los campos.
- Texto de ayuda debajo del campo de entrada, en gris apagado, línea única.
## Desplegables / selectores
- Reflejar el desplegable de detalles del agente: misma apariencia del disparador, mismo radio del menú, mismo relleno de los elementos, mismos estados al pasar el cursor/seleccionados.
- El menú no debe ser más ancho que su disparador a menos que el contenido lo requiera.
- Evita los submenús anidados a menos que un desplegable existente ya los utilice.
## Tarjetas y superficies
- El radio de la tarjeta y el estilo de la superficie coinciden con la tarjeta del compositor de chat. No introduzcas un radio más pequeño o más grande sin una razón.
- Los bordes son sutiles (una línea fina en el token de borde existente). No hay sombras proyectadas a menos que el compositor de chat use una.
- Superficies neutras en móvil / rellenos gris claro (fondos de píldoras activas, rellenos de contenedores de iconos, etc.) → `bg-gray-50`. `gray-100` y `gray-200` se han considerado repetidamente demasiado oscuros — comenzar con `gray-50`.
## Enfoque e interacción
- No agregues sombras de caja o contornos personalizados `:focus-visible` a los elementos de navegación/marketing; en su lugar, reutiliza el cambio de color al pasar el cursor. (La misma restricción generalmente se aplica dentro de la plataforma a menos que un componente de referencia tenga un anillo de enfoque explícito.)
- Cada elemento interactivo (botón, botón de ícono, fila, enlace) necesita un estado visible al pasar el cursor. Prueba pasando el cursor sobre cada uno antes de considerar el diseño terminado.
- Los estados deshabilitados usan los tokens deshabilitados existentes; no inventes un color desvanecido.
## Lista de verificación de revisión
Antes de declarar una interfaz de usuario lista, repasa:
1. ¿Reutilicé componentes existentes en lugar de construir otros nuevos?
2. ¿Hice coincidir una plantilla / diseño de página existente?
3. ¿Son los inputs visualmente idénticos a los inputs de detalle del agente?
4. ¿Son los menús desplegables visualmente idénticos a los menús desplegables de detalles del agente?
5. ¿Las tarjetas coinciden con el radio y la superficie del compositor de chat?
6. ¿Está cada etiqueta en mayúscula y minúscula normal? ¿Queda alguna en Mayúsculas Iniciales o en MAYÚSCULAS COMPLETAS?
7. ¿Es el texto breve y escrito desde la perspectiva del usuario?
8. ¿Es la página principal el botón de estilo "Agregar horario"? ¿Se utiliza la marca principal solo dentro de los modales?
9. ¿Cada botón de ícono tiene un fondo al pasar el cursor?
10. ¿Pasé el cursor sobre cada elemento interactivo en un navegador para confirmar la retroalimentación?
Si alguna respuesta es "no", arréglalo antes de abrir el PR.
## Cuando tengas dudas
- Abre el componente de referencia, lee su fuente y copia la estructura.
- Si dos componentes de referencia no coinciden, prefiera el que se haya enviado más recientemente (verifique el registro de git).
- Si el diseño realmente necesita un nuevo primitivo, coméntalo con Ming antes de construirlo: el trabajo de rediseño incluido debe estar en un solo PR con él como revisor.
Este era el aviso de implementación específico de la función:
/ui-implementComience desde la revisión
04d642bb. Agregue una división de escritorio desactivada por defecto con un carril de destino de 68px, un carril de chat de 300px y la conversación sin cambios. Mantenga la barra lateral antigua de 300px cuando el interruptor esté apagado y en móvil. Renderice cinco espacios fijados, conserve el orden definido por el usuario y muestre las opciones de reordenamiento solo durante un arrastre activo. No inspeccione la función histórica ni los refinamientos posteriores hasta que el parche independiente, las pruebas y la evidencia del navegador estén congelados.
Para la función de navegación, le pedí al agente que mantuviera la barra lateral antigua cuando la función estuviera desactivada, mostrara el nuevo diseño de tres partes cuando estuviera activada, mantuviera el cajón móvil existente y permitiera a las personas reordenar los agentes fijados.
Durante la implementación, el agente encontró un problema importante. El producto antiguo recordaba qué agentes estaban fijados, pero no recordaba su orden. Una interacción de arrastrar podría parecer correcta y luego reiniciarse después de una actualización.
Entonces el agente hizo más que dibujar el estado de arrastre. Hizo que el nuevo pedido persistiera, refrescó la página y verificó que el pedido se mantuviera. También confirmó que las manijas de reorden solo aparecieran durante el arrastre y desaparecieran después.
La entrega de la implementación mostró los dos estados de escritorio que necesitaba revisar. Los muestro a ancho completo para que la interfaz siga siendo legible. El comportamiento móvil aparece más adelante en la presentación como una captura de teléfono de alta densidad.
Estado de reposo del escritorio
Reordenamiento activo
En este punto tenía una función funcional, no otro archivo de diseño. Pero la implementación todavía no era el final. Necesitaba ver qué estaba realmente funcionando en la vista previa desplegada.
4. Use ui-walkthrough para revisar el producto real
Los recorridos de productos solían ser tediosos. Abría una vista previa desplegada, preparaba la cuenta correcta, activaba y desactivaba funciones, hacía clic en cada control, cambiaba el tamaño del navegador, tomaba capturas de pantalla y trataba de recordar qué estado representaba cada imagen.
El agente tiene un Agent Browser incorporado, así que puedo delegarle ese trabajo.
El flujo de trabajo tiene dos pasos principales:
- Enumere los escenarios primero. El agente convierte las afirmaciones de diseño e implementación en una lista de verificación.
- Ejecute la lista de verificación y adjunte evidencia. Se ejecuta en cada escenario en la vista previa desplegada y devuelve PASS, FAIL, o BLOCKED con una captura de pantalla para cada estado significativo.
Lo que esta instrucción cambia sobre la revisión
- El agente enumera los escenarios antes de comenzar a hacer clic.
- Utiliza el componente realmente desplegado a través de su Agent Browser integrado.
- Captura una captura de pantalla por cada estado significativo.
- Marca cada punto de control PASS, FAIL o BLOCKED.
- Nunca oculta un estado no disponible detrás de evidencia falsa.
Esto convierte los clics manuales en un paquete de revisión organizado. Puedo ver el comportamiento esperado, el resultado y la evidencia juntos.
La instrucción completa está a continuación. He traducido el nombre de la dependencia interna a “built-in Agent Browser” para mayor claridad para el lector; la lógica del flujo de trabajo no ha cambiado.
Instrucción original completa de ui-walkthrough
# Recorrido de la interfaz de usuario
QA visual de extremo a extremo de una función de interfaz vm0/Zero en su vista previa real por PR. Este flujo de trabajo define qué verificar y cómo reportar el resultado; no define herramientas de operación de la interfaz de usuario.
## Dependencia requerida: Agent Browser incorporado
Utilice el Agent Browser incorporado como la única fuente de verdad para cada interacción de la interfaz de usuario, incluyendo:
- Descubriendo y abriendo la vista previa por PR.
- Manejo de protección de vista previa y configuración de sesión.
- Registro, OTP, incorporación, prueba de pago en Stripe y acceso a la aplicación en vivo.
- Habilitando interruptores de función.
- Navegar, interactuar con controles, suministrar datos de prueba o simulados, capturar capturas de pantalla, subir artefactos, solucionar problemas y limpiar.
Lea y siga las instrucciones integradas actuales Agent Browser antes de realizar cualquier acción en la interfaz de usuario. No duplique comandos específicos de tiempo de ejecución, configuración del motor, mecánica de selectores, scripts de contexto de página, gestión de sesiones ni métodos de limpieza de procesos en este flujo de trabajo. Si las instrucciones integradas Agent Browser cambian, sus instrucciones actuales tienen prioridad.
## Cuándo usar
- Recorre la interfaz de usuario de una solicitud de extracción de vm0 en su vista previa desplegada.
- Verifica una función en la aplicación que requiera autenticación, incorporación, facturación, cambios de funciones o un hilo de chat real.
- Captura capturas de pantalla fieles o un breve video de recorrido de la función funcionando en la aplicación en vivo.
## Flujo de trabajo paso a paso
### 1. Establecer el objetivo y el alcance
- Identifica el PR, el commit principal, el comportamiento visible por el usuario que cambió y la vista previa esperada.
- Confirma que la vista previa desplegada corresponde a la cabeza del PR antes de probar.
- Lee la diferencia y la descripción del PR para derivar el camino crítico y los estados que demuestran el cambio.
- No arregle el código, resuelva conflictos ni cambie el comportamiento del producto durante una revisión a menos que el usuario solicite por separado la implementación.
### 2. Alcanzar la función
Utilice el Agent Browser incorporado para entrar en la vista previa y alcanzar el estado de función en vivo. Siga sus reglas actuales para autenticación, incorporación, facturación, conmutadores de funciones y excepciones solo para vista previa.
Si se utiliza un bypass, consígnelo en el informe final. Nunca use un bypass de incorporación cuando la incorporación misma esté bajo prueba.
### 3. Definir la matriz de estado visual
Antes de interactuar, enumere el conjunto más pequeño de estados que demuestre que la función funciona. Incluya los elementos aplicables:
- Estado inicial/predeterminado.
- Estado abierto, al pasar el cursor, enfocado, seleccionado, expandido o activo.
- Estados vacíos y llenos.
- Estados habilitado y deshabilitado.
- Éxito, validación, carga y estados de error.
- Colocación, colisión, volteo, recorte y comportamiento responsivo.
- Envío o acción posterior cuando la función es interactiva.
Prefiere practicar el comportamiento realmente cambiado en lugar de una prueba de humo genérica.
### 4. Conducir el componente activo
Use el Agent Browser incorporado para todas las técnicas de interacción y de datos de prueba.
El contenido simulado o inyectado solo puede usarse para colocar un componente de aplicación real en un estado visual determinista. El componente, el estilo y la interacción que se están evaluando deben seguir siendo la implementación en vivo de la vista previa del PR.
Para cada estado simulado:
- Registra qué contenido o requisito previo fue simulado.
- Distinguir el contenido simulado del comportamiento real de la aplicación.
- Nunca insinúes que el texto o los datos simulados provienen de un modelo o de una fuente de producción.
- Ejercite los controles reales y el cableado descendente siempre que el entorno lo permita.
### 5. Capturar evidencia
Utilice el Agent Browser incorporado para capturar y cargar evidencia de los puntos de control clave. Cada imagen debe demostrar un estado significativo en lugar de repetir la misma vista.
Si el usuario solicita un video, ensambla un recorrido corto con subtítulos a partir de los puntos de control verificados. Los subtítulos deben identificar la acción del usuario y el resultado esperado sin ocultar la interfaz de usuario.
### 6. Entregar e informar
Informe:
- Enlace de PR, URL de vista previa exacta y commit probado cuando esté disponible.
- Flujo de usuario exacto ejercido.
- Cuenta de prueba cuando se creó una.
- `PASS`, `FAIL`, o `BLOCKED` para cada punto de control.
- Enlaces de capturas de pantalla y un enlace de video opcional con descripciones breves.
- Interruptores de funciones, bypasses, datos simulados y otra configuración usada solo para pruebas.
- Controles fallidos, bloqueos del entorno o brechas de verificación.
No afirme que la función está verificada a menos que se haya ejecutado el flujo de vista previa en vivo y se haya capturado evidencia. Si la vista previa no está disponible, informe `BLOCKED` con la evidencia de despliegue en lugar de sustituirla por una réplica local o estática.
Este era el aviso de recorrido específico de la función:
/ui-walkthroughUtiliza la vista previa desplegada a través del Agent Browser incorporado como la única verdad del navegador. Demuestra la barra lateral con la función desactivada, la división de 68px y 300px, el orden de destino, los estados de desplazamiento, cinco ranuras fijadas, manejadores solo de arrastre, reorden persistente, selección de hilo, desplazamiento y el cajón completo del iPhone. Devuelve PASS, FAIL o BLOCKED para cada punto de control. No reemplaces un estado inaccesible con una réplica.
Para esta función, el agente organizó la presentación guiada alrededor de estas preguntas:
- ¿Todavía funciona la barra lateral antigua cuando la función está desactivada?
- ¿Aparece la nueva estructura de escritorio cuando está encendida?
- ¿Son visibles pero discretos los estados de pasar el cursor y de selección?
- ¿Son legibles cinco agentes fijados?
- ¿Los controles de reordenamiento permanecen ocultos hasta que comienza un arrastre?
- ¿Sobrevive el nuevo pedido a una actualización?
- ¿Puedo seleccionar y desplazarme por hilos reales?
- ¿Sigue funcionando el cajón móvil existente?
- ¿Están todos los destinos de navegación presentes y en el orden correcto?
Luego, el agente abrió la vista previa desplegada como un nuevo usuario, completó la incorporación, activó la función y trabajó en la lista. Probó el estado en reposo, el estado al pasar el cursor, el estado de arrastre, el comportamiento de actualización, la selección de hilos, el desplazamiento y el diseño para teléfono.
El resultado fue 11 PASS, 1 FAIL.
El fracaso fue útil. El diseño y las interacciones funcionaron, pero la vista previa desplegada mostraba solo seis destinos de productos. Activity y Insights estaban ausentes, y el orden no coincidía con el diseño seleccionado.
| Escenario | Resultado |
|---|---|
| Barra lateral antigua con la función desactivada | PASS |
| Nuevo diseño de escritorio de tres partes | PASS |
| Estados de pasar el cursor y seleccionado | PASS |
| Cinco agentes fijados | PASS |
| Guía de reordenamiento solo por arrastre | PASS |
| Pedido guardado después de actualizar | PASS |
| Selección de hilo y desplazamiento | PASS |
| Cajón móvil existente | PASS |
| Contenido y orden de destino | FAIL |
La entrega final fue un conjunto de capturas de pantalla organizadas en lugar de una carpeta de imágenes sin etiquetar. Las capturas de escritorio son de 1440 × 900 píxeles y la captura del teléfono es de 1170 × 2532 píxeles. Aparecen una a la vez a continuación para que la interfaz siga siendo legible; haga clic en cualquier imagen para agrandarla sin salir del artículo.
Función desactivada
Función habilitada
Diseño de escritorio
Destino al pasar el cursor
Agente fijado al pasar el cursor
Arrastre activo
Pedido guardado
Cajón móvil
Esto me permite revisar una función de manera estructurada. Puedo ver los escenarios previstos, el resultado real desplegado y la evidencia juntos. Si algo falla, sé exactamente dónde debe regresar el trabajo.
Cómo un equipo adopta este flujo de trabajo de diseño de productos de IA
El proceso completo es corto. Los compañeros de equipo pueden guardar cada etapa como flujo de trabajo compartido Zero en lugar de reconstruir el proceso desde la memoria.
| Escenario | Aporte | Salida |
|---|---|---|
ui-design | Pantalla actual, problema, objetivo y restricciones | Una dirección recomendada, nueve alternativas y un registro de diseño seleccionado |
ui-implement | El registro de diseño seleccionado | Un cambio de código revisable y capturas de pantalla de los estados principales |
ui-walkthrough | La función desplegada y su comportamiento esperado | Una lista de escenarios organizada con capturas de pantalla de PASS, FAIL o BLOCKED |
Un compañero de equipo no necesita reproducir mi gusto por el diseño. Deben proporcionar un buen contexto, utilizar el sistema de producto compartido, tomar una decisión explícita después de la exploración y revisar la evidencia del navegador. Los mismos tres puntos de control humanos (problema, dirección y aceptación) también dan forma a nuestra forma de gestionar agentes de IA como un equipo.
Este flujo de trabajo no elimina la práctica de diseño ni el pensamiento de diseño. Los traslada a las partes donde más importan: definir el problema, establecer restricciones, comparar direcciones, elegir compensaciones y juzgar el producto en funcionamiento.
Cuando el sistema de componentes esté maduro, ya no necesito reconstruir cada característica como bloques arrastrables en Figma. Puedo trabajar con el agente directamente en el producto, mientras que el sistema de diseño mantiene la coherencia del resultado y el recorrido mantiene el resultado honesto.
Preguntas frecuentes
¿Cómo se crea un flujo de trabajo de diseño de productos de IA?
Comience con el sistema de producto existente, no con un mensaje en blanco. Separe el trabajo en exploración, implementación y revisión. Deje que el agente genere opciones y realice comprobaciones repetibles, pero mantenga al diseñador del producto responsable del problema, la dirección elegida y la aceptación final.
¿Pueden los diseñadores de productos trabajar sin Figma?
Sí, cuando el producto ya cuenta con componentes estables, plantillas de página y patrones de interacción. Figma sigue siendo útil para un nuevo lenguaje visual o una interacción desconocida. El punto no es prohibir Figma; es para evitar reconstruir decisiones de productos conocidas en un segundo lienzo.
¿La IA está sustituyendo a los profesionales del diseño de producto?
No en este flujo de trabajo. El agente reúne opciones, edita código y verifica escenarios. El diseñador aún plantea el problema, establece restricciones, compara compensaciones, elige la dirección y decide si el producto en ejecución es lo suficientemente bueno para enviarse.
