Mi proceso de diseño en 6 pasos + entregables
¿Qué es lo que todo el mundo hace en diseño… pero todo el mundo hace distinto?
Exacto, el proceso de diseño.
Hay muchas maneras de afrontar un proyecto y todas dependen del tipo de proyecto, del cliente, del presupuesto y el tiempo, de las circunstancias… por esto, y para que pueda servir como guía, he querido compartirte mi proceso, indicando también qué se entrega en cada fase.
Vaya por delante que es mi «ideal» y que, como decía antes, no puedo cumplirlo siempre… pero tenerlo me ayuda a clarificar cómo voy a afrontar el proyecto (tanto para mí misma como para mis stakeholders).
Entiende (de verdad) el problema
A menudo inicio el proyecto con briefing inicial que, para bien o para mal, suele ser bastante breve: «hay que rediseñar la web» o «hay que añadir [X] funcionalidad nueva».
Es mi trabajo utilizar esta frase inicial para empezar a buscar información. Suelo nutrirme de:
- Datos cuantitativos, habitualmente extraídos de informes de Google Analytics y Power BI y otros datos de negocio que estén en manos de Product Owners o de cada equipo.
- Datos cualitativos. En este caso se trata de invertir tiempo en investigar con usuarios, hacer entrevistas, shadowing…
En resumen, aquí se trata de poder comprender mejor qué se esconde detrás de un «hay que rediseñar la web». Puede ser un problema de conversión en una página en concreto, o un diseño o arquitectura que los usuarios no comprenden.
Empezar a diseñar sin comprender bien qué se pide es un error. Aún en el caso de que me den toda esta información, entra dentro de mis tareas comprenderlo bien y hacer las preguntas necesarias para que quede muy claro qué se pide y cuáles son las expectativas.
Si se trata de una funcionalidad nueva para la que no existan datos dentro de la propia empresa, la alternativa es utilizar estándares dentro del sector, mejores prácticas, estudios de caso, principios de UX y otros principios que permitan comprender mejor qué está fallando actualmente (aún sin tener números).
El entregable
En este paso lo que suelo entregar es un documento de Google Slides con los datos y las conclusiones obtenidas. En algunos ocasiones va acompañado de grabaciones en Hotjar, capturas o Google Spreadsheets si hay muchos datos que observar.
Elabora una hipótesis
Con toda la información en mi mano, y habitualmente en colaboración con el equipo de diseño y Product Owner escribimos una hipótesis.
Por poner un ejemplo: «Modificando el diseño de la página [x] priorizando [y] y mejorando [z] mejorará la conversión de la página«.
Tan fácil y tan difícil… pero te aseguro que esta hipótesis estará sesgada si en el paso anterior no te tomas el tiempo de buscar datos y de procesarlos en tu cabeza para comprender bien qué está pasando actualmente.
El entregable
En este caso lo más cómodo es añadir esta hipótesis al documento del paso anterior o incluirla en la historia de Jira que creamos en el sprint. De este modo actúa de guía que puede consultarse fácilmente durante el proceso de trabajo.
Contenido, wireframes y prototipos
Cuando llego a esta fase es cuando me pongo manos a la obra: ya sé hacia dónde me dirijo y todos los stakeholders están alineados con lo que se va a hacer.
Habitualmente empiezo hablando con el equipo de marketing o con quien se encargará de elaborar los contenidos. Aquí hay dos formas de trabajos:
- A veces planteo primero una estructura preliminar en la que especifico qué bloques de contenido y en qué orden tendría sentido explicar qué. Normalmente funciona hacerlo así si la página ya existe y hay que revisarla.
- En otras ocasiones me llega un documento con los contenidos con el que trabajo para preparar los wireframes.
En cualquier caso, en esta fase se trata de ir «peloteando» de un equipo a otro mostrando la propuesta y alineando todas las visiones lo mejor posible.
Los wireframes los planteo con las resoluciones de las que tenemos más visitas, para asegurar que un alto porcentaje de nuestros visitantes verá bien el contenido. En mi caso particular, hablamos de 360×640 en móvil y 1336×768 en ordenador.
Cuando existe consenso y se han ajustado varias veces contenido y wireframes -con el equipo de marketing, desarrollo, Product Owners…- preparo un pequeño prototipo (normalmente directamente con Figma) y se usa para hacer la «última» presentación de esta fase.
Y sí, presentamos sin diseño 😉
Los entregables
Aquí suelo entregar un enlace de Figma hacia un prototipo o hacia los wireframes. En algunas ocasiones utilizo Kap para grabar la interacción con el prototipo y poder adjuntarlo fácilmente en algún canal de Slack.
Cuando hagas esto piensa en quién va a consultar lo que envíes: esa persona puede no estar familiarizada con Figma o tus herramientas, así que no la marees con enlaces y logins que seguramente no necesita.
Es la hora de… diseñar
Con todo el trabajo, información y feedback recogido en los pasos anteriores, me pongo a diseñar. Habitualmente es la fase en la que invierto menos tiempo: el UI suele depender de un Sistema de Diseño de una estética bastante definida, así que no hay mucho que reinventar.
Así que, en general me paso más tiempo pensando la estructura y wireframes del paso anterior, porque es donde reside la complejidad.
En cualquier caso, una vez está hecho el diseño se hace una presentación del proyecto. Esta parte suele ser importante si implica grandes cambios en el UI. Si es «más de lo mismo» es una presentación bastante breve.
El entregable
Es prácticamente lo mismo que el paso anterior: un enlace a Figma o, dependiendo de cómo vaya a mostrarse, lo exporto en jpg o incluyo en un Google Slides en el que explico qué pretende solucionar la propuesta, cómo y por qué este diseño puede valer.
Acompañar al equipo de desarrollo
Cuando se da por terminado el diseño es hora de desarrollar. Suelo compartirles en enlace de Figma para que tengan acceso al archivo original del diseño, puedan descargar assets y comprobar CSS, alineaciones, espaciados…
A medida que va avanzando el desarrollo voy comprobando lo que se va subiendo al entorno de test, para poder dar feedback al momento e ir iterando poco a poco para obtener un resultado que se ajuste lo máximo posible al diseño.
Como te decía en párrafos anteriores, el equipo de desarrollo ya sabe qué se está desarrollando y por qué, ya que han estado en las fases anteriores.
El entregable
Como te decía en párrafos anteriores, para el equipo de desarrollo suele ser suficiente enviar un enlace de Figma: con el panel de «Code» pueden ver fácilmente cómo es (o podría ser) el CSS del diseño y exportar assets de forma sencilla. Cuando utilizaba Sketch lo complementaba con Zeplin, pero ahora ya no es necesario 🙂
Pero… ¿funciona?
Como diseñadora, no puedo desentenderme del proyecto una vez está desarrollado y lanzado a producción. También es mi trabajo comprobar que la hipótesis se cumple.
Para hacerlo, suelo utilizar Google Optimize para hacer tests A/B o de redirección. Si es un lanzamiento de una página o producto nuevo hay que definir bien qué se quiere medir y pedir un dashboard para controlar cómo va funcionando la propuesta.
Pasado cierto tiempo (normalmente dos semanas, pero depende del tráfico y a veces se alarga más) es el momento de revisarlo todo y elaborar otras hipótesis, mejorar la propuesta o dejarla como está 🙂
Conclusiones
Como te decía al inicio, no existe un proceso de diseño estándar y depende mucho de las circunstancias del proyecto y del equipo.
El proceso que te he contado aquí es el que he construido a lo largo de los años y nace de mucha prueba y error. De hecho, más errores que otra cosa.
Pero por ahora me funciona bien, porque me permite explicar «qué» hago y el resto del equipo y stakeholders saben más o menos qué esperar de mi. No olvides que por mucho que tú tengas claro qué haces y por qué, el diseño sigue siendo una disciplina «extraña» y bastante nueva. Nos pese o no.
Y tú, ¿qué proceso de diseño sigues?
Imagen de portada: The Design Squiggle