Del diseño al código

De la maqueta al componente: cambiar de mentalidad

Hasta ahora producías páginas: resultados para mostrar, discutir, validar. El desarrollador del cliente, en cambio, no integra páginas — integra componentes: piezas autónomas y reutilizables (un botón, una tarjeta, un campo de formulario) que ensambla en su aplicación. El paso del diseño al código es ante todo este cambio de unidad de pensamiento: ya no entregas una pantalla, entregas un vocabulario de piezas.

¿Por qué importa tanto? Porque un botón codificado como componente existe en un solo ejemplar en el código, derivado mediante parámetros (su variante, su tamaño, su estado). Corregir un defecto lo corrige en todas partes. A la inversa, una página monolítica donde el mismo botón está copiado y pegado doce veces se vuelve ingobernable desde la primera evolución. Es la misma lógica que los design tokens, un nivel por encima: el sistema antes que la página.

flowchart LR
  D["Diseño validado en el artifact"] --> T["Tokens: variables CSS"]
  T --> C["Componentes: props + estados + accesibilidad"]
  C --> I["Integración por el desarrollador"]
  I --> V["Verificación: estados, teclado, contrastes"]

Anatomía de un buen componente

Un componente bien concebido se describe por sus props (sus parámetros de entrada): para un botón, típicamente variant (primary, secondary, ghost), size (sm, md, lg) y disabled. Esta interfaz no es un detalle técnico: es la traducción a código de las decisiones de tu design system. Tres variantes de botón en la maqueta = una prop variant con tres valores en el código. Si te encuentras pidiendo una cuarta variante « solo para esta página », es la señal de que una decisión de diseño se está escapando del sistema.

Pide siempre a la IA el componente más un ejemplo de uso: ver <Button variant="primary" size="lg">Probar gratis</Button> permite juzgar de inmediato si la interfaz es intuitiva. Y precisa el formato de salida desde el principio — HTML/CSS puro, React, con o sin Tailwind — porque convertir después hace perder tiempo e introduce desviaciones.

Los estados interactivos: hover, focus, disabled

Aquí está la diferencia más visible entre un resultado de demo y un componente profesional: los estados. Un botón de verdad vive como mínimo cuatro vidas: reposo, hover (paso del cursor — feedback de que el elemento es clicable), focus (selección con el teclado — indispensable, volveremos sobre ello), active (el instante del clic) y disabled (acción no disponible). Un componente sin estados no está terminado: es una imagen que se parece a un botón.

Cada estado debe ser perceptible pero coherente: al hover, se oscurece ligeramente el color (de ahí el token --color-primary-hover) y se puede elevar sutilmente la sombra; en estado disabled, se reduce la opacidad y se cambia el cursor. Las transiciones deben ser suaves — 150 a 200 ms — para el ambiente relajante de Sereno. Y piensa en los componentes más allá del botón: un campo de formulario también tiene sus estados (focus, error, relleno), una tarjeta clicable tiene su hover.

Transforma el botón de la landing de Sereno en un componente React reutilizable:
- props: variant (primary | secondary | ghost), size (sm | md | lg), disabled
- estados visuales: hover (oscurece hacia --color-primary-hover, transición 180ms), focus-visible (anillo de 2px en --color-accent, desplazado 2px), active (ligera reducción de escala), disabled (opacidad 0.5, cursor not-allowed)
- usa exclusivamente las variables CSS del design system proporcionado — ningún valor en duro
- accesibilidad: elemento <button> nativo, focus visible con el teclado, tamaño mínimo de 44px de alto en md
Entrega el código completo + 3 ejemplos de uso (uno por variant) + la lista de tokens utilizados.

La accesibilidad en el código: más allá de los contrastes

En el capítulo 2, la accesibilidad se refería a los contrastes. En el código, adquiere dos dimensiones suplementarias. Primero la navegación con el teclado: una parte de tus usuarios no usa ratón (discapacidad motriz, lectores de pantalla, o simple preferencia). Cada elemento interactivo debe ser alcanzable con Tab y mostrar claramente que está seleccionado — es el papel del estado focus-visible, ese anillo alrededor del botón que algunos diseñadores eliminan « porque es feo ». No lo elimines nunca: estílalo para que sea bonito.

Después la semántica HTML: un botón debe ser un <button>, no un <div> estilizado con un gestor de clic. El elemento nativo aporta gratis el focus de teclado, la activación con Enter y Espacio, y el anuncio correcto a los lectores de pantalla. Misma lógica para los títulos (<h1>…<h2> en orden, sin saltar niveles), las listas y los enlaces. La IA produce HTML semántico correcto… si se lo pides. Añade sistemáticamente « HTML semántico y accesible » en tus prompts de código, y pide una auditoría: « verifica este componente desde el punto de vista de la accesibilidad y lista los problemas ».

Imagen → interfaz: partir de una captura o de un boceto

Capacidad espectacular y realmente útil: dar una imagen a la IA — captura de pantalla, maqueta exportada, o foto de un boceto a rotulador en una esquina de mesa — y pedirle reproducir su estructura en código. Los modelos actuales analizan la disposición, identifican los componentes (navegación, hero, tarjetas, formularios) y producen una interfaz funcional cercana al original.

Los usos concretos en un estudio: digitalizar un taller (el cliente dibujó su visión en la pizarra — fotografía y código en cinco minutos, el efecto está garantizado), partir de una referencia (« retoma la estructura de esta captura, pero aplica por completo mi design system » — estructura prestada, piel personalizada), o reconstruir lo existente (captura del antiguo sitio del cliente como punto de partida del rediseño).

Aquí está la foto del boceto hecho por el cliente en el taller [imagen adjunta].
Reproduce la estructura de esta disposición en HTML/CSS:
- identifica cada zona (navegación, hero, columnas, footer) y nómbralas en comentarios
- aplica mi design system proporcionado abajo — la estructura viene del boceto, el estilo viene de los tokens
- donde el boceto sea ambiguo, elige la interpretación más simple y señálala en un comentario
[pega aquí tu bloque :root]

Mantener el código limpio y conectado a los tokens

Último eslabón: la calidad del código entregado. Tres exigencias que formular explícitamente. Una: el código reutiliza los tokens — todo valor en duro es un bug de coherencia (puedes pedir una auditoría: « lista todos los valores en duro que quedan en este código y sustitúyelos por los tokens apropiados »). Dos: los comentarios explican las decisiones no evidentes, no cada línea — « por qué este z-index » merece un comentario, « esto es un botón » no. Tres: los nombres (clases, props, archivos) siguen una convención coherente que el desarrollador del cliente pueda prolongar.

Adopta también el hábito de la relectura crítica: el código generado suele ser correcto, pero no siempre óptimo. Reglas CSS duplicadas, un selector demasiado específico, un estado olvidado — pide a la IA que relea su propio código (« relee este componente como un desarrollador senior exigente: calidad, accesibilidad, coherencia con los tokens ») antes de entregar. Un componente limpio se mantiene; un componente chapuceado se vuelve rápidamente ingobernable, y es la reputación del estudio la que está en juego en cada entrega.