Case Study

Alembiq

2019 | Rol: UX/UI Design

Repensando la forma en que los anunciantes y los propietarios de sites se comunican para ofertar sus servicios. Sigue leyendo si te interesa saber como integrar una plataforma entre usuarios de un DSP

Creando una aplicación para un DSP desde 0

Contexto

Kimia, una empresa de publicidad online basada en programática, quería sacar un nuevo DSP al mercado desligada de la marca Kimia.

Un DSP es una plataforma a través de la cual se genera la demanda para comprar espacio publicitario ya sea display, video o móvil, mediante los diferentes Ad Exchanges que ponen en contacto a compradores y vendedores.

Tradicionalmente la compra de medios debía realizarse mediante un acuerdo entre el anunciante y medio. Debido al auge de los DSP , este proceso se puede automatizar debido a un algoritmo que se encarga de localizar tu segmento o audiencia.

Un DSP es lo que hace que el anuncio llegue a un público de mayor calidad, gracias a que es capaz de cruzar los datos de los usuarios con los de las subastas y optimizar las campañas en tiempo real, lo que maximiza los resultados de la inversión.

Reto

El equipo tendría que afrontar varios retos, por un lado, el branding de una nueva marca (al menos un MVP Brand Guideline) y por el otro la generación de una app que pudiera adaptarse dependiendo del tipo de usuario (personas que pujan su anuncio, anunciantes, proveedores de site, compradores de tráfico, etc.).

Objetivo

distinguiéndose en la facilidad de uso y la adaptabilidad al usuario en mostrar dashboard complejos. El Dashboard tenía que poder controlarse en una App móvil de formato vertical, con la complejidad que esto tiene cuando se intenta mostrar al usuario gráficas y pujas de manera clara con KPIs determinados, pero que no se diferenciara en demasía a la experiencia en desktop.

Rol

Tenía reuniones periódicas con el equipo de desarrollo y Product Managers que se encargaban de la integración de la antigua plataforma. Fue un proyecto al que tengo mucho cariño, ya que había diseñado Dashboard, pero nunca tan complejos y que se pudieran adaptar tanto a una app como a una futura progressive web app

Herramientas

  • ✐ Papel y lápiz, post-it > Ideas, palabras, wireframes de baja fidelidad.
  • 💠 Jira > Integración equipo de desarrollo y diseño en Agile
  • 💎 Sketch > Wireframes de alta fidelidad y mockups
  • 📂 InVision > Interacciones, feedback de equipo, Benchmarking
  • 🤖 Bitbucket > Control de versiones desarrollo
  • 📂 Zeplin > Entrega a desarrollo (Hand-off)
  • 📝 Confluence > Documentación
  • 📲 Google Analytics > Métricas y toma de decisiones

Proceso

Toda la ejecución del proyecto se hizo en Ágile. Un Product Owner coordinaba tanto al equipo de desarrollo como a los diseñadores. El principal escollo que encontré era la lentitud a la hora de tener una reunión/llamada breve ante una problemática concreta, especialmente en la fase de prototipado. Ya que tanto el equipo de diseño como de desarrollo estaba en pisos diferentes manejando un volumen diversos de tareas que no estaban conectados entre los departamentos. No obstante, bajo agile, hacíamos reuniones diarias nada más entrar a la oficina para ver el status del proyecto. Eran sesiones rápidas que iban al grano en el scope general de priorización y ejecución de las tareas pendientes.

Dos complejidades principales

Priorizar que mostrar en las primeras pantallas para cada perfil de usuario (dependiendo si era un vendedor de un sitio de la web, un anunciante, una agencia, etc).

Priorizar cómo mostrar la información temporal (gráficas, subida/bajada de precios en constante actualización, etc) en dispositivos verticales.

El gran alivio fue cuando haciendo un breve Research encontré una librería de gráficas que se adaptaban a nuestras necesidades, Chart Js.

El framework que elegimos era Bootstrap en React, ya que el equipo de desarrollo se sentía cómodo bajo estos frameowrks. En esta primera fase del proyecto nos centrábamos en crear un MVP que se fuera a lanzar al mercado con las visualizaciones más útiles para el usuario, donde pudiera revisar rápidamente el resultado de las primeras exploraciones via wireframes.

Una vez recopilados todos los insights del equipo de analítica, nos pusimos a pensar en la mejor forma de sincronizarnos con diseños sobre un dashboard basado en Bootstrap a la vez que documentábamos en Confluence los insights y proceso de la aplicación.

Fue un ejercicio puramente de usabilidad sin entrar a valorar otros componentes de producto todavía, como branding y estilo del contenido. Se decidió que la aplicación sería inicialmente para Android basada en React como primera fase porque la mayoría de los usuarios estaban bajo este sistema operativo. El proceso de conceptualización y wireframing partió de mis ideas iniciales, pero fueron compartidas en el equipo, por lo que fue un proceso de cocreacción. Después de valorar todas las propuestas a lápiz, seleccionamos las mejores ideas y descartamos las que no nos convencían. Este último paso fue clave a la hora de jerarquizar y priorizar la información y el flujo de trabajo.

Un gran objetivo fue el de mostrar las máximas estadísticas posibles para cada anuncio (producto) en el menor espacio posible. Por lo que se desarrollaron multitud de variedades en vcards como se ve a continuación.

Una vez recopilados todos los insights del equipo de analítica, nos pusimos a pensar en la mejor forma de sincronizarnos con diseños sobre un dashboard basado en Bootstrap a la vez que documentábamos en Confluence los insights y proceso de la aplicación.

Fue un ejercicio puramente de usabilidad sin entrar a valorar otros componentes de producto todavía, como branding y estilo del contenido. Se decidió que la aplicación sería inicialmente para Android basada en React como primera fase porque la mayoría de los usuarios estaban bajo este sistema operativo. El proceso de conceptualización y wireframing partió de mis ideas iniciales, pero fueron compartidas en el equipo, por lo que fue un proceso de cocreacción.

Después de valorar todas las propuestas a lápiz, seleccionamos las mejores ideas y descartamos las que no nos convencían. Este último paso fue clave a la hora de jerarquizar y priorizar la información y el flujo de trabajo.

Wireframes

Un gran objetivo fue el de mostrar las máximas estadísticas posibles para cada anuncio (producto) en el menor espacio posible. Por lo que se desarrollaron multitud de variedades en vcards como se ve a continuación.

Intentábamos en la medida de lo posible, iterar siempre en diseño, haciendo prototipados rápidos para ver el comportamiento en un escenario real concreto (mobile).

Un ejemplo de esto, lo encontramos para determinar el ancho y alto de los diferentes botones. Preferimos ir sobre seguro aunque sea más lento en la etapa de diseño, para no lamentarlo posteriormente en desarrollo.

Resultados

Aprendizajes

  • Cuanto más alineado estén los perfiles de producto, diseño y desarrollo mejor implementación tendrá la aplicación.
  • Mediante prototipados rápidos aprendimos a entender el peso real de los elementos en el grid. Descubrimos como es posible mostrar datos complejos como una gráfica temporal sin sacrificar demasiado el diseño ni la usabilidad.
  • Partir de estructuras que sean adaptables (Bootstrap, React, Vue) facilita mucho el hecho de salir con un MVP en una app con un SO determinado para transitar a una mejor solución en sucesivas fases, como las progressive web apps.

Si has llegado hasta aquí, me encantaría que me dieras tu feedback

Puedes escribirme y contactarme para colaboraciones en felipe.sotoca@gmail.com

Contactar

Otros Case Studies

screenshot

Lexorbe Abogados

Ver Case Study

screenshot

UCJC App

Ver Case Study

©2020 - Felipe Sotoca - Happy to work together