Un proceso diseñado para sobrevivir a las personas.

Ocho puntos de fallo, no uno

Cuando me uní al equipo, el proceso de trabajo existía — pero solo en la cabeza de las personas. Los archivos estaban distribuidos por Figma, Confluence y unidades locales sin estructura consistente. La jerarquía del trabajo — qué iba en Figma, qué en Confluence, qué en Jira — era poco clara y se aplicaba de forma inconsistente.

Lo que parecía un problema cultural era en realidad estructural. Una auditoría de causas raíz detectó ocho puntos de fallo distintos que ralentizaban al equipo activamente. No eran independientes — cada uno alimentaba a los demás:

Principios primero, herramientas después

El primer paso fue hacer legible el estado existente. Mapear lo que estaba ocurriendo realmente — no el ideal, no lo que la gente creía que pasaba — reveló que los problemas eran estructurales, no de comportamiento. Las personas no eran descuidadas; el sistema no tenía reglas claras sobre quién era responsable de qué en cada etapa.

El instinto en estas situaciones es auditar las herramientas y luego escribir documentación para ellas. Ese es el orden equivocado. La documentación sin un principio estructural es solo más ruido.

Empecé mapeando el trabajo real — los tipos de tareas que realizaba el equipo, sus interdependencias, las decisiones que seguían perdiéndose, las preguntas que los nuevos miembros seguían haciendo. A partir de ese mapa, derivé un conjunto de reglas estructurales: qué tipo de información vive en cada herramienta, cuándo se mueve entre herramientas, quién la tiene en cada etapa.

Una vez que los principios fueron claros, la documentación se escribió sola. A las herramientas se les asignaron roles. Las convenciones de nomenclatura surgieron de esos roles. La incorporación de nuevos miembros surgió de las convenciones de nomenclatura.

Cuatro herramientas, una columna vertebral

El framework asigna un rol único y no solapado a cada una de las cuatro herramientas principales. La regla es lo suficientemente simple como para retenerla en la memoria sin documentación:

Cinco fases. Dos responsables.

Junto al framework de herramientas, el equipo necesitaba un flujo claro para cómo el trabajo de diseño — especialmente el contenido y las traducciones — avanzaba por el ciclo de producción. El proceso existente no tenía fases definidas, ni transferencias de responsabilidad explícitas, ni ningún punto en el que las traducciones pudieran verificarse antes de llegar a los usuarios.

El flujo rediseñado se estructura en cinco fases con responsabilidades explícitas. Las fases uno a tres son responsabilidad del diseñador: se define el contenido, se configuran las claves de localización y se realiza el handoff. Las fases cuatro y cinco son responsabilidad de ingeniería: implementación, integración y QA ocurren aquí. El release es el resultado de un ciclo completo, no un deadline que comprime las fases anteriores.

El cambio estructural crítico estuvo en la Fase Dos. Las claves de localización — las cadenas que alimentan el sistema de traducción — tenían que crearse durante el diseño, no durante el desarrollo. Adelantar la creación de claves convirtió las traducciones en un track paralelo desde la Fase Dos, lo que significaba que estaban listas cuando comenzaba el QA.

Decisiones de componentes, no caos de componentes.

La estructura de archivos y las convenciones de nombres resuelven el problema de organización. La gobernanza de componentes resuelve otro distinto: cuándo usar lo que ya existe, cuándo adaptarlo y cuándo proponer algo nuevo.

El sistema de diseño Skapa de IKEA proporciona una base sólida de iconos, fundamentos y componentes. Pero un equipo de producto que construye features para la Home App encontrará inevitablemente escenarios que Skapa no cubre. Sin una regla, esos huecos se rellenan de forma inconsistente — cada diseñador tomando una decisión diferente, sin trazabilidad ni revisión. El framework Skapa-First hace explícita la regla: consultar Skapa primero, adaptar si es necesario, y proponer nuevos componentes solo cuando ninguna solución existente sea viable — con justificación escrita y revisión de gobernanza antes de que cualquier componente entre en producción.

De no verificable a comprobable

El flujo de traducción era el punto de fallo más agudo. En el estado existente, las claves de localización se creaban tarde en el ciclo — típicamente por ingeniería, no por diseño — lo que comprimía la ventana de traducción, forzaba que la localización ocurriera en paralelo con el desarrollo en lugar de antes, y dejaba al QA sin ningún mecanismo para verificar la calidad del idioma antes del release. Los errores de traducción los encontraban los usuarios finales, no el equipo.

El flujo rediseñado trasladó tanto la responsabilidad como el momento de creación de las claves. Los diseñadores crean las claves de contenido durante la Fase Dos — como parte del proceso de diseño, antes del handoff. Esto convierte la traducción en un track paralelo que está listo cuando finaliza el desarrollo. El control de calidad ahora incluye un paso dedicado a la revisión de traducciones: los errores de idioma son detectables antes de que lleguen a los usuarios.

El cambio también redujo la carga cognitiva de ingeniería. Cuando las claves llegan al desarrollo ya creadas y nombradas correctamente, los ingenieros no toman decisiones de contenido bajo presión de plazo. El sistema produce mejor trabajo porque cada rol hace el trabajo para el que está posicionado.

Cuando el proceso es sólido, puedes diseñar lo que viene después.

Resolver los fallos estructurales era necesario. Pero también abrió una pregunta diferente: ahora que los handoffs y la responsabilidad eran explícitos y estaban documentados, ¿qué partes del flujo de diseño podían reestructurarse de forma fundamental — no solo mejorarse — usando IA?

De ahí surgieron dos líneas de trabajo:

Este trabajo está en curso y se está compartiendo con profesionales senior de diseño en Garaje de Ideas como parte de un programa activo de formación en IA.

Adopción imperfecta. La estructura se mantuvo.

El framework se adoptó — de forma imperfecta. Algunos hábitos llevan tiempo. Algunos miembros del equipo se adaptaron más rápido que otros. Hay rincones del proceso que todavía se negocian informalmente.

Pero la estructura se mantuvo. Los nuevos miembros del equipo pueden ahora incorporarse sin necesitar un guía personal por cada herramienta. Los handoffs tienen una forma consistente. Cuando el proceso se rompe, se rompe de maneras identificables — una convención de nomenclatura ignorada, una página de Confluence sin actualizar — que pueden arreglarse ajustando la documentación, no rebuscando en archivos o preguntando a la persona adecuada.

El cambio en el flujo de traducción tuvo el efecto más inmediato: el QA pudo verificar la calidad del idioma antes del release por primera vez. El ciclo de retroalimentación pasó de "un usuario reporta un error de traducción" a "el QA lo detecta en pre-producción".

He llegado a pensar que la adopción imperfecta de un sistema bien estructurado es la condición de éxito real — no el cumplimiento perfecto. Un proceso que sobrevive es más valioso que un proceso que era teóricamente perfecto pero requería el mantenimiento constante de una persona específica para funcionar.