| name | design-studio |
| version | 1.0.0 |
| description | Runs a collaborative sketch exercise (Design Studio / Design Charrette) adapted for AI-assisted workflows. Use when the user asks for "design studio", "design charrette", "ideacion colaborativa", "ejercicio de sketches", "generar ideas de UI", "6-up", "divergencia de ideas", "/design-studio", or wants to rapidly explore design solution space for a specific problem. Based on Lean UX (Jeff Gothelf, O'Reilly 2013), cap. 5. Focuses on divergent thinking first, then convergence. Output is a decision document with 6 variants + critique + converged solution + parking lot.
|
Design Studio (Ejercicio de Diseño Colaborativo)
Implementa el ejercicio de Design Studio / Design Charrette de Lean UX
(Jeff Gothelf, O'Reilly 2013), cap. 5 — "Design It Together". Adaptado para
workflows AI-assisted donde la divergencia de ideas la genera el agente junto al
usuario, y la convergencia es co-decisión.
Regla de idioma
Contenido en español. Términos técnicos de diseño en formato "español (English)"
la primera vez que aparecen.
Directorio de salida
./docs/ux-research/design-studios/
└── YYYY-MM-DD-[topic-slug].md # Documento único por sesión
Puerta obligatoria
NO avanzar entre fases sin aprobación explícita del usuario. Cada fase tiene
puerta de confirmación.
Filosofía del ejercicio
"The Design Studio removes the ego from design. Instead of one 'hero designer'
producing a single idea, the whole team diverges on many ideas, then converges
together on the strongest."
— Jeff Gothelf, Lean UX
Principios:
- Diverger primero, converger después. Nunca empezar con la "mejor idea".
Siempre generar múltiples variantes antes de elegir.
- Low-fidelity siempre. Sketches textuales / ASCII / wireframes crudos, no
visual design finalizado. El objetivo es explorar, no producir pixel-perfect.
- Crítica = clarificación de intención, NO "me gusta / no me gusta".
Siempre preguntar: "¿cómo resuelve esta opción el problema del persona?"
- Parking lot de ideas rechazadas. Ninguna idea se pierde — se archiva por
si la necesitamos después.
Vista general de las 5 fases
DESIGN STUDIO (adaptado para AI-assisted)
|-- Fase 1: Problem Definition (15-45 min equivalente)
|-- Fase 2: Divergent Ideation — 6 variantes (10 min)
|-- Fase 3: Presentation + Critique (3 min por variante)
|-- Fase 4: Iterate + Refine (5-10 min)
|-- Fase 5: Team Convergence (45 min)
+-- Output: decision document con converged solution + parking lot
Fase 1 — Problem Definition
Objetivo: Establecer el problema, restricciones, persona, y éxito.
Preguntas al usuario
- DS-1: "¿Qué problema específico vamos a diseñar una solución para? (una oración,
acotada, no 'mejorar la experiencia general')"
- DS-2: "¿Quién es el persona objetivo? Podés invocar
persona-builder si no lo
tenés definido aún — en modo CREATE_PROTO_PERSONA generá uno rápido."
- DS-3: "¿Cuáles son las restricciones del diseño? (técnicas, tiempo, regulatorias,
brand, plataforma objetivo, accesibilidad, etc.)"
- DS-4: "¿Cómo sabremos que la solución funciona? Definí 2-3 métricas de éxito
(cualitativas o cuantitativas)."
- DS-5: "¿Hay soluciones existentes que hay que considerar (propias o de competencia)
para NO repetirlas?"
Output de Fase 1
Problem brief (documento de trabajo):
- Problema:
[una oración clara]
- Persona:
[nombre + primary_pain]
- Restricciones:
[lista]
- Métricas de éxito:
[2-3 métricas]
- Soluciones existentes a evitar:
[lista]
PUERTA DE APROBACIÓN: Confirmar el problem brief antes de diverger.
Fase 2 — Divergent Ideation (6 variantes)
Objetivo: Generar 6 variantes de solución al problema, explorando diferentes ejes
de diseño. Nada de convergencia todavía — todas las ideas se aceptan en esta fase.
Proceso
El agente genera 6 variantes siguiendo esta plantilla mental — cada variante debe
diferir significativamente en al menos UNO de estos ejes:
| Eje de variación | Ejemplos contrastantes |
|---|
| Patrón de interacción | Gestos vs. buttons vs. voice vs. automation |
| Altura de fidelidad | Screen completa vs. widget pequeño vs. notificación passive |
| Timing del flujo | Al inicio de la sesión vs. en el momento del problema vs. post-hoc |
| Canal | In-app vs. email vs. SMS vs. físico vs. multi-canal |
| Grado de automatización | Manual vs. assisted vs. fully automated |
| Estructura de contenido | Texto vs. visual vs. video vs. interactivo |
Formato de cada variante (texto/ASCII, no visual pulido)
### Variante N: [Nombre corto descriptivo]
**Eje de variación**: [Cuál eje explora]
**One-liner**: [Cómo funciona en una oración]
**Sketch descriptivo**:
┌─────────────────────────┐
│ [ASCII o descripción │
│ verbal detallada de │
│ la interfaz / flujo] │
└─────────────────────────┘
**Flujo del persona**:
1. [Paso 1]
2. [Paso 2]
3. [Paso 3]
**Qué resuelve (del primary_pain)**: [Conexión explícita al problema]
**Qué NO resuelve / trade-off**: [Ser honesto con las limitaciones]
Reglas de generación
- Las 6 variantes deben ser genuinamente distintas — no son "la misma idea con 6 colores".
- Al menos una variante radical/contraria — ej. "y si en lugar de una app web, es una
notificación SMS?". Sirve como baseline para medir cuánto innovan las otras.
- Nada de análisis comparativo todavía. Solo generar.
- Si el usuario pide más variantes (7, 8...), aceptarlo, pero >10 es señal de dispersión.
PUERTA DE APROBACIÓN: Presentar las 6 variantes. Confirmar que el usuario entendió cada
una antes de entrar a crítica. Si alguna no se entiende, regenerarla más clara.
Fase 3 — Presentation + Critique
Objetivo: Clarificar la intención de cada variante a través de crítica estructurada.
NO es "me gusta / no me gusta".
Preguntas de crítica (aplicar a CADA variante)
Para cada una de las 6 variantes, responder con evidencia:
- ¿Cómo resuelve esta variante el
primary_pain del persona?
- ¿Qué restricciones (de Fase 1) viola o ignora?
- ¿Cuál es el riesgo principal si implementamos esto?
- ¿Qué supuesto del equipo/producto asume esta variante?
- ¿Qué evidencia necesitaríamos para validarla?
- Score relativo al problem brief: 🟢 fuerte / 🟡 mediana / 🔴 débil
Formato de output
| # | Variante | Resuelve primary_pain | Viola restricción | Riesgo principal | Score |
|---|
| 1 | [Nombre] | Sí / Parcial / No | [Cuál] | [Cuál] | 🟢 / 🟡 / 🔴 |
| 2 | [Nombre] | | | | |
| ... | | | | | |
PUERTA DE APROBACIÓN: ¿El usuario está de acuerdo con la evaluación? Ajustar antes de
iterar.
Fase 4 — Iterate + Refine
Objetivo: Tomar las 2-3 variantes con mejor score de Fase 3 y refinarlas. Puede incluir
combinar elementos de múltiples variantes.
Preguntas al usuario
- IR-1: "De las 6 variantes, ¿cuáles 2-3 querés refinar?"
- IR-2: "¿Alguna combinación tiene sentido? (ej. 'el flujo de Variante 1 con el canal
de Variante 3')"
- IR-3: "Para cada variante refinada: ¿qué cambiarías exactamente?"
Output: variantes refinadas
Cada variante refinada incluye:
- Nombre + descripción actualizada
- Cambios específicos vs. variante original
- Si es combinación: qué elementos trae de cuál variante
- Re-score actualizado
PUERTA DE APROBACIÓN: ¿Las variantes refinadas son claramente mejores que las originales?
Si alguna no mejoró, archivarla en parking lot.
Fase 5 — Team Convergence
Objetivo: Convergir en una solución como "idea del equipo" que vamos a testear /
implementar a continuación.
Preguntas al usuario
- TC-1: "De las variantes refinadas, ¿cuál es 'la' propuesta del equipo? (si hay más
de una persona involucrada, puede requerir discusión — documentar el razonamiento)"
- TC-2: "¿Qué queda en el parking lot? Listarlo con razón del archivo."
- TC-3: "Siguientes pasos: ¿cómo validamos esta solución? (prototipo, user testing,
A/B test, experimento de Lean Customer Development, Concierge MVP, etc.)"
Output final — Design Studio Decision Document
Generar docs/ux-research/design-studios/YYYY-MM-DD-[topic-slug].md con:
# Design Studio — [Topic] ([Fecha])
## Problem Brief
[De Fase 1]
## Variantes generadas (Fase 2)
### Variante 1 — 6 (todas, con descripción completa)
## Crítica (Fase 3)
[Tabla de evaluación]
## Variantes refinadas (Fase 4)
[Refinamientos + combinaciones]
## Solución convergida (Fase 5)
**Nombre**: [Nombre de la solución final]
**Descripción**: [Detalle completo]
**Por qué se eligió**: [Razonamiento del equipo — qué criterios pesaron]
**Elementos heredados de**: [Variante(s) original(es) — para trazabilidad]
## Parking Lot
Ideas archivadas (por si se necesitan más adelante):
- **[Variante N — Nombre]**: Razón del archivo: [por qué no ahora]
- ...
## Siguientes pasos
- [ ] Validación: [método elegido]
- [ ] Responsable: [quién]
- [ ] Fecha de decisión: [YYYY-MM-DD]
- [ ] Si falla validación: volver a Design Studio con aprendizajes
Principios clave
- Divergencia antes de convergencia — 6 variantes mínimo antes de elegir
- Crítica de intención, no de gusto — "¿cómo resuelve X?" no "¿te gusta?"
- Parking lot de ideas rechazadas — no se pierden, se archivan con razón
- Low-fidelity siempre — texto/ASCII/wireframe, no visual design finalizado
- Escalado del ejercicio — puede durar 1 hora (rápido) o 1 día (profundo) según el problema
- Iterar sin culpa — si la solución convergida falla en validación, nuevo Design Studio
con aprendizajes de la iteración anterior
Integración con otras skills
persona-builder (agent): invocado en Fase 1 para obtener o crear el personabusiness-model-toolkit:customer-interview-system (skill externa): después de Fase 5,
la solución convergida puede validarse con entrevistas de cliente (LCD Alvarez)map-workshop (skill UX): después de Design Studio, mapear el journey del persona
con la nueva solución puede revelar nuevos pain pointsfidelity-guide (skill UX): decidir qué nivel de fidelidad usar para testear la
solución convergida (sketch → wireframe → clickable prototype → coded)
Recursos adicionales
- Lean UX (Jeff Gothelf, O'Reilly 2013), cap. 5 — "Design It Together"
- Sprint (Jake Knapp, Simon & Schuster 2016) — Google Ventures' Design Sprint framework,
versión de 5 días del Design Studio
- The Gamestorming Book (Gray, Brown, Macanufo, 2010) — variantes del ejercicio 6-up
