En corto: Un hallazgo no es una solución. Para transformar la investigación en una decisión de diseño es necesario separar lo que se observó, la explicación que se propone y el significado que tiene para la experiencia.
Después se define su impacto, se elige un mecanismo y se convierte en una hipótesis de interfaz que pueda validarse.
La cadena completa es:
Evidencia → interpretación → hallazgo → implicación → mecanismo → interfaz → validación
Este método puede aplicarse hoy mismo con una sola observación y un wireframe de baja fidelidad.
El problema: existe evidencia, pero todavía no una decisión
Entrevistas, pruebas de usabilidad, analítica y reportes de soporte suelen producir conclusiones como:
- “Las personas necesitan más claridad”.
- “El proceso genera confusión”.
- “El estado no es visible”.
- “El botón debe destacar más”.
- “La navegación no resulta intuitiva”.
Estas afirmaciones pueden señalar un problema real, pero todavía no explican con precisión qué ocurrió, por qué podría estar ocurriendo ni qué necesita resolver el diseño.
El error aparece cuando se salta directamente de la observación a una solución:
“Las personas no vieron el botón, por lo tanto, hay que hacerlo más grande.”
La propuesta puede ser correcta, pero también podría ignorar otras causas: el botón compite con acciones secundarias, aparece antes de que la persona lo necesite, utiliza un rótulo ambiguo o está separado del contenido que debe completarse.
Entre investigar y diseñar existe una actividad intermedia: convertir lo observado en una decisión justificable y comprobable.
Explicación de cada elemento de la cadena
1.- Evidencia: qué ocurrió
La evidencia describe una conducta o resultado observable.
Durante la tarea, 5 de 6 participantes no seleccionaron el botón “Continuar” y recorrieron otros elementos buscando cómo avanzar.
Si se utiliza una cantidad, debe provenir de la investigación realizada. No se agrega para hacer que el hallazgo parezca más importante.
Algunos equipos llaman highlight a este resumen de lo ocurrido. El término es menos importante que conservar la conducta sin mezclarla con una explicación.
2.- Interpretación: por qué podría estar ocurriendo
La interpretación propone una posible explicación:
“El botón podría estar compitiendo visualmente con otras acciones y elementos de la pantalla.”
No debe presentarse como una certeza si la investigación no comprobó directamente la causa.
Palabras como “podría”, “parece” o “la evidencia sugiere” ayudan a distinguir una interpretación de un hecho observado. No debilitan el análisis; muestran con claridad qué se sabe y qué continúa siendo una hipótesis.
3.- Hallazgo o insight: qué significa
El hallazgo relaciona la evidencia con la tarea afectada:
“La jerarquía de la pantalla no comunica con claridad cuál es la acción principal para continuar.”
Un insight útil no se limita a repetir la observación ni describe todavía un componente. Explica qué problema de comprensión o interacción existe detrás de la conducta.
Para formularlo conviene responder:
- ¿Qué intenta lograr la persona?
- ¿Qué necesita comprender?
- ¿Qué decisión no puede tomar con claridad?
- ¿Qué parte del recorrido está siendo afectada?
4.- Implicación: qué impacto produce
La implicación explica por qué el hallazgo merece atención:
“La dificultad para reconocer el siguiente paso aumenta el tiempo necesario para completar la tarea y puede provocar errores, solicitudes de ayuda o abandono.”
También aquí debe distinguirse lo observado del riesgo.
Si durante la prueba se registraron demoras, puede afirmarse que la tarea tomó más tiempo. Si nadie abandonó, el abandono debe presentarse como un riesgo, no como un resultado comprobado.
La implicación ayuda a priorizar y a explicar el problema ante Producto, Negocio o Desarrollo.
5.- Mecanismo: qué debe resolver el diseño
El mecanismo define la lógica de la solución antes de elegir su apariencia:
“Establecer una única acción principal y reducir la competencia visual con las acciones secundarias.”
Todavía no se decide el color, el tamaño o la posición exacta. Primero se determina qué debe lograr la experiencia.
6.- Interfaz: cómo se materializa
La interfaz convierte el mecanismo en una propuesta visible:
Mantener “Continuar” como único CTA primario, colocarlo cerca del punto donde termina la tarea y reducir la prominencia de las acciones secundarias. Su posición y tratamiento deberán conservarse en pantallas equivalentes.
La solución ya puede representarse mediante un wireframe o prototipo.
7.- Validación: cómo saber si funcionó
La validación comprueba la hipótesis de diseño:
Después de completar la información necesaria, observar si las personas reconocen y seleccionan “Continuar” sin orientación. Registrar si exploran otras acciones, cuánto tardan en identificar el siguiente paso y qué esperan que ocurra al seleccionarlo.
No se pregunta solamente si el nuevo botón “gusta”. Se comprueba si la nueva jerarquía permite reconocer el siguiente paso.
Método para transformar un hallazgo en interfaz
1. Registrar la evidencia sin incluir una solución
Puede utilizarse la siguiente estructura:
Durante [tarea], la persona [conducta observable] al intentar [resultado esperado].
Por ejemplo:
Durante el registro, la persona recorrió la pantalla y abrió un enlace secundario al intentar avanzar al siguiente paso.
Esta redacción conserva la conducta. En cambio, “el CTA necesita más contraste” ya introduce una solución.
2. Escribir la interpretación como hipótesis
La pregunta es:
¿Qué podría explicar la conducta observada?
Es recomendable plantear más de una posibilidad:
- El CTA compite visualmente con otras acciones.
- Su rótulo no comunica continuidad.
- Está separado del contenido que debe completarse.
- Aparece antes de que la persona lo necesite.
Considerar alternativas evita atribuir todo el problema al primer elemento visible.
3. Formular el hallazgo a partir de la tarea
El hallazgo debe explicar qué necesita comprender o decidir la persona.
Una estructura útil es:
Durante [tarea], la interfaz no comunica [información, relación o siguiente acción], lo que dificulta [resultado esperado].
Por ejemplo:
Durante el registro, la interfaz no comunica con claridad cuál es la acción principal, lo que dificulta continuar después de completar los datos.
4. Expresar la implicación
Se registra el efecto observado o el riesgo relacionado:
- Mayor tiempo para completar la tarea.
- Errores de selección.
- Uso de rutas innecesarias.
- Solicitudes de ayuda.
- Retrabajo.
- Riesgo de abandono.
- Incumplimiento de una condición relevante.
La implicación no debe exagerarse. Su función es explicar la consecuencia realista del problema.
5. Elegir un mecanismo antes del componente
La siguiente guía ayuda a identificar qué tipo de respuesta conviene explorar:
| Problema observado | Mecanismos posibles |
|---|---|
| No encuentra información | Navegación, búsqueda, accesos o reorganización |
| Interpreta incorrectamente un concepto | Rotulado, explicación, ejemplo o cambio de agrupación |
| No sabe qué está ocurriendo | Estado visible, retroalimentación o resumen persistente |
| No reconoce qué atender primero | Jerarquía, orden, proximidad o revelado progresivo |
| No sabe cómo continuar | Acción principal, dependencia o instrucción contextual |
| Comete un error difícil de recuperar | Prevención, validación, advertencia o recuperación |
| Necesita comparar información dispersa | Agrupación, tabla, resumen o vista comparativa |
La tabla no entrega automáticamente una solución. Su función es reducir el campo de exploración.
6. Traducir el mecanismo a jerarquía e interfaz
Una vez elegido el mecanismo, se decide:
- Qué debe aparecer primero.
- Qué debe permanecer visible.
- Qué elementos deben agruparse.
- Qué puede quedar en segundo nivel.
- Qué debe relacionarse con la acción principal.
- Qué elementos deben reducir su prominencia.
Un elemento importante no siempre necesita ser más grande. Puede necesitar una posición estable, cercanía con la tarea o menor competencia visual.
7. Definir cómo se validará
La validación debe corresponder con el cambio realizado:
- Si cambió el rotulado: ¿se interpreta como se esperaba?
- Si cambió la navegación: ¿se encuentra la información en el lugar previsto?
- Si cambió la jerarquía: ¿se identifica primero la condición necesaria?
- Si se agregó un estado: ¿puede explicarse qué ocurre y qué sigue?
- Si se agregó una advertencia: ¿se reconoce el riesgo y la forma de corregirlo?
- Si se modificó un CTA: ¿se reconoce como la acción principal y se anticipa correctamente su resultado?
Ejemplo completo: el CTA que nadie ve
El siguiente caso es hipotético y muestra cómo documentar toda la cadena.
| Campo | Aplicación |
|---|---|
| Evidencia | 5 de 6 participantes no seleccionaron “Continuar” y buscaron otra forma de avanzar. |
| Interpretación | El CTA podría estar compitiendo visualmente con acciones secundarias. |
| Hallazgo | La jerarquía no comunica cuál es la acción principal después de completar los datos. |
| Tarea afectada | Avanzar al siguiente paso del registro. |
| Comprensión necesaria | Reconocer que la información está completa y que “Continuar” es la siguiente acción. |
| Implicación | Aumenta el tiempo de la tarea y existe riesgo de error, frustración o abandono. |
| Mecanismo | Establecer una única acción principal y reducir la competencia visual. |
| Interfaz | Colocar “Continuar” cerca del final de la tarea, utilizar el tratamiento primario y reducir la prominencia de acciones secundarias. |
| Alternativa descartada | Aumentar únicamente el tamaño no resuelve la competencia ni la relación con el contenido. |
| Validación | Observar si se reconoce y utiliza “Continuar” sin ayuda después de completar los datos. |
La alternativa descartada también forma parte del razonamiento.
Explicar por qué no se eligió otra solución demuestra que la propuesta no nació de una preferencia visual, sino de una comparación entre mecanismos.
Ejercicio de 20 minutos
No es necesario esperar a tener una investigación completa. Puede utilizarse una observación reciente de una entrevista, prueba, reporte de soporte o revisión de producto.
Paso 1. Elegir una observación
Si no se cuenta con una, puede utilizarse este caso:
En una prueba de usabilidad de un sistema interno, se solicita a una persona verificar si una solicitud está completa y enviarla a revisión.
Antes de seleccionar “Enviar”, la persona abre consecutivamente los apartados “Datos del cliente”, “Documentos” y “Resultado de validaciones”. Después regresa dos veces a “Documentos” y revisa nuevamente el resumen general.
Aunque ya recorrió toda la información, no logra determinar si la solicitud cumple los requisitos para continuar y solicita ayuda para confirmarlo. En la interfaz, cada apartado muestra sus pendientes únicamente cuando se abre; no existe un resumen general que indique qué información está completa, qué falta y qué impide realizar el envío.
Paso 2. Completar la cadena
Responder:
- ¿Qué ocurrió?
- ¿Qué podría explicarlo?
- ¿Qué significa para la tarea?
- ¿Qué impacto observado o potencial produce?
- ¿Qué necesita comprender la persona?
- ¿Qué mecanismo podría resolverlo?
- ¿Qué otra alternativa se consideró?
- ¿Cómo se manifestaría en la interfaz?
- ¿Cómo se comprobará?
Paso 3. Dibujar un wireframe
No se necesita alta fidelidad. El boceto solamente debe mostrar:
- Orden.
- Agrupación.
- Estados.
- Acción principal.
- Información secundaria.
Paso 4. Revisar la trazabilidad
El ejercicio está resuelto cuando puede explicarse cómo la evidencia conduce al mecanismo y cómo el mecanismo se convierte en una decisión visible.
Lista de comprobación
Antes de presentar la propuesta, conviene revisar:
- ¿La evidencia describe algo observado y no una solución?
- ¿La interpretación está identificada como hipótesis?
- ¿El hallazgo explica qué significa la conducta para la tarea?
- ¿La implicación diferencia el impacto observado del riesgo potencial?
- ¿Se definió qué necesita comprender la persona?
- ¿El mecanismo responde al problema identificado?
- ¿Se consideró al menos una alternativa?
- ¿La interfaz materializa el mecanismo?
- ¿La validación comprobará la hipótesis y no solamente la aceptación visual?
Si alguno de estos puntos no puede completarse, no significa necesariamente que el diseño esté mal. Indica que puede faltar evidencia o que se saltó una decisión intermedia.
Conclusión
Convertir hallazgos en interfaz no significa reproducir literalmente lo que las personas dijeron. Significa distinguir hechos de hipótesis, comprender la tarea afectada, explicar su impacto, seleccionar un mecanismo y convertirlo en una propuesta comprobable.
Si no puede explicarse cómo la evidencia conduce al mecanismo y después a la interfaz, todavía no existe una decisión de diseño trazable. Esa dificultad no debe ocultarse con mayor fidelidad visual: señala exactamente qué falta comprender.
