El brief: donde se gana o se pierde el proyecto antes de abrir Figma
Un brief mal hecho condena el proyecto entero, por mucho que luego diseñes bonito. Y esto lo decimos después de ver cientos de proyectos de alumnos y también de clientes reales que pasan por nuestro campus de Chamberí.
Un brief que sirve de verdad responde a tres cosas: qué problema resuelve el producto, para quién y cómo se va a medir el éxito. Si el cliente te dice "quiero una web moderna", ese no es un brief, es una excusa para que luego nadie esté contento con el resultado. Hay que preguntar más: ¿quién usa esto?, ¿qué hace hoy que no debería hacer?, ¿qué pasa si falla? En estudios como IDEO o Fjord (parte de Accenture) la fase de descubrimiento puede llevarse semanas enteras antes de dibujar nada, y no es capricho: es ahorro de tiempo después.
Una cosa que repetimos mucho en clase: el brief no es un documento cerrado que te entregan y ya. Es algo vivo que se revisa durante todo el proyecto, porque casi siempre el cliente descubre lo que quiere a medida que ve avances.
Investigación: la parte que todo el mundo se salta y no debería
La investigación no es un trámite de power point, es la base que decide si el diseño funciona o es un adorno caro. Entrevistas, benchmarking, análisis de la competencia, mapas de empatía... suena a mucho papeleo, pero sin esto diseñas a ciegas.
En UX real trabajamos con varias herramientas de investigación, pero lo que de verdad cambia las cosas es hablar con usuarios de carne y hueso. Cinco entrevistas bien hechas te dan más información útil que una encuesta de doscientas respuestas mal planteada. Esto es algo que se nota mucho en los proyectos de **diseño UX/UI** que hacemos en TRAZOS: los alumnos que se toman en serio esta fase llegan al wireframe con decisiones ya tomadas, no con dudas.
Y aquí va una opinión que no todo el mundo comparte: no hace falta investigar durante un mes para cada proyecto. Hay clientes con presupuesto y tiempo limitado, y una investigación rápida pero bien enfocada vale más que una perfecta que nunca se termina.
Arquitectura de información y wireframes: construir antes de decorar
Antes de pensar en colores o tipografías hay que decidir cómo se organiza el contenido y cómo se mueve el usuario por él. Esto es arquitectura de información, y se hace con wireframes, no con diseños bonitos.
Un wireframe en blanco y negro, con cajas y texto placeholder, sirve exactamente para esto: validar la estructura sin que nadie se distraiga discutiendo si el azul es muy azul. Figma se ha convertido en la herramienta estándar para esta fase porque permite trabajar en equipo en tiempo real, algo que antes costaba sangre con archivos sueltos por email.
Aquí es donde se decide el flujo del usuario: cuántos clics hacen falta para completar una acción, qué pasa si el usuario se equivoca, dónde están los puntos de fricción. Un dato que repetimos en el campus: cada paso extra en un formulario reduce la conversión. No es teoría, es algo que se ve en analítica de cualquier web real.
Diseño visual: donde entra la marca y el detalle
Aquí sí entran el color, la tipografía, el espaciado, la jerarquía visual. Pero todo esto tiene que apoyar la estructura ya validada, no inventarse encima.
El diseño visual en UX/UI no es decoración, es comunicación. Un botón que parece botón, un texto que se lee sin esfuerzo, un contraste que funciona para alguien con la vista cansada o con una pantalla de móvil barata bajo el sol. Esto suena básico pero es donde más fallan los proyectos: diseños preciosos en la pantalla grande del diseñador que se rompen en un móvil Android de gama media.
Los premios de la industria, como Awwwards, Webby Awards o CSS Design Awards, reconocen trabajos que combinan estética con funcionalidad real. No ganan los diseños más llamativos, ganan los que resuelven bien el problema y además tienen un acabado cuidado. Esa combinación es exactamente lo que buscamos enseñar: no basta con que algo quede bonito en Figma, tiene que funcionar cuando lo lleva a producción un desarrollador.
Prototipado y testeo: comprobar antes de construir
Un prototipo navegable te permite probar la experiencia antes de que un desarrollador escriba una sola línea de código. Esto ahorra dinero, tiempo y discusiones.
Con Figma puedes montar prototipos interactivos bastante completos: transiciones, estados, microinteracciones. No es lo mismo que el producto real, pero sirve para detectar problemas gordos antes de que cuesten caro arreglarlos. Hacer un test con cinco o seis usuarios reales, aunque sea informal, revela cosas que ningún diseñador ve solo mirando su propia pantalla durante horas.
Una cosa que vemos mucho en alumnos que vienen de otros campos: les cuesta aceptar que el usuario no entiende algo que para ellos es obvio. Pues bienvenido al mundo real. Si tres de cinco usuarios se pierden en el mismo punto, el problema no es el usuario, es tu diseño.
El handoff: el momento que define si tu trabajo sobrevive al desarrollo
El handoff es la entrega del diseño al equipo de desarrollo, y es donde se pierden más horas por falta de orden. Un diseño perfecto que llega mal documentado al desarrollador se convierte en un producto mediocre.
Figma, de nuevo, facilita esto con su modo de inspección: el desarrollador puede ver medidas exactas, colores en hexadecimal, espaciados, tipografías, todo sin tener que preguntarle al diseñador cada cinco minutos. Pero la herramienta no sustituye la comunicación. Un buen handoff incluye documentación de componentes, estados (hover, activo, deshabilitado), comportamiento responsive y casos límite.
Y aquí entra algo que en TRAZOS insistimos mucho: saber al menos los fundamentos de HTML, CSS y algo de JavaScript cambia radicalmente cómo diseñas. No hace falta programar como un desarrollador full stack, pero entender cómo se construye con React o cómo funciona WordPress te hace diseñar cosas que son posibles de verdad, no fantasías que luego el desarrollador tiene que rechazar.
Los roles reales detrás de este proceso
Este proceso no lo hace una sola persona casi nunca, aunque en proyectos pequeños toque hacer de todo. Las salidas profesionales que vemos con más frecuencia entre nuestros alumnos son diseñador UX/UI, diseñador de producto digital, diseñador web, desarrollador front-end, desarrollador full stack y maquetador web.
Cada rol pesa distinto según el proyecto y el tamaño del equipo. En una startup pequeña una sola persona puede llevar investigación, wireframes, diseño visual y parte del front-end con HTML y CSS. En empresas más grandes, como las que mencionan nuestros profesores que vienen de sitios como Ogilvy o Electronic Arts, los equipos están más especializados y el handoff se vuelve un proceso formal con herramientas y documentación específica.
Algunos de nuestros alumnos han acabado trabajando en sitios como IFEMA Madrid, Sego Finance o Fiscalges Alternative, llevando procesos completos de este tipo desde el brief hasta producción. No es magia, es seguir el proceso con cabeza y no saltarse pasos por prisa.
Si te interesa ver cómo se enseña este proceso de principio a fin, con Figma, HTML, CSS, JavaScript, React y Node.js incluidos en el programa, échale un vistazo al **programa de diseño UX/UI** en el campus de Chamberí. Se aprende haciendo, que es como de verdad se interioriza esto.
