SUS, UEQ o cuestionario propio: cómo medir la usabilidad de tu prototipo en el TFG de Informática (comparativa 2026)

El prototipo funciona. Has pasado cuatro meses con el backend, el frontend y el despliegue, y llegas al capítulo de evaluación con la sensación de que ahí no hay nada que hacer: enseñárselo a unos cuantos compañeros, preguntarles si les gusta y escribir dos párrafos.

Ese capítulo es exactamente donde se pierden los puntos de un TFG de Informática. El tribunal no va a discutir tu elección de framework, pero sí va a preguntar cómo sabes que lo que has construido sirve. Y «pregunté a diez amigos y les pareció bien» no es una respuesta.

La buena noticia es que no hay que inventar nada: existen instrumentos estandarizados, gratuitos, con datos de referencia publicados, que se administran en tres minutos. La decisión se reduce a cuál usar.

Lo primero: un cuestionario no mide la usabilidad entera

La norma ISO 9241-11 define la usabilidad con tres componentes: eficacia (¿consigue el usuario terminar la tarea?), eficiencia (¿a qué coste de tiempo y esfuerzo?) y satisfacción (¿cómo la percibe?).

Un cuestionario, sea el que sea, mide la tercera. Es percepción autoinformada. Si tu capítulo de evaluación consiste únicamente en una puntuación de satisfacción, has dejado dos tercios de la definición sin datos, y esa es la crítica más fácil de formular en una defensa.

La estructura que aguanta cualquier tribunal es doble:

• Métricas de comportamiento por tarea: define entre cuatro y seis tareas representativas, y para cada usuario registra si la completó, cuánto tardó y cuántos errores o peticiones de ayuda hubo. Se anota con un cronómetro y una hoja de cálculo; no hace falta instrumentación.
• Un cuestionario estandarizado al final, administrado después de las tareas y no antes, que captura la percepción global.

Con eso ya tienes eficacia, eficiencia y satisfacción, que es literalmente la definición de la norma. El resto de este artículo trata la segunda mitad.

SUS: diez preguntas y un número

La System Usability Scale la publicó John Brooke en 1996 y sigue siendo el instrumento de usabilidad más utilizado del mundo, por una razón muy práctica: son diez afirmaciones con una escala de acuerdo de cinco puntos, se responden en dos minutos y producen una única cifra entre 0 y 100.

Su rasgo de diseño más característico es que los ítems alternan polaridad: los impares están redactados en positivo («me gustaría usar este sistema con frecuencia») y los pares en negativo («encontré el sistema innecesariamente complejo»). Eso obliga a leer y frena la respuesta automática en línea recta.

El cálculo es aritmético y hay que hacerlo bien:

1. En los ítems impares, la contribución es la respuesta menos 1.
2. En los ítems pares, la contribución es 5 menos la respuesta.
3. Suma las diez contribuciones —el resultado va de 0 a 40— y multiplica por 2,5.

Aquí viene el error más repetido en los TFG: el resultado no es un porcentaje ni un percentil. Un SUS de 72 no significa «al 72 % de la gente le gustó». Es una puntuación en una escala de 0 a 100 que solo cobra sentido comparada con datos de referencia.

Y esos datos existen. A partir del análisis de varios centenares de estudios, la media del SUS se sitúa en torno a 68, y ese valor funciona como línea de flotación: por encima estás mejor que el sistema promedio, por debajo, peor. Trabajos posteriores han asociado tramos de puntuación a etiquetas verbales —de «pobre» a «excelente»— y a una escala de calificación tipo A–F en la que el sobresaliente empieza alrededor de 80.

Ese es el gran valor del SUS para un TFG: tu 74 significa algo fuera de tu trabajo. Un cuestionario propio no te da eso jamás.

UEQ: veintiséis pares de adjetivos y seis dimensiones

El User Experience Questionnaire, publicado por Laugwitz, Held y Schrepp en 2008, no usa escalas de acuerdo sino diferencial semántico: veintiséis pares de adjetivos opuestos —complicado/sencillo, aburrido/emocionante, convencional/original— con siete posiciones entre ellos. La diferencia de formato entre ambos enfoques está desarrollada en la comparativa de Likert, diferencial semántico y escala Stapel.

Lo que devuelve no es una cifra sino seis dimensiones: atractivo, claridad, eficiencia, fiabilidad, estimulación y novedad. Las tres primeras son de calidad pragmática —¿cumple su función?— y las dos últimas de calidad hedónica —¿resulta interesante usarlo?—. Las puntuaciones van de −3 a +3 y, por convención, un valor por encima de 0,8 se considera una valoración positiva y por debajo de −0,8, negativa.

El UEQ trae dos cosas que un TFG agradece: está disponible gratuitamente con traducciones oficiales a muchos idiomas, el español entre ellos, y se distribuye con una herramienta de análisis en hoja de cálculo que calcula las dimensiones y las sitúa automáticamente contra un banco de datos de referencia de cientos de productos, con categorías del tipo «excelente», «bueno», «por encima de la media». Existe además una versión corta de ocho ítems que reduce las seis dimensiones a dos meta-escalas, útil cuando el cuestionario se administra al final de una sesión larga.

La comparación, en una tabla

Por qué el cuestionario propio casi nunca compensa

Escribir diez preguntas sobre tu aplicación es fácil. Lo difícil es defender que esas diez preguntas miden algo.

Un instrumento nuevo exige, como mínimo: definir el constructo, redactar un banco de ítems, someterlo a juicio de expertos para la validez de contenido, ejecutar una prueba piloto, analizar su estructura factorial y estimar su fiabilidad. Eso es un TFG entero, y encima uno de Psicometría, no de Informática. Además, la estructura factorial necesita muestras que un proyecto de fin de grado no reúne: con quince usuarios no se valida ninguna escala.

Hay un caso legítimo, y es acotado: preguntas específicas de tu dominio que ningún instrumento estándar cubre —si la nomenclatura del sector se entendió, si un flujo concreto resultó natural—. La forma correcta de incorporarlas es como añadido, no como sustituto: administra el instrumento estandarizado completo y sin tocar, y detrás pon tus dos o tres preguntas propias, analizadas por separado y sin mezclarlas en ninguna puntuación agregada. Alterar los ítems de un SUS o de un UEQ invalida los datos de referencia, que eran justamente la razón de usarlos.

Y si lo que quieres es aplicar un instrumento validado por otro autor que no esté en abierto, hay un trámite previo: pedir permiso al autor del cuestionario. Tanto el SUS como el UEQ son de uso libre en investigación citando la fuente, lo que ahorra ese paso.

Cuántos usuarios necesitas

Aquí conviven dos preguntas distintas que se confunden constantemente.

Si quieres encontrar problemas de usabilidad, la evaluación es cualitativa y funciona con muy pocos participantes: cinco usuarios observados haciendo tareas destapan la mayor parte de los problemas graves de una interfaz, porque los fallos serios los tropieza casi todo el mundo. Ese es el famoso argumento del test con cinco usuarios, y es correcto para ese fin.

Si quieres una puntuación, la lógica cambia por completo, porque una media calculada sobre cinco personas tiene un intervalo de confianza enorme. Con doce a quince participantes empiezas a tener una estimación razonablemente estable del SUS de un sistema, y por debajo de diez la cifra es prácticamente anecdótica. Y si tu objetivo es comparar dos versiones y afirmar que una es mejor, entonces estás haciendo un contraste de hipótesis y necesitas el cálculo de tamaño muestral correspondiente: bastantes más de quince.

La salida honesta cuando la muestra es la que es —y en un TFG suele ser la que es— consiste en reportar la media con su desviación típica y su intervalo de confianza, y describir la evaluación como exploratoria en las limitaciones. Un intervalo ancho declarado vale mucho más que una media presentada como si fuese exacta.

Cómo se analiza y cómo se reporta

Con un solo sistema evaluado, el análisis es descriptivo: media, desviación típica, intervalo de confianza y la comparación con la referencia externa. Nada más. No hay contraste de hipótesis porque no hay dos grupos.

Si comparas dos versiones —tu prototipo frente a la herramienta que sustituye, o dos variantes de interfaz—, entonces sí hay contraste. Con los mismos usuarios probando ambas es un diseño de medidas relacionadas; con grupos distintos, independientes. La elección entre la prueba paramétrica y su alternativa está en la guía de t de Student frente a Mann-Whitney. Y acompaña siempre el p valor con un tamaño del efecto: con dieciséis participantes, «no significativo» casi nunca quiere decir «no hay diferencia».

Sobre la fiabilidad interna: puedes calcular el alfa de Cronbach de tu administración del SUS y reportarlo, y queda bien hacerlo. Recuerda invertir antes los ítems de polaridad negativa, o saldrá un valor absurdamente bajo. En el UEQ, la fiabilidad se calcula por dimensión, no sobre los veintiséis ítems juntos.

Describe además la muestra: cuántos participantes, perfil, experiencia previa con sistemas parecidos. La tabla de características de la muestra ocupa media página y contesta por adelantado la primera pregunta del tribunal.

Errores que cuestan nota

• Administrar el cuestionario sin que el usuario haya usado el sistema. Enseñar capturas y preguntar no mide usabilidad; mide opinión sobre unas imágenes.
• Traducir el instrumento tú mismo sobre la marcha. Existen versiones publicadas en español de ambos; usa una y cítala. Una traducción improvisada rompe la comparabilidad con los datos de referencia.
• Quitar o reordenar ítems «porque no aplican». Convierte un instrumento validado en un cuestionario propio, con todas sus desventajas y ninguna de sus ventajas.
• Evaluar con tus compañeros de clase y no decirlo. Es una muestra por conveniencia perfectamente admisible en un TFG, siempre que se declare como tal en las limitaciones.
• No incluir el instrumento en los anexos. El cuestionario administrado, la hoja de tareas y el consentimiento informado van al final de la memoria, junto con el resto de la documentación técnica del proyecto de Ingeniería Informática.

Entonces, ¿cuál elijo?

Regla corta: SUS por defecto. Es el instrumento más rápido, el más citado y el que mejor se compara con el exterior, y para una herramienta, un panel de gestión o un sistema interno mide justo lo que interesa. UEQ cuando la dimensión afectiva forma parte de tu objetivo —un videojuego, una app de consumo, una interfaz deliberadamente novedosa—, porque separa «funciona bien» de «resulta atractivo», y esa distinción da material real para el capítulo de discusión.

Nada impide administrar los dos: en total son treinta y seis ítems, unos siete minutos, y da dos ángulos sobre el mismo prototipo. Lo que no procede es un tercer camino: inventarse el instrumento.

Preguntas frecuentes

¿Un SUS de 68 está bien?

Está en la media. Es el valor de referencia habitual, así que un 68 significa «tan usable como el sistema promedio». Para hablar de un buen resultado hay que acercarse a 80.

¿Puedo pasar el SUS por formulario web en lugar de en persona?

Sí, y es lo normal después de una sesión presencial de tareas. Lo que no debe hacerse es distribuir el enlace a gente que no ha usado el sistema.

¿Sirve el SUS para evaluar una web o solo software?

Sirve para webs, aplicaciones móviles, hardware y sistemas de voz. Los ítems están redactados de forma deliberadamente genérica; solo hay que sustituir «el sistema» por el nombre de lo evaluado, y esa es la única modificación admitida.

¿Qué hago si un usuario no completa alguna tarea?

Se registra como tarea no completada —ese es tu dato de eficacia— y el participante responde igualmente el cuestionario. No lo excluyas: los fracasos son parte del resultado.

¿Necesito consentimiento informado para probar con usuarios?

Sí. Aunque no recojas datos sensibles, estás trabajando con personas: hoja de información, consentimiento firmado y datos anonimizados. Muchas escuelas de ingeniería lo exigen ya de forma explícita en el TFG.

¿El SUS distingue usabilidad y facilidad de aprendizaje?

Se ha propuesto una lectura en dos subescalas, con dos de los diez ítems agrupados como facilidad de aprendizaje. Es una interpretación razonable y se puede mencionar, pero la puntuación global sigue siendo el resultado principal.

¿Y si mi prototipo no está terminado?

Se evalúa igual, declarando el estado. Evaluar un prototipo de baja fidelidad es una práctica normal; lo que hay que hacer es escribir en la memoria qué estaba y qué no estaba implementado cuando se pasó la prueba.

Del dato al capítulo de evaluación

Una vez tienes las tablas de tareas y las puntuaciones, queda la parte que decide la nota: justificar el instrumento elegido, describir el protocolo con detalle suficiente para replicarlo, presentar los resultados y discutir qué implican para el diseño de tu sistema. Tesify trabaja con tus propios datos —no inventa participantes ni puntuaciones— y te ayuda a convertirlos en capítulos redactados, con la bibliografía en el formato que exija tu escuela.

Empieza gratis con Tesify y avanza tu TFG desde hoy. Más de 9.000 estudiantes ya lo usan, y el 100 % del texto sigue siendo tuyo.