software guidelines experience examples user-interface usability

user-interface - guidelines - user interface design pdf



Consejos de UI fácilmente digeribles para desarrolladores (19)

¿Cuáles son algunos de los consejos clave de diseño de la interfaz de usuario que todo desarrollador debería saber?

Si bien hay una serie de recursos de IU para desarrolladores (por ejemplo, el Diseño de interfaz de usuario para programadores de Joel Spolsky), estoy interesado en más de una lista de viñetas que se pueden comunicar en 1 o 2 páginas.

Me interesan más sugerencias de UI tácticas y cotidianas, a diferencia de los objetivos generales de diseño de UI que se cubrirían en una reunión de diseño de UI (presumiblemente asistida por al menos una persona con un buen sentido de IU). Una colección de estos consejos podría cubrir aproximadamente el 80% de los casos que encontraría un programador de todos los días.

Grandmaw Testing.

Este es mi término para la pregunta conceptual: "¿Puede su abuela, que nunca ha usado una computadora más allá del correo electrónico y visitando www.cutecats.com, usarla? (Suponiendo que tenga el conocimiento del mundo real para usar esa aplicación en particular)".

Todo lo común debería ser obvio; nada debe ser magia de caja negra con efectos secundarios. Las cosas poco comunes deben ser accesibles en un formato común que el usuario haya utilizado anteriormente.

Etiquetado claro, ruta clara a un archivo de ayuda, acciones claras con efectos claros.

Si la abuela no puede usar tu programa Paint, debes pensar realmente en tu UI.

  1. Minimiza la cantidad de clics
  2. Aspecto uniforme (tamaño del texto, botones ... y otros controles)
  3. Minimice las ediciones gratuitas ... (por ejemplo: en una entrada de dirección ... proporcione estados en un menú desplegable ... etc.)
  4. En un menú desplegable para la lista de países ... enumere primero el país de residencia ... (¿cuántos de ustedes se sienten frustrados porque Estados Unidos se enumera en la parte inferior y tienen que desplazarse hacia abajo?)
  5. Descensos generales se pueden pedir como la elección de los usuarios
  6. No Spelling msitake;) en absoluto
  7. Preste atención al texto de etiquetado: para la dirección de correo electrónico (tenga el título como correo electrónico ... créame ... lo he visto como dirección de e_mail :)
  8. Símbolo de moneda para los montos. visualización de dígitos uniformes en cantidad ... ej: $ 12.15 ==> $ 12.15 $ 10.9 ==> $ 10.90 9. Barra de progreso / estado
  9. Etiqueta de amigo para indicar el campo de error antes de que el usuario haga clic en el botón Aceptar / Guardar (por ejemplo: para una dirección de correo electrónico si no hay "@" no es necesario esperar hasta que el usuario haga clic en Aceptar y luego indicar una dirección de correo electrónico no válida)
  10. Evite entradas repetidas ... (por ejemplo: recuérdame la opción en la pantalla de inicio de sesión)
  11. opción de aplicación global para permitir que el usuario continúe desde donde se quedó en la instancia anterior)
  12. cuando se muestran datos en una cuadrícula ... opciones de filtro de estilo excel
  13. valores predeterminados para las entradas.

Amigos ... ¡¡¡siéntanse libres de aclarar cualquiera de los puntos anteriores con las razones válidas !!!

  1. pregúntele al usuario, no solo invente las cosas
  2. simplificar: elimine un paso, elimine los clics, etc.
  3. familiarizarse con los principios de usabilidad

Al diseñar una IU, es lo más simple posible, pero no más sencillo.

Cuando esté a punto de realizar una acción que cambiará o eliminará la información, no pregunte "¿está seguro?": Los usuarios aprenderán a hacer clic en el botón como parte de la acción. Intente permitir un ''Deshacer'' en el diseño del sistema.

Elija la opción predeterminada con la que la mayoría de los usuarios estén satisfechos.

En lugar de los botones arbitrarios "Aceptar" y "Cancelar", que, dado el contexto, pueden ser ambiguos, y los usuarios hacen clic ciegamente en uno, los botones deben contener una breve descripción de lo que hacen.

[Ok, Please Cancel my subscription ], [ Please do not cancel my subscription ]

es mucho mejor que

Cancel my subscription? [ OK ] [ Cancel ]

(Este tipo de fallas a menudo surgen en el día a día)

Encuentre lo que el usuario hará con más frecuencia y luego haga que sea lo más fácil de hacer.

Por ejemplo: Tengo una queja personal de larga ejecución con diseño de microondas.

Muchos requieren que configures un reloj que nunca utilizas para nada antes de usar el microondas, y se olvida cada vez que pierde potencia Y se requieren 10 pulsaciones de teclas en esos botones difíciles de usar para hacerlo.

Una simple prueba de usabilidad se daría cuenta de que el tiempo de cocción más común utilizado en microondas es el "minuto" estándar y múltiplos de los mismos. Un microondas ideal debería poder cocinar un producto por 1 minuto a alta potencia en 3 o menos acciones.

Para tiempos fuera de un minuto, pero dentro de los 5 minutos del dorado "1" minuto, debe haber un poco más de pasos, pero no significativamente, y solo requiere un número significativo de acciones para tiempos de cocción> 5 minutos. (que son bastante raros)

2 ejemplos de un excelente diseño de microondas

1. 4 partes. Secuencia de puerta, temperatura, tiempo, secuencia de iluminación de tiempo

La marcación de temperatura es analógica y persiste desde la configuración anterior, con un rango variable de deslizamiento.

El marcador de tiempo es digital, pero simulado análogo, girando el dial en el sentido de las agujas del reloj aumenta el tiempo del reloj (que se muestra mediante una secuencia de iluminación debajo del dial). Girar el dial en sentido antihorario disminuye el tiempo del reloj. Cocinar disminuye el tiempo del reloj.

La puerta se cierra y la hora en el reloj comienza a cocinar. La apertura de la puerta detiene la cocción.

operación estándar: abra la puerta, cargue, marque el tiempo de giro, cierre la puerta (u opcionalmente, cierre la puerta primero, y la cocción comienza tan pronto como> 1s esté en el reloj)

2. 6 partes, puerta, esfera, botón de encendido, botón de inicio, botón borrar, pantalla de tiempo digital

El botón de inicio sin tiempo seleccionado comienza a cocinar durante 1 minuto a alta potencia.

El botón de inicio mientras cocina agrega 1 minuto al tiempo.

El marcado de tiempo persiste entre sesiones. Al girar el dial, el tiempo almacenado en la posición de los diales se copia al temporizador digital.

Presionar "power" antes de comenzar la cocción

  1. en caso de que no se haya girado el dial, copie la hora actual almacenada en la posición de los datos en el temporizador digital.
  2. en el caso de que se haya girado el dial, disminuye la elección del nivel de potencia en 1, o si en el nivel de potencia más bajo, vuelve al más alto.

Presionando la potencia mientras se cocina disminuye el nivel de potencia sobre la marcha.

operación estándar: 1 minuto de alto = presionar inicio.

1 minuto medio alto = presionar inicio, presionar energía.

2 minutos de alto = presione comenzar dos veces.

<anytime> en high = girar el dial hasta que esté feliz, presionar inicio.

<anytime> on <anypower> gire el dial hasta que esté satisfecho, presione power until happy, presione start.

<hora previamente elegida> en alta = presionar potencia, presionar inicio

<hora previamente elegida + 1 minuto> en alta = presione la tecla de encendido, presione inicio dos veces.

Como puede ver aquí, agregar una pequeña cantidad de botones adicionales puede agregar un gran grado de diseño expresivo y funcional.

Cualquier diseño con un teclado numérico para la especificación del tiempo, tiende a fallar en mis criterios para un buen diseño.

Se observó que estos diseños pueden, para algunas personas tienen una mayor curva de aprendizaje, pero una vez aprendidos, la memoria muscular lo hace instintivo. A diferencia de otros diseños (¿obvios?) Pero demasiado complicados, incluso un usuario culto repetidamente tendrá que pasar tediosas cantidades de tiempo realizando tediosas operaciones arbitrarias, simplemente para alcanzar objetivos comunes.

Las paradas de pestaña correctas son obligatorias.

No aumente la "capacidad de descubrimiento" a costa de la claridad y usabilidad básicas.

Realice algunas pruebas de usabilidad en el pasillo (de la misma manera que haría las revisiones del código).

Incluso una prueba de usabilidad realmente rápida "¡eh !, prueba esto" (si puedes llamarlo así) con el tipo que tienes al lado hará una gran diferencia. Lo principal es hacer que alguien que no sea tú pruebe la interfaz de usuario que acaba de construir.

Es sorprendente la cantidad de veces que otras personas se estancan con su nueva interfaz de usuario, y solo toma un par de minutos (por lo general) para encontrar los mayores problemas.

Si utiliza una ventana emergente de un editor, asegúrese de devolver su punto de inserción o estado a lo que era antes de la ventana emergente. Demasiados programas simplemente te dejan "pendiente" y tienes que encontrar el camino de regreso.

Siempre brinde a su usuario una "salida" desde donde sea que no requiera el uso del botón Atrás.

El mejor ejemplo:

Si ocurre un error, déles un enlace de regreso a donde estaban (o al menos a donde puedan comenzar de nuevo).

Use consejos de herramientas tanto como sea posible. Es sorprendente cómo estos pequeños pueden agregar una gran cantidad de ayuda al usuario final y no son molestos con la aplicación en sí.

Mi regla básica de diseño de UI es hacer que cada "página" haga una tarea y una tarea solamente. Mantiene las páginas simples, lo que mantiene el diseño limpio y hace que la aplicación sea más comprensible.

Este tipo de diseño se denomina interfaz de usuario inductivo. Aquí hay un documento que Microsoft publicó en 2001 sobre el tema. El texto puede estar un poco anticuado, pero los principios en general son bastante buenos. La única advertencia es que hay un equilibrio en el diseño de esta manera. Si simplifica excesivamente a demasiados usuarios, tendrá que navegar por todas partes para llevar a cabo tareas simples, y las ganancias en comprensibilidad se perderán por falta de productividad.

Algunos consejos simples para el diseño web y el diseño de aplicaciones de la interfaz de usuario diaria:

  • Utilice bocetos estáticos simples para comenzar los planes preliminares de desarrollo de aplicaciones web. -No permite demasiadas opciones a los usuarios. en su lugar, use el diseño de proveedores para enviar a los usuarios por un camino del que se beneficiarán. -Definir grupos de usuarios clave y los viajes que realizaron -Practicar el diseño iterativo como parte de la interfaz de usuario para garantizar el retorno de la inversión

Me gusta seguir estas pautas:

  1. Estándar: siga estándares / patrones conocidos, reutilice ideas de todos los productos que respete
  2. Simple: mantenga sus soluciones simples y fáciles de cambiar (si es necesario)
  3. Elegante: use menos para lograr más
  • utilice una barra de menú estándar (los diseñadores de GUI aficionados parecen trazar su propio curso aquí por alguna razón). Asegúrese de que los primeros elementos sean Archivo, Editar y Ver, y el último sea Ayuda
  • no se preocupe por temas de color o máscaras; atenerse a un aspecto estándar que sea coherente con su plataforma
  • usa la fuente predeterminada del sistema
  • use aceleradores de menú que sean consistentes con su plataforma
  • adhiérase al diseño probado y verdadero con una barra de menú en la parte superior, una barra de estado en la parte inferior y, si es necesario, un panel de navegación a la izquierda
  • nunca hacer un agarre en todo el sistema
  • Si puede elegir, haga que todas las ventanas sean redimensionables.
  • use grupos de botones de radio para "elegir exactamente uno". Siempre asegúrese de que uno de ellos esté seleccionado por defecto. Si desea que el usuario no elija ninguna, agregue otro botón de radio para "no hay elección"
  • use grupos de botones de verificación para "elegir cero o más"
  • restringir la entrada si es necesario (es decir: ignorar simples no dígitos en un campo de entrada numérico) en lugar de esperar a que el usuario ingrese datos, enviar y luego arrojar un diálogo que dice "¡oye, las letras no están permitidas!". Si no están permitidos, no los acepte en primer lugar.
  • ser liberal en lo que acepta como entrada. Por amor de Dios, no arrojes un ajuste para un campo de SSN si omiten los guiones, o ponlos cuando no los quieras. La computadora es inteligente, deje que se dé cuenta de que xxxxxxxxx y xxx xx xxxx y xxx-xx-xxxx son todos números válidos de la seguridad social.
  • siempre permita espacios en campos largos como números de serie y otras cosas. La calidad de los datos aumenta si un usuario puede agrupar números en conjuntos de tres o cuatro. Si su modelo de datos no puede manejar los espacios, puede eliminarlos antes de guardar los datos.
  • Evite los cuadros de diálogo emergentes como la peste. Nunca muestre uno a menos que sea absolutamente necesario. Si decide que debe hacerlo, deténgase y vuelva a pensar su diseño antes de continuar. Hay momentos en que son necesarios, pero esos momentos son considerablemente menos frecuentes de lo que puedas imaginar.
  • preste atención al recorrido del teclado. La mayoría de los juegos de herramientas intentan hacer las cosas bien, pero siempre doblemente. Un uso debería poder usar la tecla de tabulación para recorrer los widgets de una manera lógica.

Todas estas reglas pueden, por supuesto, romperse. Pero solo rompa si lo está rompiendo por una razón justificable.

Recuerde, el software está ahí para ayudar al usuario, debe hacer lo que quiera, en lugar de hacer que haga lo que quiere.