¿Cuáles son algunas buenas pautas de usabilidad que un desarrollador promedio debería seguir?

Question

No soy 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, una reputación de nuestras interfaces horribles.

¿Alguna sugerencia?

Answer 1

Lea Don't Make Me Think by Steve Krug. Es un excelente punto de partida y una breve lectura fácil.

EDITAR: Esto es principalmente para la usabilidad web, pero aún así sería una buena lectura, incluso si usted está haciendo clientes ricos.

Answer 2

• No hacer las cosas funcionan de manera diferente que sus usuarios están esperando (es decir, rompiendo el botón "atrás" cuando se utiliza Ajax en formularios web
• Siga el director de KISS

Realmente, ninguna entrada de reglas alguien va a ser una variación sobre el tema: no hace sus usuarios opinan

"no haga que pienso" ya ha sido publicado, consulta Design of Everyday Things y Designing with Web Standards que también son excelentes para la lectura de usabilidad liviana.

Answer 3

El 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 manera, no subconscientemente unirá los botones a las funciones, ingresará los campos a las variables, etc.

La mejor IU puede ser un dolor de código, y si su código de fondo está escrito en su mayoría, se saboteará su pensamiento.

Aparte de eso, señalaría Apple's Human Interface Guidelines. 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.

OS   Dejando las cosas de lado, ese documento tiene algunos puntos de partida bastante buenos sobre los fundamentos.

Answer 4

Fuente: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png

Answer 5

que he publicado preguntas relacionadas:

• What metrics for GUI usability do you know?
• GUI design techinques to enhance user experience

Answer 6

Evitar modes. Es frustrante para un usuario cuando la entrada funciona a veces pero no a otros, o hace cosas diferentes en momentos diferentes.

Answer 7

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 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.
• ¿Algo 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.

Answer 8

Sólo dos cosas, en realidad:

1. "Una interfaz de usuario está bien diseñado cuando el programa se comporta exactamente como el usuario pensó que sería" - quoted de Joel Spolsky de User Interface Design For Programmers
2. Ponga sus diseños en la parte delantera de un usuario. Un verdadero usuario final es el mejor, pero para una retroalimentación ligera y rápida, no se puede vencer a las pruebas de usabilidad en el pasillo, es decir, agarrar a un compañero de trabajo.

Si recuerda el consejo de Joel y asegúrese de obtener información sobre cualquier cosa que hagas y actuar en consecuencia decir iterate, no se va a ir demasiado lejos mal. Y me haría eco de la recomendación para Don't 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.

Answer 9

Aquí hay algunas reglas simples:

• menos clics son mejores.
• Las funciones de uso frecuente 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 un usuario necesita para llegar a algo.

PD - por favor no le cuente esto a las personas de Microsoft Office 2008; ¡los pobres pequeños llorarían para dormir esta noche! :)

Answer 10

Sugiero leer estos blog posts de Enso creadores.

Por supuesto que repetir guías/ideas/consejos de los libros tales como
The Design of Everyday Things y About Face, pero sin embargo, los mensajes contienen un buen número de puntos de vista y (OMI) que son una buena lectura.

Answer 11

Qué información necesita su usuario, ponga eso en la pantalla y nada más. Si no puede definir lo que el usuario necesita, obtenga otro usuario.

Answer 12

Recuerda que tu aplicación será una de las muchas con las que tendrá que 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.

Answer 13

(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 autoinducirse. 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.

Answer 14

proporcionan accesos directos de teclado para los usuarios de energía (incluso si es tan simple como "Pulse Enter para buscar")

No ponga demasiado en pantalla a la vez.

Si aparece un cuadro de mensaje, sus usuarios generalmente nunca lo leerán.

Answer 15

• simple es mejor que complejo
• Complejo es mejor que complicado (eliminar 'si anidados')
• intuitiva (buenos elementos no necesita explicación)
• siguen 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, el par agraphs próximos)
• espacio en blanco es importante

Answer 16

Además de las otras recomendaciones aquí, me gustaría recomendar Designing Interfaces by Jenifer Tidwell como una buena forma de familiarizarse con las convenciones de interfaz de usuario.
Además, The inmates are running the asylum By Alan Cooper es excelente para proporcionar una idea de cómo abordar el diseño de interacción.

Answer 17

Un buen paso para 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.