usability - tipos - tecnicas de usabilidad
¿Cuáles son algunas buenas pautas de usabilidad que un desarrollador promedio debería seguir? (17)
No soy un especialista en usabilidad, y realmente no me importa serlo.
Solo quiero un pequeño conjunto de reglas generales que pueda seguir al codificar mis interfaces de usuario para que mi producto tenga una usabilidad decente.
Al principio, pensé que esta pregunta sería fácil de responder "Usa tu sentido común", pero si es tan común entre nosotros los desarrolladores, no tendríamos, como grupo, reputación de nuestras interfaces horribles.
¿Alguna sugerencia?
Solo dos cosas, realmente:
- "Una interfaz de usuario está bien diseñada cuando el programa se comporta exactamente como el usuario pensó que sería" - citado en Joel Spolsky''s User Interface Design For Programmers
- Pon tus diseños en frente de un usuario. Un verdadero usuario final es el mejor, pero para una retroalimentación ligera y rápida, no se puede superar las pruebas de usabilidad en el pasillo, es decir, agarrar a un compañero de trabajo.
Si recuerdas el consejo de Joel y te aseguras de recibir retroalimentación sobre lo que sea que hagas y actuar en consecuencia, es decir iterar, no te equivocarás demasiado. Y me haría eco de la recomendación de Do not Make Me Think de Steve Krug; probablemente sea el mejor libro relacionado con el trabajo que he leído, sin excepción, y es tan aplicable al software de escritorio como a los sitios web.
Espero que esto ayude.
Evita los modos . Es frustrante para un usuario cuando la entrada funciona a veces pero no a otros, o hace cosas diferentes en momentos diferentes.
Lea Do not Make Me Think por Steve Krug . Es un excelente punto de partida y una breve lectura fácil.
EDITAR: Esto se debe principalmente a la usabilidad de la web, pero aún sería una buena lectura, incluso si está haciendo clientes ricos.
- No haga que las cosas funcionen de manera diferente a lo que sus usuarios esperan (es decir, rompiendo el botón "Atrás" cuando usa Ajax en formularios web)
- Sigue al director de KISS
En realidad, cualquier regla que alguien publique será una variación del tema: No hagas pensar a tus usuarios
"Do not Make Me Think" ya ha sido publicado, vea también Diseño de cosas cotidianas y Diseño con estándares web que también son excelentes para la lectura de facilidad de uso.
Piensa en los usuarios que usarán tu aplicación. ¿Por qué lo están usando y en qué contexto?
- ¿La mayoría serán usuarios profesionales que conozcan el dominio en el que se utiliza la aplicación y la usen mucho? Entonces no tenga miedo de agregar una gran cantidad de datos a las pantallas, siempre y cuando se organice lógicamente para los usuarios (normalmente eso no está en orden alfabético :-). Piense en las pantallas de comercio para los borkers comunes o las cabinas de los aviones.
- ¿Los usuarios son usuarios ocasionales? Mantenlo simple. Evite los cambios de contexto (mantenga todo / tanto como sea posible de los datos necesarios para una tarea en la pantalla en cada momento). No rompa las expectativas sobre cómo funcionan los widgets de GUI. Diseño para fallas.
- Cualquier cosa en el medio? Permitir que los usuarios crezcan en la interfaz de usuario. Haga un seguimiento del uso para que luego pueda determinar dónde parece que los usuarios pasan más tiempo para que pueda mejorar las áreas más usadas de su aplicación.
- Pruebe su aplicación con amigos y colegas (la prueba de corredor) para ver si pueden usarla de manera eficiente.
Eso es un comienzo.
Sugiero leer estas publicaciones de blog de los creadores de Enso .
Por supuesto, repiten guías / ideas / consejos de libros tales como
El Diseño de las Cosas cotidianas y Acerca de la cara , pero sin embargo, las publicaciones contienen bastantes ideas y (IMO) son una buena lectura.
Qué información necesita tu usuario, ponlo en la pantalla y nada más. Si no puede definir lo que el usuario necesita, obtenga otro usuario.
Recuerde que su aplicación será una de las muchas con las que deberá lidiar el usuario. No hagas cosas solo para ser diferente o kewl. No proponga gráficos, comportamientos, terminología o interacciones inusuales. Use los controles, convenciones, utilidades y comportamientos estándar de sistema operativo.
Deje que su aplicación interactúe con otras aplicaciones; permita cortar y pegar datos, guarde sus datos en formatos que otras aplicaciones puedan leer y permita importar datos de otras aplicaciones en lugar de usar su UI.
Si está creando una aplicación de escritorio, no intente tomar el control de la computadora del usuario. Deje solo la carpeta Documentos, la barra de tareas y las preferencias de la aplicación del usuario. No cambie nada que ya esté instalado en la computadora. Permitir interacciones con guiones o secuencias de comandos.
Si está creando una aplicación web, no intente controlar el navegador. No intente subvertir las barras de menú, el historial, el diseño o las fuentes estándar. Permitir al usuario cambiar la página usando Javascript.
Además de las otras recomendaciones aquí, recomendaría Designing Interfaces by Jenifer Tidwell como una buena forma de familiarizarse con las convenciones de UI.
Además, los internos están ejecutando el asilo Por Alan Cooper es excelente para proporcionar una idea de cómo abordar el diseño de interacción.
Proporcione atajos de teclado para usuarios avanzados (incluso si es tan simple como "presionar enter para buscar")
No pongas demasiado en la pantalla a la vez.
Si aparece un cuadro de mensaje, sus usuarios generalmente no lo leerán.
Un buen seguimiento de Do not Make Me Think es Robert Hoekman ''s Designing the Obvious . Está más enfocado en aplicaciones web, a diferencia de sitios web como en Krug''s.
(1) Las acciones comunes deben requerir el menor esfuerzo posible y deben ser obvias ; por otro lado, las acciones que raramente se necesitan pueden requerir muchos pasos y pueden ocultarse detrás de menús y diálogos. Para poder hacerlo, siempre debe describir lo que el usuario querrá hacer con la aplicación al enumerar los casos de uso .
(2) Una IU debe ser autodocumentación . El manual debe integrarse en los diálogos y menús de la aplicación, ya que los usuarios no leen los manuales por separado. Por ejemplo, el atajo de teclado debe mostrarse en el elemento de menú que representa la acción a la que está asociado.
He publicado preguntas relacionadas:
Aquí hay algunas reglas simples:
- Menos clics son mejores.
- Las funciones utilizadas con frecuencia deberían ser más fáciles de encontrar.
- Las características para usuarios "avanzados" pueden ser más difíciles de encontrar que las anteriores.
Piense en la cantidad de clics de mouse / teclado que le toma al usuario llegar a algo.
PD: por favor, no le digas a las personas de Microsoft Office 2008 sobre esto; ¡los pobres pequeños llorarían para dormir esta noche! :)
- Simple es mejor que complejo
- El complejo es mejor que complicado (elimina ''ifs anidados'')
- Intuitivo (buenos elementos no necesitan explicación)
- Siga la convención (por ejemplo, subrayado significa enlace, rojo significa error, pestaña va al siguiente campo, etc.)
- Use la semántica para aplicar la lógica (el encabezado lee primero, los párrafos a continuación)
- el espacio en blanco es importante
El único consejo más importante que le daría a alguien es trabajar primero en la interfaz de usuario. Pluma y papel y todo. De esta forma, no subconscientemente se asociarán botones a funciones, campos de entrada a variables, etc.
La mejor interfaz de usuario puede ser una molestia para el código, y si su código de back-end está escrito en su mayoría, se saboteará su pensamiento.
Aparte de eso, señalaría las Pautas de la interfaz humana de Apple . Por supuesto, si su plataforma no es OS X, tome las secciones de OS X con mucha sal. Lo que funciona en OS X podría no funcionar en Windows. Debes abrazar los modismos de tu plataforma.
A parte de OS X, ese documento tiene algunos puntos de partida bastante buenos sobre los fundamentos.