Convertir la incertidumbre en dirección de producto.
Un programa de Discovery global basado en evidencia que convirtió información fragmentada en una dirección de producto validada, antes de escribir una sola línea de código.
Panorama de sistemas que muestra las plataformas operativas, los servicios de diagnóstico y las fuentes de datos que informan el ecosistema de producto más amplio.
Resumen del proyecto
Un programa de Discovery conectado, no una serie de actividades de investigación aisladas.
El reto, en breve
Las personas que gestionaban cuentas empresariales estaban desbordadas por información fragmentada: las alertas críticas estaban dispersas en múltiples sistemas internos, cada uno mostrando información distinta en momentos distintos, con poca consistencia en cómo debía priorizarse realmente el trabajo. La dirección creía que una asistencia inteligente podría ayudar, pero no había evidencia de que fuera la respuesta correcta, ni de si la gente confiaría lo suficiente en ella como para adoptarla. En lugar de comprometer inversión en ingeniería basándose en suposiciones, el programa se propuso reunir evidencia primero.
En lugar de comprometer inversión en ingeniería basándonos en suposiciones, primero necesitábamos evidencia.
“¡Tenemos más información que un banco! Hay insights ahí fuera que no tenemos tiempo de revisar. Deberíamos reducir, sustituir y centralizar, ya que los insights están desagregados en distintas fuentes.”
Mi papel, en breve
Lideré el flujo de trabajo de UX de todo el programa, siendo responsable de convertir la incertidumbre organizativa en una dirección de producto validada. Planifiqué y dirigí un esfuerzo de Discovery en varias fases que abarcó cinco regiones globales, moderando personalmente la mayoría de las entrevistas, talleres y sesiones de usabilidad, y fui responsable de la forma de la solución de principio a fin: service blueprints, modelo de interacción, arquitectura de la información y los requisitos funcionales de producto sobre los que se construyó el concepto.
Impacto, en breve
A lo largo de 5 regiones globales, el programa reunió evidencia de 100 entrevistas iniciales, 190 participantes y 260 respuestas a encuestas, y después validó la dirección a través de 40+ sesiones de evaluación de prototipos y 5 Pruebas de Concepto programadas. Concluyó con una dirección de producto validada, un modelo de priorización basado en evidencia, service blueprints del estado futuro y requisitos funcionales de producto — aportando confianza ejecutiva basada en evidencia global en lugar de en suposiciones, sin comprometer antes inversión en ingeniería basada en suposiciones.
El reto
Este programa no empezó con la IA. Empezó con las personas que gestionaban cuentas empresariales, y los equipos más amplios que las apoyaban, desbordados por información fragmentada.
Las alertas críticas estaban dispersas en múltiples sistemas internos, cada uno mostrando información distinta en momentos distintos, con poca consistencia en cómo debía priorizarse realmente el trabajo. Los usuarios encontraban con frecuencia información inconsistente al cambiar entre herramientas operativas y fuentes de datos, comparando manualmente informes y decidiendo qué merecía atención primero.
La dirección creía que una asistencia inteligente podría ayudar, pero no había evidencia de que fuera la respuesta correcta, de qué debía hacer exactamente, ni de si la gente confiaría lo suficiente en ella como para adoptarla.
En lugar de comprometer inversión en ingeniería basándonos en suposiciones, primero necesitábamos evidencia.
La tarea por delante era más grande que diseñar una interfaz. Significaba entender cómo trabajaba realmente la gente a través de regiones, tipos de cliente y modelos de negocio, antes de decidir qué, si acaso, debía construirse.
Mi papel
Lideré el flujo de trabajo de UX de todo el programa, siendo responsable de convertir la incertidumbre organizativa en una dirección de producto validada, no simplemente de producir investigación o diseñar pantallas.
A lo largo del programa, planifiqué y dirigí un esfuerzo de Discovery en varias fases que abarcó cinco regiones globales, moderando yo mismo personalmente la mayoría de las entrevistas, talleres y sesiones de usabilidad. Cuando el idioma o la experiencia local lo hacían poco práctico, dirigí a facilitadores regionales manteniéndome responsable de la síntesis y el criterio, de modo que el estándar de evidencia se mantuviera consistente en todos los lugares donde se desarrolló el programa.
Más allá de la investigación, fui responsable de la forma de la solución de principio a fin: convirtiendo flujos de trabajo fragmentados en service blueprints, definiendo el modelo de interacción y la arquitectura de la información, y traduciendo la evidencia en los requisitos funcionales de producto sobre los que se construyó el concepto. Sin capacidad interna de ingeniería disponible, colaboré con una empresa externa de ingeniería para convertir esa dirección en Pruebas de Concepto programadas en cuatro plataformas. También lideré el nombre y la identidad visual del concepto, y sintetizé todo el programa en la recomendación ejecutiva sobre la que finalmente actuó la dirección.
Cada etapa redujo deliberadamente la incertidumbre antes de avanzar a la siguiente inversión.
El recorrido de diez etapas detrás de los cinco capítulos que siguen.
Información fragmentada, todavía sin evidencia de una solución.
Entender el problema antes de diseñar nada.
Trazando cada sistema que alimenta el flujo de trabajo actual.
Entender el servicio antes de diseñar la interfaz.
Probar si se confiaba en el propio concepto.
Iterar el prototipo con evidencia real.
Entender cómo juzga realmente la gente la urgencia.
Convertir ese razonamiento en un modelo, no en una suposición.
Probar la implementación antes de la inversión real.
Dirección basada en evidencia, no la opción más emocionante.
Descubrimiento e investigación de usuarios
Entender el problema antes de diseñar una solución. Lo que este capítulo eliminó: la incertidumbre sobre el propio problema.
Nuestro primer objetivo fue cuestionar las suposiciones, no confirmarlas. A través de entrevistas, encuestas y talleres en todas las regiones, exploramos cómo gestionaba realmente la gente demandas contrapuestas, y dónde estaba la fricción real.
El problema no era simplemente “demasiadas alertas”. Era una toma de decisiones fragmentada.
Las entrevistas y los talleres sacaron a la luz diferencias significativas por región, tipo de cliente y rol: algunos compañeros gestionaban una única cuenta estratégica, otros gestionaban cientos de cuentas en cientos de ubicaciones. Esas diferencias, no una única persona promediada, acabaron moldeando cada decisión posterior. Este capítulo también sacó a la luz problemas que el caso de negocio original no había previsto, entre ellos, principalmente, información duplicada, comunicación ineficaz y fatiga de decisión.
“¡Tenemos más información que un banco! Hay insights ahí fuera que no tenemos tiempo de revisar. Deberíamos reducir, sustituir y centralizar, ya que los insights están desagregados en distintas fuentes.”
Mapeo de afinidad y síntesis de los hallazgos de investigación utilizados para identificar patrones de comportamiento, puntos de fricción operativos y áreas de oportunidad que informaron la experiencia del estado futuro.
Trazando el ecosistema
Diseñar el servicio antes de diseñar las pantallas. Lo que este capítulo eliminó: la incertidumbre sobre cómo debían comportarse las alertas a lo largo de todo el servicio.
Antes de diseñar una sola interfaz, tracé cómo se movían las alertas por la organización, rastreando más de treinta tipos de alertas operativas a través de múltiples sistemas, roles de usuario y procesos de negocio. Esto reveló dónde se originaba la información, cómo fluía entre equipos, y dónde los usuarios experimentaban una complejidad innecesaria.
En lugar de optimizar pantallas individuales, diseñé el propio servicio del estado futuro. El trabajo estableció una arquitectura de servicio escalable que cubría tanto alertas sensibles al tiempo como no sensibles al tiempo, definiendo comportamientos consistentes, puntos de decisión, procesos de trastienda, responsabilidades operativas y recorridos de usuario antes de que empezara el diseño de la interfaz.
Que la organización pudiera generar una alerta no significaba que el usuario debiera recibirla.
“Me costaría trabajar con 89 alertas… eso simplemente no pasaría.”
Estos service blueprints se convirtieron en la referencia compartida para Producto, Ingeniería y Diseño, alineando a todos en torno a cómo debía funcionar el servicio antes de decidir cómo debía verse.
Sensibilidad temporal y prioridad
Uno de los descubrimientos más significativos de la investigación fue que el problema no era simplemente el número de alertas que recibían los usuarios.
El verdadero reto era entender qué alertas requerían realmente atención, cuándo requerían acción, y qué se esperaba que hicieran los usuarios a continuación.
Desarrollé una estrategia de alertas del estado futuro que cubría tanto alertas sensibles al tiempo como no sensibles al tiempo, estableciendo una relación consistente entre urgencia, prioridad y comportamiento del usuario antes de que empezara cualquier diseño de interfaz.
Estos principios se convirtieron en la base del ciclo de vida de las alertas, el marco de priorización y el service blueprint del estado futuro.
Explora el Marco del Ciclo de Vida de Alertas
Documentación de apoyo del programa de diseño de servicio.
Puntos clave del Service Blueprint
- Service blueprint del estado futuro que cubre las alertas sensibles al tiempo.
- Definió interacciones de cara al público, procesos de trastienda y responsabilidades operativas.
- Estandarizó el ciclo de vida de las alertas en múltiples sistemas empresariales.
- Identificó carencias de servicio, puntos de fricción operativos y oportunidades antes de invertir en ingeniería.
- Estableció patrones de servicio reutilizables que informaron cada interfaz posterior.
Ese principio se convirtió en la base de cada decisión de diseño que siguió.
Validando el concepto
Validar el concepto pronto. Lo que este capítulo eliminó: la incertidumbre sobre si el propio concepto era el correcto.
Antes de cualquier inversión en ingeniería, probé un prototipo interactivo mediante sesiones moderadas que combinaban un laboratorio de usabilidad presencial con investigación remota en todas las demás regiones.
El objetivo nunca fue validar una interfaz. Era averiguar si la gente confiaba en el concepto.
“Todo está en una vista resumida y será como una vista de pájaro.”
“Para mí es perfecto porque es corto, directo, va al grano. No quiero tener que entrar en cada notificación. Así que para mí me dice exactamente qué es, para quién, qué es, cuál es el problema. Así que lo veo de inmediato.”
La gente necesitaba entender la lógica detrás de la priorización y sentir genuinamente que reducía su esfuerzo, evidencia que moldeó la siguiente iteración mucho antes de que se escribiera cualquier código.
Investigación moderada con usuarios: entender el apetito y las necesidades de los usuarios respecto a un sistema centralizado, mediante investigación moderada que combinó un laboratorio de usabilidad presencial e investigación remota.
Pruebas de usabilidad presenciales
Planifiqué, construí y dirigí el primer programa de pruebas de usabilidad presenciales y remotas de la organización: reclutamiento, diseño del prototipo, facilitación y entrevistas, hasta la observación, la síntesis y la incorporación directa de los hallazgos al diseño de producto.
Investigación remota con usuarios
Sesiones de investigación moderadas remotamente utilizadas para validar conceptos con participantes de múltiples regiones, permitiendo retroalimentación rápida y un refinamiento iterativo a lo largo de todo el proceso de diseño.
Diseñando el modelo de decisión
Lo que este capítulo eliminó: la incertidumbre sobre cómo debían resolverse realmente las prioridades contrapuestas.
Una pregunta seguía sin respuesta: cuando varias cosas exigían atención a la vez, ¿qué debía decidir el sistema mostrar primero? En lugar de responder eso nosotros mismos, construimos un programa de investigación de priorización dedicado: talleres que sacaron a la luz cómo razonaba la gente sobre la urgencia, el riesgo, el impacto en el cliente y el esfuerzo, seguidos de una encuesta que validó esos patrones a escala.
El resultado no fue otra interfaz. Fue un modelo de decisión basado en evidencia.
“¿Quizá si eres el gerente y ves que esto es una alerta de alta prioridad, puedes asignar una tarea a tu gente?”
Ese modelo se convirtió en la lógica detrás del motor de priorización integrado en la Prueba de Concepto. También sacó a la luz una variación regional genuina, que surgió a través de los talleres y la encuesta y no de ninguna prueba visual: algunos mercados ponderaban más el tamaño del cliente, otros el riesgo contractual. Esa evidencia moldeó directamente cómo una futura versión del modelo podría adaptarse por región y rol, en lugar de imponer una única regla a todos.
Talleres de priorización
Planifiqué y facilité talleres de priorización multifuncionales en torno a las necesidades de los usuarios, el valor operativo y las prioridades de negocio.
Los resultados de estos talleres ayudaron a definir los requisitos que finalmente informaron el algoritmo de priorización y la futura estrategia de alertas.
Talleres de priorización multifuncionales que ayudaron a definir los requisitos para el futuro algoritmo de priorización.
Confianza en la ingeniería
Validar el enfoque de ingeniería. Lo que este capítulo eliminó: la incertidumbre sobre cómo debía construirse realmente el concepto.
Solo una vez validado el propio concepto, el programa pasó a las Pruebas de Concepto programadas. En colaboración con un equipo externo de ingeniería, traduje la dirección de UX en versiones funcionales en cuatro plataformas, nunca pensadas como software de producción, sino como una forma de probar enfoques de implementación antes de comprometer inversión interna en ingeniería.
Se evaluaron múltiples conceptos programados. La gente prefería sistemáticamente la experiencia móvil independiente, pero la evidencia contaba una historia distinta: la mayoría trabajaba principalmente desde portátiles, muchos no tenían teléfono proporcionado por la empresa, y una aplicación separada probablemente quedaría sin usar.
“Me parece muy interesante que esté en el mismo sistema que ya usamos…”
No era la opción más emocionante. Era la opción con más probabilidades de tener éxito.
Esa recomendación es la evidencia más clara del propósito de todo el programa: el criterio, basado en evidencia, por encima de la preferencia personal.
Validando pruebas de concepto programadas: retroalimentación de clientes sobre usabilidad, deseabilidad y encaje operativo antes de invertir en ingeniería.
Resultado
El programa tuvo éxito, no lanzando software, sino eliminando la incertidumbre que habría convertido el lanzamiento de software en una apuesta.
Lo que entregó fue una dirección de producto validada, un modelo de priorización basado en evidencia, service blueprints del estado futuro, requisitos funcionales de producto, Pruebas de Concepto funcionales y, lo más importante, confianza ejecutiva basada en evidencia global en lugar de en suposiciones.
Ver con más detalle: Usar investigación y datos para impulsar el diseño (PDF) →
De la incertidumbre a la dirección de producto.
El programa concluyó con un vídeo de concepto que reunió meses de investigación, priorización y validación en una única visión para los interesados. En lugar de presentar funcionalidades aisladas, demostró cómo la evidencia había moldeado cada aspecto de la experiencia propuesta.
Una nota al pie sobre el nombre: este programa empezó su vida como “Digital Co-Pilot” — antes de que existiera el Copilot de Microsoft, da la casualidad. Cuando la colisión de nombres se volvió inevitable, lideré el cambio de marca a Nexa, dando forma al nuevo nombre y a la identidad junto con el trabajo de producto anterior.
Vídeo de presentación del concepto: visión ejecutiva que muestra la dirección de producto validada, el modelo de interacción y el enfoque de priorización.
Lo que esto demuestra
Un buen Discovery no demuestra que una idea sea correcta. Le da a una organización suficiente evidencia para tomar una decisión con confianza, sea cual sea esa decisión.
El programa empezó entendiendo la información fragmentada y la toma de decisiones. Solo más tarde surgió la asistencia inteligente como una posible capacidad dentro de la dirección validada, nunca como la razón por la que existía el trabajo.
El mayor valor aquí nunca fue la interfaz. Fue convertir la ambigüedad en una decisión con la que una organización pudiera comprometerse de verdad.
Ese es el trabajo de un Diseñador de Producto Principal: criterio estratégico, pensamiento sistémico y la disciplina de recomendar lo que realmente tendrá éxito, no simplemente lo más emocionante de construir.
Descubre la misma disciplina aplicada a otra escala.