Desde el inicio, el trabajo se planteó como un programa plurianual con una gobernanza clara, en lugar de una colección de iniciativas aisladas. El cliente designó un equipo central de seis miembros procedentes de operations, digital product, engineering y finance. Coordinaban las cuestiones diarias, gestionaban el acceso a las estaciones y alineaban a los responsables locales.

Por encima de este grupo, un comité de dirección compuesto por cinco ejecutivos se reunía en hitos definidos. Este grupo revisaba los hallazgos de la investigación, tomaba decisiones sobre la dirección arquitectónica y resolvía los equilibrios entre eficiencia operativa, cumplimiento normativo y estrategia tecnológica a largo plazo. Su implicación garantizó que las decisiones sobre flujos de POS, terminales exteriores e integración en el vehículo no se trataran como ajustes locales.

El programa se dividió en streams con una secuencia clara. El rediseño de los flujos de POS duró seis meses y constituyó la base del trabajo posterior. El stream de terminales de pago exteriores se extendió durante siete meses y se apoyó en las lecciones aprendidas de los cambios en POS. La aplicación CarPlay se diseñó en dos meses, una vez comprobadas las hipótesis de integración. Otras actividades como el journey mapping, la definición del concepto móvil y la consolidación del Design System se desarrollaron de forma transversal a estos streams.

Esta estructura creó puntos de revisión predecibles y permitió al cliente planificar los recursos de desarrollo. También facilitó asegurar que las decisiones tomadas para un canal no fueran contradichas por elecciones en otro. En la práctica, esto es esencial para una multi-channel user experience que pueda ser gobernada en lugar de simplemente parcheada.

El programa comenzó con trabajo de campo en siete estaciones del área de Zúrich a través de Sandbox Experiments. Durante una semana, el equipo realizó cuarenta horas de observación estructurada y documentó 532 transacciones en distintos momentos del día y patrones de tráfico. El objetivo era comprender cómo se lleva a cabo realmente el trabajo y dónde los sistemas digitales ayudan o dificultan.

Los investigadores observaron a treinta y seis cajeros durante la operación en tiempo real. Se centraron en la frecuencia con la que el personal cambiaba entre los modos de combustible y tienda, en cómo navegaban la lógica de descuentos y fidelización, y en qué momentos confiaban en la memoria en lugar de en las indicaciones en pantalla. Este trabajo se complementó con veinticuatro entrevistas a cajeros, supervisores de turno y aprendices. La investigación se realizó en alemán, lo que facilitó la comunicación directa y la captura precisa de la terminología específica del sector.

Las transacciones se codificaron por tipo y por complejidad. El equipo identificó patrones en los que el personal omitía campos de forma habitual, volvía a introducir datos para corregir errores o esperaba las respuestas del sistema mientras las colas crecían. Estos patrones sirvieron posteriormente como evidencia para cambios arquitectónicos.

El enfoque combinó entrevistas, contextual inquiry y codificación cuantitativa. La intención no era recopilar historias, sino construir un conjunto de datos estructurado para la user research en retail operations. Esto creó una base para una evidence based UX para retail que podía discutirse de forma transparente con los stakeholders de operaciones e ingeniería.

Con el corpus de investigación establecido, el equipo construyó modelos de journey que describían el comportamiento tanto de los clientes como del personal a través de los distintos canales. El foco no estaba en los journeys de marketing, sino en secuencias operativas relevantes que comienzan con la llegada a la estación y terminan con el pago completado y la asignación de fidelización.

Para los clientes, el mapeo capturó cómo los conductores elegían una estación, cómo se acercaban al área de servicio, cómo seleccionaban un surtidor y cómo combinaban el repostaje con compras en tienda. Para el personal, el mapeo documentó cómo gestionaban la formación de colas, las transacciones mixtas, excepciones como tarjetas rechazadas y la conciliación al final del turno.

Cada journey se dividió en pasos discretos con sus correspondientes disparadores, estados del sistema y condiciones ambientales. Esto permitió al equipo ver dónde la lógica de los sistemas digitales divergía de la lógica del trabajo real. Por ejemplo, ciertos flujos obligaban a los cajeros a cambiar de pantalla varias veces para tipos de transacciones que ocurren con frecuencia durante los picos de demanda.

Los modelos también describían las transiciones entre canales. Un conductor podía llegar mediante la navegación in-vehicle, autorizarse en el terminal exterior y luego entrar en la tienda para completar una compra combinada. El personal necesitaba información coherente a lo largo de todos estos pasos. Al definir claramente estas estructuras, el equipo preparó el terreno para el rediseño del sistema POS y aseguró que los cambios en un canal no generaran nuevas incoistencias en otro.

El stream de POS se centró en los sistemas de caja, ya que soportan la mayor carga operativa. Basándose en los modelos de journey, el equipo catalogó los tipos de transacciones y los agrupó por frecuencia y complejidad. Esto incluía flujos separados para solo combustible, combustible combinado con compras en tienda, canje de vales, operaciones de fidelización y gestión de excepciones.

Se modelaron dieciséis arquitecturas POS alternativas mediante option space mapping. Cada opción reorganizaba cómo se agrupaban las acciones y cómo se presentaba la información en relación con las secuencias de tareas. El objetivo era reducir la navegación innecesaria, limitar los cambios de modo y hacer que la gestión de errores fuera más coherente. El equipo comparó cada opción con el conjunto de datos observado de 532 transacciones para ver con qué frecuencia una estructura determinada cubría los recorridos más comunes.

Se seleccionaron seis conceptos para el prototipado. Estos prototipos se implementaron a nivel de wireframe en pantallas que reflejaban el diseño de 1920 x 1080 píxeles de las cajas reales. Veintinueve sesiones de prueba a través de los distintos streams incluyeron una evaluación estructurada de los prototipos con cajeros y supervisores. Los comentarios se centraron en la velocidad, la claridad en el orden de las tareas y la alineación con las rutinas de conciliación.

La solución resultante no perseguía la novedad. Reorganizó los flujos para que las operaciones más comunes requirieran menos pasos y menos transiciones mentales, respetando al mismo tiempo las limitaciones del hardware existente mediante constraint respecting. Aquí es donde el point of sale UX tiene mayor impacto en el retail operations UX, y no en florituras de interfaz aisladas.

El trabajo de pruebas generó varios hallazgos concretos que explicaban por qué las configuraciones anteriores tenían dificultades bajo cargas máximas. Los cajeros habían desarrollado atajos personales para compensar los problemas de diseño. Estos atajos funcionaban para el personal con experiencia, pero dificultaban la formación de los nuevos empleados. Las secuencias de corrección de errores observadas mostraron que pequeñas incoherencias en el orden de los campos producían retrasos desproporcionados cuando las colas eran largas.

Durante las pruebas, los cajeros respondieron positivamente cuando las secuencias seguían la lógica interna de su trabajo en lugar de la estructura del software heredado. Destacaron mejoras en los casos en que el sistema se alineaba con la forma en que piensan sobre la combinación de combustible, artículos de tienda y acciones de fidelización. Los supervisores subrayaron que los flujos más predecibles facilitan mantener el control en los periodos de mayor actividad, ya que reducen el número de casos especiales que requieren intervención.

El equipo utilizó este feedback para perfeccionar la arquitectura final mediante tension-driven reasoning. Se realizaron cambios en la agrupación de acciones, la ubicación de la información clave y la gestión de excepciones poco frecuentes que conllevan un alto coste operativo cuando se manejan incorrectamente. Estas decisiones se documentaron de forma que pudieran discutirse con el equipo de ingeniería en términos precisos.

A través de este proceso, el rediseño del POS estableció un modelo fiable para los cajeros y creó una referencia para los canales relacionados. También proporcionó al comité directivo del cliente una demostración tangible de cómo las decisiones estructuradas pueden surgir de la evidencia de campo y traducirse en cambios a nivel de sistema en el retail operations UX.

Tanto en las cajas interiores como en los terminales exteriores, el proyecto tuvo que trabajar dentro de los límites del hardware existente. El cliente no estaba sustituyendo los dispositivos, por lo que el diseño no podía apoyarse en mejoras como pantallas más grandes o procesadores más rápidos. Esto convirtió el embedded system UX en una preocupación explícita y no en un simple detalle de fondo.

Las resoluciones de pantalla de 1920 x 1080 píxeles para las cajas y de 1024 x 768 píxeles para los dispositivos exteriores se trataron como parámetros fijos. El equipo midió los tiempos de respuesta típicos de las operaciones clave y detectó secuencias específicas en las que la latencia del sistema afectaba a los patrones de interacción. Por ejemplo, los retrasos entre la autorización y la confirmación llevaron a los cajeros a aplicar soluciones alternativas que complicaban la formación y la documentación.

Las decisiones de diseño buscaban minimizar la dependencia de secuencias sensibles a la latencia. Cuando las pantallas requerían información más extensa, la estructura priorizaba la claridad sobre la densidad. Para el hardware embedded, esto no es una preferencia estética, sino una forma de evitar superar los límites prácticos de interacción bajo carga.

Estas consideraciones se documentaron para los equipos de ingeniería, de modo que pudieran comprender por qué se recomendaban ciertos diseños o patrones de interacción. El objetivo era garantizar que la implementación no reintrodujera patrones que parecen eficientes en teoría, pero que causan problemas en condiciones operativas reales.

A medida que los streams maduraban, el equipo consolidó los patrones en un único Design System que cubría cajas, terminales exteriores, CarPlay y el concepto móvil. El sistema incluía definiciones de componentes, reglas de interacción y notas de uso, estructuradas por canal y por patrones compartidos. Su objetivo era apoyar tanto la implementación actual como la evolución futura.

La documentación aclaró qué elementos eran comunes entre los distintos dispositivos y cuáles eran específicos de una plataforma determinada. Por ejemplo, los estados de los botones, las elecciones tipográficas básicas y ciertos patrones de presentación de datos se mantuvieron consistentes. Otros aspectos, como las rejillas de diseño y los modelos de interacción, se adaptaron a las limitaciones de cada tipo de dispositivo y al contexto de uso.

Los desarrolladores recibieron assets alineados con su toolchain existente. El equipo de diseño participó en las sesiones regulares de implementación para aclarar comportamientos y resolver dudas sobre edge cases durante la Implementation Partnership. Esto redujo el riesgo de divergencias entre el comportamiento previsto y el comportamiento real, especialmente en la gestión de errores y las transiciones de estado.

El Design System se describe mejor como un Design System para aplicaciones retail que deben operar tanto en terminales embedded como en entornos conectados. Su propósito no es solo el branding visual, sino una toma de decisiones repetible que los equipos de producto e ingeniería pueden aplicar al ampliar o ajustar el ecosistema.

La aplicación CarPlay abordaba otra parte del journey. Debía permitir descubrir estaciones cercanas, guiar hasta el área de servicio e identificar el surtidor correcto tras la llegada. Al mismo tiempo, debía cumplir con las normas de la plataforma que limitan la distracción del conductor y con las regulaciones locales sobre el comportamiento durante el repostaje.

El equipo definió escenarios de uso en los que los conductores se acercan a una estación, reciben indicaciones al entrar en el área de servicio y confirman el surtidor en el que se detienen. Las secuencias de interacción se mantuvieron cortas. Siempre que fue posible, el diseño se apoyó en acciones por voz y confirmaciones simples en lugar de una navegación extensa por menús. Esto refleja la disciplina propia del automotive UX design, en lugar de los patrones de las aplicaciones móviles de consumo.

El trabajo de integración se centró en la identificación coherente de los surtidores y en una autorización segura. La aplicación debía comunicarse con el back end existente para que el estado de los surtidores y el estado del pago coincidieran con la realidad en el área de servicio. Las sesiones de prueba con conductores analizaron con qué claridad la app transmitía estos estados y en qué medida la lógica coincidía con las expectativas.

La estructura resultante sirvió como base de la UX de la app CarPlay para este cliente. Se alineaba en principio con los flujos definidos para los terminales exteriores y las cajas, al tiempo que respetaba las restricciones más estrictas de las interfaces in-vehicle. Este canal influyó posteriormente en otras partes del ecosistema cuando los conductores se acercaban a la estación a través del vehículo en lugar de mediante herramientas de navegación independientes.