Registro de decisiones de diseño: cómo documentar el porqué
Un registro de decisiones de diseño guarda qué se decidió, por qué y qué alternativas se descartaron. Aprende su formato, cuándo escribirlo y cómo mantenerlo.
¿Qué es un registro de decisiones?
Es una lista de decisiones, cada una en su propia entrada. El formato más conocido viene de la ingeniería de software: los Architecture Decision Records (ADR). Michael Nygard los propuso en 2011 como una forma ligera de documentar decisiones de arquitectura, pensada para equipos ágiles. Martin Fowler describe cada ADR como un documento corto que captura una sola decisión relevante, idealmente en una página.
Para diseño de producto, la idea es la misma. Ejemplo ilustrativo: una entrada puede decir “Usamos una navegación inferior en móvil, en lugar de un menú hamburguesa, porque los usuarios de prueba necesitaban cambiar de sección con frecuencia”. Dentro de seis meses, cuando alguien proponga un menú hamburguesa, la entrada responde la pregunta sin reunión.
¿Por qué le importa a un diseñador?
Porque la mayoría de las decisiones de diseño se toman en conversaciones, capturas de pantalla y mensajes que nadie guarda. Cuando el equipo cambia, los nuevos llegan y reabren debates que ya se cerraron. Nygard lo resume así: sin contexto, quien hereda una decisión solo puede aceptarla a ciegas o revertirla a ciegas, y ambas opciones son malas.
Un registro también te protege en las revisiones. Cuando un stakeholder pregunta por qué no se incluyó una función, la respuesta está escrita con las alternativas que se evaluaron.
¿Qué campos debe tener una entrada?
El modelo de Nygard propone cinco partes: título, estado, contexto, decisión y consecuencias. Las plantillas de equipos públicos, como la del GOV.UK, usan una estructura parecida: estado, contexto, decisión y consecuencias.
| Campo | Qué responde | Ejemplo |
|---|---|---|
| Título | Qué se decidió, en pocas palabras | “Navegación inferior en móvil” |
| Estado | En qué punto está | Propuesta, aceptada o reemplazada |
| Contexto | Qué fuerzas la motivaron | “Los usuarios de prueba cambiaban de sección cada pocos minutos” |
| Decisión | Qué se eligió, en voz activa | “Usaremos una barra inferior con cuatro secciones” |
| Consecuencias | Qué cambia, para bien y para mal | “Menos toques, pero menos espacio para opciones secundarias” |
Fowler suma dos campos que vale la pena incluir: las alternativas serias con sus pros y contras, y el nivel de confianza en la decisión. También sugiere anotar qué cambios de contexto deberían llevar a reevaluarla.
El campo de estado no es decorativo. Fowler lo plantea en tres valores: propuesta mientras se discute, aceptada cuando ya rige y reemplazada cuando otra decisión la sustituye (con un enlace a la nueva). Nygard añade el valor obsoleta.
¿Cuándo escribir una entrada?
Escribe una entrada cuando la decisión sea difícil de revertir o afecte a más de una pantalla o equipo. Nygard usa el término “architecturally significant” para las decisiones que afectan la estructura, las características no funcionales, las dependencias, las interfaces o las técnicas de construcción. En diseño, eso se traduce a decisiones sobre patrones de navegación, sistema de componentes, tono de voz o principios de accesibilidad.
No hace falta escribir una entrada para cada ajuste visual. Si lo haces para todo, el registro se llena de ruido y nadie lo lee.
¿Cómo se mantiene?
Fowler propone una regla simple: una vez aceptada, la entrada no se reabre ni se modifica. Si la decisión cambia, escribes una nueva que reemplaza a la anterior y marcas la vieja como reemplazada con un enlace. Así queda un historial claro de cuánto tiempo gobernó cada decisión. Nygard lo formula igual: si una decisión se revierte, se conserva la vieja y se marca como reemplazada. Esto evita las dos malas salidas que él describe: aceptar a ciegas o revertir a ciegas.
La GOV.UK usa archivos numerados en Markdown dentro del repositorio del proyecto, para que la documentación viaje con el código. Fowler sigue la misma idea: cada archivo lleva un número consecutivo y el nombre de la decisión, por ejemplo 0001-HTMX-for-active-web-pages. Para equipos de diseño, un documento compartido o una base de datos funcionan igual, siempre que sea fácil de encontrar y de buscar.
Ejemplo
Ejemplo ilustrativo: un equipo de producto discute si mostrar precios con o sin impuestos en el carrito. En la reunión, dos personas defienden opciones distintas. El diseñador escribe una entrada con el título “Precio con impuestos incluidos en el carrito”, el contexto (quejas de clientes por un cargo final mayor al esperado), la decisión, dos alternativas descartadas (mostrar el precio sin impuestos con un aviso, y mostrar ambos en el carrito) y la consecuencia de que el carrito será más largo. Un mes después, cuando finanzas pide cambiar el formato, la entrada muestra qué se evaluó y qué se perdería si se modifica.
Errores comunes
- Escribir la decisión sin el contexto, de modo que dentro de un año nadie entiende por qué se tomó.
- Documentar solo lo que se eligió y no las alternativas descartadas.
- Editar una entrada aceptada en lugar de reemplazarla, lo que borra el historial.
- Registrar todo, incluidas decisiones menores que no justifican el esfuerzo.
- Dejarlo en un lugar que nadie abre, sin enlace desde el proyecto ni desde las especificaciones de diseño.
Un registro funciona bien junto con las especificaciones de diseño y con el proceso de diseño UX. Si las decisiones nacen en equipos distribuidos, colaboración remota en equipos de diseño explica cómo mantenerlo accesible para todos. Y si una decisión se apoya en datos, conviene citar el estudio en la sección de contexto.