Design brief: el documento que alinea antes de diseñar
Un design brief define problema, objetivos, audiencia y restricciones antes de diseñar. Qué incluir, quién lo aprueba y en qué se diferencia del creative brief.
¿Para qué sirve?
Sirve para no discutir el problema después de haber diseñado la solución. Muchos proyectos fracasan no porque el diseño sea malo, sino porque dos personas entendieron cosas distintas sobre el objetivo. El brief obliga a escribir esa comprensión compartida.
Dovetail explica que el equipo de diseño y el cliente suelen armar el brief en colaboración (Dovetail: What is a design brief?). Asana añade que el alcance debe acordarse entre ambas partes y que las dos deben revisar y aprobar el documento final antes de empezar a trabajar (Asana: Design brief). Esa aprobación no es un trámite: es el momento en que el alcance se fija.
¿Qué debe incluir?
Dovetail, Maze y Asana proponen un núcleo parecido. Una versión práctica tiene estas secciones:
- Contexto y problema. Qué pasa hoy y por qué importa. Una o dos frases bastan si el problema es claro.
- Propósito y objetivos. Lo que el proyecto debe lograr. Asana plantea la pregunta «¿qué métricas usaremos para medir el éxito?» y remite a objetivos SMART.
- Audiencia. Quién usa el producto y qué necesita. Si ya tienes proto-personas o investigación, enlázalas aquí.
- Alcance y entregables. Qué se diseña y qué no. Dovetail recomienda fijar el alcance desde el inicio para poder negociar cuando aparezcan cambios.
- Restricciones. Tiempo, presupuesto, tecnología, marca y accesibilidad. Las restricciones son las que más discusiones evitan.
- Competencia y referencias. Qué hacen otros y qué se toma como punto de partida. Dovetail, Maze y Asana incluyen un análisis de la competencia.
- Stakeholders. Quién decide, quién aprueba y quién consulta.
- Criterios de éxito. Cómo se va a medir si el trabajo funcionó.
- Calendario. Fechas de entrega y revisiones clave.
¿Qué hace que un objetivo sirva?
Un objetivo de brief no es «mejorar la experiencia». Es algo como «subir la confirmación de citas de 60 % a 75 % en seis semanas». Figma, en su guía de creative brief, sugiere objetivos SMART, es decir, específicos, medibles, alcanzables, relevantes y con plazo.
Para que el objetivo sea útil, el brief debe decir también qué se hará si no se cumple. Esa línea, escrita antes, evita decidir a los gritos en la última revisión.
¿En qué se diferencia de un creative brief?
Las fuentes no se ponen de acuerdo en la frontera. Figma dice que el creative brief fija la base estratégica del proyecto y que el design brief se apoya en ella con requisitos técnicos y visuales concretos. Dovetail describe el creative brief como el que cubre objetivos y mensajes clave de todo el proyecto, y el design brief como el centrado en lo visual. Asana, en cambio, ubica el design brief en la preproducción y el lado de negocio, y deja la ejecución creativa al creative brief.
Como no hay un estándar, la regla práctica es preguntar al cliente o a la agencia qué documento espera y qué debe contener.
¿Quién lo escribe y quién lo aprueba?
Depende de la organización. Dovetail lo presenta como un trabajo conjunto entre diseño y cliente, y Asana dice que puede ser liderado por el cliente, por el diseñador o hecho en colaboración. Figma, en su guía de creative brief, dice que suele ser el project manager quien reúne los aportes de los stakeholders, y que el presupuesto y el calendario deben aprobarse con sus superiores. Lo importante es que alguien tenga la responsabilidad de cerrarlo y que todos los que lo firman sepan qué están aprobando.
¿Cuándo NO conviene un brief largo?
- En un cambio pequeño de un componente existente, un brief de cuatro páginas es desproporcionado. Basta con una nota de tres líneas con el problema y el criterio de éxito.
- Si el brief se escribe después del diseño, sirve como justificación, no como alineación. Cuando eso pasa, el documento solo registra decisiones ya tomadas.
- Si el equipo no tiene a nadie que pueda tomar decisiones sobre el alcance, el brief se vuelve una lista de deseos sin dueño.
Dovetail señala que un brief suele tener una o dos páginas. Esa extensión es un buen límite: si crece más, quizá estás mezclando dos proyectos.
Ejemplo ilustrativo
Ejemplo ilustrativo: una aseguradora quiere que sus clientes puedan declarar un siniestro desde el celular. El design brief dice que el problema es que el 40 % de los reportes llega por teléfono porque la app no muestra el paso de fotos. El objetivo es que el 30 % de los reportes se haga desde la app en tres meses. La audiencia son personas que han tenido un accidente en las últimas dos semanas, con poco tiempo y estrés. Las restricciones son que el sistema de pagos no se toca y que el flujo debe cumplir WCAG 2.2 AA. El alcance incluye el flujo de reporte, no el de pago. Los criterios de éxito son el porcentaje de reportes desde la app y el tiempo promedio de carga de fotos. Todo esto cabe en una página y permite decir no a una petición de último minuto: agregar un chat en vivo, que queda para la siguiente fase.
Cuando el brief define el problema, el siguiente paso suele ser una investigación para validarlo, y después una síntesis con síntesis de investigación. Si el flujo tiene muchos pasos, un wireflow permite mostrar el recorrido sin esperar al diseño final.
Errores comunes
- Escribir un brief de objetivos vagos como «ser más moderno».
- No fijar el alcance, de modo que cada revisión agrega pantallas.
- Dejar las restricciones para el final, cuando ya no pueden cambiar.
- Firmar un brief sin que los stakeholders sepan qué están aprobando.
- Olvidar los criterios de éxito y, al final, no saber si el proyecto funcionó.
- Escribir el brief después del diseño y tratarlo como si hubiera guiado las decisiones.
Qué puedes hacer mañana
- Toma el último proyecto que empezaste sin brief y escribe el problema y el criterio de éxito en una página.
- Antes de tu próxima reunión de inicio, envía un borrador con un objetivo medible y pide una corrección.
- Escribe al lado de cada restricción quién puede cambiarla. Si nadie puede, es una restricción real.