Una empresa europea nos pidió a CAPSLOCK, un laboratorio de IA aplicada, ayuda con un problema que parecía pequeño. Unas dos docenas de su gente hacen pantallas, presentaciones y documentos en Claude cada semana: ingenieros, analistas, stakeholders. Ninguna es diseñadora, y ninguna tiene por qué serlo. Su trabajo es el contenido. Les construimos un skill que lleva la apariencia de la empresa a todo lo que hace Claude, y la forma más corta que encontramos de decir qué cambió es esta: "Fue como tener un diseñador personal para cada persona de la empresa."
Un skill es una carpeta de instrucciones y archivos que Claude lee antes de construir. Lo que la gente construye con él son artefactos: páginas que hace Claude y que se pueden compartir con un link. Lo que vimos nosotros, sin una cifra detrás: los documentos internos de la empresa nunca se habían visto tan bien.
Antes del skill, el contenido salía bien. El caso, los insumos, el recorrido, las cifras. La apariencia salía mal: un tema genérico, las fuentes equivocadas, sin el marco del producto, y decisiones que el equipo ya había acordado (tarjetas, no filas; acciones abajo) que Claude no tenía cómo saber.
el segundo trabajo que nadie hace
Hacer que un artefacto se vea como la empresa es un segundo trabajo. Cambiarle el estilo, cambiar las fuentes, rehacer el marco del producto a ojo, preguntarle a diseño si está bien.
No era prioridad de nadie, y con razón. Así que la mayoría lo dejaba como salía, y páginas genéricas llegaban tal cual a sponsors y juntas directivas. Los pocos a quienes sí les importaba ponían el tiempo, o lo mandaban a diseño con un "¿esto va con la marca?". Las decisiones acordadas se volvían a discutir en reuniones, porque la página que todos tenían enfrente no las mostraba.
Esto no se arregla pidiéndole a la gente que le importe más algo que no es su trabajo. Se arregla haciendo que la apariencia correcta sea la de por defecto.
el skill se encarga de la apariencia, vos del contenido
Claude no diseña mal. Diseña de memoria, desde cero, cada vez. Así que le dimos algo que llenar en vez de algo que dibujar.
El skill funciona como un molde: el molde da la forma, quien pide pone la masa. Adentro de este están los tokens de diseño de la empresa (sus colores, tamaños de letra y espaciados, cada uno guardado como un valor con nombre), el marco real de cada producto, plantillas para presentaciones, documentos, memos, resúmenes de una página y paquetes de descubrimiento, y un elenco inventado de personas y cifras. Un pequeño verificador marca cualquier color o tamaño que no esté en el sistema de diseño.
Diseño escribe las reglas de apariencia una vez. Nadie más las edita. Y hay cuatro cosas que Claude nunca decide por su cuenta:
- La apariencia. Sale del sistema de diseño, copiada, nunca redibujada.
- Los datos de personas reales. Un artefacto es una página que se puede compartir. Los datos reales de clientes se cambian por el elenco inventado y nunca se ponen en la página, aunque alguien lo pida. Para nombres reales de colegas, Claude pregunta una vez.
- Compromisos que nadie hizo. Metas, fechas y ahorros que nadie dio aparecen como "por confirmar", nunca como un número creíble.
- Decisiones que el equipo ya acordó. Cuando el contenido de alguien choca con un patrón acordado, Claude construye el patrón y deja una línea en las notas: "Hecho como tarjetas, según la decisión del espacio de trabajo."
qué cambió para quienes hacen las cosas
Marca sin esfuerzo. A quienes nunca les importó, sigue sin tener que importarles. La página sale viéndose como el producto porque los colores, tamaños y marcos salen del sistema de diseño, no de memoria. Los pocos a quienes sí les importaba recuperan su tiempo, y dejan de pedirle a diseño que revise la marca. Diseño deja de ser la policía de la marca.
Tiempo. Un analista lo usó para preparar una revisión con un sponsor e hizo 25 versiones en un día. El prototipo tomó parte de una semana en vez de la semana entera. Cuando llega feedback, los cambios vuelven al mismo link.
Alineación. El stakeholder puede abrir el link antes de la reunión, así que la reunión es sobre el contenido. La apariencia ya está resuelta, y las decisiones acordadas llegan incluidas, con una nota que lo dice.
La gente lo cambia por su cuenta. El mismo analista abrió el chat del artefacto y pidió un cambio por su cuenta. En sus palabras: "Eso ayuda un montón."
Nuestra apuesta, todavía sin medir. Una diseñadora junior con esto trabaja a nivel de senior en la apariencia, y pone su tiempo en el contenido. No lo hemos probado con juniors; es una opinión, y nos gustaría que se confirme o se desmienta.
Y lo que no reemplaza. Un link no lleva el razonamiento detrás de un diseño, así que la reunión sigue importando. Y todo lo que Claude resuelve por su cuenta (qué día cuenta como "hoy" en un plan, por ejemplo) tiene que quedar escrito en la página, para que nadie se entere después.
cómo sabemos que aguanta
Lo probamos de dos formas.
Con personas. El grupo piloto lo usó en su trabajo real, y nos sentamos con ellos mientras lo hacían: a qué recurrían, dónde estorbaba, qué cambiaban por su cuenta. La revisión del analista de arriba es una de esas sesiones.
Con un set de pruebas. Escribimos 17 pedidos del tipo que la gente de ahí hace de verdad: un resumen de una página para la junta, un dashboard del equipo, una pantalla para una solicitud de datos, una presentación para un town hall, cada uno con la voz de quien lo pediría, desde un analista hasta una responsable de cumplimiento o alguien en su primera semana. Claude hizo cada uno con el skill, y uno de ellos otra vez sin él. Otro Claude revisó cada resultado con una lista corta: ¿se ve como el producto?, ¿tiene datos de personas reales?, ¿se inventó alguna cifra? (Cómo hacemos pruebas así.)
Una prueba sintética, corrida de las dos formas. No hay pantallas reales de antes y después del equipo, y sus páginas no las podemos mostrar. Así que, para ver qué cambia el skill, armamos una prueba: un pedido con un cliente inventado, hecho una vez con el skill y otra vez sin él.
Ese pedido pegaba los datos del cliente, escritos como si fueran reales. Sin el skill, volvió con fuentes del sistema, 79 problemas marcados por el verificador y el nombre, número de cuenta, dirección y saldo del cliente en la página, dos veces cada uno. Con el skill, en los 17 pedidos, la apariencia coincidió con el producto y ningún dato personal llegó a ninguna página, incluso cuando el pedido venía de una responsable de cumplimiento insistiendo "es para legal". Con la lista corta, el único pedido corrido sin el skill sacó 2.0 de 5; los 17 pedidos corridos con él promediaron 4.4. Esas dos cifras no se comparan de igual a igual, así que leelas como una dirección.
Cuánto confiar en "otro Claude revisó": calificó cada página solo contra la lista corta de arriba, y ninguna persona comparó sus notas con las propias, así que no hubo calibración humana. Además, el skill lo construimos nosotros. Leemos esas cifras como una señal fuerte, no como una medición. Las personas del piloto son la otra mitad de la evidencia.
qué todavía falla
Parte de esto, con honestidad:
- La página quedó limpia, el chat no. Cuando le pidieron poner nombres reales en una pantalla, el modelo se negó, y después explicó en el chat cómo volver a ponerlos a mano. Ahora eso es una regla: no ayudar a ponerlos.
- Un pedido de código recibió un prototipo. Un desarrollador pidió un componente para meter en el código y recibió un artefacto, cuando la respuesta correcta era indicarle la librería real de componentes.
- Se llenaron huecos. Donde un proceso tenía un hueco, el modelo a veces lo llenó con detalles creíbles en vez de marcarlo. La regla estaba escrita; no se siguió todas las veces.
Cada una de estas está en la lista para la siguiente versión. La lista es el trabajo.
de dos docenas a muchos
El skill está empaquetado como un plugin de enterprise (la forma de instalar un mismo skill para mucha gente a la vez), instalado por grupos, así que nadie lo configura a mano. Está hecho para correr dentro del entorno de la propia empresa y para cumplir las normas europeas de datos. Una persona responsable del lado de diseño lo actualiza cuando cambia el sistema de diseño o un producto, y cada artefacto muestra qué versión lo hizo, así que uno viejo es fácil de detectar. El punto débil es una actualización que a alguien se le olvida.
seis preguntas para empezar
- ¿Quién en tu empresa hace de verdad artefactos con IA, y qué hace?
- ¿Cuáles de tus fuentes de verdad (tokens, componentes, pantallas de producto, plantillas) podría copiar Claude con exactitud?
- ¿Qué nunca debería cambiar de un artefacto al siguiente?
- ¿Qué no debe decidir nunca Claude por su cuenta, empezando por los datos reales?
- ¿Cómo vas a comparar el mismo pedido con y sin el skill?
- ¿Dónde vas a anotar lo que todavía hace mal?