El registro de decisiones: por qué los mejores diseñadores documentan las decisiones que nadie les pidió
La brecha entre un diseñador intermedio y uno senior no es el pulido del portafolio, sino la capacidad de capturar, defender y arrastrar el porqué de cada decisión de diseño. Un manual práctico del registro de decisiones, la plantilla de seis campos, dónde guardarlo y los equipos con nombre que ya lo usan.
Un diseñador senior y uno intermedio pueden entregar la misma pantalla. El senior recuerda por qué. El intermedio recuerda qué.
Esa brecha es un solo artefacto. Un registro breve, fechado y estructurado de cada decisión de diseño con su razonamiento adjunto. El registro de decisiones. La mayoría de los diseñadores no lleva uno porque la escuela nunca lo pidió y el equipo anterior no tenía ninguno. La práctica no se propaga por accidente.
Los equipos que marcan el estándar en 2026 ya lo usan. Linear tiene RFC de diseño. Vercel publica especificaciones de producto junto a las de ingeniería. Anthropic publica notas de investigación. Stripe mantiene documentos de revisión de diseño. Brian Lovin guarda los suyos en un sitio personal público. Jordan Singer lanza pequeños productos con diarios de diseño públicos adjuntos. El mismo artefacto en cada sala.
Este es el manual. Qué es un registro, por qué los responsables de contratación lo leen primero, de dónde viene la práctica, la plantilla de seis campos, dónde guardarlo, casos reales, el modo de fallo y cómo empezar mañana.
El artefacto que la mayoría de los diseñadores no lleva
El artefacto más infravalorado del diseño es el registro de decisiones. No el caso de estudio, no el archivo de Figma, no la presentación. Un registro breve, estructurado y fechado de cada decisión de diseño con su razonamiento adjunto, escrito antes de que el trabajo salga.
El costo de saltárselo aparece en silencio. A los seis meses, el diseñador no sabe decir por qué los campos del formulario se apilan en lugar de ir en línea, quién lo decidió ni qué se recortó. A los tres años, el portafolio tiene seis proyectos y cero decisiones defendibles. El diseñador es intermedio de por vida.
Qué es realmente un registro de decisiones
Un registro estructurado de las decisiones de diseño, las alternativas consideradas, las restricciones en juego, el razonamiento detrás de la decisión, el responsable y el resultado. Seis campos, fechado, concreto, enlazado a artefactos. Esa es toda la definición.
No es un caso de estudio. Los casos de estudio presentan cada elección como inevitable. Un registro muestra la elección tal como se tomó, con las alternativas sobre la mesa, las restricciones que las descartaron y el resultado del que ahora el diseñador es responsable.
No es una nota de reunión. Un registro anota qué se decidió y por qué, incluso cuando la decisión ocurrió en un mensaje de Slack de treinta segundos. La hoja de ruta mira hacia adelante. El registro mira hacia atrás a cada decisión ya tomada, fechada, firmada y lista para defenderse.
Por qué los responsables de contratación lo valoran más que los mockups
Los mockups pulidos muestran resultado. Los registros de decisiones muestran criterio. En 2026, los responsables de contratación senior leen primero el registro porque el resultado es barato con IA y el criterio no.
Un modelo entrega una landing pulida en ocho minutos. El responsable que mira esa página no aprende nada del diseñador que la entregó. Mismo modelo, mismo prompt, mismas referencias de Dribbble. El registro es el único artefacto que sobrevive a la commoditización del pulido por la IA, porque el registro no es el resultado, es el rastro de decisiones que produjo este resultado en lugar de los otros dieciocho.
La lectura lleva dos minutos. El responsable abre el registro, revisa cinco entradas y ve cómo piensa el diseñador. Alternativas específicas, restricciones con nombre, razonamiento concreto, resultados asumidos, la disposición a escribir "ahora haría esto distinto". Esa es toda la entrevista, comprimida en un documento.
De dónde viene la práctica
El registro de decisiones es más antiguo que el software. Christopher Alexander escribió lenguajes de patrones que se leen como registros de decisiones a escala de edificio, cada patrón fechado, nombrado, justificado y con alternativas anotadas. Los arquitectos llevan cuadernos de diseño desde hace siglos.
El software lo heredó a través de la cultura de los RFC. El IETF publica documentos de Request for Comments desde 1969. Los ADR (registros de decisiones de arquitectura) en Spotify, Pivotal y Thoughtworks son el mismo artefacto a menor escala. La herencia más reciente son los laboratorios de investigación. Anthropic publica notas de investigación que se leen como registros de decisiones a nivel de modelo.
Tres linajes, un mismo artefacto. Los diseñadores son los adoptantes tardíos, y el listón sube tan rápido que llegar tarde empieza a leerse como ser junior.
La plantilla de seis campos, cópiala
Seis campos. Decisión, Alternativas, Restricciones, Razonamiento, Responsable, Resultado. La plantilla es corta a propósito. La disciplina está en escribirla, no en diseñarla. Copia este bloque. Úsalo mañana.
Date: 2026-04-30
Project: Acme Onboarding v3
Decision
Stack email and password vertically on the signup screen, no inline
social login row.
Alternatives
1. Inline social login row (Google, Apple, GitHub) above the fields.
2. Two-step flow, email first then password on screen 2.
3. Magic-link only, no password field.
Constraints
- Mobile-first, 360px min width, single column.
- Engineering will not ship social OAuth this quarter.
- Support flagged 14% of tickets as password reset confusion.
- [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic.
Reasoning
Vertical stack ships fastest and matches the brand register. Two-step
tested cleaner in 2024 but added a screen we cannot afford given the
38% drop on screen 2. Magic-link only blocks the password manager
flow 22% of paid users rely on.
Owner
Maya Chen, design. Reviewer: Jordan Park, eng lead.
Outcome (filled 2 weeks post-ship)
Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate
magic-link as v3.1 when OAuth lands in Q3.
Una entrada por cada decisión real. Entre cinco y diez entradas por proyecto. Sáltate la portada. El bloque de arriba es el trabajo.
Cómo escribir cada campo sin titubeos
Cada campo tiene una regla. Sáltate la regla y el registro se vuelve teatro.
Decisión. Una frase, en presente, concreta. "Apilar correo y contraseña en vertical." No "sentimos que vertical podría funcionar". Si la decisión aún no se ha tomado, no escribas la entrada todavía.
Alternativas. Lista numerada, de dos a cuatro opciones reales que estaban sobre la mesa. Nada de hombres de paja. Si solo se consideró una, escribe esa y explica por qué se detuvo la búsqueda.
Restricciones. Lista con viñetas, con nombre y con fuente. Capacidad de ingeniería, reglas de marca, tickets de soporte, mínimo de accesibilidad, presupuesto de rendimiento. Sin ellas, el registro se lee como lavado de gusto.
Razonamiento. De tres a cinco frases, sin "sentimos". Usa porque. Usa comparado con. Cita la restricción o el dato que decidió. Enlaza el artefacto.
Responsable. Pon el nombre del diseñador. Pon el nombre del revisor. Los registros anónimos no sobreviven al contacto con un revisor senior.
Resultado. Se completa entre dos semanas y dos meses después del lanzamiento, con fecha. Qué hizo la métrica, qué se revisó, qué cambiaría la próxima vez. La disposición a escribir "me equivoqué con el bloqueo del magic-link" es la señal de mayor confianza del registro.
Dónde guardar el registro
El registro vive donde el equipo vaya a abrirlo de verdad. El almacenamiento importa menos que la cadencia.
Notion. La configuración más fácil para todo el equipo. Una base de datos, una entrada por decisión, seis campos como columnas. La mayoría de los equipos de producto ya lo paga y un diseñador puede montarlo en una hora.
Linear docs. La opción correcta si ingeniería y diseño ya viven ahí. Las decisiones quedan junto a las incidencias que las provocaron, y el paso a RFC de ingeniería está a un clic.
Un archivo markdown en el repositorio. La opción correcta para ingenieros de diseño y responsables de sistemas de diseño. Un decisions.md en la raíz del repo o bajo /docs/decisions/ se lee como algo serio porque está versionado con el código. Los ingenieros respetan este formato a primera vista.
Un pequeño blog privado o sitio personal. La opción correcta para un diseñador individual que construye un rastro público. Brian Lovin lleva el suyo así. Sitio estático, entradas fechadas, enlaces públicos. La pieza sirve a la vez de portafolio y de presencia de contratación.
Elige uno. Úsalo durante un trimestre. El primer fallo es elegir una herramienta y no volver a abrirla.
Los RFC de diseño de Linear y las especificaciones de producto de Vercel
Linear trata los RFC de diseño como artefactos de primera clase en sus documentos. Cada decisión de diseño relevante sale con un RFC, escrito antes del trabajo, revisado por los líderes de diseño e ingeniería y archivado con el proyecto. El RFC es parte del trabajo, no un resumen posterior.
Vercel publica especificaciones de producto junto a las de ingeniería en el mismo repositorio. La decisión de diseño y la de ingeniería conviven en el mismo documento, fechado, con responsable y revisado. El equipo trata la especificación como el contrato. Cuando v0 lanza una nueva superficie, la especificación forma parte del artefacto de lanzamiento.
Ambos equipos tratan el razonamiento escrito como parte del oficio. No como un resumen del miércoles por la tarde. No como algo opcional. El artefacto es el trabajo igual que el archivo de Figma es el trabajo, y un diseñador que llega sin uno parece inacabado.
Las notas de investigación de Anthropic y los documentos de revisión de diseño de Stripe
Anthropic publica notas de investigación que se leen como registros de decisiones a nivel de modelo. Qué probaron, qué funcionó, qué no, cuál es el siguiente paso. Cortas, fechadas, con responsable, enlazadas. Lee tres y la práctica se vuelve obvia. Las notas son el registro, no el discurso.
Stripe mantiene documentos de revisión de diseño que sobreviven a los ciclos de producto. Stripe Press es la superficie pública, la práctica interna es más antigua. Las revisiones se escriben, se archivan y se retoman cuando el siguiente ciclo se topa con una decisión parecida. Memoria institucional que se acumula con los años en lugar de irse cuando un diseñador senior se marcha.
Si quieres ayuda para integrar esto en el oficio de tu equipo, contrata a Brainy. BrandBrainy entrega la capa de oficio que la IA no puede falsificar. ClaudeBrainy entrega los paquetes de Skills y las bibliotecas de prompts que convierten el registro de una disciplina en un hábito por defecto.
Brian Lovin y Jordan Singer llevan los suyos en público
Brian Lovin mantiene un sitio personal de largo recorrido que se lee como un registro de decisiones público sobre su propio trabajo. Páginas cortas, escritura directa, decisiones de diseño explicadas en tres o cuatro frases cada una, fechadas y enlazadas al producto en vivo. Años de entradas. El sitio sirve de portafolio y de presencia de contratación, el doble uso en el que se apoya el manual de el anti-portafolio.
Jordan Singer lanza pequeños productos con diarios de diseño públicos adjuntos. Cada proyecto tiene un registro escrito de las decisiones detrás, publicado abiertamente, con la disposición de decir en voz alta "esto no funcionó". El diario es el marketing, el registro y el artefacto de contratación a la vez.
Ambos son plantillas que cualquier diseñador en activo puede copiar esta semana. Sitio estático, entradas de seis campos, fechadas, públicas, enlazadas. Quince minutos por entrada. Tres al mes. Al cabo de un año, el registro público se lee como senior de una forma que ningún caso de estudio de Behance logra.
La advertencia: la racionalización a posteriori
Un registro de decisiones escrito después de que el trabajo salió y el resultado se conoce no es un registro, es un discurso de ventas. Los responsables de contratación senior notan la diferencia en dos minutos.
El delator es el campo de alternativas. Un registro en vivo lista alternativas que de verdad estaban sobre la mesa, a menudo con alguna que suena fuerte. Un registro a posteriori lista tres opciones que quien escribe nunca consideró en serio, diseñadas para que la elegida parezca obvia. El responsable de contratación ha hecho el mismo ejercicio cien veces. Sabe cómo se ve el maquillaje.
El otro delator es el campo de resultado. Los registros en vivo incluyen resultados que no coincidieron con la predicción. "Esperaba una mejora de conversión, la prueba salió plana, esto es lo que falló." Los registros de teatro solo incluyen victorias, redondeadas de antemano para parecer mejores de lo que fueron.
La solución es incómoda. Escribe la entrada antes de que el trabajo salga. Ponle fecha. Envíala a un revisor que te lleve la contraria. Completa el resultado dos semanas después, incluso cuando las noticias sean malas. Sobre todo cuando sean malas. La entrada honesta se acumula.
Cómo usar el registro en entrevistas y revisiones
Un registro se gana su lugar dos veces. Una cuando el trabajo sale, otra cuando el diseñador recorre la decisión con un responsable de contratación o un revisor senior.
En una entrevista, el registro sustituye al recorrido del caso de estudio. Abre el documento. Elige tres entradas. Para cada una, lee la decisión, nombra la alternativa más fuerte, nombra la restricción determinante, explica el razonamiento en dos frases, comparte el resultado incluyendo qué cambiaría la próxima vez. Cinco minutos por entrada, quince en total. El responsable aprende más sobre criterio que con una presentación de caso de estudio de cuarenta y cinco minutos.
En una revisión senior, el registro es la conversación. El revisor lee la entrada, cuestiona el razonamiento, pregunta por qué se descartó la alternativa más fuerte. La discusión afila la siguiente decisión antes de tomarla. Eso es una buena revisión de diseño. No feedback sobre píxeles renderizados, sino debate sobre la decisión que hay detrás.
Un diseñador que sabe defender el registro defiende el trabajo. Un diseñador sin registro no defiende nada.
El nuevo listón: el trabajo senior sin registro se lee como junior
El registro de decisiones ya no es un extra deseable para seniors. Es la señal más barata de criterio senior que un diseñador puede entregar, y el costo de saltárselo va en aumento.
Un portafolio senior con registro público se lee como senior. Uno sin registro se lee como trabajo que quizá fue senior, difícil de saber. Los responsables de contratación leen ambos. Al primero le devuelven la llamada. Un junior con registro en tres proyectos pequeños se lee por encima de su nivel. Un junior con doce shots perfectos de Dribbble y sin registro se lee como el mismo junior de hace un año.
El gusto es el último foso defensivo en 2026 porque la producción se commoditizó, y el registro es el artefacto público que prueba que el gusto existe en el trabajo. Si trabajas como híbrido de ingeniería de diseño, el registro sirve también de RFC de ingeniería en la capa de diseño. Si estás subiendo por la nueva escalera de carrera del diseño, el registro es el artefacto sobre el que se apoya la escalera.
FAQ
¿Qué es un registro de decisiones de diseño?
Un registro breve y estructurado de decisiones de diseño con su razonamiento adjunto. Seis campos por entrada: Decisión, Alternativas, Restricciones, Razonamiento, Responsable, Resultado. Fechado, concreto, enlazado a artefactos.
¿En qué se diferencia de un caso de estudio?
Un caso de estudio presenta cada elección como inevitable. Un registro muestra las decisiones tal como se tomaron de verdad, con las alternativas sobre la mesa, las restricciones que condicionaron la decisión y el resultado asumido. Los casos de estudio venden. Los registros documentan.
¿Dónde debería guardarlo?
Donde tu equipo vaya a abrirlo de verdad. Notion para equipos de producto, Linear docs para equipos que ya están ahí, un archivo markdown en el repositorio para ingenieros de diseño, un pequeño sitio privado para un rastro público individual.
¿Qué longitud debe tener cada entrada?
Corta. La plantilla completa cabe en una pantalla. Quince minutos por entrada.
¿Y si mi empresa no lo adopta?
Llévalo tú por tu cuenta. El registro individual de un diseñador se acumula de un empleo a otro. Brian Lovin y Jordan Singer llevan los suyos en público. La práctica es tuya, no de tu empleador, y el artefacto se va contigo.
Empieza el registro esta semana
Tres movimientos. Monta el almacenamiento. Elige Notion, Linear, el repositorio o un sitio pequeño. Levántalo en treinta minutos. Elige el que vayas a abrir mañana.
Escribe tres entradas sobre decisiones ya tomadas. Decisiones reales de este trimestre. Seis campos cada una. Alternativas honestas, restricciones reales, sin titubeos, resultados fechados y sin maquillaje. Las tres primeras son las más difíciles, el resto sale más rápido.
Muestra el registro a un revisor senior. Pídele que cuestione el razonamiento. Toma la crítica como señal. Actualiza las entradas. La primera revisión es donde el registro empieza a acumularse.
Si quieres ayuda para integrar la práctica del registro de decisiones en el oficio de tu equipo, contrata a Brainy. BrandBrainy entrega la capa de marca y oficio que la IA no puede falsificar. ClaudeBrainy entrega los paquetes de Skills y las bibliotecas de prompts que convierten el registro de una disciplina en un hábito por defecto. Los equipos que ya lo usan se están despegando. El listón sube, y el diseñador que empieza esta semana es el que los equipos con nombre estarán leyendo dentro de un trimestre.
If you want help building the decision-log practice into your team's craft, BrandBrainy ships the brand and craft layer that AI cannot fake, and ClaudeBrainy ships the Skill packs and prompt libraries that turn the log from a discipline into a default.
Get Started
