Del benchmark a la decisión
En muchos equipos de producto, el benchmark empieza igual: una carpeta compartida llena de capturas, enlaces a webs “bien resueltas” y una hoja con nombres de competidores. Durante unos días, se revisan ejemplos, se comentan detalles y se apuntan ideas. Y luego, con bastante frecuencia, todo ese material se queda ahí parado.
La realidad es que ver lo que hace la competencia no cambia el producto por sí mismo. Lo que marca la diferencia es el salto posterior: convertir ese “mira qué bien lo hace X” en criterios claros, patrones adaptados y decisiones que se noten en las siguientes pantallas.
Ese salto, precisamente, es el que suele faltar.
El benchmark como pregunta, no como álbum de referencias
La primera trampa aparece antes de abrir ni una web: usar el benchmark como paseo turístico. “Vamos a ver qué hay por ahí” puede servir para calentar, pero no da mucho más.
Los benchmarks más útiles empiezan con una pregunta sencilla: ¿Qué decisiones de diseño tenemos por delante?
No es lo mismo mirar a la competencia porque viene:
- Un rediseño de navegación.
- Un nuevo flujo de alta.
- Una revisión de pricing.
- Una pantalla de estado para un sistema complejo.
Si el equipo no ha dicho en voz alta qué tiene que resolver, el benchmark se dispersa. Se compara todo con todo y la sesión termina en opiniones sueltas: “esto me gusta”, “esto no lo veo para nosotros”.
En cambio, cuando el equipo pone sobre la mesa preguntas como: “¿cómo presentan el riesgo?”, “¿cómo guían una firma digital?”, “cómo explican límites y comisiones?”, entonces mirar ejemplos ajenos se vuelve mucho más interesante. Deja de ser una galería de inspiración y se convierte en observación con intención.
De ejemplo a criterio: qué estamos viendo exactamente
El segundo paso consiste en dejar de ver “pantallas bonitas” y empezar a leerlas como decisiones de diseño.
Cuando alguien dice “me gusta este onboarding”, en realidad hay varias capas detrás:
- Número de pasos.
- Nivel de detalle de los textos.
- Tipo de ayudas: ejemplos, iconos, avisos.
- Tono con el que se piden los datos.
- Qué se deja para más adelante y qué se pide desde el inicio.
Si el equipo no descompone esos elementos, el benchmark se queda en una sensación estética. Si se despieza, de repente aparecen criterios y patrones.
Por ejemplo, en un proyecto reciente para una entidad financiera, analizamos varias formas de presentar condiciones antes de una firma digital. Anotamos cosas como:
- Tres productos muestran primero un resumen de condiciones antes de pedir datos.
- Dos marcan de forma muy visible las comisiones en la misma pantalla donde se acepta el contrato.
- Casi todas separan “datos personales” de “datos económicos”.
Eso ya no es “me gusta este banco”, sino una lista de decisiones concretas que otros han tomado, con las que se puede dialogar. Y lo mismo se puede hacer en proyectos relacionados con la salud, administración o SaaS B2B.
Traducir patrones a nuestro contexto
Una vez que se han visto varias soluciones, llega la parte delicada: no copiar, sino interpretar.
En este punto conviene hacerse algunas preguntas incómodas:
- ¿Nuestro volumen de usuarios, canales y casos de uso se parece al de esos ejemplos?
- ¿Compartimos nivel de riesgo, madurez y confianza?
- ¿Qué pasaría si aplicáramos tal cual esa misma solución en nuestro producto?
Muchas veces se descubre que lo que funciona en un gigante del sector, con un proceso muy guiado y un ejército de soporte 24/7 detrás, no encaja igual en una herramienta más acotada, con otro tipo de usuario.
Por eso es tan útil ir un paso más allá y formular patrones adaptados, del estilo:
- “En nuestro producto, cualquier acción con consecuencias económicas lleva una pantalla de confirmación con resumen de datos”.
- “Los avisos legales extensos se consultan en un enlace aparte; en pantalla mostramos solo lo imprescindible para tomar la decisión”.
- “Los datos sensibles de salud se muestran siempre con contexto, nunca aislados”.
Son frases que ya hablan de nuestro sistema, aunque hayan nacido mirando fuera. A partir de ahí, las nuevas pantallas dejan de improvisarse y empiezan a plegarse a un marco común.
Del benchmark al backlog
Hay un momento en el que el benchmark tiene que abandonar las presentaciones y aterrizar en tareas para incluir en el backlog. Si no, todo queda en “muy interesante” y poco más.
Una forma práctica de hacerlo es cerrar el análisis con tres listas:
- Lo que vamos a mantener tal cual: aspectos del producto actual que se han visto sólidos frente a la competencia.
- Lo que vamos a ajustar con guía clara. Cambios concretos, por ejemplo:
- Simplificar el primer paso de registro.
- Reescribir mensajes de error críticos.
- Reordenar secciones en una pantalla clave.
- Lo que queremos probar: ideas que merecen un test de usabilidad, un experimento o un prototipo antes de extenderlas al resto del sistema.
Cada punto puede traducirse en ítems de backlog, con responsables y contexto: no “hacer onboarding como X”, sino “reducir de 6 a 3 pasos y añadir un resumen final, siguiendo el patrón definido en el benchmark”.
Así, el trabajo previo no se queda en un informe, sino que se liga directamente a los siguientes sprints.
Contar lo que hemos decidido, no solo lo que hemos visto
Hay un último beneficio del benchmark bien cerrado que a veces pasa desapercibido: la capacidad de explicar decisiones hacia fuera.
Cuando se llega a una sesión con negocio o con tecnología con frases del estilo “nadie en el sector pide estos datos tan pronto”, “la mayoría muestra este aviso antes de la firma, no después”, o “somos el único que mete tres pasos más en este flujo”, la conversación cambia. Las decisiones de diseño dejan de parecer caprichos individuales y se apoyan en una lectura comparada del mercado.
El benchmark deja de ser una colección de pantallazos para pasar a ser un mecanismo de conversación. Ayuda a negociar prioridades, a justificar renuncias y a alinear expectativas.
Mirar lo que hace la competencia es sencillo. Lo difícil comienza justo después, cuando el equipo se sienta a traducir esas referencias en criterios, patrones y cambios concretos en el producto. Ahí es donde el benchmark deja de ser un ejercicio estético y se convierte, de verdad, en una herramienta de diseño.
Foto de portada de Rodrigo Rodrigues | WOLF Λ R T en Unsplash.
