Este caso empezó con un briefing que yo no escribí, y terminó contradiciendo una parte de él. Vale contarlo en ese orden, porque fue la investigación la que dio la vuelta a la mesa.
El punto de partida
El reto vino hecho: coger Square Register, que es un sistema de punto de venta operado por un empleado detrás del mostrador, y convertirlo en un autoservicio de supermercado. Todo en una tablet que acompaña a la persona por la tienda: elegir, registrar, pesar, pagar y recibir el comprobante, sin depender de otro equipo y sin pasar por caja.
El objetivo declarado era reducir la cola. Y venían dos metas con él, escritas como preguntas:
01. ¿Cómo podríamos crear una nueva experiencia de compra donde el usuario tenga autonomía total?
02. ¿Cómo simplificar el recorrido del cliente y ofrecerle un sistema fiable para su compra?
Quédate con la primera. Autonomía total es la expresión exacta que la investigación vino a contradecir, y de ahí sale la decisión más importante de este caso.
El producto del que parte el ejercicio.Esta imagen es material de comunicación de la propia Square, y no trabajo mío.
Dos cosas tienen que quedar claras antes de cualquier pantalla. La primera es que esto es un estudio: el briefing es de un bootcamp y usa una empresa real como escenario. Nada de esto se hizo para Square, ni lo encargó ella, ni lo ha visto. La segunda es que trabajé en solitario, desde el primer desk research hasta el último componente.
El método estaba planificado en cuatro etapas desde el principio, y los cuatro meses dieron para cumplir las cuatro.
El proceso tal como se cuenta después: cuatro etapas, en línea recta.
Descubrir (Discover)
- Desk research
- Análisis de la competencia
- Investigación de campo
- Canvas
- Survey
- Entrevistas
- Test de usabilidad
Definir (Define)
- How might we
- User flow
- Task flow
Desarrollar (Develop)
- Crazy 8's
- Rabiscoframe
- Wireframes
Entregar (Deliver)
- Prototipo en alta fidelidad
- Test de usabilidad
- Ajustes
Lo que no fue lineal fue el recorrido. Fíjate en que el test de usabilidad aparece dos veces en el plan, en el descubrimiento y en la entrega, y fue el segundo el que mandó el proyecto de vuelta a la definición: la validación de edad cambió de sitio cuando el producto ya tenía pantallas hechas.
La investigación
Empecé por el mercado y terminé en las personas. El orden importó menos de lo que yo esperaba, porque lo que cambió el proyecto vino del final.
Desk research. Reuní datos sobre abandono de compra por culpa de la cola y sobre la preferencia por escanear los propios productos. Sirvieron para lo que sirve ese tipo de dato, que es confirmar que el problema existe y tiene tamaño. Lo anoto con la salvedad honesta: son números de 2023, de prensa especializada de retail, y la adopción del autoservicio en Brasil ha subido bastante desde entonces. Justifican el proyecto en su momento, y no deben leerse como retrato de hoy.
Análisis de competidores. Esta fue la parte que más me enseñó sobre la categoría. En vez de comparar folletos, fui a buscar registro de uso real de cuatro competidores: Amazon, Zaitt, Shopic y Caper by Instacart. Cada uno se convirtió en una franja del tablero, con foto del equipo, foto de la pantalla en uso y anotación de qué resolvía o estorbaba ese momento.
Cuatro competidores documentados por uso, y no por folleto.De aquí sale la noción de lo que ya era convención en la categoría.
Entrevistas. Tres personas, unos veinte minutos cada una, en persona. El objetivo era entender su preferencia en cuanto al tipo de atención en el supermercado, y el recorte fue deliberadamente amplio: gente que va al supermercado, use o no el autoservicio.
Entré con tres hipótesis de formato en competencia, y están registradas en el guion: desarrollar solo una aplicación, desarrollar un tótem para finalizar la compra, o desarrollar un sistema en tablet con todo dentro. Las entrevistas existían para decidir entre ellas.
Tres personas no son muestra para generalizar, y nada de esto debe leerse como estadística. Es muestra para encontrar dirección.
Lo que dijeron los datos
El dolor más fuerte no era la cola. Era quedarse sin salida. Fue el hallazgo que dio la vuelta al proyecto, porque contradecía el briefing que yo había recibido:
"Los usuarios prefieren la mayoría de las veces la ayuda de un empleado para no perder tiempo resolviendo problemas del sistema."
"Tener siempre personas cerca ayuda a tener más confianza y a pedir ayuda rápido si hace falta."
La meta 01 pedía autonomía total. Lo que las personas describieron fue otra cosa: resolver solas lo que funciona, sin quedarse atrapadas cuando algo falla. Autonomía, para quien está comprando, no es ausencia de gente. Es no depender de gente para el camino normal.
Las personas pidieron la balanza sin saber que estaban pidiendo un formato. Dos de los comentarios más concretos eran sobre pesar:
"Me gustaría poder pesar el producto en el propio autoservicio para agilizar el proceso."
"Tener una balanza inteligente que entienda lo que quiero pesar sin que yo tenga que ir a otro sitio."
Eso decidió la disputa entre las tres hipótesis. Una aplicación en el móvil no pesa nada, y un tótem al final de la tienda obliga a ir hasta allí. Solo la tablet sujeta al carrito lo resolvía, y por eso ganó, y no por ser la más moderna de las tres.
La balanza decidió el formato.Responde a dos de las citas más concretas de las entrevistas.
Y apareció una petición muy concreta: más formas de pago, incluido el vale de comida. Fue la más fácil de atender de todas, y la única que se puede comprobar solo mirando la pantalla: débito, crédito, efectivo, PIX, compra dividida en dos tarjetas, y VR en la fila de marcas.
La petición de una de las entrevistas, atendida y verificable: el VR está en la fila.
Las decisiones
Ayuda con plazo, y con salida
El botón de ayuda no abre un chat ni un centro de atención. Llama a una persona de verdad y muestra la cuenta atrás hasta que llega.
La cuenta atrás es la decisión entera. Sin ella, la petición de ayuda se convierte en espera indefinida, que es exactamente el estado descrito en las entrevistas como motivo para abandonar el autoservicio. Con ella, la persona sabe si merece la pena esperar.
Y hay un botón de cancelar, porque quien se ha resuelto solo en los primeros segundos no debería quedar rehén de su propia petición.
Pedir ayuda muestra cuánto va a tardar en llegar.La cuenta atrás convierte una petición de auxilio en una espera con plazo, y el cancelar existe porque no toda petición necesita cumplirse.
Quien busca el producto es el sistema
Encontrar el artículo no puede depender de llamar a alguien. La primera versión ya tenía búsqueda, pero fue el test el que la puso en el centro de la pantalla.
La búsqueda devuelve el producto con el pasillo donde está, marca el punto en el plano de la tienda y muestra la posición del carrito respecto a él. Quien prefiere cogerlo a la vuelta toca "Avísame", y el sistema avisa al pasar cerca.
Dónde está el artículo, y dónde estás tú.El plano responde las dos preguntas en la misma pantalla.
Interrumpir una sola vez
Algunos productos exigen acreditar la mayoría de edad. La primera versión pedía esa validación en el momento en que el artículo entraba en el carrito, que es donde nace la regla.
En la práctica eso paraba la compra cada vez que aparecía un artículo restringido. La validación pasó al pago, una sola vez, con el documento. En el carrito queda solo un aviso de que ese artículo habrá que validarlo después.
La regla sigue en pie.Lo que cambió fue cuántas veces interrumpe la compra.
Del problema a la pantalla
Antes de dibujar pantalla, dibujé el servicio.
El canvas organizó problema, usuarios, competidores, alternativas y propuesta de valor en una sola página. Vale la salvedad que ya estaba en el proyecto original: ese ejercicio se hizo sin stakeholder, con datos obtenidos en búsqueda online. Es un canvas de estudio, y no una alineación con quien decide el negocio.
Hecho sin stakeholder, y eso está anotado en el propio material desde 2023.
El blueprint de servicio fue lo que más cambió el diseño. Cruza las etapas del recorrido, de la necesidad a la posventa, con lo que la persona hace, los puntos de contacto, lo que el sistema hace por debajo, los dolores, las oportunidades y las soluciones posibles. Ahí es donde la validación de edad aparece como problema de servicio, y no de pantalla.
Etapa por etapa, lo que la persona hace y lo que el sistema necesita hacer para que eso funcione.
El task flow mapeó los caminos con las decisiones explícitas, incluidas las que no siguen adelante.
Cada rombo tiene salida hacia los dos lados.Las que salen mal también necesitaban pantalla.
Solo entonces vinieron los bocetos. Hice Crazy 8's y crazyframes en papel, para probar disposición de pantalla sin encariñarme con ninguna.
Papel y bolígrafo primero.Una idea mala descartada aquí cuesta minutos, y no días.
En los wireframes en media fidelidad tomé una decisión que retrasó el principio y compensó al final: no usar ningún UI kit hecho. Quería descubrir los componentes dibujando las pantallas, y no encajar las pantallas en componentes que alguien ya había resuelto. Fue esta versión la que se convirtió en prototipo navegable y fue al test.
La versión que llegó a manos de los participantes.Media fidelidad a propósito: demasiado acabado hace que el test se convierta en una valoración estética.
El sistema detrás
El moodboard fue menos sobre estética y más sobre quién usa. El supermercado es uno de los pocos sitios por donde pasa todo el mundo, y la referencia tenía que mostrarlo: gente distinta, productos, el origen de lo que se compra y lo que pasa cuando la compra llega a casa.
La referencia es el público, y no la interfaz.Quien usa el autoservicio del supermercado es todo el mundo.
En la interfaz, la decisión fue no inventar. Square ya tenía un sistema de diseño establecido, y el ejercicio era extender un producto existente, no sustituirlo. Diseñé componentes nuevos para lo que el autoservicio exigía, siguiendo lo que ya estaba en uso.
El artículo del carrito es el ejemplo. No es una línea de lista: es un componente con estado. Entrando, saliendo, y la variante que lleva el aviso de validación pendiente.
El mismo artículo en tres momentos.El aviso de validación es estado del componente, y no una pantalla aparte.
Y el diagrama de abajo es el producto en una sola página: las pantallas y las conexiones entre ellas.
Las pantallas y los caminos entre ellas.El mapa de la tienda es alcanzable desde cualquier punto, y eso es decisión, no sobra de maquetación.
El producto funcionando
El caso hasta aquí muestra decisión. Estas grabaciones muestran su resultado en movimiento, en el prototipo de alta fidelidad.
Fíjate en dos cosas que no vinieron de la investigación y entraron porque el producto las necesitaba para existir: la validación del ticket de aparcamiento y la elección de cómo recibir el comprobante. Y fíjate en el estado de error del ticket, con el código rechazado en rojo. En un sistema donde no hay un empleado al otro lado del mostrador, la pantalla que sale mal es tan parte del producto como la que sale bien.
5 grabaciones, 1 min en total
Registrar productos por código de barras o escribiendo el código del artículo.
Pesar fruta y verdura en la propia estación, sin ir a otro sitio.
Validar el ticket del estacionamiento antes de pagar, incluso cuando el código está mal.
Elegir la forma de pago y acreditar la mayoría de edad una sola vez, al final.
Recibir el comprobante por correo y valorar la experiencia.
El test, y lo que cambió
El test de usabilidad fue presencial, con el prototipo en media fidelidad en una tablet, para acercarse a la situación real de hacer una compra y pagar en el propio aparato.
De ahí salieron dos cambios.
La validación de edad cambió de sitio. Se hacía cuando el producto entraba en el carrito, y pasó a hacerse una sola vez, en el pago. Fue lo que prefirieron los participantes, y es la decisión descrita arriba.
La búsqueda pasó al centro de la pantalla. La barra de búsqueda creció, los resultados pasaron a aparecer en tiempo real con el sector donde está el producto, la ruta hasta él quedó visible desde donde está la persona, y el "Avísame" ganó la notificación de proximidad. Lo que había antes era demasiada información, y parte de ella duplicada.
Aquí necesito ser claro sobre una laguna de este caso: no tengo registro visual del test. Se hizo en persona, con las personas usando la tablet, y no guardé la comparación entre la pantalla testeada y la pantalla ajustada. Los cambios de arriba están descritos porque ocurrieron y orientaron la versión final, pero el caso no consigue enseñarlos uno al lado del otro, y no voy a montar después una comparación que no existió en su momento.
Es el briefing lo que hay que reescribir
El aprendizaje que saqué del proyecto en su momento fue sobre negocio: entender el problema junto a quien decide, en vez de resolver la interfaz y presentarla después. Sigue siendo válido, y el canvas hecho sin stakeholder es la evidencia de ello dentro del propio material.
Revisitándolo ahora, añado un segundo, y es más incómodo. Recibí un briefing que decía autonomía total, las entrevistas dijeron otra cosa, y el enunciado nunca cambió. Las decisiones siguieron a las entrevistas: la pantalla de ayuda y el mapa de la tienda existen justamente por lo que dijeron las personas. Pero nunca volví al briefing para corregir la meta, y seguí llamando autonomía a una cosa que la investigación ya había redefinido.
Ese es el aprendizaje que me llevo: cuando la investigación contradice el briefing, actualizar las pantallas no basta. Es el briefing lo que hay que reescribir, si no la decisión siguiente vuelve a salir de la premisa vieja.