El kickoff ya pasó. Hay un deck, un Figma vacío y tres personas que recuerdan cosas distintas. A la segunda semana el equipo de diseño pregunta por usuarios, objetivos y restricciones. La respuesta es «ya lo hablamos» y, en la práctica, no hay un brief de proyecto UX UI que se pueda usar.
No es un problema de actitud. Es un problema de contrato. Si el brief no deja por escrito qué problema se resuelve, para quién y qué queda fuera, el diseño se convierte en una ronda de opiniones. Cuatro semanas no se pierden pintando pantallas: se pierden reabriendo decisiones que deberían haber llegado cerradas.
Este artículo es el brief que pedimos en Truman antes de abrir un archivo de diseño UX/UI. Qué tiene que estar cerrado, qué puedes dejar abierto y cómo no convertir el kickoff en un bucle.
Qué es un brief de proyecto UX UI (y qué no es)
Un brief no es un moodboard ni un inventario de páginas. Es el documento que permite a un diseñador tomar 20 decisiones al día sin preguntarte cada una. Si no cumple esa función, es marketing interno con otro nombre.
En Truman lo tratamos como un contrato de trabajo, no como un anexo comercial. Tiene que caber en una reunión de 90 minutos y sobrevivir a que cambie el interlocutor. Si solo lo entiende quien lo escribió, no es un brief: es una nota personal.
Tres cosas que un brief no tiene que resolver el día uno: el sistema de diseño completo, el copy final de cada pantalla y la lista exhaustiva de estados de error. Esas piezas se descubren diseñando. Tres cosas que sí: el problema de negocio, el usuario principal y el perímetro. Sin eso, cualquier wireframe es decoración.
Si estás eligiendo estudio y aún no tienes claro qué pedir en esa primera fase, este criterio encaja con cómo elegir una agencia de UX/UI en València: no por el portfolio más brillante, sino por cómo te obligan a concretar antes de abrir Figma.
Lo que tiene que estar cerrado antes del kickoff
Cerrado no significa grabado en piedra. Significa que hay un responsable, una frase y una fecha. Si alguien puede reabrir la decisión sin coste, no está cerrada.
| Pieza del brief | Estado al kickoff | Si falta, qué pasa |
|---|---|---|
| Problema de negocio en una frase | Cerrado | El diseño discute estética en lugar de resultado |
| Usuario principal y contexto de uso | Cerrado | Se diseña para un promedio que no existe |
| Perímetro: qué entra y qué queda fuera | Cerrado | Cada revisión añade una pantalla «pequeña» |
| Métrica de éxito del rediseño | Casi cerrado | Nadie sabe si el diseño funcionó a los 90 días |
| Restricciones técnicas y de marca | Casi cerrado | Se tiran tres semanas de UI incompatibles con el stack |
| Look & feel final y microcopy | Abierto | Forzarlo ahora convierte el brief en un concurso de gustos |
El problema de negocio tiene que ser observable. «Modernizar la imagen» no sirve. «El 60 % de las solicitudes de cita se abandonan en el paso 2» sí. No hace falta un dashboard perfecto: hace falta una frase que un diseñador pueda traducir a flujo.
El usuario principal es uno, no siete. Puedes tener secundarios, pero el brief nombra a quién priorizamos cuando hay conflicto. En un hospital o una fundación, ese conflicto es diario: investigador, gestor, paciente, dirección. Si no eliges, el menú acaba siendo un organigrama.
El perímetro es la parte que más duele escribir y la que más semanas ahorra. «Rediseñamos el alta y el listado; el backoffice se queda para fase 2» es un brief. «Mejoramos la experiencia digital» es una invitación a perder el trimestre.
Lo que puedes (y debes) dejar abierto
Un brief que lo cierra todo es sospechoso. O copia una web de referencia o está disfrazando decisiones de diseño como requisitos. Dejar abierto no es vaguedad: es marcar el método con el que se va a cerrar.
Deja abierto el número exacto de pantallas. Deja abierto el componente concreto de cada estado. Deja abierto el tono fino del microcopy. Cierra, en cambio, cómo vais a decidir: test con 5 usuarios, revisión con un decisor, o criterio del estudio con una ronda. Sin método, «lo vemos sobre la marcha» es el inicio del bucle.
El sistema de diseño también puede empezar abierto. Lo que no puede faltar es si ya existe uno, si hay que heredarlo o si se construye desde cero. Esa decisión cambia el calendario entero. Si quieres el criterio largo, está en qué es un sistema de diseño y cuándo lo necesitas.
Si mañana cambia el interlocutor, ¿el brief sigue siendo usable o hay que volver a explicar el proyecto desde cero?
Cómo no convertir el kickoff en un bucle de cuatro semanas
El bucle tiene una forma reconocible. Semana 1: kickoff amplio, todo el mundo asiente. Semana 2: primer flujo, primer «esto no es exactamente así». Semana 3: entra marketing o dirección con otra prioridad. Semana 4: se «redefine el enfoque» y el Figma sigue en la página 1.
La forma de cortarlo no es más reuniones. Es un brief con dueño y una regla de oro: lo que no está en el documento no se diseña en esta fase. Las ideas nuevas van a un parking visible. Si una idea es urgente de verdad, se cambia el perímetro por escrito, no de pasillo.
En València vemos el mismo patrón en pymes y en instituciones: el kickoff se usa para alinear a gente que no se había sentado antes. Eso no es brief, es política interna. Haz esa reunión antes. El estudio no debería ser el primer sitio donde el comité se pone de acuerdo.
Tip técnico: el brief en el archivo, no en el correo
Pegamos el brief firmado en la primera página del Figma (o en la cabecera del repo). Objetivo, usuario, perímetro y «fuera de alcance» visibles mientras se diseña. Cuando un comentario contradice el brief, no se debate el gusto: se señala la frase. Si hay que cambiarla, se versiona. Un hilo de correo de 40 mensajes no es una fuente de verdad; es ruido con timestamp.
Cómo se ve un brief usable en proyectos reales
En Ceylan el brief no empezó por el look de una joyería. Empezó por cómo se elige una pieza, qué fricción hay entre catálogo y confianza, y qué no íbamos a resolver en la primera versión. Sin ese perímetro, el ecommerce se habría convertido en un catálogo infinito de excepciones.
En FIHGUV el brief tenía que nombrar públicos que no se parecen: investigación, gestión, ciudadanía. Si el documento no prioriza, la arquitectura de información se convierte en un mapa de la organización. El brief bueno elige a quién se le facilita la vida primero.
En los dos casos el documento cabía en una página y se pudo enseñar a alguien que no había estado en el kickoff. Ese es el test. Si necesitas 40 minutos de contexto oral, el brief no está listo y el diseño va a pagar esa deuda.
Cuando el brief está cerrado, el siguiente paso no es «más pantallas»: es comprobar con usuarios baratos y pronto. El método está en tests de usabilidad que no necesitan un lab. Un brief sin test posterior es una hipótesis bien redactada.
El brief no está para impresionar al comité. Está para que el diseñador pueda decir que no. Si no se puede usar para rechazar una petición, no es un brief: es una presentación.
Antes de llamar kickoff a la primera reunión, verifica esto
- ¿El problema de negocio cabe en una frase observable, no en un eslogan?
- ¿Hay un usuario principal nombrado y un contexto de uso (dispositivo, momento, prisa)?
- ¿El perímetro dice qué entra en esta fase y qué queda fuera, con ejemplos?
- ¿Existe una métrica o señal de éxito a 30–90 días?
- ¿Están escritas las restricciones técnicas, legales y de marca que no se pueden romper?
- ¿Hay un decisor único para desempates, no un comité de «lo vemos»?
- ¿Lo que queda abierto tiene método y fecha de cierre, no «ya se verá»?
- ¿Alguien que no estuvo en la reunión puede diseñar con este documento?
Preguntas frecuentes sobre el brief de un proyecto UX/UI
¿Cuánto tiene que ocupar un brief de proyecto UX UI?
Una página bien escrita gana a un PDF de 20. Si necesitas anexos (inventario de URLs, accesos, normativa), van aparte. El brief es el contrato; los anexos son material. Si el documento principal no se puede leer en diez minutos, nadie lo va a usar mientras diseña.
¿Quién lo escribe: el cliente o el estudio?
Lo escribe el estudio a partir de una conversación, y lo firma el cliente. Pedir que el cliente llegue con el brief perfecto es una forma educada de retrasar el proyecto. En Truman salimos de la entrevista con un borrador en 48 horas. El valor no es la plantilla: es obligar a elegir.
¿Se puede empezar a diseñar sin brief?
Se puede. Se hace todo el rato. El coste es que las dos primeras semanas de diseño son, en realidad, discovery encubierto y más caro: cada cambio tira pantallas, no párrafos. Si el calendario aprieta, acorta el brief, no te lo saltes.
¿Qué diferencia hay entre brief, discovery y kickoff?
El discovery investiga. El brief decide. El kickoff alinea al equipo sobre esa decisión. Si el kickoff investiga, vas tarde. Si el brief investiga, no es un brief. Mezclar las tres cosas en una sola reunión es la receta de las cuatro semanas perdidas.
