Notas · Proceso

Benchmarking no es copiar a la competencia.

Es una de las palabras más malentendidas del diseño de producto. Se la asocia con espiar lo que hacen otros para copiarlo un poco mejor. Pero en UX el benchmarking bien hecho no se trata de la competencia. Se trata de tus usuarios, y de todo lo que ya aprendieron a usar antes de llegar a vos.

Cuando arranco un proyecto, en algún momento aparece la pregunta: "¿ya miraste lo que hace la competencia?". La intención es buena, pero la forma de plantearlo casi siempre lleva al lugar equivocado. Y ni hablar de la connotación negativa que la palabra competencia genera en algunas personas (pero eso no viene al caso de esta nota).

Mirar a la competencia para diferenciarse suena estratégico. En la práctica, termina en una lista de funcionalidades que el otro tiene y nosotros no, y en la ansiedad de igualarlas. Eso no es benchmarking. Eso es hacer inventario del vecino.

El benchmarking es un método de investigación. Se hace en las fases iniciales de un proyecto para entender cómo distintos productos resuelven un mismo problema, sean o no competidores directos. No busca una lista de qué copiar. Busca entender el terreno en el que tu producto va a existir: qué convenciones ya están instaladas, qué patrones la gente da por sentado, dónde hay consenso y dónde hay espacio real para hacer algo distinto.

No confundir con análisis competitivo

Por eso traducir benchmarking como análisis competitivo no es 100% correcto. Estos términos se confunden todo el tiempo, pero responden preguntas distintas. El análisis competitivo mira contra quién competís y cómo te diferenciás en el mercado: es un eje de negocio y posicionamiento. El benchmarking mira cómo se resuelve un problema puntual, en la competencia o fuera de ella: es un eje de solución y diseño.

Por eso el mejor benchmark de un proceso de pago puede venir de un producto de otra industria que resolvió ese flujo con excelencia, aunque no compita con vos en nada. Se tocan —tus competidores también son buena materia de estudio— pero no son lo mismo: uno ordena el mercado, el otro ordena decisiones de diseño. Esta nota va del segundo.

Por qué importa tanto en UX: tu persona usuaria no vive en tu producto

Acá es donde una ley de usabilidad le da fundamento a todo esto. Y no es una opinión de diseño, es una de las bases del comportamiento de las personas usuarias.

Ese tiempo construye modelos mentales. Expectativas sobre dónde va el carrito, cómo se ve un botón activo, qué pasa cuando toco un ícono de guardado, dónde busco el menú.

Cuando alguien llega a tu producto, no llega en blanco. Llega con años de hábitos formados en otros lados. Si tu interfaz contradice esos hábitos sin una razón que valga la pena, la persona no piensa "qué diseño original". Piensa "no entiendo cómo se usa esto". La familiaridad casi siempre le gana a la originalidad.

Y acá se cierra el círculo con el benchmarking. Esas convenciones que tu usuario trae puestas no viven en tu cabeza ni en la del cliente. Viven afuera, en los productos que esa persona usa todos los días. El benchmarking es, literalmente, la forma de ir a estudiarlas.

Con un límite que conviene tener claro. El benchmarking te deja observar el ecosistema de convenciones que probablemente contribuye a formar las expectativas de tu usuario. No te dice qué modelo mental tiene realmente esa persona, ni por qué, ni si esa convención funciona para tu audiencia en particular. Para eso necesitás investigación con usuarios. El benchmarking ordena el terreno; no reemplaza salir a preguntar.

Aun con ese límite, no es un lujo de proyectos grandes. Es la manera de no diseñar a ciegas contra las expectativas de la gente.

Cómo se hace uno que sirva

Un benchmarking no es abrir diez pestañas y sacar capturas hasta cansarse. Es un ejercicio con estructura, y su calidad depende menos de la cantidad de productos que del criterio con el que se lo aborda. Lo pienso en cuatro momentos.

1. 01

   Elegir qué analizar

   Como punto de partida, cinco a siete productos suele ser suficiente para detectar patrones sin convertir el ejercicio en una investigación interminable. No es una regla universal, es una heurística práctica. Y no tienen que ser todos competidores directos: a veces el mejor aprendizaje sobre cómo resolver un flujo no viene de otro producto de tu rubro, sino de alguno que resolvió ese mismo problema con excelencia en otra industria.

2. 02

   Definir los criterios antes de mirar

   Este es el paso que separa un benchmarking de una recorrida sin rumbo. Antes de abrir nada, defino qué voy a observar y por qué, siempre atado a los objetivos del proyecto. Los criterios pueden ser generales —contenidos, navegación, estructura— o específicos —cómo se resolvió la búsqueda, el onboarding, un flujo puntual—. Todo va a una tabla: los criterios en las filas, los productos en las columnas, con espacio para anotar. La tabla no es burocracia. Es lo que después me deja comparar en serio en lugar de recordar en desorden.

3. 03

   Analizar con ojos de primera vez

   Recorro cada producto como si lo usara por primera vez, prestando atención a los criterios que definí. Anoto lo que funciona —buenas prácticas que vale la pena tener presentes— y lo que genera fricción —cosas que quiero evitar—. Y registro todo con imágenes: las capturas de los momentos más relevantes son lo que sostiene el análisis y evita que se vuelva pura memoria.

4. 04

   Sintetizar en conclusiones aplicables

   La parte que más se saltea, y la única que le da valor a todo lo anterior. Reviso las anotaciones y las convierto en un informe: los productos analizados, los criterios usados, el análisis de cada uno, y un resumen que recoja fortalezas, debilidades y recomendaciones de diseño concretas para el proyecto. Un benchmarking que termina en capturas sueltas no sirve. Uno que termina en decisiones, sí.

Lo frecuente no es lo mismo que lo correcto

Algo importante a tener en cuenta. Que seis de siete productos resuelvan algo de la misma manera no significa que esa sea la mejor solución. Puede significar que hay una convención sólida que a tu usuario le conviene encontrar. O puede significar simplemente que todos heredaron el mismo patrón, que existe una restricción técnica que lo empuja, o que nadie se tomó el trabajo de cuestionarlo.

Detectar un patrón es el principio del análisis, no el final. La pregunta que sigue no es "¿cuántos lo hacen así?", sino "¿por qué lo hacen así, y le sirve a mi usuario?". Una solución que funciona bien en una interfaz puede ser un error en otra: el contexto de uso cambia todo.

El error que lo vuelve inútil

Hay una forma de hacer benchmarking que se ve prolija y no sirve para nada: la que se usa para confirmar lo que ya se había decidido. Se elige la referencia que le da la razón a la idea que traíamos, se ignora la que la contradice, y se sale del ejercicio exactamente igual que como se entró, pero con la sensación de haber investigado.

El benchmarking no está para validar tus supuestos. Está para ponerlos a prueba. Si termino el análisis y ninguna de mis ideas iniciales se movió, lo más probable es que no miré con honestidad.