El rol UX se separa en cuatro especialidades. En muchas organizaciones no se separa, y una sola persona las cubre todas con distinta profundidad. Esa figura compuesta (el "UX generalista") es la más común en la práctica, pero no es una quinta especialidad: es la ausencia de la separación. Lo que decide si la separación ocurre es el reto que la organización enfrenta.
flowchart LR
R["UX Research"] -->|"problemas, arquetipos"| D["Diseño de producto"]
D -->|"prototipo a validar"| R
C["Content design"] -->|"lenguaje, nomenclatura"| D
S["Design system / DesignOps"] -->|"componentes, reglas"| D
D -->|"especificación"| E["Delivery"]
E -->|"lo construido"| S
El diagrama muestra las dependencias, pero esconde lo que en la práctica dominaba el flujo, y conviene decirlo explícito porque es lo que va a hacer comparable este estado con los siguientes:
<aside> ⚠️
◆ Paso esencial. Sin ese paso, en una sola pasada, el proceso no entrega nada.
◇ Esencial pero alternativo. Los dos pasos marcados así son alternativas entre sí: hace falta uno de los dos, no los dos.
</aside>
Supuesto exploratorio de Itera sobre el estado del arte, levantado antes de validar con quien ejerce el rol. Los pasos sin marca no son prescindibles en régimen: son prescindibles para entregar una vez.
| Nodo | Labor | Herramientas típicas | Artefacto que producía | Qué la hacía lenta (Fricción) |
|---|---|---|---|---|
| UX Research | ◆ Reclutar participantes | User Interviews, | ||
| Respondent, | ||||
| Ethnio, | ||||
| Listas propias por correo | Panel de participantes agendados | Disponibilidad de personas reales. Días o semanas, y no dependía del equipo | ||
| UX Research | ◇ Entrevistas y sesiones moderadas | Zoom, | ||
| Google Meet, | ||||
| Lookback, | ||||
| UserZoom | Grabaciones y notas de campo | Una sesión por franja horaria, con dos personas del equipo presentes | ||
| UX Research | ◇ Testing no moderado | Maze, | ||
| UserTesting, | ||||
| UserZoom, | ||||
| Optimal Workshop | ||||
| (card sorting, tree testing) | Resultados de tareas, mapas de calor | Llenar la muestra, y el costo por participante | ||
| UX Research | ◆ Síntesis y análisis | Miro o Mural con notas adhesivas, | ||
| Sheets y Excel, | ||||
| Airtable, | ||||
| Dovetail, | ||||
| Notion | Informe de hallazgos, arquetipos, journey map | Transcribir y codificar a mano. La labor más cara en horas persona de todo el flujo | ||
| UX Research | Repositorio de investigación | Dovetail, | ||
| Notion, | ||||
| Confluence, | ||||
| Airtable, | ||||
| carpetas en Drive | Base consultable de hallazgos previos | No la lentitud sino el desuso: se llenaba y no se consultaba | ||
| UX Research | Analítica de comportamiento | Google Analytics, | ||
| Hotjar, | ||||
| FullStory, | ||||
| Amplitude, | ||||
| Mixpanel | Señal cuantitativa de uso real | Nada. Es el único input del flujo que no requería esperar a nadie | ||
| Diseño | ◆ Ideación y workshops | Miro, | ||
| FigJam, | ||||
| Mural, | ||||
| pizarra física con post-its | Conceptos, mapas, oportunidades priorizadas | Agenda de todos los participantes en la misma hora | ||
| Diseño | Arquitectura de información y flujos | Whimsical, | ||
| Miro, | ||||
| Lucidchart, | ||||
| Figma | Diagramas de flujo, mapas de sitio | Rehacer el diagrama cada vez que el flujo cambiaba | ||
| Diseño | ◆ Wireframes y diseño de interfaz | Figma se vuelve el estándar hacia el final del período. | ||
| Antes Sketch (con Abstract para versionado) y Adobe XD. | ||||
| Balsamiq para wireframe rápido | Pantallas y estados | Producir todos los estados de cada pantalla a mano | ||
| Diseño | ◆ Prototipado | Figma, | ||
| InVision, | ||||
| Principle, | ||||
| ProtoPie, | ||||
| Axure, | ||||
| Framer | Prototipo clicable para testear | El prototipo era desechable: el esfuerzo no se recuperaba en la construcción | ||
| Diseño | ◆ Entrega de especificación | Figma inspect, | ||
| Zeplin, | ||||
| InVision Inspect, | ||||
| Confluence, | ||||
| Jira | Especificación visual y de comportamiento | El ida y vuelta de preguntas de desarrollo sobre lo que el documento no cubría | ||
| Content design | ◆ Microcopy y nomenclatura | Google Docs, | ||
| Excel, | ||||
| comentarios en Figma, | ||||
| Ditto, | ||||
| Frontitude | Copy deck, tabla de strings | El texto vivía en un documento paralelo a la pantalla y se desincronizaba | ||
| Content design | Guía de voz y tono | Notion, | ||
| Confluence, | ||||
| Google Docs | Documento normativo | Cumplimiento manual, revisión por lectura | ||
| Design system | Librería de componentes de diseño | Figma libraries, | ||
| Sketch libraries con Abstract | Librería publicada y versionada | Propagar un cambio de componente a los archivos que ya lo consumían | ||
| Design system | Documentación | zeroheight, | ||
| Storybook, | ||||
| Backlight, | ||||
| Notion, | ||||
| Confluence | Sitio de documentación del sistema | Mantenerla al día contra dos fuentes que cambiaban por separado | ||
| Design system | Componentes construidos | Storybook, | ||
| Chromatic | Librería de código | Que el componente de código y el de diseño derivaran entre sí | ||
| Design system | Tokens | Tokens Studio (antes Figma Tokens), | ||
| Style Dictionary | Valores sincronizados entre diseño y código | La sincronización nunca fue automática de punta a punta | ||
| DesignOps | Operación del proceso | Jira, | ||
| Notion, | ||||
| Confluence, | ||||
| estructura de archivos en Figma | Convenciones de archivo, licencias, medición del trabajo de diseño | Trabajo de coordinación puro, invisible en cualquier entregable | ||
| Frontera con Delivery | Handoff | Jira, | ||
| Confluence, | ||||
| Figma inspect, | ||||
| reuniones de refinamiento | Especificación aceptada como suficiente para construir | Es el punto donde el flujo se detenía a esperar. Las herramientas de delivery quedan fuera de alcance de este trabajo |
<aside> ☝
La columna de fricción casi nunca habla de herramientas.
</aside>
Habla de personas: disponibilidad de participantes, agendas coincidentes, revisiones de desarrollo, propagación de cambios entre equipos. Ninguna herramienta del período atacaba eso, porque no era un problema de herramienta. Esto es lo que hay que tener a la vista antes de evaluar cualquier promesa de compresión de ciclos: si la fricción era humana, una herramienta más rápida no la toca.
Hay una asimetría de madurez que va en contra de la intuición: