Caso · Rediseño · App Gasco
Cómo la app de pedidos de Gasco pasó a completar40% más pedidos
Y su calificación subió de 1,7 a 4,8 estrellas en 3 meses.
- Rol
- Lead Product Designer (Lead UX)
- Equipo
- Product Owner, Tech Lead, equipo de desarrollo y equipo de UX
- Período
- 2024 – principios de 2026
- Plataforma
- App móvil iOS y Android
Impacto
+40%
Pedidos completados, vs. año anterior
+30%
Clientes activos, en los primeros 3 meses de lanzamiento
−30%
Llamadas al call center
1,7 → 4,8
Rating en tiendas, en 3 meses
Resultados de la versión en producción (la tercera, sobre la plataforma externa). Medido con Mixpanel (flujos de registro, pedido y uso general), reportes internos de pedidos y las tiendas de apps.
Contexto
Elproblema
El procesoCuatro versiones en dos años
El proyecto atravesó dos cambios de plataforma tecnológica, y cada uno obligó a rediseñar la experiencia sobre nuevas restricciones.
Primera iteración, sobre la base técnica original: se reordenaron el flujo de pedido, el resumen y el seguimiento.
Segunda iteración, sobre una nueva base con desarrollo interno: se rediseñó la estructura completa.
Plataforma externa: el negocio optó por una solución ya construida, principalmente para reducir costos y, en segundo lugar, para ganar velocidad. Tuvimos que adaptar toda la experiencia a sus restricciones.
Mi propuesta: la visión que definí sobre cómo debía evolucionar la app.
La primera es la app original, antes del rediseño. La 4 es mi propuesta, que no llegó a implementarse.
Wireframes
La segunda iteración se definió en wireframes. Para la selección de productos y el resumen del pedido se evaluaron dos estructuras alternativas cada una, antes de llevar la elegida a alta fidelidad.
Clic para ampliar
Decisionesclave
Hacer que la espera se sienta
El research, con entrevistas, grabaciones de sesión y tickets de soporte, mostró que el principal reclamo era no saber dónde venía el pedido. Propuse un seguimiento por etapas: pedido recibido, buscando chofer, chofer aceptó y pedido en camino. Pero los choferes aceptaban tan rápido que las cuatro etapas pasaban en menos de un segundo, y ese salto instantáneo generaba desconfianza. Tomé la decisión de dar a cada etapa entre 3 y 5 segundos, para que el cliente percibiera el avance de su pedido. La ansiedad y los reclamos disminuyeron.
Elegir con los usuarios, no por gusto
Las piezas más visibles se probaron con usuarios antes de definirse. En notificaciones se evaluaron 3 propuestas, y la elegida obtuvo el 53% de las preferencias. En la sección de productos se evaluaron 4, y la elegida obtuvo el 55%; los usuarios la describieron como "fácil de usar y clara".
Quitar lo que nadie usaba
La app ofrecía packs de gas y formatos como grúa horquilla o gas catalítico, que casi nadie compraba. Además confundían: al preguntarle si su gas era normal o catalítico, el usuario quedaba en duda. Decidí sacarlos del flujo principal, y pedir gas pasó a ser una decisión simple.
Diseñar dentro de una plataforma externa
Cuando el negocio eligió la plataforma externa, principalmente por costo, tuvimos que adaptar toda la experiencia a sus restricciones. Mi rol fue defender lo esencial. El caso más claro fue el registro: la plataforma traía demasiados pasos, y defendí reducirlo a lo indispensable.
Solución
Una app enfocada en una sola tarea: pedir gas rápido y saber cuándo llega. Sin productos que confunden, con un registro corto y un seguimiento que muestra el avance del pedido.
Hacia dóndeiba
Aprendizajes
La velocidad percibida importa tanto como la real: mostrar el proceso puede generar más confianza que hacerlo instantáneo.
Hoy instrumentaría la app desde el primer día para medir cada decisión, y la lanzaría por etapas, validando con usuarios en cada entrega.
Siguiente caso
Gascontigo→