El camino hacia la nueva página de Inicio de PedidosYa

Si uno abría la aplicación de PedidosYa a principios de este año 2021 probablemente se frustraba con el tiempo que se tomaba en cargar. Es entendible ya que la primera página tardaba (en arranque en frío — como se le llama a la primera vez que levanta la app) unos 17 segundos en promedio ponderado entre usuarios de Android y de iOS.

Por supuesto que no estábamos para nada orgullosos de eso pero las razones para que eso pase eran complejas y no eran simples de eliminar en un corto plazo. Sabíamos que teníamos que atacar un problema que venía acumulando inconvenientes durante mucho tiempo y por lo tanto iba a requerir alguna solución de fondo.

El problema de la Home de PedidosYa radicaba principalmente en los siguientes puntos:

• En la carga de esa página se pedía mucha información contextual para que todos los demás flujos de la app puedan funcionar cuando fuesen invocados. Por ejemplo, se pedían los medios de pago disponibles en el país antes de cargar la página de inicio.
• La Home no era de ningún equipo. Nadie era el dueño, entonces nadie se sentía responsable por las cosas que no estaban tan bien.
• Mucha de la lógica de negocio de esa pantalla estaba en el frontend lo que hacía que iterar cualquier comportamiento sea costoso en tiempo, entonces muy pocas veces se iteraba.
• La Home era parte del código legacy y monolítico de la app. No era un módulo independiente como sí a esta altura en el tiempo ya lo eran varios flujos de la app. Es más, esta pantalla y la siguiente (la que muestra un listado de restaurantes o supermercados) eran parte de la misma base de código enmarañada con el paso de los años y los features.

Primeros pasos hacia la solución

La primera cosa medio evidente que hicimos fue ponerle nombres a este problema. Formamos un equipo. El equipo de Home. Un problema sin dueño es difícil de atacar y supimos que era la primera cosa que teníamos que hacer si queríamos mejorar esa experiencia al abrir la app como primer objetivo.

Formamos un equipo multidisciplinario con un Product Manager, un Engineering Manager, un UX Designer y desarrolladores expertos en las tecnologías nativas mobile (iOS y Android), web y backend. Aunque todos eran perfiles cross funcionales en sí más allá del expertise particular que tenían.

A partir de ahí, con el problema ya identificado, teníamos que entender qué camino debíamos tomar para cumplir con ese norte de mejorar la experiencia en términos de tiempo de carga a la vez que dejábamos ese flujo mucho más iterable y dinámico en el tiempo al punto de poder personalizar la experiencia y mostrar el contenido ajustado para cada uno de nuestros usuarios.

En término de tecnología queríamos ir hacia un mundo que nos deje iterar muy rápido, y a eso se ajustaban las siguientes opciones:

• Tecnología híbrida. Hicimos pruebas exitosas con flutter.
• Webviews. Habíamos empezado a resolver algunos flujos de esta forma en la compañía, pero todavía no teníamos todas las interacciones de UI totalmente resueltas.
• SDUI con tecnología nativa mobile. Conocíamos sobre este patrón pero no teníamos experiencia en PedidosYa, así y todo nos pusimos a bajarlo a tierra.

Entre algunas pruebas rápidas que hicimos y la experiencia que teníamos llegamos a bajar la siguiente comparativa en base al equipo que teníamos y los objetivos que perseguíamos:

Server Driven UI (SDUI)

Finalmente fuimos por el patrón de Server Driven UI (o también conocido como BDUI, de Backend Driven UI). Simplemente es la idea de desarrollar la aplicación de frontend con pantallas y flujos basados en respuestas de servicios de backend. Para no irnos en palabras, a mi me gusta pensarlo en términos de dónde queda cada responsabilidad a partir de adoptar este paradigma.

Convencionalmente uno diría que las preguntas que tiene que resolver la aplicación para mostrar una pantalla son las siguientes. Veamos cómo la mayoría de las decisiones pasan a ser responsabilidad de nuestro/s servicio/s de backend.

Cómo ven, la mayoría de las responsabilidades pasan a estar en nuestros servicios de backend y las aplicaciones mobile sólo van a saber cómo dibujar cada componente que les llegue. En definitiva traducir un tipo de componente (el único acuerdo tipado previo que tiene que tener con el backend) en algo visual. Ejemplo: un componente de tipo CARD tiene una imagen de tantos pixeles de ancho, un link y un radius x que le dan forma a ese componente visual.

El resto es orquestado por un servicio que en definitiva decide qué dibujar en la pantalla, en qué orden quiere ubicar esos componentes y cuándo va a cargar ese contenido (ejemplo, es quien decide qué es más importante para el time-to-interact y podría decidir cargar otros componentes de manera lazy — en diferido -).

Así es cómo el contrato entre tipos de componentes se vuelve lo más relevante en esta interacción y desacopla el resto de los problemas, dejando un frontend muy vago y sin lógica de negocio lo que en principio nos daba independencia para tomar decisiones sin depender de un release de la app que en general es una de las cosas que más le pegan al time-to-market en el desarrollo de aplicaciones móviles. Además nos da la posibilidad de, a futuro, enfocarnos en cosas que a veces dejamos de lado (accesbilidad, microinteracciones, etc).

Aquí un ejemplo del contrato para dibujar los banner de la Home:

Notar que en definitiva el servicio de back compone cada ítem de la pantalla mediando un JSON que anida componentes que van hasta el mayor nivel de desagregación posible volviendo cada uno de ellos reutilizable donde más se pueda, siendo totalmente agnósticos del problema de negocio que resuelven. En el ejemplo: el carrusel de banners tiene atributos propios que lo describen, entre ellos hijos que son a su vez otros componentes tipados.

Así entiendo que ya pueden imaginar cómo se dibuja la pantalla entera, que hoy consta de un search box, una sección de verticales o shortcuts, un carrusel de banners, otro banner opcional que indica el estado de la orden (si tuvieses una en progreso), otro banner opcional para puntuar al repartidor o la orden en sí, y varios carruseles más con distintas agrupaciones personalizadas con oferta de locales clusterizada según distintos criterios.

En el camino se aprende

Cuando comenzamos este proyecto erramos en dos premisas que creímos válidas y me parece importante resaltar por si al momento de estar leyendo estas líneas tenés pensado tomar un approach parecido en tu solución:

• Elegir un patrón de diseño NO es un proyecto sólamente técnico. Nosotros creíamos que migrar una arquitectura a un nuevo paradigma era cuestión de una célula de programadores modularizando gran parte de la aplicación, creando el nuevo servicio de backend e ir migrando los componentes a este nuevo stack de manera que al finalizar el proyecto íbamos a encontrarnos con una nueva experiencia, más dinámica, más veloz, de la que la compañía se iba a enorgullecer. Pero por el contrario, no tienen idea de la cantidad de decisiones de producto que tuvimos que tomar en el camino. En definitiva, visualmente estábamos replicando lo mismo, pero en términos de comportamiento migrar a esta nueva forma de construir nos dejó parados en un lugar donde cada paso era una decisión nueva. Desde si tenía sentido migrar ciertos assets que sabíamos que no convertían bien, hasta cuándo debíamos mostrar cada cosa, cómo modelábamos el nuevo servicio pensando en funcionalidad futura, etc etc. Los ejemplos son infinitos y pagamos un precio muy caro por no tener las respuestas en los momentos correctos. Nos llevó a tener que hacer mucho retrabajo y los tiempos en los que esperábamos entregar la solución no se cumplieron ni por cerca. Conclusión: definan bien el producto antes pensando en las ventajas que trae la nueva forma de construir y pensar la solución.
• Ser dueño de una pantalla no necesariamente delimita la responsabilidad a eso y sólo eso. Cuando tomamos la responsabilidad de la Home, entendimos que teníamos que trazar una línea entre el servicio encargado de dibujarla, personalizarla, ordenarla y tomar decisiones de negocio en torno a todo lo que tenga que ver con esa experiencia; pero no tuvimos en cuenta que no toda la información necesaria para cumplir ese objetivo a veces no es consumible de una manera fácil, está lo suficientemente desacoplada de otros servicios y/o incluso hay responsables por eso que nos pueden hacer la vida muy fácil. Así es como tuvimos que hacernos dueños de muchas integraciones y servicios que servían (sirven) contenido a la home, que no eran de nadie, en los que fuimos encontrando problemas y tuvimos que solucionar y que con el tiempo tuvimos que ir abrazando para poder ir destrabando lo que para nosotros era vital: salir con la nueva Home. Entonces, como parte de la definición de un proyecto de estas características, definan bien el alcance, entiendan si todas esas aristas están resueltas, identifiquen equipos y responsables, abran las conversaciones de antemano y no den nada por sentado.

A escena!

Desde la semana pasada (al momento de escribir esta publicación) el 100% de los usuarios de PedidosYa viven una nueva página de inicio, la Nueva Home.

Hoy nuestros usuarios en los 15 países de Latinoamérica donde tenemos presencia tienen una aplicación que carga 17x más rápido que un año atrás. Ellos también pueden ver el contenido más relevante primero y nuestra página de inicio ya es personalizable para cada uno de ellos. Los momentos del día podrían indicar fácilmente experiencias distintas. Las preferencias y tu job-to-be-done como usuario van a impactar también.

Vieja Home (izq) vs Nueva Home (der)

No puedo terminar sin agradecer a todo el equipo que se embarcó en este proyecto tan relevante para la compañía.

Vamos por más!