Cómo diseñar una barra de navegación paso a paso
Tags: ux, design, uxresearch, ui
Published: 2021-03-17 11:12:16

Cuando  pensamos en aumentar la satisfacción de nuestros usuarios en ocasiones puede resultar más tentador imaginar una nueva y flamante funcionalidad que volver la mirada a los básicos de nuestro producto. 

Sin embargo, como ux designers sabemos que pocas cosas pueden tener un **impacto** más **global** en un producto digital que su navegación. ¿Por qué?

* Es transversal, está presente en todo el producto.
* Es el GPS que pones a disposición de los usuarios para que sepan donde están y lleguen a donde quieren llegar.  
* Es un facilitador para cumplir objetivos de negocio, ya que te permite destacar funcionalidades alineadas con ellos. 

En Milanuncios sabíamos que teníamos una deuda de ux en este terreno así que nos sentamos para ver cómo podíamos priorizar este proyecto y mejorar la experiencia de navegación de nuestros usuarios. 

¿Quieres saber cómo lo hicimos? ¡Sigue leyendo!

# Fase de Research

El primer paso era actualizar nuestro **Inventario** para poder estimar el alcance de esta deuda de usabilidad. 

Gracias a este ejercicio analizamos las particularidades de las 7 barras de navegación y menús laterales diferentes que teníamos en **desktop**. Además recogimos todas las páginas donde el usuario podía sentirse atrapado por la carencia de alguno de estos elementos de navegación. 

En **mobile** en cambio teníamos una única barra de navegación pero con una iconografía que no se correspondía con la del resto de la plataforma y por tanto resultaba confusa. Esto sumado a que la interfaz no respetaba la distancia de seguridad necesaria en móvil entre elementos accionables daba lugar a una alta tasa de rebote. Es decir, teníamos un montón de personas queriendo entrar a la funcionalidad X que por error entraban en la Y. 

Quedaba así claro que nuestro **primer objetivo** sería **unificar** la experiencia de navegación y eliminar los callejones sin salida detectados en el inventario. 

Este ejercicio también sirvió para poner sobre la mesa que íbamos a tener que trabajar con **tres tecnologías** diferentes para cambiar nuestra barra de navegación en toda la plataforma: React, Twig y nuestro monolito de php. Esto aumentaba el nivel de ambición y nos obligaba a fasear el proyecto para alcanzar nuestra meta. 

El siguiente paso era analizar el ámbito del problema desde varios **enfoques** muy diferentes que incluían a distintos stakeholders para tener una visión 360º.  Para ello organizamos las incógnitas a resolver en **4 capas**:

1. Estrategia y objetivos de negocio
2. Marco tecnológico
3. Datos de uso
4. Usabilidad

A nivel de **estrategia**, la barra de navegación actual no invitaba ni a loguearse ni a registrarse a los usuarios, con lo que estábamos perdiendo la oportunidad de mostrarles las ventajas que esto puede suponer para ellos. 

Por otro lado, desde el punto de vista de **negocio** surgía la necesidad de dar a conocer nuestro servicio de envíos puerta a puerta. 

En esta capa estratégica también nos sentamos con nuestro experto en **SEO** para ver las implicaciones de cambiar nuestra barra de navegación. A pesar de ser un elemento “invisible” hemos de tener claro que si queremos que nuestro producto tenga éxito siempre debemos prestarle atención.

En cuanto al **marco tecnológico**, ahora que ya sabíamos que trabajaríamos con React, Twig y php nuestra mayor preocupación era entender cómo podían afectar al rendimiento cada una de las soluciones posibles. 

Pero también debíamos averiguar si existían limitaciones a la hora de propagar los datos de una tecnología a otra y cuánta lógica íbamos a poder incorporar a nuestra barra de navegación en sus primeras iteraciones. Por ejemplo, ¿íbamos a poder enviar notificaciones sobre los mensajes o las alertas directamente en la barra de navegación?

Para resolver este tipo de  dudas y llevar el proyecto a buen puerto fue vital trabajar mano a mano con el equipo frontend durante todo el proceso. 

A nivel de **datos de uso** el primer paso fue repasar nuestro tagging plan con el equipo de Data y ver si algún elemento clave no estaba siendo medido. Una vez que tuvimos toda la información cuantitativa necesaria, analizamos cómo los usuarios se movían de una página a otra teniendo en cuenta el tráfico total de cada una. Pudimos trazar así  el viaje que realizaban los usuarios al navegar por Milanuncios y entender qué funcionalidades eran más relevantes y cuáles podían estar demasiado escondidas en el sistema actual. 

Por último, en cuanto a **usabilidad** empezamos a hacernos preguntas como qué mejoras de accesibilidad podíamos realizar con la barra de navegación o cómo iba a cambiar ésta la relación entre el área de gestión de anuncios y el perfil de usuario. 

Durante mucho tiempo el perfil de usuario había formado parte de un menú de segundo nivel dentro del área de gestión de anuncios. Sin embargo con la incorporación de mejoras como la foto de perfil o la verificación del correo electrónico, había llegado el momento de darle más relevancia. Esto apuntaba a un cambio de jerarquía en el futuro menú de nuestra barra de navegación. 

En paralelo a esta investigación dividida en 4 capas no podíamos olvidarnos de mirar hacia fuera. 

Realizamos un **benchmark competitivo** que incluía: desde la competencia más directa a gigantes de referencia como Amazon o Ebay, pasando por especialistas en distintos campos. Un total de más de 30 portales a estudiar para recoger posibles **expectativas** y entender el **modelo mental** que nuestro segmento de usuarios podía tener a la hora de navegar por cualquier sitio web. 

* ¿Qué elementos son los más repetidos? 
* ¿Cuales están presentes cuando el usuario está logueado? 
* ¿Cuales desaparecen si no tienes cuenta? 
* ¿Qué adaptaciones se realizan para un diseño responsive?

Además de resolver estas dudas pudimos empezar a tomar **decisiones de diseño**. Descubrimos por ejemplo que el logo de Milanuncios tenía un tamaño muy por encima de la media del mercado. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ml1rjgi5p0rlthj9a8a8.jpg)

Si bien su presencia en la barra de navegación es vital como **elemento de branding** sabemos que el espacio en pantalla es extremadamente valioso.  Así que redujimos a un tamaño óptimo su ancho en desktop y en mobile optamos por hacer uso de nuestro avatar y ganar terreno para los elementos funcionales.

# Fase de Diseño

Ahora sí, había llegado el momento de empezar a construir. 

¿La barra de navegación de nuestros sueños? 

No, una que nos permitiera aprender todavía más. Para ello realizamos un **test a/b/c** en web mobile con el objetivo de validar hipótesis y tener datos reales de lo que podía ser la curva de aprendizaje de nuestros usuarios. 

Optamos por enfrentar los actuales 3 iconos a dos variantes de menú con un solo nivel de opciones. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2zzkbhyq0utu4yrrg12p.jpg)

Gracias a este experimento pudimos validar la hipótesis de que era posible añadir un paso más a nuestro flujo de navegación sin que supusiera una caída en los accesos. 

También vimos reforzada nuestra teoría de los accesos erróneos puesto que en ambas variables obtuvimos un número mayor de accesos totales respecto al original, pero con los porcentajes claramente redistribuidos. 

En cuanto al menú hamburguesa y el botón “Menú”, no obtuvimos un claro vencedor lo que nos invitaba a seguir explorando soluciones de diseño. 
 
Por fin podíamos diseñar una barra de navegación más cercana a nuestro ideal y empezar a ponerla a prueba. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e928g0lucaaixvwl4yqm.png)

Organizamos un **test de usabilidad** y seleccionamos dos tipos de perfil: usuarios y no usuarios de Milanuncios. De este modo, no solo podríamos validar si aquellas personas que ya conocían la plataforma se adaptaban a la nueva navegación sin problemas sino que también podríamos ver si alguien que usaba la plataforma por primera vez la entendía. 

El test giraba en torno a 5 tareas que incluían desde publicar un anuncio a eliminar una cuenta y que obligaban a los participantes a recorrer el menú de dos niveles que habíamos prototipado de forma exhaustiva.

Con los insights obtenidos pudimos tomar decisiones como por ejemplo simplificar nuestro menú a un único nivel. Los elementos que habíamos ubicado en el submenú no tenían importancia suficiente para los participantes como para añadirle complejidad al código, al tracking y al usuario. 

También descubrimos el mejor lugar para ubicar el cierre de sesión. En nuestro prototipo habíamos optado por probar una de las ubicaciones menos estándar entre los patrones que habían aparecido durante el benchmark. Sin embargo, la última posición del primer nivel se destacó como el lugar idóneo para colocarlo. Era el primer sitio al que se dirigían los participantes del test para buscarlo. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/glbttvt9on7y70rq4txu.png)

# Salida a producción

Una vez que se compartieron los resultados del test de usabilidad con todo el equipo pudimos trazar un **roadmap** y planear el despliegue de la nueva barra de navegación. 

Decidimos fasear la salida en dos **iteraciones**. 

Primero incorporamos la barra de navegación dejando que conviviera con el antiguo menú lateral aunque algunos accesos se vieran duplicados. De este modo,  podíamos realizar un sanity check técnico con menos riesgo en caso de que algo fallase y empezar a observar si los accesos de los usuarios se desplazaban a nuestra barra de navegación.

Una vez que confirmamos también que todas las métricas eran estables pusimos en marcha la siguiente iteración. Eliminamos los menús duplicados tanto en desktop como en web mobile y reubicamos las opciones que antes sólo estaban disponibles en dicho menú dentro del área de gestión de anuncios. 

# Análisis de resultados

Dos semanas después de esta segunda iteración empezábamos a ver el **ROI** de nuestro trabajo:

**Multiplicamos por cinco** los accesos al perfil del usuario en general sin que bajaran los accesos al área de gestión de anuncios. 

**Aumentamos un 15%** los usuarios únicos logueados en el móvil. 

Manteníamos  estable nuestra métrica de salud de número de anuncios publicados nuevos. 

Unos datos que nos indicaban que el trabajo debía continuar. Quedaban en nuestro roadmap al menos 3 mejoras a realizar que estábamos deseosos de realizar:

* Mostrar notificaciones de los mensajes recibidos en el chat
* Loguear al usuario en la propia página en la que se encuentra en lugar de mandarle a otra.
* Mostrar la foto del perfil en lugar de un placeholder.

Si tú también quieres ver cómo continúa esta historia, no nos pierdas de vista. 

¡Seguiremos iterando!