Portafolio · Laboratorio IA
Revisión del sistema de diseño asistido por IA
El objetivo no era rediseñar un botón, sino comprobar cómo una auditoría apoyada en IA puede mejorar un Design System real sin sustituir el criterio del diseñador.
El punto de partida
Un Design System nunca está terminado
Diseñar un componente es la parte sencilla. Mantenerlo consistente, accesible y escalable con el tiempo es lo que realmente pone a prueba un Design System.
El punto de partida fue un componente Button que ya formaba parte del Design System, con meses en producción. No lo elegí por ser perfectible ni por representar mi nivel de diseño: lo tomé como caso real para probar si apoyarme en una IA en la primera lectura técnica de una auditoría tenía sentido, sin delegarle ninguna decisión.
Claude se encargó de señalar posibles inconsistencias iniciales. Todo lo demás —arquitectura, accesibilidad, naming, evolución del sistema— se decidió revisando cada punto manualmente.
Buscaba, sobre todo:
- Consistencia entre variantes y estados.
- Mejor accesibilidad.
- Un sistema más escalable.
- Variables y Design Tokens bien organizados.
- Menos fricción para reutilizar el componente.
- Documentación que sirviera de verdad a desarrollo.
La pregunta
¿Puede una IA ayudar a auditar un Design System?
Antes de tocar nada planteé una hipótesis de trabajo: si le pedía a una IA que auditara un componente ya en producción, ¿encontraría algo que se me hubiera pasado? Y si lo hacía, ¿merecería la pena revisar cada propuesta una por una antes de aplicar ningún cambio?
Hipótesis: la IA puede ayudar a detectar inconsistencias y a acelerar la documentación, pero no debería decidir nada por sí sola.
La responsabilidad de decidir qué cambiar, qué descartar y cómo documentarlo seguía siendo mía, no de la herramienta.
Cómo lo abordé
Un proceso con orden, no un atajo
Dividí el trabajo en fases claras para mantener el control en cada paso, sobre todo a la hora de decidir qué recomendaciones de la IA tenían sentido.
- Revisé el estado del componente tal y como estaba en el Design System.
- Le pasé el componente a Claude para una primera lectura técnica.
- Comprobé uno a uno los puntos que señalaba, comparándolos con el componente real.
- Prioricé por impacto: qué cambios importaban y cuáles eran ruido.
- Decidí qué se implementaba y qué se quedaba fuera.
- Apliqué los cambios aprobados en Figma.
- Reescribí la documentación del componente.
- Volví a revisar consistencia y accesibilidad antes de darlo por cerrado.
En ningún momento decidió la herramienta: solo aceleró la primera lectura.
Lo que revisó Claude
Una primera lectura técnica
Le pedí que analizara el componente, ya existente en el sistema, desde varios ángulos técnicos:
- Consistencia
- Variables
- Naming
- Component Properties
- Auto Layout
- Accesibilidad
- Design Tokens
- Documentación
- Escalabilidad
El resultado fue una lista de observaciones, no de decisiones: cada una se contrastó con el componente real antes de darla por válida.
Qué recomendaciones aportaban valor
No todo lo que propone una IA merece la pena
De la lista que devolvió Claude, una parte se quedó en el camino tras revisarla manualmente. Esto es lo que sí llegó a producción, y lo que decidí dejar como estaba:
Implementado
- Variables de color unificadas: fin a los valores sueltos sin token.
- Capas y propiedades renombradas: se entienden sin abrir el archivo dos veces.
- Auto Layout ajustado: admite nuevos tamaños sin romperse.
- Estados documentados: queda claro cómo y cuándo usar cada uno.
No implementado
- Nuevas variantes de tamaño: no resolvían ningún problema real del producto.
- Cambiar el radio de esquina: habría tocado una identidad visual ya validada sin necesidad.
- Un sistema de iconos nuevo: quedaba fuera del alcance de esta auditoría.
Estado inicial de la auditoría
El estado heredado del sistema, antes de decidir nada
Este era el componente ya integrado en el Design System: el estado heredado que se tomó como punto de partida para evaluar consistencia, accesibilidad, escalabilidad, arquitectura y documentación.
Y así quedó tras implementar, una por una, solo las mejoras que superaron la revisión manual.
El cambio se nota sobre todo en la consistencia entre estados y variantes, y en una arquitectura más fácil de escalar y de traducir a código.
Qué cambió en la base del sistema
Menos parches, más estructura
La auditoría no se quedó en un solo componente: sirvió para revisar los Design Tokens y reorganizar las Variables que ya existían en el sistema.
- Tokens nuevos para color, espaciado y tipografía.
- Variables con nombres que por fin tienen sentido.
- Una base más preparada para los próximos componentes.
- Menos trabajo de traducción al pasar esto a desarrollo.
- Menos deuda técnica acumulada en el sistema.
Documentar sin perder criterio
Un borrador rápido, revisado a mano
Le pedí a Claude un primer borrador de la documentación a partir de la auditoría: la parte más mecánica —estructurar, ordenar, poner ejemplos— quedó resuelta rápido.
Ese borrador lo reescribí donde hacía falta y lo adapté al criterio del sistema. Nada de lo publicado salió tal cual lo generó la IA.
Qué mejoró
Lo que cambió de verdad
- Componentes más consistentes entre sí.
- Traspaso a desarrollo más directo.
- Una arquitectura que escala mejor.
- Documentación que se entiende a la primera.
- Menos inconsistencias sueltas por el sistema.
- Más reutilización entre pantallas.
- Variables mejor organizadas.
Qué aprendí
Una herramienta más, no un atajo
Claude ayuda a leer un componente rápido y evita perder tiempo en tareas mecánicas dentro de una auditoría. Eso es real.
Pero decidir qué cambiar, qué descartar y cómo documentarlo sigue siendo trabajo de diseño.
El valor no está en usar la herramienta, sino en saber qué parte de su propuesta sirve y cuál no.
Sobre el uso de IA en este proyecto
Usé IA para acelerar la lectura técnica de un componente ya existente en el sistema y el primer borrador de su documentación. Qué cambiar, qué descartar, cómo documentarlo y cómo encajaba en la arquitectura del sistema lo decidí yo, revisando cada punto antes de darlo por bueno.