Por Thales (Juste Gnimavo) — CEO y Fundador, ZeroSuite, Inc.
Nota sobre el cliente: El ERP de gestión de flotas que se usa como ejemplo de trabajo en este artículo se menciona bajo el seudónimo KASSIA. El nombre real de la empresa y su dominio se mantienen en reserva a petición del cliente mientras se termina su sitio web público, y se restituirán en cuanto se lance.
He escrito extensamente sobre Claude Code. Los agentes paralelos, los ciclos de auditoría, los planes de trabajo de varios días despachados a un ingeniero que entrené para mi código base. He escrito sobre Web Claude — el compañero estratégico de combate que mantiene el contexto a lo largo de días y resiste cuando mi encuadre se desvía.
Hay un tercer miembro del equipo por el que casi nadie me pregunta. Y es, cada vez más, con el que empiezo todos los proyectos.
Claude Design.
El espacio de trabajo de Claude Design en claude.ai. A la izquierda, un brief de diseño comprometido por adelantado — estética, tipografía, tokens de color, maquetación, animación. En el centro, los componentes y los documentos de specs que generó. A la derecha, una vista previa en vivo del resultado. Es una superficie de diseño con control de versiones y gestión de archivos, no una ventana de chat.
Cuando la gente imagina «construir software con IA», imagina generación de código. Entra un prompt, sale una función. Toda la conversación sobre el desarrollo aumentado por IA está estancada en la superficie de ingeniería. Mientras tanto, la parte del producto que en realidad decide si un usuario confía en él — la parte que decide si un padre en Abiyán entrega dinero, si un gestor de flotas cree en los números que ve en pantalla — se trata como una ocurrencia tardía. «Hazlo que se vea bonito.» «Añade algo de pulido.» Como si el diseño fuera una capa de pintura que aplicas al final.
Yo ahora lo hago al revés. En cualquier proyecto nuevo, Claude Design va primero, y es dueño de todo el sistema visual y de UX de principio a fin antes de que Claude Code escriba una sola línea de código de producción. No un mockup. No un mood board. Un sistema de diseño completo, versionado y de nivel producción — tokens, componentes, prototipos funcionales, y el lenguaje de diseño para las funcionalidades de IA dentro del producto.
Permítanme mostrarles exactamente qué significa eso, con un ejemplo real, y luego darles el proceso que ejecuto cada vez.
El error que casi todo el mundo comete
El flujo de trabajo por defecto en 2026 luce así: tienes una idea, abres Claude Code o Cursor, describes la aplicación, y le pides que la construya. El modelo arma un proyecto, conecta algunas rutas, y — porque pediste una aplicación funcional — toma decisiones de diseño sobre la marcha. Elige una tipografía. Elige un azul. Suelta algunas tarjetas redondeadas y un degradado. Entrega algo que funciona.
Y luce como todo lo demás que se entrega de esa manera. Los mismos valores por defecto de shadcn. El mismo degradado de héroe índigo a púrpura. El mismo olor genérico a SaaS. Lo llamo slop no porque esté roto, sino porque es anónimo. No tiene punto de vista. Nadie decidió nada; las decisiones fueron un efecto secundario de un prompt de ingeniería.
Esto es lo que la gente de producto con experiencia sabe y los principiantes no: no puedes atornillar un sistema de diseño después del hecho. Para cuando Claude Code ha escrito cuarenta componentes, cada uno ha tomado una decisión independiente sobre el espaciado, sobre el radio, sobre cómo luce un estado deshabilitado, sobre qué significa «peligro» visualmente. No hay un lenguaje compartido. Refactorizar eso hacia la consistencia más tarde cuesta más de lo que habría costado diseñarlo de antemano. Esto es cierto para equipos humanos y es exactamente igual de cierto para los de IA.
La solución no es «pedirle a Claude Code que tenga más cuidado con el diseño». La solución es separar la superficie por completo. El diseño es un contexto operativo distinto, con un formato de salida distinto, una vara de calidad distinta, y un tipo de prompt distinto. Confundirlo con la ingeniería es el error de raíz.
Lo que Claude Design realmente produce — un ejemplo real
Hace unas semanas empecé un proyecto nuevo: un ERP premium de gestión de flotas para una empresa de transporte de África Occidental — al que aquí me refiero como KASSIA. El producto maneja dinero: depósitos de conductores, controles anti-fraude, un registro de auditoría de solo adición, separación de poderes entre roles (el contable valida lo que el cajero registra; nada escribe en la base de datos sin que un humano con el rol correcto lo apruebe). El tipo de producto donde un error tipográfico en un número, o una pantalla de aspecto barato, te cuesta la confianza del cliente el primer día.
Era greenfield. Sin código base existente. Sin archivo de Figma. Sin equipo de diseño. Lo que tenía era un brief de producto y una identidad de marca heredada que quería elevar, no descartar.
Le di a Claude Design ese brief. Esto es lo que regresó — y quiero ser preciso, porque el alcance es justamente el punto:
Un sistema de tokens completo. No «aquí hay algunos colores». Un conjunto en capas de archivos de tokens CSS: rampas de color primitivas (un azul marino profundo para la confianza y la precisión, un burdeos reservado para acciones sensibles y bloqueantes, un dorado para el énfasis premium, un degradado azur a violeta como firma de las funcionalidades de IA), y luego tokens semánticos encima (superficie, borde, el vocabulario de estados anti-fraude — validado, pendiente, bloqueado, atrasado — cada uno mapeado a un significado, no a un hexadecimal en bruto). Tokens de tipografía: una familia display, una familia de cuerpo humanista, una familia monoespaciada reservada para las cifras financieras y las huellas de auditoría, con numerales tabulares en todas partes donde aparece dinero. Espaciado en una rejilla de 4px. Un sistema completo de elevación y «glow» que distingue la profundidad neutra (sombras) de la señal (el glow se reserva para el orbe de IA y los estados activos — nunca aplicas glow a una superficie neutra). Tokens de movimiento: duraciones, curvas de resorte, los keyframes de la respiración y la escucha del orbe de IA. Y todo ello tematizado para modo claro y oscuro desde el principio, con el oscuro diseñado para ser espectacular en lugar de una ocurrencia tardía invertida.
Una biblioteca de componentes — con contratos. Aproximadamente dos docenas de primitivas de React: botones, botones de icono, insignias, insignias de estado, avatares, inputs, switches, tarjetas, tarjetas de estadística, pestañas, sparklines, indicadores, tablas de datos, modales, toasts, tooltips, una paleta de comandos. Pero esto es lo que lo convierte en un sistema y no en un montón de mockups: cada uno de los componentes se entregó con un contrato TypeScript .d.ts que define sus props, y una ficha .prompt.md que explica cuándo y cómo usarlo. Un manifiesto ataba todo el conjunto. Esto no es «una IA dibujó algunos botones». Esto es un diseñador senior entregando una biblioteca de componentes tipada con documentación de uso — el artefacto exacto que produce un equipo real de sistema de diseño, salvo que producido en un flujo de trabajo conversacional a partir de un brief.
El lenguaje de diseño para las funcionalidades de IA. Toda la ventaja competitiva de este producto es una IA de voz embebida — la interfaz principal, no un widget lateral. Claude Design produjo el lenguaje de diseño para ella: un orbe de voz con estados definidos (respirando cuando está inactivo, un ecualizador cuando escucha, un halo rotatorio cuando piensa), una barra de comandos con una paleta ⌘K, una tarjeta de respuesta de IA, y — crítico — un banner de borrador que codifica la regla más importante del producto: la IA prepara un borrador, un humano con el rol correcto lo valida, nada escribe en la base de datos sin esa validación. La disciplina anti-fraude no es solo lógica de backend; es visible en el sistema de diseño como un patrón reutilizable. Eso es un diseñador pensando en el producto, no solo decorándolo.
Dos UI kits clicables. Un back-office web completo (login, el dashboard del director con un briefing de IA, los flujos de IA «preguntar vs. actuar», la lista de conductores con vistas de detalle, la búsqueda ⌘K, un módulo de ayuda y onboarding) y un portal móvil del conductor separado (login con teléfono más PIN, el espacio personal del conductor — deuda, depósitos, vehículo, un micrófono de voz). Clicables. Reales. Navegables antes de que existiera una sola línea de código de producción.
A partir de un brief. En un contexto de diseño. Antes de que Claude Code tocara nada.
El sistema de diseño KASSIA como un mapa de archivos — 134 archivos a partir de un solo brief. Cada componente entrega tres archivos: el visual (.jsx, violeta), el contrato de props tipado (.d.ts, cian) y la tarjeta de uso (.prompt.md, verde). Ese triplete que se repite, más las capas de tokens, los specimens de guidelines y dos UI kits clicables, es lo que lo convierte en un sistema y no en una maqueta.
Por qué esto es un sistema, no un conjunto de pantallas
Esta es la distinción que todo el mundo pasa por alto, así que quiero dejarla bien afilada.
Un mockup es una imagen de una pantalla. Un sistema de diseño es el conjunto de decisiones y partes reutilizables que hacen que cada pantalla futura sea consistente sin volver a decidir nada. La diferencia entre ambos es la diferencia entre un producto que luce coherente en la pantalla uno y un producto que sigue luciendo coherente en la pantalla cuarenta.
Lo que Claude Design entregó fue lo segundo. Los contratos tipados significan que Claude Code — cuando más tarde lo porta a producción — no adivina qué props toma una StatusBadge; lee el .d.ts. Las fichas .prompt.md significan que cuando una pantalla nueva necesite diseñarse dentro de seis semanas, las reglas de «cuándo uso una tarjeta versus una tarjeta de estadística» ya existen por escrito. Los archivos de tokens significan que cambiar el color primario de la marca es una sola edición, no una búsqueda en cuarenta archivos. El manifiesto significa que todo el conjunto es navegable y auditable.
Esto es infraestructura de diseño versionada, documentada y reutilizable. Es exactamente lo que un diseñador de producto senior entrega a un equipo de ingeniería cuando hace bien su trabajo — una biblioteca de Figma más componentes codificados más directrices escritas. La única diferencia es que salió de un contexto de diseño conversacional en una fracción del tiempo y a coste marginal cero.
La gente subestima Claude Design porque solo le ha pedido una pantalla. Nunca le ha pedido un sistema. Así que concluyen que es un juguete para generar mockups, cuando en realidad es capaz de producir el artefacto con más apalancamiento de toda la construcción — aquel del que todo lo demás hereda.
El traspaso: cómo Design alimenta a Code
Aquí es donde las dos superficies se conectan, y por qué mantenerlas separadas rinde frutos.
La salida de Claude Design es una implementación de referencia: HTML y JSX, tokens reales en CSS, prototipos funcionales. El trabajo de Claude Code es portar eso al stack de producción — en nuestro caso normalmente SvelteKit y Tailwind. El traspaso es limpio precisamente porque el sistema de diseño es explícito. Claude Code recibe los archivos de tokens (los mapea a valores del tema de Tailwind), los contratos de componentes (reproduce la misma API de props), y el UI kit (tiene un objetivo de precisión de píxel que igualar). No hay ambigüedad que resolver, ni gusto que inventar. La ingeniería se convierte en un porte fiel, no en una segunda ronda de diseño-por-accidente.
Compáralo con el flujo de trabajo por defecto, donde le pides a Claude Code que «construya un dashboard que luzca profesional». Ahora la sesión de ingeniería es también una sesión de diseño, conducida por la superficie menos equipada para ello, sin tokens, sin contratos, sin punto de vista — y el resultado es el slop anónimo de antes. La separación no es burocracia. Es lo que hace que ambas superficies operen en su máximo. Design decide; Code ejecuta la decisión. Cada uno hace lo que mejor sabe hacer.
Este es el mismo principio que hace confiable el flujo de trabajo de ingeniería multi-agente: cuando el trabajo cruza una interfaz, el productor documenta el contrato y el consumidor es informado con el artefacto, nunca dejado a inferir. Claude Design es el productor del contrato de diseño. Sáltalo, y cada agente de ingeniería aguas abajo está infiriendo el diseño de un prompt vago.
El proceso que ejecuto en cada nuevo proyecto
Esta es la parte a robar. Esta es la secuencia exacta, y ahora es innegociable para mí en cualquier cosa greenfield.
Paso 1 — Escribe un brief de diseño, no un prompt de construcción. Antes de abrir un contexto de diseño, escribo un brief dirigido a un diseñador, no a un ingeniero. Contiene: qué es el producto y quién lo usa, el registro emocional que quiero (para KASSIA: «premium, profundo, luminoso — confianza y precisión, nunca ostentoso»), los activos de marca heredados si los hay, las restricciones duras (francés primero, formato de moneda FCFA, sin emoji, accesibilidad), y las superficies en alcance (back-office web más portal móvil). Quince minutos de escritura. Es la misma disciplina que el brief de ingeniería, apuntada a una superficie distinta.
Paso 2 — Exige primero un sistema de tokens, antes de cualquier pantalla. Le pido explícitamente a Claude Design que establezca los cimientos — rampas de color, tokens semánticos, tipografía, espaciado, elevación, movimiento, claro y oscuro — antes de dibujar una sola página. Este es el orden que previene el slop. Cimientos primero, pantallas después. Una pantalla construida sobre tokens es consistente por construcción; una pantalla construida primero y tokenizada después nunca converge del todo.
Paso 3 — Exige contratos y fichas de uso con cada componente. No solo lo visual. El .d.ts y el .prompt.md. Esto es lo que convierte un mockup en un artefacto de traspaso y lo que hace que el sistema sobreviva más allá de la primera sesión. Si un componente se entrega sin su contrato, no está terminado.
Paso 4 — Consigue UI kits clicables, uno por superficie. Un prototipo real y navegable para cada superficie distinta (la aplicación web y el portal móvil son problemas de diseño distintos y reciben kits distintos). Quiero hacer clic a través de los flujos reales — el login, el dashboard, la interacción de IA, las vistas de detalle — y sentir el producto antes de que exista código de producción. Aquí es donde atrapo errores de producto gratis, mientras no cuesta nada corregirlos.
Paso 5 — Diseña las superficies de IA como ciudadanas de primera clase, no como una burbuja de chatbot. Si el producto tiene IA dentro — y todos los míos la tienen — su lenguaje de diseño es parte del sistema: los estados del orbe, la barra de comandos, la tarjeta de respuesta, y las reglas que codifican la disciplina del producto (para un producto de dinero, el patrón borrador-luego-validar está en el diseño). La IA es la columna vertebral de la UX, así que se diseña como la columna vertebral, no se atornilla como un widget.
Paso 6 — Solo ahora, traspasa a Claude Code. Con los tokens, los contratos y los UI kits en mano, la sesión de ingeniería es un porte, no una invención. Claude Code mapea los tokens al framework de producción, reproduce la API de los componentes, e iguala el kit. Traspaso limpio. Sin diseño-por-accidente.
Seis pasos. Los primeros cinco viven enteramente en la superficie de diseño. Para cuando empieza la ingeniería, cada decisión visual y de UX ya se ha tomado, escrito y aprobado — por mí, mirando un prototipo clicable, no por un agente de ingeniería improvisando contra un plazo.
Por qué este es el apalancamiento más subestimado de todo el stack
Permítanme exponer el caso de negocio sin rodeos, porque esto no es una preferencia estética.
Para los productos que construyo — IA de voz para estudiantes africanos, orquestación de pagos, un ERP que maneja dinero — el diseño es confianza, y la confianza es conversión. Un padre en Abiyán decidiendo si poner 100 FCFA en una aplicación de tutoría toma esa decisión en los primeros tres segundos, por sensación, antes de leer una palabra. Un gestor de flotas decidiendo si creer en los números anti-fraude de un dashboard los cree más cuando el dashboard luce como si lo hubieran construido personas que se toman el dinero en serio. En los mercados emergentes especialmente, una interfaz premium, coherente y confiable no es un lujo prescindible. Es la diferencia entre un producto que convierte y uno que se desinstala.
Esa superficie — la que decide la confianza — es la que la mayoría de los constructores genera como efecto secundario de un prompt de ingeniería. Gastan su cuidado en la arquitectura que el usuario nunca ve e improvisan la superficie por la que el usuario los juzga en tres segundos. Es exactamente al revés.
Claude Design corrige esto, y lo corrige barato. Un sistema de diseño completo y de nivel producción — tokens, dos docenas de componentes documentados, dos UI kits clicables, un lenguaje de diseño de IA — a partir de un brief, en un contexto de diseño, por el coste de una suscripción. La salida es el artefacto con más apalancamiento de la construcción, porque cada pantalla que el producto tendrá jamás hereda de él. Hazlo bien una vez, de antemano, y la consistencia es automática para siempre. Sáltalo, y pagas la inconsistencia en cada pantalla, para siempre.
Tres superficies, no una. Web Claude es dueño de la estrategia. Claude Code es dueño de la ingeniería. Y Claude Design es dueño del sistema que el usuario realmente toca. Opera las tres, y opera Design primero. Es el miembro del equipo que estás dejando dormido.
Un fundador. Tres superficies de Claude. Siete productos. El diseño va primero.