Las reglas de oro del diseño de interfaces (2013)
(cs.umd.edu)- Los 8 principios de diseño de interfaces de Ben Shneiderman son criterios prácticos que pueden aplicarse a la mayoría de los sistemas interactivos, aunque requieren validación y ajustes según cada área de diseño.
- La terminología y las acciones consistentes, la usabilidad universal y la retroalimentación informativa son condiciones básicas para que el usuario pueda predecir y comprender los cambios de estado.
- El flujo de trabajo debe agruparse en unidades con inicio, desarrollo y cierre, y al completarse debe ofrecer una confirmación clara para que al usuario le resulte fácil pasar a la siguiente acción.
- La prioridad debe ser prevenir errores y, cuando ocurran, ofrecer instrucciones concretas de recuperación y una reversión sencilla para reducir la ansiedad del usuario.
- Si se pone en el centro la sensación de control y una baja carga de memoria, es posible mejorar la productividad y la sensación de dominio en interfaces móviles, de escritorio y web.
Naturaleza de los principios y alcance de aplicación
- Ben Shneiderman condensó un amplio conocimiento sobre diseño de interfaces de usuario en unas cuantas Golden Rules, organizándolas como pautas aplicables a la mayoría de los sistemas interactivos.
- Estos principios surgieron de la experiencia y se han refinado durante más de 30 años, pero en áreas de diseño específicas requieren validación y ajustes adicionales.
- La lista inicial de 1985 también fue recibida como una guía útil para estudiantes y diseñadores, y Jakob Nielsen, Jeff Johnson y otros añadieron variaciones y ampliaciones.
- Esta versión corresponde a la sección 3.3.4 de Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition.
Las 8 reglas de oro del diseño de interfaces
-
Buscar la consistencia
- En situaciones similares se necesita una secuencia de acciones consistente.
- Deben usarse los mismos términos en prompts, menús y pantallas de ayuda.
- Los colores, la disposición, el uso de mayúsculas y las tipografías también deben ser consistentes en general.
- Las excepciones, como confirmar un comando de eliminación o no mostrar lo que se escribe al ingresar una contraseña, deben ser comprensibles y limitadas.
-
Buscar la usabilidad universal
- Es necesario reconocer las necesidades de distintos tipos de usuarios y contar con un diseño flexible que facilite la transformación del contenido.
- Las diferencias entre principiantes y expertos, edades, discapacidades, diferencias internacionales y diversidad tecnológica amplían el alcance de los requisitos.
- Las explicaciones para principiantes y los atajos y funciones de avance rápido para expertos elevan la percepción de calidad de la interfaz.
-
Proporcionar retroalimentación informativa
- Toda acción del usuario debe ir acompañada de retroalimentación de la interfaz.
- Para acciones menores y frecuentes basta una respuesta simple, pero para acciones poco frecuentes e importantes se necesita una respuesta más sustancial.
- Presentar visualmente el objeto de interés facilita mostrar con claridad los cambios.
-
Diseñar flujos de interacción que den sensación de cierre
- Las secuencias de tareas deben organizarse en grupos con inicio, desarrollo y cierre.
- La retroalimentación informativa al final de un grupo de tareas aporta sensación de logro, alivio y señal de preparación para la siguiente tarea.
- En un sitio web de comercio electrónico, un ejemplo es el flujo que va desde la selección de productos hasta el pago y cierra la transacción con una página de confirmación clara.
-
Prevenir errores
- Siempre que sea posible, la interfaz debe diseñarse para que el usuario no pueda cometer errores graves.
- Algunos ejemplos son desactivar opciones de menú inapropiadas o no permitir letras en un campo de entrada numérica.
- Si ocurre un error, deben ofrecerse instrucciones de recuperación simples, constructivas y específicas.
- No se debe obligar al usuario a volver a llenar todo un formulario de nombre y dirección por un solo código postal incorrecto; debe guiársele para corregir solo la parte equivocada.
- Una acción incorrecta no debería cambiar el estado de la interfaz o, si lo hace, debe proporcionarse una forma de restaurarlo.
-
Permitir una reversión fácil
- Siempre que sea posible, las acciones deben poder deshacerse.
- La reversión reduce la ansiedad porque da al usuario la seguridad de que puede cancelar errores, y también lo anima a explorar opciones desconocidas.
- La unidad de reversión puede ser una sola acción, una tarea de entrada de datos o un grupo de tareas como un bloque de nombre y dirección.
-
Mantener al usuario en control
- Los usuarios experimentados desean con fuerza sentir que controlan la interfaz y que la interfaz responde a sus acciones.
- Los cambios inesperados, la modificación de acciones familiares, la entrada de datos tediosa, la dificultad para obtener la información necesaria y las situaciones en las que no se puede producir el resultado deseado incomodan al usuario.
-
Reducir la carga de la memoria de corto plazo
- La capacidad humana de procesar información en la memoria de corto plazo es limitada y, como regla práctica, puede recordar alrededor de “7±2 chunks”.
- Deben evitarse las interfaces en las que el usuario tenga que recordar información de una pantalla para usarla en otra.
- Un teléfono móvil no debería exigir volver a ingresar un número telefónico, la ubicación dentro de un sitio web debería mostrarse siempre y los formularios largos deberían comprimirse para caber en una sola pantalla.
Criterios prácticos que obtiene el diseñador
- Estos principios deben interpretarse, refinarse y ampliarse según cada entorno.
- Aunque tienen limitaciones, son un buen punto de partida para diseñadores móviles, de escritorio y web.
- La entrada de datos simplificada, las representaciones comprensibles y la retroalimentación rápida e informativa se enfocan en aumentar la productividad del usuario.
- Una buena interfaz debe ayudar al usuario a sentir competencia, dominio y control sobre el sistema.
1 comentarios
Opiniones en Hacker News
Aunque no siempre se considera parte del "diseño" de una UI, el rendimiento también se pasa por alto con frecuencia.
Una UI con mal rendimiento prácticamente rompe todas estas reglas de diseño. Mi smart TV Sony con Android se ve excelente, pero la UI es tan lenta que en la práctica resulta casi inutilizable.
Una UI inestable que cambia todo el tiempo también viola la mayoría de los principios. Las smart TV son especialmente malas en esto: el diseño de la pantalla de inicio y la ubicación de los íconos de las apps cambian seguido sin una buena razón.
Además, una queja personal que me molesta cada vez más son los íconos sin etiqueta. Muchas veces ni siquiera tienen tooltips, y si tienes que googlear la documentación para saber cómo se llama un botón, ese diseño de UI es malo.
La gente joven se concentra en interfaces difíciles de usar, y esa dificultad funciona como una característica de insiders que excluye a la generación de sus padres.
Un buen diseñador conversa con los desarrolladores sobre cómo la UI que propone afecta el rendimiento, y ayuda a hacer concesiones cuando ingeniería toma decisiones técnicas visibles para el usuario.
La UI no solo tenía cientos de íconos pequeños, sino que la documentación también usaba esos mismos íconos. El manual decía cosas como "primero haz clic en [], luego presiona [] y por último ve a [] para hacer []".
Hablo de una versión muy temprana de V5, hace mucho tiempo; espero que ahora haya mejorado.
Todo lo demás se parece más a programar.
Escucho los mismos dos podcasts de noticias todas las mañanas, pero las recomendaciones de la app se mezclan cada mañana sin ninguna razón.
Lo más molesto es que, al iniciar, la app muestra por un momento el diseño de ayer, se congela alrededor de un segundo mientras carga y luego reordena los elementos. En ese instante siempre termino tocando por error el elemento que se está moviendo, y es extremadamente frustrante.
Un diseñador con el que trabajé hace unos años explicó de forma excelente por qué la consistencia es importante.
No se trata de una paleta de colores limitada ni de una elección de tipografía que nadie va a notar. Perseguir reglas minuciosas termina produciendo software terrible. Algunas personas confunden reducir la variedad de la UI con aumentar la consistencia.
Lo central es permitir que el usuario se vuelva experto en ese software.
Ese diseñador ponía como ejemplo Microsoft Office. La gente se enorgullece de "saber" Microsoft Office y, como percibe la inercia de "Office", se mueve con naturalidad entre varias apps. Siento lo mismo con Vim. Simplemente sabes cómo debería funcionar algo, y un plugin nuevo bien hecho normalmente respeta ese patrón.
Office y (Neo)Vim no son ejemplos de UI sobresaliente, pero sí son excepcionalmente estables.
Por ejemplo, cuando muestras cuatro opciones, podrías usar un combobox de elementos seleccionables con búsqueda de [Insert UI Library], adaptado al tema de marca, o simplemente mostrar radio buttons o checkboxes comunes con etiquetas. Lo segundo es mejor en todos los sentidos.
Con solo ver círculos y cuadrados, el usuario sabe si debe elegir una sola opción o varias; puede ver las cuatro opciones; no aparece el teclado móvil para "buscar" y tapar todavía más una pantalla pequeña; y la accesibilidad casi siempre queda cerca del 100%.
Pero esa opción falla en el rubro de "combina de forma linda con nuestro sistema de diseño", así que los diseñadores normalmente eligen la primera y, peor aún, la estandarizan hasta convertir el uso de widgets comunes en un "bug".
Al final, demasiados "diseñadores UX" veneran la estética y el branding a costa de todo lo demás. Los widgets de UI no son el lugar para expresar marca o creatividad. Es como no deberías crear una tipografía propia que obligue a que cada letra tenga forma de logo. Al cliente le importa más poder terminar su trabajo que la marca.
Dañó mucho la capacidad de encontrar la función que necesitabas.
Siempre es algo especial ver a alguien que no se considera técnico moverse a toda velocidad en Excel.
Las reglas de diseño de UI de Microsoft son bastante impresionantes. Gracias a años de consistencia, la gente puede seguir usando el software aunque lo actualicen cada 1 o 2 años. No lo digo porque sea fan de Microsoft.
La clave de una actualización son los cambios incrementales que mejoran la UX. Dicho eso, no entiendo por qué el equipo de diseño no rechazó que Win 95 introdujera el concepto de "clic derecho en cualquier lugar para propiedades y configuraciones/detalles más profundos". Era una función invisible, porque no le mostraba al usuario dónde se podía hacer clic derecho. Parece que durante los primeros usos de Win 95 nadie entendía lo del clic derecho.
Estoy de acuerdo en que la pericia es relevante, pero creo que hace falta conectar un poco más por qué la consistencia lleva a la pericia.
La consistencia consiste en extender, como interés compuesto, lo que el usuario ya sabe del sistema hacia otras partes del mismo. Si el sistema es consistente, el esfuerzo invertido en aprender X e Y también te permite entender Z y W, porque funcionarán de la misma manera. En un sistema inconsistente, se obtiene mucho menos valor de la inversión de aprendizaje previa.
Office, al menos a largo plazo, no es estable. La infame cinta fue una triste desviación de una UI de Word que era estable y eficiente, y la incomprensible regresión de Microsoft en toda la plataforma Windows empeoró el problema. Por ejemplo, quitar la barra de menús de las aplicaciones. No tengo idea de por qué hicieron eso.
Una “regla” más que me gustaría que se incluyera es exponerle al usuario el modelo conceptual
Si no se entiende el modelo conceptual del producto, por muy bien etiquetados que estén los íconos, siempre habrá confusión. Por ejemplo, imaginemos un producto con un comando “New Configuration”: para empezar, no queda claro qué es una “Configuration”. ¿Es una plantilla que permite definir otros objetos? ¿Una forma de cambiar rápidamente entre varios conjuntos de opciones? ¿Un contenedor como una carpeta?
La UI debería diseñarse de modo que el usuario pueda inferir el modelo conceptual simplemente explorando la interfaz. Eso no siempre es fácil
La parte de “por ejemplo, cuando un usuario ingresa un código postal incorrecto, no hay que hacerlo volver a ingresar todo el formulario de nombre y dirección, sino guiarlo para que corrija solo la parte incorrecta” es el mayor punto de frustración, y todavía se ve con frecuencia
Este principio también debería respetarse al avanzar y retroceder en formularios de varias páginas
También es importante que “una acción incorrecta no debería cambiar el estado de la interfaz y, si lo cambió, debería indicar cómo volver al estado original”
En pantallas pequeñas como las de teléfonos y relojes, los diseñadores que intentan ahorrar espacio dependen cada vez más de los íconos. Pero muchos íconos son desconocidos o difíciles de interpretar, y a veces solo se entiende qué hacen después de tocarlos. Esos íconos deben tener necesariamente una forma de volver al estado original si uno se equivoca
Ya es un problema cuando intento iniciar sesión con correo electrónico y contraseña, pero si presioné “¿Olvidaste tu contraseña?”, por favor no me mandes a un formulario que me pide volver a ingresar ese mismo correo que acabo de escribir
La frase “pon en gris los elementos de menú que no sean apropiados” tiene una condición
Si no queda claro por qué están en gris, no debería hacerse. El comando debería permanecer habilitado y, si al hacer clic no puede usarse en ese momento, un mensaje de error debería explicar por qué. Hacer que el usuario tenga que averiguar por qué un comando está deshabilitado es frustrante
La excepción es cuando es muy probable que el usuario pierda mucho tiempo hasta el final antes de enterarse de que no puede usarlo
Lectura relacionada: https://medium.com/@vedranio/james-bond-and-the-design-of-di...
Parece una forma de quedarse con lo mejor de ambos mundos
Una app de tareas hace esto. Los comandos premium no se distinguen visualmente de los gratuitos, así que uno termina haciendo clic en ellos seguido, y cada vez aparece un cuadro de diálogo de suscripción que interrumpe todo el flujo
Para mí, eso es un error grave de UI
Una UI que deshabilita ciertas acciones sin decir el motivo siempre me enfurece
Las 10 heurísticas de usabilidad de Nielsen sirven como una buena estrella polar
https://www.nngroup.com/articles/ten-usability-heuristics/
La página de NN hace que la información sea mucho más fácil de absorber, es más concisa y el diseño de la página es mucho mejor
Ambos artículos contienen información y orientación que vale la pena tener en cuenta, pero resulta irónico que la página original adopte esas viejas convenciones de mismo tamaño de letra y párrafos que la página de NN descartó
También frustra que Hacker News no siga parte de esta información. Al editar un comentario existente, después de presionar el botón “update”, la retroalimentación no es lo bastante clara. Supongo que vuelve a dibujar la pantalla
Hay que dejar de usar UI que insertan algo justo en el lugar que estaba por seleccionar y hacen que uno toque lo equivocado
Puede que esto viole algunas de las reglas anteriores, o que sea un problema que se pueda mitigar, pero personalmente es algo que me vuelve loco y lo considero un error especialmente grave
Falta una regla importante. Hubo una época en la que parecía demasiado obvia: hay que distinguir la información estática de los elementos interactivos
Además, los elementos interactivos que no se puedan aplicar no deberían ocultarse, sino ponerse en gris. Así el usuario aprende que esa función existe, dónde está y qué condiciones debe cumplir para usarla
Relacionado con eso, nunca hay que depender de una UI de escondidas donde algo aparece solo cuando el usuario pasa el cursor por casualidad. Uno está tratando de terminar una tarea, no de explorar un calendario de Adviento
Una regla de oro que aprendí es que, una vez dibujada la interfaz, los elementos no deben moverse inesperadamente
Google es especialmente malo en esto: los botones se mueven entre el momento en que levantas el pulgar y cuando tocas la pantalla, pero no es solo Google
Si el objetivo apareció de nuevo dentro de aproximadamente 0,25 segundos antes de ser tocado, no debería generarse el evento táctil. Por la velocidad de reacción humana, no se puede apuntar y tocar un botón tan rápido
Estas son claramente reglas de oro de una utopía
La mayoría no se opondría a este tipo de reglas
Aun así, la mayoría de los desarrolladores seguramente ha tenido que lidiar con interfaces que rompen estas reglas con frecuencia. No porque no las entendieran o no quisieran aplicarlas, sino porque el costo en ese momento era demasiado alto
Por ejemplo, poder deshacer es muy difícil, y solo es posible si las estructuras de datos debajo de la aplicación se diseñan desde el principio con eso en mente. La prevención de errores es similar: saber exactamente qué es un error ya es difícil y costoso, y ofrecer feedback perfecto en el lenguaje del usuario es aún mucho más complejo