EL RESULTADO
Mis criterios de diseño vivían en mi cabeza. Los convertí en herramientas.
Tres skills —design system, research y voz de marca— que bajaron un flujo de 3–5 días a 1 hora más revisión, y sostienen los mismos criterios cuando cada persona del equipo genera con su propia IA.
El mismo pedido, con y sin la skill del design system · Arrastrá para comparar ↔
Mismo prompt, mismo modelo, misma pantalla. Lo único que cambia es si la skill está cargada. El valor no está en usar la herramienta: está en el criterio que le cargaste.
EL PROBLEMA
Y LA RESTRICCIÓN
El equipo empezó a generar con IA, cada uno con su herramienta y su prompt. La velocidad subió y la consistencia se fue: dos personas resolviendo pantallas del mismo producto entregaban propuestas que no parecían del mismo sistema.
El design system estaba documentado, pero documentado no es lo mismo que aplicado: nadie abre un archivo de tokens antes de pedirle una pantalla a un modelo. La restricción era que el criterio no viajaba — vivía en la documentación y en las conversaciones, y ninguna de las dos entra en el prompt de otra persona.
01 — SKILL DEL DESIGN SYSTEM
Codificar lo que es regla, y dejar afuera lo que es juicio
La línea la tracé así: entra a la skill todo lo que se puede verificar sin opinar —tokens, escala tipográfica, grilla, estados de componente, jerarquía de acciones, reglas de accesibilidad—. Queda afuera todo lo que depende del caso: qué mostrar primero, cuánta información tolera una pantalla, cuándo romper el patrón. La skill no diseña: garantiza el piso para que la revisión discuta el criterio y no el padding.
Contra qué medía el output: no "quedó lindo". Componentes del sistema usados vs. inventados, contraste y tamaño mínimo, y cantidad de correcciones en la revisión — que bajaron. Un flujo pasaba si no requería tocar nada estructural.
DÓNDE TRACÉ LA LÍNEA
ENTRA A LA SKILL
Se puede verificar sin opinar.
QUEDA AFUERA
Depende del caso: hay que decidir.
02 — SKILL DE RESEARCH
Obligar a la definición antes de dejar dibujar
El riesgo real de la IA no es que diseñe mal: es que resuelve al toque un problema mal planteado. Esta skill no responde con pantallas, responde con preguntas, y recorre cinco etapas —contexto, usuario y tarea, hipótesis, evidencia en contra, definición del problema— donde en cada una hay que decidir algo antes de pasar a la siguiente. Recién después habilita bocetar.
La regla: ninguna etapa avanza sin una decisión escrita — qué sabemos, qué estamos suponiendo y qué dato nos haría cambiar de idea.
NINGUNA ETAPA AVANZA SIN UNA DECISIÓN ESCRITA
Contexto
¿Qué está pasando y por qué ahora?
Usuario y tarea
¿Quién es y qué está tratando de lograr?
Hipótesis
¿Qué creemos que pasa, y qué parte es suposición?
Evidencia en contra
¿Qué dato nos haría cambiar de idea?
Definición del problema
¿Qué problema vamos a resolver, en una oración?
RECIÉN ACÁ HABILITA BOCETAR
Antes de esta línea, la skill responde con preguntas. Nunca con pantallas.
03 — SKILL DE VOZ Y TONO
Un español por país, no un neutro que no habla nadie
Femmto opera en varios mercados y el "español neutro" sonaba a traducción en los tres. La skill lleva la voz de marca —cercana, clara, sin alarmar en un contexto de salud— y encima las reglas de cada variante: voseo y registro coloquial en Argentina, tuteo más formal en México, giros propios de Colombia, además de las palabras del dominio médico que cambian de país en país.
Cómo lo validé: los copys propuestos los revisó gente de cada mercado. Lo que sonaba raro volvió a la skill como regla, no como corrección suelta.
MISMO MENSAJE, TRES VARIANTES DE ESPAÑOL
AR · ARGENTINA
MX · MÉXICO
CO · COLOMBIA
LA ALTERNATIVA
QUE DESCARTAMOS
Evaluamos ampliar la documentación del design system en vez de convertirlo en skill.
Era el camino conocido y más barato, pero ya teníamos la prueba de que no alcanzaba: la documentación existía y el output seguía saliendo fuera del sistema. Documentar le pide a la persona que se acuerde; codificar hace que el criterio se aplique solo, en el momento en que se genera.
LO QUE NO FUNCIONÓ
La primera versión de la skill del design system era la documentación volcada tal cual. El output parecía correcto y no lo era: descripciones lindas que el modelo interpretaba a su manera. Hubo que reescribirla como reglas verificables — valores, límites y ejemplos de qué no hacer.
QUÉ HARÍA DISTINTO
Hice skills para generar, no para revisar. El equipo empezó a producir más consistente, pero la revisión seguía dependiendo de mi ojo. La cuarta skill que faltaba era la de crítica: los mismos criterios aplicados a mirar, no solo a producir.