En resumen
Desde la idea de un producto hasta su desarrollo, ¿cuál es el la función del diseño de UX y UI? Eso es lo que veremos en este artículo a través de un ejemplo de diseño de una aplicación móvil.
Este artículo forma parte de otro ⚠️
Si esta es su primera visita aquí, bienvenido 👋 . Ten en cuenta que este artículo forma parte de otro más global: Iniciarse en el diseño UX/UI, una guía completa. Aunque no es esencial, sigo recomendando empezar allí primero si eres nuevo en el diseño UX/UI.
Tabla de contenido
El contexto
Tomemos una nueva startup con una idea de una app de fitness disruptiva que, combinada con una IA, utilizaría la cámara de tu smartphone para analizar tus movimientos y así darte consejos de mejora en función de su calidad. Señalemos, y eso es importante, que se trata del primer producto de la startup y que no tienen datos de sus potenciales usuarios. Ten en cuenta que, en realidad, el siguiente ejemplo puede funcionar con la mayoría de las startups para las que su primer producto sería una aplicación móvil.
(Para información, hay una aplicación llamada “SwingVision” que hace esto para el tenis y recientemente, Peloton anunció un producto que hace lo mismo que mi ejemplo).
Sin entrar en todos los detalles sutiles de la gestión de proyectos, ya que haría falta un libro entero (o incluso varios) para hacerlo, veamos las líneas generales del proyecto.
Tened en cuenta que no todos los proyectos del mundo siguen este plan, yo os pongo un caso genérico, pero cada proyecto se adaptará en función de la demanda, los recursos, el tiempo, etc.
Nota: en los siguientes párrafos, hablaré de diseñador UX y diseñador UI para distinguir a dos personas, pero como se ha dicho en los artículos anteriores, la mayoría de las veces se trata de un diseñador UX/UI.
1 - Visión y lanzamiento
Todo proyecto comienza con una idea, una visión. Es desde este punto de inicio que entramos en el proceso. Sin una visión, no habría pinturas de Miguel Ángel, ni el primer viaje a la luna, ni Google.
El diseñador UX o UX/UI estará al principio de la proceso, y dependiendo de sus habilidades, puede ser llevado a la concepción del brief (o especificaciones) con el product owner (o PO, es el titular de la visión del producto en el método Agile), esto es a menudo el caso cuando hablamos de un product designer (ver product designer).
Este brief no tiene por qué adoptar la forma de un documento de 300 páginas, lo cual es posible en el caso de proyectos de gran envergadura, pero en general será uno (o varios) documentos compartidos en los que se describan, entre otras cosas: la visión, el problema a resolver y la solución prevista (más o menos precisa en esta fase). Es un documento importante que debe unir a los equipos en torno a una visión clara.
Una vez el briefing creado, se hace una reunión de inicio del proyecto con todo el equipo para asegurarse de que todo el mundo está alineado con la visión. Para los diseñadores, es importante obtener cuanto antes la opinión de los desarrolladores sobre las limitaciones técnicas para evitar hacer diseños que no sean viables.
2 - Diseño UX
En nuestro ejemplo, me estoy centrando en el diseño de la aplicación móvil, pero como recordatorio, el interés del diseñador UX es la experiencia del usuario con la startup en su conjunto (bueno, depende de si hacemos una diferencia con el diseño CX).
Basándose en el brief, el diseñador UX analizará los detailles y, si es necesario, consultará el PO para validar su comprensión. La buena comprensión del problema que el proyecto pretende resolver es crucial para el diseñador UX, cuanto mejor sea, mejor será la solución.
El objetivo principal del diseñador UX es identificar las necesidades de los usuarios finales y armonizarlas con el producto y la visión. En cuanto al producto en sí mismo, se describe en el brief, pero por supuesto va evolucionando a lo largo de la fase de UX y UI (y globalmente, durante la vida de la empresa).
A continuación, aplicará diferentes técnicas del campo de la UX y, como ya se ha dicho, sería imposible decir cuáles son las que se utilizan en todos los casos, ya que depende del proyecto, del tiempo, del presupuesto y de las habilidades del diseñador.
Sin embargo, idealmente para nuestro ejemplo, los pasos serían los siguientes:
2.1 Entrevistas con los usuarios
Si para nuestra startup no fuera su primer producto, lo más probable es que ya tuviera datos sobre sus usuarios que pudiera aprovechar. Como no es el caso, el primer paso será entrevistar (cara a cara o en línea) a una selección de clientes potenciales para entender mejor sus comportamientos y expectativas.
2.2 Definición de persona
A continuación, el diseñador UX procederá al análisis de los datos de la fase de investigación anterior. Sintetizará dos-tres (o más si es necesario) perfiles típicos de usuario y creará un personaje para cada uno. Son útiles para todo el equipo, permite tener en mente quiénes son los usuarios de nuestro trabajo. Para el equipo de UX, por supuesto, pero también para el equipo de marketing, para establecer campañas adaptadas a los usuarios.
2.3 Scenario map
Ahora que hemos definido a nuestros usuarios y creado personajes, es el momento de “jugar” con ellos y ver cómo pueden evolucionar en el producto.
Con los actores del proyecto, el diseñador UX definirá las acciones de los usuarios en función de sus objetivos recogidos en los personas. Estas acciones se llaman los “User stories”, por ejemplo en nuestro caso, una podría ser: “Como usuario, quiero recibir una formación personalizada para progresar de forma óptima para mí”. El scenario map enumera los pasos en el futuro producto para realizar todas las acciones del usuario, y para cada paso, los equipos enumerarán ideas de diseño, preguntas y comentarios a tener en cuenta.
2.4 User flows
Una vez que hemos definido todas las acciones del usuario con sus escenarios, es el momento de articularlas con la lógica entre ellas en un user flow. En esta parte, la contribución de los desarrolladores es esencial. El user flow es útil tanto para los diseñadores como para los desarrolladores para tener una visión global de la estructura y la lógica de la aplicación.
Hay que tener en cuenta que antes de este paso podemos hacer story maps, que son parecidos a los scenario maps pero que entran en más detalle sobre las acciones del usuario, una especie de “pre user flow” en definitiva.
2.5 Wireframes
En esta fase, el diseñador UX definirá la estructura de las pantallas que se perfilan en el user flow. El wireframe, sin diseño UI, mostrará la visión del diseñador UX sobre la distribución de los elementos (imágenes, títulos, botones, etc.) que considere más adecuados para el proyecto.
Nota: también podría hacer primero una zonificación (o “blockframe”) para obtener la aprobación antes de dedicar tiempo al wireframe.
El wireframe se hace sin los textos o el mínimo, en general son otras personas ( copywriter, marketing, PO, etc.) quienes los escriben, pero el diseñador UX puede participar.
2.6 Tests internos y con usuarios
Si el tiempo lo permite, es aconsejable hacer tests con usuario (dependiendo del wireframe, si es demasiado abstracto puede ser contraproducente).
Para eso, el diseñador UX habrá realizado un prototipo que pueda ser utilizado con los wiframes (por ejemplo, los botones serán clicables) y podrá recoger las observaciones de los usuarios mientras navegan en el producto.
Y sobre todo, el wireframe debe ser validado por todos los actores del proyecto, esto es importante antes de pasar a la fase de diseño UI. Si más tarde, durante la fase de UI o incluso durante el desarrollo, descubrimos fallos importantes en la UX, a la startup le costará más corregirlos que ahora.
3 - Diseño UI
Una vez validada la UX, puede comenzar la UI. Hay que tener en cuenta que el diseñador UI, para optimizar el tiempo, puede empezar a trabajar antes de que la fase de UX esté terminada. En el primer paso (3.1) y en menor medida en el segundo (3.2) (en partes del wireframe ya validado).
3.1 Investigación y moodboard
La creatividad se alimenta de trabajos existentes, por lo que el diseñador UI buscará inspiración en diseños que pueden ponerse en un moodboard. Se recomienda elaborar al menos dos de ellos con estilos diferentes y presentarlos a los responsables del proyecto para obtener su opinión.
3.2 Bocetos
Antes de empezar con tu herramienta digital, recomiendo especialmente hacer primero bocetos de la UI a mano, que se basan en los wireframes del diseñador UX y describen su contenido con más detalle. No soy el único que lo ha notado, pero en esta fase somos más creativos con un lápiz (o un lápiz digital) que con un ratón.
3.3 Construcción de la styleguide
Es una guía visual y textual de los elementos que componen la UI, tales como: colores, tipografías, tamaños de espaciado, iconos, ilustraciones, la forma de los botones, formularios, animaciones, etc. Se comparte con los desarrolladores, por ejemplo con ZeroHeight.
De hecho, esta parte se realiza a lo largo de los siguientes pasos, vamos de un lado a otro todo el tiempo. Sería contraproducente intentar hacer todo la styleguide por un lado sin probarlo en las pantallas de la aplicación.
En un sentido más amplio, la styleguide forma parte de una estructura mayor: el design system. Este sistema consiste en proporcionar y mantener la coherencia global del fondo y la forma de los diseños producidos por la empresa. Es una fuente central de conocimiento, compuesta, por ejemplo, por la visión de la empresa, las indicaciones sobre las elecciones de marketing (tono, vocabulario, etc.), el diseño (styleguide) y el código (convención de notación, tecnologías, etc.). Se comparte con todos los actores de los productos de la empresa. Buenos ejemplos son los de Decathlon e IBM.
3.4 Mockups y prototipos
“Si una imagen vale más que 1000 palabras, un prototipo vale más que 1000 reuniones.” - IDEO
El mockup son los bocetos limpios, los wireframes con el diseño final. El prototipo es el acto de hacer que las pantallas del mockup sean interactivas, es la piedra angular de nuestro proceso, el clímax de los pasos anteriores de UX y UI y será la base para los tests con los usuario y el trabajo de los desarrolladores.
En pocas palabras: el diseñador UI mejorará los wireframes con colores, tipografía, iconos, botones, imágenes, etc. Y los hará interactivos. Hace unos años, hacer un prototipo clicable no era una tarea fácil, pero desde la llegada de herramientas como Sketch, Figma o Adobe XD, ahora es mucho más sencillo, y sin hacer nada de código.
3.5 Tests internos y con usuarios
Antes de que los desarrolladores comiencen sus tareas, el diseñador UI probará el prototipo con los usuarios potenciales para ver si hay algún bloqueo o dificultad. También se prueba con los responsables del proyecto (incluidos los desarrolladores, por supuesto) para que todos estén alineados. Una vez más, las herramientas mencionadas anteriormente facilitan la colaboración al ofrecer la posibilidad de compartir un enlace del prototipo con todos y comentarlo.
Si hay una regla de oro en los tests con los usuarios, sería ésta: es mejor arreglar los problemas donde es más barato. Es decir, en el prototipo que en el producto desarrollado (es más sencillo y, sobre todo, menos costoso mover los botones en un prototipo que en el producto desarrollado).
Se trata de una fase crítica y, aunque no se le dedique suficiente tiempo, puede bastar con los tests internos. Pero esta fase está ahí para evitar en lo posible los cambios de última hora en la aplicación cuando estamos en la fase de desarrollo.
3.6 Preparación para los desarrolladores
Los programas antes mencionados también permiten hacer lo que se denomina “handoff” para los desarrolladores, es decir, facilitarles el trabajo. Exportaremos assets como ilustraciones e iconos a los tamaños adecuados, documentaremos la styleguide indicando las reglas que hay que respetar (espaciado, contrastes, animaciones, etc.) o comentaremos el prototipo con cualquier observación que les evite tener dudas sobre nuestra visión.
4 - Desarrollo
Los desarrolladores hacen su trabajo. Pero los diseñadores nunca están lejos, porque seguramente tienen algunas observaciones para ellos y es probable que trabajen con el método Agile (más adelante veremos los métodos de gestión de proyectos). Por lo tanto, para optimizar el tiempo, el director del proyecto habrá planificado las tareas del diseñador UI para que los desarrolladores empiecen a trabajar cuando una o varias funcionalidades estén prototipadas, probadas y validadas. Y mientras ellos desarrollan, el diseñador UI sigue con el prototipo de la siguiente funcionalidad.
Luego, una vez terminada, se lanza la versión 1 en producción. Pero no todo se detiene ahí, los productos evolucionan constantemente y, muy rápidamente, volvemos al principio del proceso en función de los comentarios de los usuarios para mejorar el producto. Por ejemplo, los equipos de Adobe XD han abierto una cuenta en uservoice.com. Los usuarios pueden enviar sus ideas para nuevas funciones y votar las que más les gusten (adobexd.uservoice.com).
(Bueno, llevan cinco años pidiendo un tema oscuro, porque sí, es una gran paradoja, una aplicación de diseño UX/UI que sólo tiene un tema claro…)
Para continuar con su impulso
Como se mencionó al principio de este artículo, es parte de un conjunto más amplio, para continuar es por aquí.
Doko Zero
Diseñador UI con conocimientos de UX y desarrollo web