Las diez heurísticas de Nielsen las encuentras explicadas en cualquier sitio. Lo que casi nadie cuenta es qué haces después: cómo evalúas de verdad una interfaz, cómo decides qué problemas son graves y cuáles son ruido, y cómo presentas los hallazgos para que alguien los arregle.
Esta guía va de eso. Del proceso, no de la definición.
Qué es un análisis heurístico (y qué no)
Un análisis heurístico es una evaluación de usabilidad en la que una o varias personas con experiencia revisan una interfaz comparándola con un conjunto de principios conocidos, y documentan los problemas que encuentran. El método lo formalizaron Jakob Nielsen y Rolf Molich a finales de los ochenta.
Su gran ventaja es que no necesitas usuarios. Puedes hacerlo en dos días, con poco presupuesto, y detectar una parte importante de los problemas antes de invertir en tests.
Su gran limitación es la otra cara de lo mismo: no estás observando a nadie. Estás aplicando criterio experto, y el criterio experto tiene sesgos. Un análisis heurístico te dice qué incumple un principio de usabilidad; no te dice si a los usuarios reales les importa.
Por eso no sustituye a un test con usuarios. Lo precede, lo complementa y, en el mejor de los casos, hace que ese test se centre en lo que de verdad no sabes.
Cuándo tiene sentido hacerlo:
- Antes de un rediseño, para saber de qué partes.
- Cuando heredas un producto que no conoces.
- Cuando hay métricas malas pero no sabes dónde está el problema.
- Cuando no hay presupuesto ni tiempo para investigación con usuarios.
Cuándo no:
- Cuando el problema es de producto, no de interfaz. Si nadie usa una funcionalidad, la heurística no te va a decir por qué.
- Cuando ya tienes datos de comportamiento que apuntan a algo concreto. Ahí ve directo a ese punto.
Las diez heurísticas, en una tabla
Aquí están las diez para tenerlas a mano durante la evaluación. Si quieres la explicación extensa de cada una, está en la página original de Nielsen Norman Group.
| # | Heurística | La pregunta que te haces |
|---|---|---|
| 1 | Visibilidad del estado del sistema | ¿El usuario sabe qué está pasando ahora mismo? |
| 2 | Relación con el mundo real | ¿Habla el idioma del usuario o el del sistema? |
| 3 | Control y libertad | ¿Puede deshacer, cancelar o salir sin miedo? |
| 4 | Consistencia y estándares | ¿Lo mismo se llama igual y se comporta igual en todas partes? |
| 5 | Prevención de errores | ¿Se puede evitar el error antes de que ocurra? |
| 6 | Reconocer antes que recordar | ¿Obliga a memorizar algo de otra pantalla? |
| 7 | Flexibilidad y eficiencia | ¿Hay atajos para quien ya sabe, sin estorbar a quien no? |
| 8 | Estética y diseño minimalista | ¿Lo importante compite con lo accesorio? |
| 9 | Recuperación de errores | ¿El mensaje dice qué pasó y cómo salir? |
| 10 | Ayuda y documentación | ¿Existe ayuda y se encuentra donde hace falta? |
La lista es la parte fácil. Lo que sigue es donde se decide si el análisis sirve para algo.
El proceso, paso a paso
1. Define el alcance antes de mirar nada
El error más común es abrir el producto y empezar a apuntar cosas. Acabas con cuarenta hallazgos repartidos por toda la aplicación y ninguno accionable.
Define primero qué vas a evaluar y qué no. Normalmente el alcance se define por flujos, no por pantallas: el registro, el checkout, la búsqueda, la creación de un elemento. Un flujo completo de principio a fin dice mucho más que diez pantallas sueltas.
Escribe también qué se espera que el usuario consiga en cada flujo. Sin eso no puedes juzgar si la interfaz lo está estorbando.
2. Elige a los evaluadores
Nielsen defendía que entre tres y cinco evaluadores detectan la mayoría de los problemas, y que a partir de ahí el retorno cae rápido. Con uno solo encontrarás en torno a un tercio.
Si trabajas solo, no es motivo para no hacerlo, pero sé consciente de la limitación: vas a encontrar lo que tu experiencia te permita ver, y te vas a saltar lo que das por sentado.
Un truco barato: pide a alguien de otra disciplina —soporte, comercial, desarrollo— que haga una pasada con la lista. Detectan cosas distintas porque miran el producto desde otro lado.
3. Evalúa por separado, no en grupo
Cada evaluador recorre los flujos por su cuenta y anota lo que encuentra, sin comentarlo con los demás. Esto importa: si evaluáis juntos, la primera persona que habla condiciona a las demás y perdéis justamente la diversidad de criterio que hace útil al método.
Haz dos pasadas por cada flujo. La primera, libre, para familiarizarte con el producto. La segunda, con la lista de heurísticas delante, buscando incumplimientos concretos.
Por cada hallazgo, anota tres cosas:
- Dónde: la pantalla o el paso exacto, con captura.
- Qué heurística incumple: si no encaja en ninguna, probablemente no sea un problema de usabilidad sino una opinión tuya sobre el diseño.
- Qué le pasa al usuario: la consecuencia, no la característica. No «el botón es gris», sino «el usuario no distingue si la acción está disponible».
4. Consolida los hallazgos
Ahora sí os juntáis. Se ponen todos los hallazgos en común, se agrupan los que son el mismo problema visto desde sitios distintos y se eliminan los duplicados.
Aquí suelen aparecer dos sorpresas. La primera: problemas que solo ha visto una persona y que resultan ser importantes. La segunda: problemas que ha visto todo el mundo y que, al discutirlos, resultan ser preferencia estética y no usabilidad. Las dos cosas son señal de que el proceso está funcionando.
Cómo priorizar: la escala de severidad
Esta es la parte que separa un análisis heurístico útil de una lista de quejas. Un informe con treinta problemas sin jerarquía no se implementa: se archiva.
Nielsen propone una escala de cinco niveles:
| Nivel | Significado | Qué hacer |
|---|---|---|
| 0 | No es un problema de usabilidad | Descartar |
| 1 | Cosmético | Arreglar solo si sobra tiempo |
| 2 | Menor | Prioridad baja |
| 3 | Mayor | Prioridad alta |
| 4 | Catastrófico | Imprescindible antes de lanzar |
Y la severidad no se asigna a ojo. Se calcula combinando tres factores:
Frecuencia. ¿Le pasa a todo el mundo o solo a quien entra por un camino raro? Un problema en el flujo principal pesa más que uno en un caso límite.
Impacto. ¿Puede el usuario superarlo por su cuenta o se queda bloqueado? Un botón mal alineado molesta; un mensaje de error que no dice qué hacer detiene la tarea.
Persistencia. ¿Se aprende y deja de ser un problema, o vuelve a tropezar cada vez? Los problemas que se aprenden bajan de severidad con el uso; los que no, se acumulan como fricción permanente.
Un problema puede ser cosmético en frecuencia y catastrófico en impacto. Cuando los tres factores no coinciden, gana el impacto: lo que bloquea al usuario se arregla primero.
Un ejemplo de cómo cambia la conversación. «El formulario de pago pide demasiados datos» es una queja. «El 60% de los usuarios abandona en el paso de pago; el formulario pide el NIF, que no es necesario para completar la compra y obliga a levantarse a buscar la cartera. Severidad 4: frecuencia alta, impacto bloqueante, persistente.» Eso es un hallazgo que alguien puede priorizar en un sprint.
Cómo presentar los hallazgos
El informe no es para ti. Es para quien tiene que decidir en qué invertir tiempo de desarrollo.
Lo que funciona:
- Ordenado por severidad, no por pantalla ni por heurística. Quien lo lee quiere saber qué arreglar primero.
- Una recomendación concreta por hallazgo. «Mejorar la claridad» no es una recomendación. «Eliminar el campo NIF del paso de pago y pedirlo solo en facturación» sí lo es.
- Con captura anotada. Ahorra media reunión.
- Separando lo que es problema de usabilidad de lo que es propuesta de mejora. Mezclarlos hace que se descarte todo junto.
Lo que no funciona: un documento de cuarenta páginas con las diez heurísticas explicadas al principio. Quien lo va a leer no necesita el marco teórico, necesita la lista de qué está roto.
Cómo aplico esto en Nexo Clinical
Las heurísticas se escribieron pensando en software de escritorio, usado por alguien sentado, con tiempo y sin consecuencias graves si se equivoca. Cuando las aplicas a un contexto distinto, algunas se tensionan entre sí.
En Nexo Clinical, una historia clínica electrónica para transporte sanitario urgente, el usuario trabaja de pie, en movimiento, con guantes y con un paciente delante. Tres heurísticas que en una web se llevan bien resultan incompatibles ahí:
Control y libertad del usuario (3) contra prevención de errores (5). La heurística 3 pide que se pueda deshacer. Pero un registro clínico deja traza legal: no se puede borrar una constante ya anotada como si fuera un carrito de la compra. La solución no fue eliminar el deshacer, sino distinguir entre corregir antes de firmar y rectificar después, con dos comportamientos distintos.
Estética y diseño minimalista (8) contra reconocer antes que recordar (6). Esconder lo secundario en menús desplegables reduce el ruido visual, pero en un servicio urgente cualquier campo puede volverse crítico sin aviso. Obligar a recordar dónde está algo es peor que mostrar de más.
Flexibilidad y eficiencia (7). La heurística asume dos perfiles: novato y experto. En una ambulancia es la misma persona, y su capacidad de atención depende de la gravedad del servicio, no de su experiencia con la aplicación. El atajo no puede estar escondido para el experto: tiene que estar disponible siempre, porque quien lo necesita es alguien que va con prisa, no alguien que domina el producto.
La conclusión práctica es que las heurísticas son un punto de partida, no un criterio de aceptación. Cuando dos se contradicen, decidir cuál gana es trabajo de diseño, y la decisión hay que poder defenderla con el contexto de uso, no con la lista.
Herramientas y plantillas
- Plantilla de análisis heurístico para Figma: estructura los hallazgos y la severidad sin montarte una hoja de cálculo.
- Optimal Workshop: para complementar con card sorting o tree testing si el problema es de arquitectura.
- Google Forms: suficiente para recoger los hallazgos de varios evaluadores de forma ordenada.
Conclusión
Un análisis heurístico no vale por la lista de principios. Vale por el proceso: definir el alcance, evaluar por separado, consolidar, priorizar por severidad y presentar de forma que alguien pueda actuar.
Si te lo saltas y vas directo a apuntar lo que no te gusta de una interfaz, tendrás un documento. Si sigues el proceso, tendrás una lista de decisiones.
Y cuando la aplicación que evalúas se usa en un contexto que Nielsen no imaginó —con prisa, con guantes, con consecuencias reales— la lista es solo el principio de la conversación.
Si quieres seguir por aquí: cómo medir la experiencia del usuario con métricas UX y cómo aplicar el diseño centrado en el usuario paso a paso.