Cada año se lanzan miles de aplicaciones. Muchas tienen todo el dinero, la mejor tecnología y diseños increíbles, pero igual fracasan. ¿La razón? Se enfocaron tanto en crear el producto que olvidaron entender primero qué problema querían solucionar.

¿Qué es realmente el Discovery?

El Discovery no es solo hacer entrevistas o recopilar datos. Es una etapa estratégica que ocurre antes del diseño y desarrollo, cuyo objetivo no es crear funcionalidades, sino generar claridad.

Se puede comparar con la construcción de una casa: antes de levantar paredes, es vital entender el terreno, las necesidades de los habitantes y el presupuesto disponible. Los pilares del Discovery son:

1. Alinear el negocio y el usuario: Encontrar el equilibrio entre los objetivos comerciales y las necesidades reales del cliente
2. Reducir la incertidumbre: Sustituir suposiciones por evidencia para minimizar riesgos costosos en etapas avanzadas
3. Validar hipótesis: Probar ideas mediante prototipos o MVPs antes de invertir recursos en desarrollo completo.

El costo de omitir el Discovery

Cuando un equipo decide saltarse esta etapa para «ganar tiempo», suelen aparecer consecuencias críticas que afectan la rentabilidad y salud del proyecto.

• Retrabajo: Ajustes drásticos en flujos o diseños cuando el producto ya está avanzado.
• Sobrecostos: Cada cambio en fases tardías es significativamente más caro.
• Funciones sin valor: Construir herramientas que nadie usa, aumentando la complejidad innecesariamente.
• Baja adopción: El caso de Windows 8 es un ejemplo histórico; Microsoft rediseñó la interfaz pensando en pantallas táctiles cuando la mayoría de sus usuarios seguía en computadores tradicionales, resultando en una experiencia confusa y poco natural.

Anatomía de un Discovery bien ejecutado

Para que esta etapa sea efectiva, debe responder a cuatro dimensiones fundamentales.

• Negocio: ¿Qué busca la empresa? (Ej. aumentar conversiones o reducir costos).
• Usuario: ¿Qué problemas enfrenta y cómo los resuelve hoy?
• Problema: Definir con claridad qué vale la pena resolver antes de proponer soluciones.
• Validación temprana: Probar la dirección estratégica con experimentos simples.

Caso Práctico: Agendamiento de Citas Médicas

Durante el webinar, se presentó una comparativa visual entre dos aplicaciones que lucían igual de modernas, pero funcionaban de forma distinta [00:21:00]:

1. Flujo Sin Discovery: Basado en supuestos. Presentaba un listado abrumador de doctores desde el inicio, obligando al usuario a filtrar y decidir sin guía. Al finalizar, el flujo simplemente se cerraba sin ofrecer pasos siguientes.
2. Flujo Con Discovery: Basado en la comprensión del usuario. El sistema guiaba al paciente por categorías (ej. «primera hora disponible»), reduciendo la carga cognitiva. Al confirmar la cita, ofrecía acciones relevantes como «ver mis citas» o «gestionar recordatorios», cerrando el ciclo de manera útil.

Lección clave: Agregar más pasos o vistas no siempre hace el flujo más complejo; a menudo lo simplifica al evitar que el usuario se sienta abrumado por demasiada información en una sola pantalla.

Preguntas Frecuentes del Webinar

• ¿Cuánto tiempo toma? Generalmente de 2 a 4 semanas, dependiendo de la complejidad y cantidad de usuarios.

• ¿Quiénes deben participar? Se requiere un equipo multidisciplinario: Product Owner, diseñadores UX/UI, desarrolladores y stakeholders del área de negocio o ventas.