Hace unos meses nos enfrentamos a un reto que, en apariencia, parecía sencillo: implementar un menú de usuario para nuestra plataforma.
Lo que comenzó como una implementación rápida pa tirar millas, se convirtió en un proceso de iteración donde creemos haber conseguido traer a nuestro caso particular patrones que consideramos buenas prácticas en la industria. Todo pasito a pasito, con mucho trabajo de equipo, y sobre todo disfrutando del camino.
En este post os contamos todo el proceso: desde las primeras ideas hasta la implementación final, pasando por los debates internos, las referencias que analizamos y las decisiones que tomamos en cada paso.
🌱 El punto de partida: Backend intentando centrar un div
Aunque parezca mentira, después de 10 años no teníamos un menú de usuario en nuestra web. Lo único que teníamos era el menú de usuario de la plataforma que usamos para los cursos, y las necesidades que veíamos que teníais los usuarios de Codely por el feedback que nos dais.
Para cubrir esta necesidad, se implementó un primer prototipo funcional y minimalista. El objetivo era tener algo funcional rápido, validar que cubría las necesidades básicas, y usarlo como base sobre la que iterar.
Primera versión, funcional pero muy simple
Esta versión funcionaba y cumplía su propósito. Pero era "un menú más":
- Le faltaba cariño visual de intentar ir un pasito más allá
- No se integraba con la identidad visual del resto de la página por no seguir el Design System
- Desaprovechaba el potencial de un elemento tan crítico como un menú de usuario, más allá de agrupar enlaces
🎨 Integración con el sistema de diseño
Con la funcionalidad básica validada, era momento de darle un empujón visual. Teníamos un prototipo en Figma que mejoraba el diseño del componente hasta acercarse más al resto de elementos de la aplicación.
Mockup en Figma
Aunque tenía buena pinta de forma aislada, había cositas que no terminaban de encajar. Especialmente después de años usando nuestro Design System.
Vimos que algunos elementos visuales nuevos (como sombras demasiado pronunciadas) rompían la consistencia con el resto de la aplicación. Quedaban bien en el componente aislado, pero desentonaban con el sistema de diseño que llevábamos usando años.
El primer aprendizaje: tener en cuenta la cohesión visual con el resto de nuestra aplicación.
🛠️ Primera iteración: Un paso adelante, pero mucho camino por recorrer
Con un diseño a seguir (a pesar de tener detalles que nos chirriaban), nos pusimos manos a la obra. El objetivo era tener algo production ready que empezase a sentar unas bases sólidas.
Menú cerrado mostrando avatar
Menú abierto tapando el avatar inicial y mostrando uno nuevo dentro
Con estos cambios, se empezaba a ver el potencial de lo que podría llegar a ser.
Pero aún quedaban muchas cosas por pulir. Sobre todo, había un detalle que se haría evidente más adelante: no habíamos pensado lo suficiente en las oportunidades de conversión.
🔍 Aprendiendo de aquellos que ya se han enfrentado al mismo problema
Antes de continuar iterando a ciegas, decidimos algo que resultó ser clave: analizar cómo lo hacían productos que admiramos.
Esta fase de investigación fue fundamental para entender patrones comunes y buenas prácticas. Y para evitar caer en reinventar (mal) la rueda.
Supabase
Lo que nos gustó:
- No solapa el modal con el trigger. Evita confusión visual.
- Asume que si ves tu avatar, sabes que ahí hay configuración
Lo que no nos convenció:
- Demasiado minimalista, no integra elementos que aprovechen este tipo de componentes
- No aprovecha el espacio para información útil
Menú de usuario de Supabase
Retool
Lo que nos gustó:
- Muestra información relevante (rol del usuario)
- Indicador de desplegable claro
Lo que no nos convenció:
- Repetir el avatar dentro del menú resulta redundante
Menú de usuario de Retool
Raycast
Lo que nos gustó:
- Animación sutil en hover
- Menú limpio y fácil de entender
Lo que no nos convenció:
- Demasiado minimalista, no integra elementos que aprovechen este tipo de componentes
Menú de usuario de Raycast
Otras inspiraciones que confirman nuestros aprendizajes
También analizamos otros productos, aunque ya empezábamos a notar patrones que se repetían.
Menú de usuario en Vercel
Mockup de menú de usuario encontrado en la comunidad de Figma
Los patrones que identificamos
Después de analizar múltiples productos, identificamos varios patrones comunes que nos interesaba empezar a aplicar:
- Agrupación de elementos
- Acción destructiva separada
- Iconografía estándar
- Información contextual
🔄 Aplicando los patrones identificados
Con estas referencias claras, era momento de implementar una versión más pulida.
No se trataba solo de copiar lo que hacían otros, sino de adaptar las mejores prácticas a nuestro contexto específico.
Agrupar elementos relacionados entre sí
Empezamos a organizar el contenido del dropdown en secciones lógicas:
- Información del usuario (nombre, email, badge de plan)
- Navegación principal (mis cursos, perfil público, ajustes)
- Acción destructiva (cerrar sesión)
Empezamos a incluir el tipo de suscripción en el menú
Separar la acción destructiva
Siguiendo un patrón muy extendido, "Cerrar sesión" va separado del resto de opciones. Un separador visual claro indica que es una acción diferente.
Asumir que el usuario no es tonto
Eliminamos redundancias innecesarias que solo añadían ruido:
- Quitar "Sesión iniciada como": Si ves tu avatar, ya sabes que estás logueado
- No mostrar email ni nombre junto al avatar cuando el dropdown está cerrado: El avatar ya es suficiente indicador
- Mostrar la información relevante solo cuando es necesaria
Con el avatar es suficiente para saber que ahí está el menú de usuario
Usar iconografía estándar
Cambiamos a iconos que los usuarios ya hayan podido ver en otras aplicaciones:
- Rueda dentada para configuración/ajustes
- Puerta con flecha para cerrar sesión
- Código para "Mis cursos"
Esto hace más intuitivo el uso del menú, permitiendo que nuevos usuarios puedan adaptarse rápidamente.
Aprovechar el dropdown para mostrar información contextual
Y aquí llegamos a una de las mejoras que más nos interesa: aprovechar el menú como oportunidad de conversión.
CTAs contextuales
El menú de usuario es uno de los elementos más visitados de cualquier plataforma en el día a día. Parece tener sentido aprovecharlo para mostrar acciones relevantes según su situación específica.
En lugar de mostrar siempre el mismo contenido estático, decidimos personalizar el menú según el estado de suscripción del usuario. Sugiriendo lo que consideramos son los pasos lógicos en el user journey.
Usuario no suscrito, mostramos CTA para adquirir un plan
Sub Lite, mostramos CTA para que puedan acceder al catálogo completo del plan Standard
Sub Standard, mostramos CTA para que puedan acceder a los cursos exclusivos Premium
Sub Premium sin CTA de upgrade, dado que es el plan más completo del que disponemos a día de hoy
Sub con renovación desactivada, con CTA para reactivar la renovación automática. Aún tienen acceso a los cursos, pero lo perderán al agotar la duración que les quede
⚠️ Transmitir urgencia desde el diseño
Este último caso es especialmente crítico desde el punto de vista de negocio: son usuarios que ya han tomado la decisión de cancelar, pero aún están utilizando la plataforma. Es nuestra última oportunidad de convencerlos a quedarse antes de que pierdan el acceso completamente. Un momento clave para la retención de usuarios.
Sin embargo, el diseño no estaba ayudando a transmitir la importancia que queríamos darle. Parecía un CTA más, con la misma relevancia que el resto.
El problema del banner blindness
Aquí nos topamos con un patrón de comportamiento que no habíamos tenido en cuenta hasta ahora: si dos CTAs se parecen visualmente, el usuario puede tender a ignorarlos por costumbre. Como cuando ignoras banners publicitarios sin darte cuenta.
Vimos que el CTA de reactivación, al ser visualmente similar a otros CTAs del menú, podía pasar desapercibido. Y este era precisamente el CTA más crítico para nosotros.
La solución: Usar un diseño visual completamente diferente para este CTA en concreto 👇
- Fondo amarillo con patrón zebreado (tipo alerta/obras)
- Texto más urgente: "Perderás acceso en X días"
- CTA más directo: "Reactivar" en lugar de "Renovar"
Estilamos el CTA de renovación con un estilo diferente que transmita urgencia
🏷️ No abusar de los CTAs
Un aspecto importante que tuvimos que resolver durante esta iteración fue cómo mostrar el plan del usuario sin que se confundiera con los botones interactivos.
Inicialmente reutilizamos el componente Pill de nuestro Design System (el mismo que usamos para filtros). Pero esto creaba un problema de UX: los usuarios podían pensar que podían hacer clic en el badge del plan para realizar alguna acción. Dado que nuestra intención era informar, estaba claro que estábamos usando la herramienta incorrecta para resolver el problema.
El badge de tipo píldora sugiere interactividad, confundiendo al usuario
Esto hizo necesario crear un componente Badge específicamente para información no interactiva, con:
- Diferente border-radius para distinguirlo visualmente de los botones
- Colores específicos usando las variaciones de producto del Design System
- Cumplimiento de WCAG con ratio de contraste de al menos 7:1
Mostramos el plan actual con un estilo distinto a los CTAs
Mantenemos los colores del sistema de diseño mientras aseguramos la legibilidad
De esta forma, mantenemos la coherencia visual pero evitamos la confusión entre elementos informativos (badges) y elementos interactivos (botones y píldoras).
📱 Diseño móvil: equilibrando UX y accesibilidad
El diseño para móvil vino con desafíos propios de diseñar primero pensando en escritorio. La pregunta principal era: ¿dónde colocar la apertura del menú?
Primera versión donde el avatar estaba pegado al menú hamburguesa
Las opciones que evaluamos
- Avatar a la derecha, menú hamburguesa a la izquierda: El menú hamburguesa queda lejos del pulgar, pero es una posición común. Aplicaciones como Gmail usan este layout.
- Avatar a la izquierda, mantener menú hamburguesa a la derecha: Menú hamburguesa más accesible al pulgar, pero dificulta acceder al menú del usuario. Además, es un layout menos usado.
- Unificar todo en el menú hamburguesa: Es como hacen Vercel y otros de la industria, pero perderíamos acceso rápido al menú de usuario.
Decisión final: Mover el menú hamburguesa a la izquierda, mantener el avatar a la derecha, y centrar el logo en el medio.
Mantenemos ambos menús cómodos de acceder en móvil
Menú abierto en móvil
¿Por qué esta opción? Decidimos priorizar la accesibilidad del menú de usuario por encima de tener un header más minimalista, evitando tener que hacer muchos clicks para acceder.
Aunque la opción 3 (unificar todo en el menú hamburguesa) habría resultado en un diseño más limpio, habría provocado esconder el acceso al menú de usuario que tanto habíamos optimizado para conversión. Preferimos cargar un poco más el header manteniendo ambos elementos visibles y accesibles. Especialmente considerando que el menú de usuario se había convertido en una herramienta para sugerir al usuario el siguiente paso a tomar.
⚙️ Una vuelta de tuerca más
Después de implementar todos estos CTAs contextuales, nos dimos cuenta de que dependíamos de que el usuario abriera el menú para ver que había algo importante que revisar.
Esto era especialmente crítico en casos como usuarios con suscripciones a punto de ser canceladas.
La solución fue añadir un punto de notificación sobre el avatar cuando hay algo relevante que requiere la atención del usuario. De esta forma, llamamos su atención y le comunicamos que hay algo que revisar sin que haya llegado a desplegar el menú.
Indicar al usuario, sin tener que hacer click, que hay algo que ver
Este pequeño detalle transforma un elemento pasivo en uno activo: en lugar de esperar a que el usuario explore por su cuenta, le damos una señal clara de que hay algo que merece su atención.
🎓 Aprendizajes clave
1. La investigación es parte de la funcionalidad
Dedicar tiempo a analizar cómo lo hacen productos de referencia es inversión en conocimiento. Nos permitió ahorrar horas de iteración a ciegas.
2. El contexto es oro
Un menú de usuario no es solo navegación, es una oportunidad de conversión contextual. Cada variación del estado del usuario es una oportunidad para mostrar información y acciones relevantes que no importarían tanto en otra situación.
3. Si parece un pato y camina como un pato...
Distinguir visualmente elementos informativos de interactivos no es solo estética, es UX.
Un componente informativo que parece botón sin serlo genera frustración. Un CTA crítico que se parece a los menos importantes se ignora. El estilo visual debe reflejar la función, no solo verse "bonito".
4. Iterar con propósito
Cada iteración debería centrarse en resolver un problema. No es iterar por iterar, sino para avanzar hacia una dirección concreta.
🤝 Conclusión
Lo que comenzó como un componente "simple" se convirtió en un ejercicio de diseño de producto y trabajo en equipo.
Cada decisión, desde la posición de un icono hasta el color de un CTA, impacta en la experiencia del usuario. Y, en última instancia, a la identidad de nuestro producto.
El proceso que seguimos (propuesta inicial, investigación, iteración) es aplicable a cualquier feature de producto. La clave está en aprender de referencias de la industria, mientras tenemos en cuenta las necesidades específicas de nuestros usuarios.
Incluso a pesar de empezar con una implementación "de backend", pensamos que hemos hecho un buen trabajo con el componente. Hemos logrado que esté al nivel del resto de la app. Con colaboración y un proceso iterativo, hemos conseguido traer a nuestro caso particular patrones que consideramos buenas prácticas en la industria.
Versión final tras todo el proceso de iteración
¿Qué os ha parecido este proceso? ¿Habéis tenido experiencias similares iterando componentes aparentemente "simples"? Nos encantaría conocer vuestra experiencia en Twitter o LinkedIn.