Caso de estudio · 2024—presente
La IA como práctica de diseño
Empecé a usar IA para analizar más investigación y prototipar ideas más rápido. Con el tiempo, esos experimentos se volvieron sistemas repetibles de investigación, crítica basada en personas, prototipado e implementación — y cambiaron mi forma de entender el diseño.
01 · El punto de partida
Primero usé IA para resumir transcripciones de llamadas con clientes y buscar patrones de UX. Mientras tanto, Chainsaw, el equipo de I+D de Time Doctor, necesitaba moverse rápido — así que usé herramientas generativas tempranas como Lovable para convertir conversaciones en interacciones en lugar de presentaciones.
A medida que las herramientas mejoraron y Time Doctor fomentó una adopción más amplia de la IA, empecé a buscar de forma sistemática las partes del proceso de diseño donde la IA podía quitar trabajo repetitivo, dejar patrones a la vista o hacer que las ideas se pudieran probar antes.
La IA empezó como una forma de procesar más. Terminó siendo una forma de ampliar lo que podía hacer en mi trabajo de diseño.
El principio de operación
Primero defino el sistema: el objetivo, la evidencia, las reglas y las salvaguardas. La IA hace el trabajo pesado dentro de esos límites; quien diseña sigue siendo quien decide.
La IA puede acelerar el trabajo. No puede ser la fuente de verdad.
02 · Encontrar journeys en la investigación existente
Reclutar clientes específicamente para investigación de journeys era difícil. Pero los clientes ya describían su trabajo en llamadas de onboarding, soporte, ventas y Customer Success.
El método
Primero revisé las llamadas a mano y seleccioné las grabaciones donde los usuarios describían claramente un proceso. Cuando entendí cómo era una evidencia útil, usé IA para analizar más de 30 llamadas seleccionadas y extraer patrones recurrentes.
La IA estructuró la evidencia. Yo armé e interpreté el journey.
Lo que volvió fue un conjunto de estructuras comparables, no un mapa terminado:
- Objetivos
- Pasos
- Puntos de contacto
- Motivaciones
- Fricción
- Modelos mentales
Dos de las oportunidades que surgieron
-
01
Reportes conectados
Los gerentes querían conectar Web & App Usage con Activity Summary al investigar a colaboradores individuales, pero los reportes vivían por separado.
-
02
Punto de partida de la investigación
Los gerentes solían empezar sus investigaciones desde el User Dashboard, pero sus widgets no seguían la secuencia de preguntas que realmente querían responder.
Ambas quedaron documentadas como oportunidades de diseño y pasaron a los equipos de producto y diseño responsables de esas áreas.
Documenté el método en el Research Repository para que otra persona de diseño pudiera reproducir el proceso sin mí.
03 · De las personas sintéticas a Persona Lens
Conocí las personas sintéticas en un taller donde a un Custom GPT le daban una descripción simple de una persona y le pedían que la interpretara. La idea conversacional era útil, pero la evidencia que había debajo era demasiado escasa.
Lo abordé al revés: construir primero la persona a partir de la investigación y después hacer conversacional esa evidencia.
De qué estaba hecha
- Entrevistas directas con personas.
- Patrones extraídos de decenas de llamadas con clientes.
- Investigación existente en el repositorio.
Exterior · Protección
Mantenía la línea frente a prompts diseñados para descarrilar a la persona o extraer lo que había debajo.
Medio · Comportamiento
Hacía que el GPT respondiera en personaje en vez de volver a ser un asistente genérico.
Núcleo · Evidencia
La persona respaldada por evidencia: objetivos, comportamientos, contexto, frustraciones, modelos mentales, herramientas y citas representativas.
Persona Lens
Cuando Time Doctor estandarizó en torno a Claude, reconstruí la idea como un Claude Skill llamado Persona Lens. El cambio importante no fue técnico.
Un destino al que había que ir.
Contexto que podías invocar dentro del trabajo que ya estabas haciendo.
- «¿Qué pensaría de esto un líder de RR. HH. de una empresa consolidada?»
- «Revisa este flujo como un líder de RR. HH. de una pequeña empresa. ¿Qué no se alinea con las necesidades, los puntos de dolor o el lenguaje de este usuario?»
Los experimentos útiles dejaron de ser experimentos. Pasaron a ser parte de cómo trabajaban otras personas.
Persona Lens incluía las personas existentes de Time Doctor y se podía compartir a través de la organización de Claude de la empresa, de modo que PMs y diseñadores podían usarlo sin configurar nada.
Nunca pretendió reemplazar a los usuarios reales. Era un primer filtro — para cuestionar supuestos, revisar conceptos, anticipar inquietudes y hacer más valiosas las escasas conversaciones con clientes.
04 · Prototipar con IA
Usar cada herramienta para lo que hace más rápido
Las primeras salidas de Figma Make se alejaban fácilmente de la UI de Time Doctor, así que creé prompts y plantillas reutilizables para componentes e interacciones comunes, en lugar de partir de un prompt en blanco cada vez.
A partir de ahí el trabajo se asentó en un ir y venir. Si mover algo toma segundos en Figma, pedirlo por prompt es más lento. Si construir la interacción a mano toma más tiempo, de eso se encarga la IA.
La pregunta dejó de ser «¿Puede la IA hacer esto?» y pasó a ser «¿Quién de los dos es más rápido y mejor en esta parte?»
La ganancia práctica fue el momento: interacciones de mayor fidelidad podían llegar antes a los usuarios, cuando la dirección aún era barata de cambiar.
- Figma Make — generar y explorar ideas rápidamente
- Figma — hacer a mano cambios visuales precisos con más rapidez
- Figma Make — añadir interacción y comportamiento mediante IA
05 · De las reglas de diseño al código
En vez de esperar que una herramienta de IA recordara cómo funciona un sistema de diseño, empecé a documentar las reglas mismas.
- Design tokens guardados en Markdown.
- Variables de Figma que reflejan esos tokens.
- Reglas del sistema de diseño documentadas en archivos
.md. - Cambios sincronizados de vuelta al sistema documentado cuando corresponde.
- Codex y Claude Code leyendo esos archivos como contexto de diseño.
Eso permitió moverse entre Figma, Codex y Claude Code sin depender de un único producto de IA para cargar con todo el sistema de diseño en su memoria.
Dónde está el límite
Trabajar más cerca del código no reemplaza a la ingeniería. Reduce la distancia de traducción entre diseño e ingeniería.
Antes de dejar Time Doctor, ya hacía cambios de código asistidos por IA dentro del proceso existente de revisión y aprobación — lo suficiente para que los diseñadores mejoraran detalles de UX sin tratar producción como un patio de juegos.
Estoy aplicando el mismo enfoque de forma más completa en mi app de boxeo Corner Coach, donde la gobernanza del sistema de diseño, los tokens y las reglas de IA se definen juntos desde el principio.
06 · Qué cambió en mi práctica
Cuando empecé a usar IA, esperaba que su mayor ventaja fuera procesar más información, más rápido.
El cambio más importante fue darme cuenta de que podía actuar como colaboradora a lo largo de la investigación, el prototipado y la implementación — siempre que yo siguiera siendo responsable del sistema a su alrededor.
Las herramientas cambiarán. El sistema para trabajar con ellas es lo que sobrevive.
Un flujo de trabajo que uso hoy puede quedar obsoleto en semanas. Lo que perdura es la capacidad de entender el problema humano, estructurar el trabajo, definir las salvaguardas, inspeccionar el resultado y decidir qué sigue.
La IA no nota la duda en una entrevista, no entiende cómo se siente el agotamiento después de un largo trayecto, ni sabe cuándo alguien dice una cosa pero quiere decir otra porque no logra poner el problema en palabras. Eso sigue siendo trabajo de quien diseña.
No quiero que la IA tome la decisión final por mí. Quiero que lo mejor de lo que ella puede hacer y lo mejor de lo que yo puedo hacer hagan mejor la decisión.
Asistido por IA
- Estructurar evidencia a lo largo de decenas de llamadas
- Una primera pasada desde el punto de vista de una persona
- Construir interacción dentro de un prototipo
- Implementar contra reglas de diseño documentadas
Me toca decidir
- Qué problema vale la pena resolver
- Qué significa realmente la evidencia
- Lo que un usuario quiso decir pero no dijo
- Qué se lanza y qué no
Las pantallas son maquetas o están anonimizadas · Sin información de clientes ni de empleados