El odio como señal de diseño

Cuando un usuario te dice que tu producto es una mierda en una feria, lo mejor que podés hacer es escucharlo.

Estaba en una convención especializada del rubro para el que trabajaba, charlando con gente junto al stand, cuando alguien se acercó y, sin ningún tipo de filtro, me soltó:

“Qué buscador de mierda que tienen. Nunca encuentro nada de lo que necesito. Por suerte para aceptar el pago funciona relativamente bien.”

Podría haberlo tomado como el comentario ácido de un usuario puntual. Pero hay algo que aprendí con el tiempo: es bastante inusual que alguien exprese un problema de usabilidad de forma tan concreta y directa. Cuando alguien llega a ese punto, generalmente representa a un grupo mucho más grande que simplemente no dice nada.

Al día siguiente fui a buscar al equipo que se ocupaba de esos usuarios. Les pregunté si habían tenido quejas sobre el buscador. El diseñador respondió sin titubear: “Sí, es una mierda. Nadie encuentra nada. Se armó así porque era la manera más rápida y nunca más se tocó.”

Esa frase lo resume todo y creo que todas las empresas tienen su versión de “se armó así por tal motivo y nunca más se iteró”, ya sea por falta de tiempo, de priorización, recursos o rotación de personas.

El problema es cuando eso le pasa a una funcionalidad crítica.

El error original

La plataforma para la que trabajaba era compleja: actuaba como intermediaria de financiamiento entre entidades comerciales , bancos, empresas y usuarios finales. No vendíamos nada. Mostrábamos líneas comerciales de financiamiento para pagar productos.

El error conceptual de base lo planteó muy bien el CEO de la compañía con una sola pregunta: “Cuando buscás para comprar un auto, ¿primero ves cómo lo vas a pagar, o primero buscás el auto que querés y después te fijás cómo se puede pagar?”

Version en producción anterior

Sin embargo, habíamos partido de la premisa equivocada: como la empresa ofrecía líneas comerciales, el buscador debía centrarse justamente en eso, y no tanto en el producto en sí. La consecuencia de esa decisión se amplificaba con otro problema: el mismo usuario podía ver tres valores distintos del mismo producto dependiendo de si estaba deslogueado, logueado, o logueado con una entidad bancaria asociada. Cuando empecé a trabajar ahí, la persona que me capacitó tuvo que explicármelo tres veces. Y eso no es un problema de mi comprensión — es un problema de diseño.

Encima, de vez en cuando había promociones que se sumaban a la misma pantalla. El resultado era un sistema que nadie terminaba de entender.

A medida que pasó el tiempo y la gente rotó de puestos, se llegó a la conclusión cómoda de que “el diseñador lo había armado mal”. Pero eso es una simplificación injusta. El diseñador a cargo hizo su mejor esfuerzo para satisfacer una lista interminable de requerimientos que varios departamentos habían ido agregando sin un criterio unificado. Probablemente no tenía poder de decisión suficiente para cambiar el rumbo.

El sistema crítico de búsqueda no funcionaba. Y el resultado era predecible: los usuarios ignoraban el buscador y contactaban directamente a sus distribuidores locales para que les ofrecieran opciones. El canal digital estaba siendo reemplazado por el teléfono.

Dos años después: el tablero en blanco

Cuando tomé la tarea ya con un rol de decisión como Product Designer, lo primero que hicimos fue establecer qué sabíamos con certeza:

• Menos del 14% de los usuarios entraba regularmente a la sección de búsqueda.
• El tiempo de permanencia promedio era de menos de 1 minuto.
• La recurrencia era de apenas el 10%, y en general correspondía a usuarios que también eran vendedores o representantes de empresas.

Esos números son desastrosos. Cuanto menos tiempo pasaban los usuarios explorando productos, menos oferta conocían y, por ende, hacían menos negocios a través de la plataforma — o los hacían de forma más acotada a través de sus vendedores de confianza.

Las preguntas que necesitábamos responder eran claras:

• ¿Al usuario realmente le interesa ver primero los medios de pago?
• ¿Le queda claro que los precios varían según su estado de sesión?
• ¿Qué busca? ¿Lo encuentra?
• ¿Cuál es nuestra tasa de “sin resultados”?

La hipótesis

Con eso en mente, formulamos una hipótesis de trabajo:

“Si el buscador se centrara en los productos primero, en las empresas segundo y por último en la financiación, los usuarios llegarían de manera más natural y granular a la información.”

A partir de ahí armamos una lista de features clave que queríamos incorporar:

• Los resultados estarían asociados al área geográfica del usuario (si estaba logueado).
• Los resultados se ordenarían por empresa, destacando las más relevantes o con más ventas.
• El buscador reconocería tanto el nombre legal como el nombre de fantasía de cada empresa — muchos usuarios buscaban “Agroquímicos Don José” y el sistema no devolvía resultados porque ese no era el nombre fiscal registrado.
• En caso de no encontrar resultados, el buscador sugeriría empresas y productos relacionados.
• Se incorporaría IA para entender búsquedas con errores ortográficos o variaciones.

Primer prototipo

En un día armamos un prototipo rápido que reflejaba estos cambios. Los principales eran:

• El usuario podía buscar por producto o empresa, con cualquier nombre.
• Al buscar por producto, veía todas las empresas que lo ofrecían, con filtros zonales. Si estaba logueado, las empresas de su zona aparecían primeras.
• Los “destacados” tenían un rol mucho menos protagónico, y se limpió la pantalla de información innecesaria, siguiendo una lógica de cascada: primero el producto, luego las empresas, al final las líneas de crédito.
• Se invitaba al usuario a continuar el proceso, y al loguearse se le informaba que, dado su historial, tenía precios preferenciales disponibles.

Salir al campo

Teníamos hipótesis, features y prototipo — todo en un día. Lo que seguía era validar o refutar la idea con datos reales.

El proceso fue simple y bastante comprimido dentro de un sprint:

1. Enviamos una encuesta a una muestra media de usuarios con preguntas básicas sobre su experiencia actual.
2. Coordinamos entrevistas con distintos tipos de usuarios.
3. Al final del sprint nos juntamos a comparar notas y ajustar el prototipo.

Los resultados fueron muy alentadores: 89% de tasa de aceptación con algunos cambios menores surgidos de los insights de las entrevistas.

Vender el cambio

Para presentar la propuesta a los stakeholders armamos una versión MVP que cambiaba la base estructural: el usuario buscaba primero el producto y lo último que veía eran las líneas disponibles. También agregamos una función de comparación y la posibilidad de compartir por WhatsApp, que resultó ser la forma más usada por los usuarios para pasarle opciones a sus clientes.

Hubo resistencia. El equipo comercial decía que faltaba información visible. Los desarrolladores pensaban que era un cambio demasiado grande. Pero los datos eran elocuentes:

• Uso de la sección: menos del 15%
• Recurrencia: 10%
• Tiempo de permanencia: casi inexistente
• Usuarios que consideraban necesario mejorar el buscador: 96% (según las encuestas)
• Tasa de aceptación del prototipo en entrevistas: más del 80%

Con eso sobre la mesa, no hubo mucho margen para el debate. Nos dieron luz verde y en 2 sprints teníamos la versión nueva funcionando.

Los KPIs que nos importaban

Antes del lanzamiento definimos qué íbamos a medir y por qué.

Adopción

• Tasa de uso del buscador
• CTR en la barra de búsqueda

Calidad y relevancia (engagement)

El promedio de menos de 1 minuto indicaba frustración: el usuario entraba, no encontraba nada y se iba. Queríamos que ese tiempo aumentara porque encontraba valor.

• Tasa de búsquedas sin resultados (zero-result rate)
• Click-through rate en resultados
• Tiempo de permanencia post-búsqueda
• Tasa de refinamiento de búsqueda

Retención y negocio Para atacar ese 10% de recurrencia:

• Tasa de recurrencia de búsqueda
• Tasa de conversión asistida por búsqueda

Las metas que seteamos fueron:

KPI Meta

Uso de la sección > 25%

Tiempo de permanencia > 2.5 minutos

Recurrencia > 25%

Búsqueda sin resultado < 5%

MVP Final de producción

Los resultados

Con el MVP en producción y el equipo de Marketing comunicando el “nuevo buscador”, medimos en dos ventanas: las primeras 3 a 6 semanas para señales tempranas, y el primer Q para la evaluación definitiva.

Los resultados al cierre del primer trimestre fueron:

KPI Resultado

Uso de la sección 75%

Tiempo de permanencia 3.1 minutos

Recurrencia 55%

Búsqueda sin resultado 1%

Reflexión final

Lo más valioso de la metodología lean no es el proceso en sí, sino la cultura que genera: la capacidad de cuestionar las premisas, salir rápido a validar y no quedar prisionero de decisiones tomadas en otro contexto, por otras personas, con otros objetivos.

En este caso, la empresa funcionó durante 2 años con una funcionalidad crítica rota. No porque nadie se diera cuenta — el propio Product Designer lo sabía. Sino porque se partió de una hipótesis inicial incorrecta, basada en un desconocimiento del cliente, y nadie tuvo el tiempo, el poder o el mandato para revisarla.

Vale la pena notar los tiempos: 1 sprint para armar y validar la hipótesis. 2 sprints para el desarrollo técnico y la implementación. Menos de un mes para resolver un problema que arrastraba dos años.

El usuario que me dijo en aquella convención que el buscador era una mierda tenía razón. Y fue la señal más honesta que alguien nos podría haber dado.

¿Tenés un caso similar en tu empresa? ¿Una feature que “se armó así” y nunca más se tocó? Me encantaría leerlo en los comentarios.