Sin capturas: el producto y sus datos son confidenciales. Todo lo que se muestra aquí son esquemas conceptuales del trabajo de diseño.
Diseño de producto para una plataforma de distribución inteligente de stock utilizada por empresas de retail para planificar la implantación de nuevas colecciones en sus tiendas físicas.
El problema central no era técnico, sino de confianza. La plataforma generaba propuestas de distribución basadas en análisis de mercado, tendencias y múltiples variables procesadas por algoritmos complejos. Pero los usuarios no confiaban suficientemente en ellas: las editaban manualmente de forma sistemática, reduciendo el valor real de la automatización. A este comportamiento lo llamamos internamente el coeficiente de apuesta — la diferencia entre lo que el sistema proponía y lo que el usuario finalmente aceptaba. Nuestro reto era reducirlo.
La distancia entre lo que el sistema proponía y lo que el usuario aceptaba sin tocar. Reducir esa distancia era el encargo.
Esquema conceptual. Muestra la dirección del cambio de comportamiento, no cifras medidas.
El enfoque fue doble. Por un lado, trabajamos el coeficiente de apuesta directamente: haciendo visibles los factores que el algoritmo tenía en cuenta para generar cada propuesta, de forma que el usuario pudiera evaluarla en lugar de simplemente aceptarla o rechazarla. Por otro, rediseñamos el flujo de primera implantación de nuevas colecciones para reducir la carga cognitiva y facilitar que los usuarios confiaran en las recomendaciones sin perder la sensación de control.
El mismo algoritmo, otra relación con él.
El diagnóstico llegó antes que cualquier propuesta. La pregunta no era cómo mejorar el algoritmo, sino por qué quienes lo usaban lo corregían sistemáticamente.
Entrevistas con usuarios clave
Entrevistas con quienes trabajaban en el flujo, para entender por qué no confiaban en las propuestas del sistema.
Análisis de sesiones grabadas
Revisión de sesiones reales para ver cómo se trabajaba de verdad con las propuestas.
Mapeo de fricciones
Mapeo de las fricciones del flujo existente, donde apareció el patrón de edición sistemática.
El ejercicio de visión fijó el techo. MoSCoW, la alineación con stakeholders y el roadmap son lo que convirtió ese ideal en un plan de entrega y no en una lista de deseos.
Ejercicio de visión
Una versión ideal del producto, desarrollada sin limitaciones técnicas.
MoSCoW
Cada mejora clasificada en must, should, could o won't have.
Alineación con stakeholders
Objetivos y limitaciones reales, acordados con quienes responden de ellos.
Creación de roadmap
Un plan estratégico para implementar las mejoras de forma progresiva.
Must have
Sin ello la entrega no funciona.
Should have
Importante, pero la entrega sobrevive sin ello.
Could have
Merece la pena si el margen lo permite.
Won't have
Deliberadamente fuera de esta entrega — y dentro del roadmap.
El flujo se diseñó entero de una vez, sin límites técnicos. Recortar hasta lo que se podía construir fue una segunda decisión, aparte — y las pantallas quedaron planteadas para que los pasos que se dejaron fuera entren en un sitio que ya existe.
Los pasos punteados se diseñaron junto al resto, no se añadieron después. Cada uno tiene su sitio reservado en pantallas ya entregadas.
Con el alcance acordado, el trabajo pasó a definir el flujo en detalle y a ponerlo delante de usuarios antes de construirlo.
Arquitectura de información
Reestructuración de la arquitectura de información y del modelo de navegación para reducir la carga cognitiva del flujo.
Diseño del nuevo flujo
Un proceso iterativo: cada ronda de diseño se revisaba y volvía a entrar en la siguiente.
Colaboración con producto
Trabajo cercano con el product manager para definir requisitos y funcionalidades.
Validación de componentes
Con el equipo de diseño, validando la experiencia de usuario y los componentes visuales.
Prototipos interactivos
Prototipos que simulaban la experiencia final para poder probarla de verdad.
Data Science e Ingeniería
Trabajo estrecho con los equipos técnicos para que las decisiones de diseño fueran viables y los datos que justifican cada propuesta estuvieran disponibles.
El diseño no terminaba en la entrega: se validaba antes de construirlo, se acompañaba mientras se construía y se revisaba una vez construido.
Validación pre-desarrollo
Pruebas y validaciones con distintos equipos internos, y reuniones con clientes reales.
Soporte durante el desarrollo
Asistencia y colaboración con el equipo técnico mientras las pantallas se construían.
Validación post-desarrollo
Verificación de la calidad del diseño y de la implementación funcional de lo desarrollado.
Caso de estudio completo disponible bajo solicitud.