Aprende a usar prompts con tokens de diseño y reglas de componentes para que las pantallas generadas en React mantengan coherencia en espaciado, tipografía y formularios.
La inconsistencia en la UI normalmente aparece en pequeños detalles que resultan raros al navegar. Una página tiene padding generoso, otra se siente apretada. Los encabezados saltan entre tamaños, los botones cambian de forma y color, y el mismo input se comporta distinto según la pantalla.
La mayoría de las veces, la deriva viene de unos básicos:
Esto es común cuando las pantallas se generan a partir de prompts separados. Cada prompt es, en efecto, un nuevo comienzo, así que el modelo rellena decisiones faltantes adivinando. Incluso “usar un estilo moderno” deja cientos de pequeñas elecciones: 8px vs 12px de gap, 14px vs 16px de texto, cuándo mostrar errores, cómo es un botón primario.
Puedes limpiar dos o tres pantallas manualmente, pero no escala. Acabas persiguiendo ajustes CSS puntuales, copiando estilos entre archivos y volviendo a arreglar formularios. Las reglas están en tu cabeza, no en el proyecto.
Imagina generar una pantalla de login hoy y una de perfil mañana. Si una muestra errores solo al enviar y la otra al perder foco, los usuarios lo notan. Si la altura del botón primario cambia entre pantallas, la app se siente remendada.
La consistencia se vuelve la norma cuando cada pantalla sigue el mismo sistema compartido: design tokens (espaciado, tipografía, color) más un pequeño conjunto de reglas de componentes y formularios.
Los design tokens son valores nombrados simples que reutilizas en toda la UI. En lugar de pedir “padding cómodo” en cada pantalla, usas un token como space-4. En vez de “ligeramente redondeado”, usas radius-md. El nombre se mantiene estable incluso si más tarde cambias a qué corresponde.
Los tokens son el conjunto de decisiones que quieres que todas las pantallas compartan. Eliminan gusto y conjeturas, que es exactamente lo que causa deriva cuando generas o construyes nuevas páginas.
Los tokens típicos cubren espaciado, tipografía, colores, forma y una pequeña cantidad de elevación. La ganancia es práctica: un header siempre usa el mismo tamaño, una tarjeta siempre usa el mismo padding y un botón primario conserva el mismo color y radio.
Tokeniza lo que afecta la sensación general del producto: la escala de espaciado, tamaños de fuente y alturas de línea, colores principales (texto, fondo, primario, danger, borde) y un pequeño conjunto de radios de borde.
Deja flexibles las decisiones impulsadas por el contenido, como la longitud del copy, qué icono usar o si una sección necesita dos o tres tarjetas.
Cuando generas pantallas (incluyendo con herramientas como Koder.ai), dar un pequeño set de tokens desde el inicio reduce la cantidad de conjeturas y hace que la salida sea notablemente más consistente.
Un set de tokens es simplemente un menú corto de valores permitidos. Más pequeño es mejor porque deja menos espacio para elecciones aleatorias, pero aún debe cubrir lo básico que hace que las pantallas se vean mal.
Empieza por el espaciado. Elige una escala y úsala en todas partes para padding, gaps y layout. Un conjunto como 4, 8, 12, 16, 24, 32 cubre la mayoría de la UI. Si un diseño pide 10px u 18px, redondea al token más cercano en lugar de introducir nuevos números.
Luego define defaults tipográficos para que encabezados y texto de cuerpo dejen de desviarse. No necesitas un sistema tipográfico enorme. Necesitas pasos claros y repetibles.
Un set compacto que sigue siendo usable sin inflarse:
La accesibilidad también pertenece al sistema. Define un estilo de outline en focus (color, grosor, offset) para que los usuarios de teclado obtengan estados de foco consistentes. Establece un tamaño mínimo de objetivo táctil (por ejemplo 44x44) para móvil. Limita los colores de texto a un conjunto pequeño y confiable para mantener el contraste predecible.
Si los botones a veces se ven apretados, a menudo es porque una pantalla usó padding 10 y otra 12. Con tokens, puedes decir: “Buttons usan paddingY=8, paddingX=16, radius=12, token de outline en focus, min height 44.” Una vez que esos números están fijados, el generador deja de improvisar.
Los tokens fijan los números. Las reglas de componentes fijan los hábitos.
Elige un pequeño conjunto de componentes centrales y trátalos como los únicos bloques de construcción para pantallas. Mantenlos simples y reutilizables: Button, Input, Select, Checkbox, Card. Puedes añadir TextArea y Modal, pero deben seguir el mismo sistema (labels, espaciado, estados).
Luego, limita variantes y define cuándo están permitidas. Por ejemplo: Button tiene primary, secondary y danger. Primary es para la acción principal en la pantalla (usualmente una). Secondary es para cancelar o acciones de baja prioridad. Danger solo para acciones destructivas como eliminar. Si no se puede justificar una variante, usa secondary por defecto.
Las reglas de espaciado evitan la deriva sutil. Define valores por defecto dentro de los componentes: padding de Button, altura de Input, gap label-campo, el gap estándar entre campos apilados. Añade unas pocas reglas de layout también: Cards tienen padding interno fijo y espaciado header/body consistente; Modales usan los mismos pasos de ancho y alineación del footer.
Finalmente, haz que los estados sean innegociables porque aquí es donde las UIs suelen empezar a verse aleatorias:
Cuando generas una pantalla con muchos formularios como “Create project”, estas reglas evitan mezclas de tamaños de botón, posiciones de etiquetas que cambian o una “tarjeta especial” que solo aparece en una página.
Incluso con visuales estables, muchas quejas de “se siente raro” vienen del comportamiento de formularios. Si cada pantalla maneja etiquetas, errores y foco de forma distinta, los usuarios lo perciben como inconsistencia.
Elige un patrón de formulario y úsalo en todas partes: etiqueta, marcador optional/required, helper text y luego texto de error. Mantén el wording consistente también (por ejemplo, etiquetas en sentence case, helper text corto y mensajes de error que empiecen con un verbo).
Las reglas que previenen la mayor parte de la deriva:
Fija tamaños y layout para que las pantallas no “respiren” de manera distinta. Define una altura de input, una altura de botón y un ancho de campo por defecto. En desktop, alinea campos a una rejilla consistente y apila labels sobre inputs. En móvil, haz campos full width y evita formularios de dos columnas salvo que sea realmente necesario.
Un ejemplo simple: una pantalla “Create project” puede tener Name, Region y Description. Incluso si Region es un select, trátalo como cualquier otro campo: misma altura, misma posición de label, misma línea de error. Si el usuario envía con Name vacío, el foco va a Name, el error aparece debajo y el layout permanece estable.
Si generas pantallas en Koder.ai, pon estas reglas de formulario en tu prompt una vez y reutilízalas en features para que cada nuevo formulario se comporte igual sin limpieza repetida.
Trata tu prompt como un pequeño contrato UI. Mantenlo corto, específico y reutilizable para que cada nueva pantalla encaje con el mismo espaciado, tipografía, componentes y comportamientos.
Un patrón práctico es pegar un spec UI compacto al inicio de tu petición y luego describir la pantalla en lenguaje llano.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Después del spec, añade algunas comprobaciones de aceptación que detecten la deriva temprano:
Si usas un generador por chat, mantiene este spec estable entre peticiones. Cambiarlo cada vez anula el propósito.
Escribe el contrato UI antes de generar nada: un set pequeño de tokens (espaciado, tipografía, colores, radios, sombras) más un inventario corto de componentes (Button, Input, Select, Card, Modal, Table, Toast). Si falta un token o componente, el modelo lo inventará y tu UI derivará.
Luego crea una pantalla de referencia que ponga a prueba las reglas. Una página con muchos formularios es buena porque incluye encabezados, helper text, errores de validación, botones primario y secundario y un toast de éxito. Trata esa pantalla como baseline.
A partir de ahí, crea nuevas pantallas componiendo lo que ya definiste. No pidas “nuevo estilo”. Pide la misma Card, la misma escala de espaciado, los mismos pasos tipográficos y el mismo patrón de campos.
Un flujo simple:
Si una pantalla “Search users” termina con espaciado más apretado que la referencia, no ajustes márgenes manualmente. Actualiza los tokens de espaciado o la regla de padding de Card una vez, luego regenera.
Si trabajas en Koder.ai, snapshots y rollback ayudan: bloquea una baseline, experimenta con seguridad y revierte rápido si un cambio empieza a introducir drift.
La manera más rápida de perder consistencia es tratar tokens y reglas como sugerencias. Pequeñas excepciones se multiplican.
Una trampa común es cambiar la escala de espaciado a mitad de proyecto. Las primeras pantallas usan 8, 16, 24. Una nueva introduce 10 y 18 “porque se ve bien”. Ahora la deriva está permitida y las pantallas antiguas nunca se actualizan.
Otra fuente de deriva es dejar que el generador invente nuevos estilos de componente. Si no dices “solo estas variantes de botón existen”, puede crear un nuevo radio o diferente padding en un solo lugar.
Los estados son otro fallo frecuente. Loading, empty y error suelen cambiar espaciado y comportamiento. Si los añades al final, normalmente obtienes patrones apresurados que no coinciden.
También vigila la vaguedad: “hazlo moderno con sombras suaves” es impreciso, mientras que reglas de comportamiento como “los errores muestran bajo el campo”, “los botones deshabilitados mantienen estilos de foco” y “Enter envía solo en el último campo” son concretas y repetibles.
Si quieres un bloque guardarraíl ligero para pegar en prompts, mantenlo corto:
Antes de mergear una pantalla generada, haz un escaneo de dos minutos.
Empieza por el espaciado. Busca valores aleatorios como 13px o márgenes puntuales añadidos “solo para encajar”. Si usas tokens, cada gap debería salir del set aprobado, incluyendo gutters, padding de tarjetas y espaciado entre campos.
Luego comprueba la tipografía contra tu escala. Los encabezados deben decrecer de forma predecible. El texto de cuerpo no debe cambiar de tamaño entre secciones similares. La altura de línea importa, especialmente en pantallas densas como settings.
Revisa botones. Variantes y tamaños deben seguir tus reglas: primary para la acción principal, secondary para acciones menos importantes, danger solo cuando realmente borra. Altura del botón, colocación de iconos y estilo de label deberían coincidir.
Para formularios, la consistencia es sobre estructura. Las etiquetas permanecen en un lugar, los indicadores required siguen una regla, helper text y errores no compiten, y los errores aparecen en un punto consistente.
Una checklist corta:
Finalmente, haz una comprobación rápida en móvil. Reduce el ancho y confirma que el layout se adapta sin inventar nuevos tamaños de fuente o espaciados.
Imagina un flujo de onboarding simple: tres pantallas (Profile, Preferences, Confirm), más una pantalla de Settings después. Quieres que cada pantalla parezca salida del mismo diseñador, aunque se generen por separado.
Antes de generar nada, proporciona un pequeño set de tokens y unas reglas de componentes:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Ahora genera “Profile” y “Preferences” por separado. Porque ambas pantallas deben usar Page, Card, Field y Button row como se definió, salen con los mismos márgenes, espaciado de etiquetas y colocación de botones. El paso Confirm sigue encajando aunque tenga más texto de solo lectura.
El comportamiento de formularios es donde suele colarse la deriva, así que defínelo una vez y reutilízalo: submit deshabilitado hasta ser válido, errores inline solo tras blur o submit, Enter envía solo en el último paso, y el botón Back nunca borra valores ya introducidos.
Cuando necesites una pieza nueva, no dejes que el modelo improvise. Añade una regla y regenera pensando en la reutilización:
Convierte tokens y reglas en un spec reutilizable que realmente uses. Si es demasiado largo para pegar, no se seguirá.
Un spec práctico suele incluir: tu tabla de tokens (espaciado, tipografía, radios, colores), un set corto de reglas de componentes (botones, inputs, cards, headings), reglas de comportamiento de formularios (timing de validación, errores, disabled/loading), defaults de layout (padding de página, max width, espaciado de secciones) y una breve lista de “nunca hacer” (márgenes aleatorios, tamaños tipográficos ad-hoc).
Luego adopta un hábito: actualiza el spec primero, no píxeles individuales.
Si usas Koder.ai (koder.ai), el modo planning es un buen lugar para reafirmar y confirmar el spec antes de generar UI. Cuando quieras probar alternativas, snapshots y rollback te permiten explorar sin perder una baseline estable.
Porque cada petición de pantalla es un nuevo comienzo. Si no das un sistema compartido, el generador completa los detalles faltantes adivinando: espaciados, tamaños de fuente, padding de botones, sombras y comportamiento de formularios—así pequeñas diferencias se acumulan entre páginas.
Los tokens de diseño son valores nombrados y reutilizables para cosas como espaciado, tamaños tipográficos, colores y radios.
En lugar de “padding cómodo”, usas algo como space-md. El nombre se mantiene estable y cada pantalla reutiliza las mismas decisiones para que la UI deje de desviarse.
Empieza pequeño y cubre solo lo que causa deriva visible:
Incluye un bloque compacto de spec UI al inicio de cada petición y trátalo como un contrato:
Luego describe la pantalla debajo. La clave es mantener el spec sin cambios entre pantallas.
Los tokens definen los números; las reglas de componente definen los hábitos. Reglas útiles:
Regla por defecto: si una variante no se puede justificar, usar la estándar.
Elige un patrón y no lo rompas:
Esto evita la inconsistencia típica de “una pantalla valida en blur y otra solo al enviar”.
Estandariza unos pocos estados no negociables:
Si no especificas estados, cada pantalla tenderá a inventar su propio patrón.
No dejes que improvisen el estilo. Añádelo como una extensión documentada de un patrón existente:
Si no puedes describirlo con tokens, suele ser demasiado personalizado y causará drift.
Crea una pantalla de referencia que ejercite las reglas (una página con muchos formularios funciona bien), y reutiliza el mismo spec para cada nueva pantalla.
En Koder.ai, puedes usar planning mode para reafirmar y confirmar el spec antes de generar, y snapshots/rollback para mantener una baseline estable mientras experimentas.
Haz una revisión rápida antes de aceptar la pantalla:
Si algo falla, actualiza el spec/tokens y regenera—no parchees márgenes aislados.
Si necesitas un valor “nuevo”, redondea al token más cercano en vez de inventar 10px u 18px.