Operaciones de Diseño · Sistemas · Facilitación

Un proceso diseñado para
sobrevivir a las personas.

Cuando me uní al equipo de IKEA Home Services, no había ningún sistema de trabajo compartido. Lo construí — un framework cross-tool abarcando Figma, Jira, Confluence y Phrase — desde los principios.

IKEA · Actual Garaje de Ideas × IKEA Operaciones de Diseño
ClienteIKEA / Ingka Group
AgenciaGaraje de Ideas / Groupe EDG
Mi rolDesign Operations Lead
Período2023 — Presente
AlcanceDiseño de Procesos · Documentación · Arquitectura de Herramientas
El problema

Sin sistema, solo memoria

Cuando me uní al equipo de IKEA New Business Platform, 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.

El proceso que existía dependía de personas concretas para mantenerlo en la memoria y transmitirlo informalmente. Cuando esas personas no estaban disponibles, o cuando se unían nuevos miembros al equipo, el sistema se derrumbaba. Cada incorporación era una negociación nueva. Cada handoff requería que alguien explicara cosas que deberían haber estado documentadas.

Enfoque

Principios primero, herramientas después

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.

"Figma es la fuente de la verdad de diseño. Confluence es la fuente de la verdad de contexto. Jira es la fuente de la verdad de progreso. Cuando algo existe en dos sitios sin una jerarquía clara, ya está roto."

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.

El framework

Cuatro herramientas, una columna vertebral

El framework define una jerarquía clara en las cuatro herramientas principales que usa el equipo:

  • Figma

    Fuente de la verdad de diseño. Todo el trabajo de diseño activo vive aquí. Ninguna decisión de diseño existe solo en Confluence o Jira.

  • Confluence

    Fuente de la verdad de contexto. El porqué detrás de las decisiones, síntesis de investigación, documentación de procesos, materiales de incorporación.

  • Jira

    Fuente de la verdad de progreso. Estado de tareas, alcance del sprint, bloqueos. No es un repositorio de diseño.

  • Phrase

    Fuente de la verdad de copia. Todas las cadenas listas para localización fluyen por Phrase. Ninguna copia vive solo en Figma.

VERDAD HUB 01 / TOKENS DE DISEÑO 02 / SPEC 03 / CONOCIMIENTO 04 / L10N 01 / FIGMA Librerías de componentes, tokens de diseño & UI kits. Fuente visual de verdad — exporta specs a ingenieros. 02 / JIRA Mapeo de sprints & seguimiento de estado. Vincula cambios de diseño directamente a entregables de código. 03 / CONFLUENCE Specs & guías WoW. Traduce tokens en estándares de equipo y principios compartidos. 04 / PHRASE Copia global & diccionario de localización. Inyecta traducciones en diseño y código.
Una regla: cada herramienta tiene un trabajo. El sistema se mantiene porque el principio es lo suficientemente simple como para recordarlo sin la documentación.
Resultado

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 que pueden arreglarse ajustando la documentación, no rebuscando en archivos.

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.