Portada > Artículo

Usabilidad en aplicaciones para teléfonos móviles

13-06-2005 - Miquel Nieto

Resumen: Con unos dispositivos desesperadamente heterogéneos y minúsculos y en un entorno dinámico repleto de distracciones, la usabilidad se vuelve crítica. La aplicación del principio de �??menos es mas�?�, así como intentar adaptar la interfaz a cada dispositivo, evitando diseños genéricos, son algunas de las claves para lograr una experiencia de uso aceptable.

Debate (15 comentarios) | Valoración media: 2,95 | Votos: 6771 | Lecturas: 38257

Autores: Miquel Nieto y Jose María Sánchez de Ocaña .

La usabilidad trata de la efectividad (capacidad de completar tareas), la eficiencia (esfuerzo necesario para completarlas) y la satisfacción percibida por el usuario durante la interacción con una máquina, sea ésta un ordenador, una radio o un teléfono móvil. Estos 3 elementos están condicionados por el perfil de los usuarios, por sus objetivos y por el contexto de uso.

El contexto de uso del teléfono móvil

El entorno en el que un usuario usa un teléfono móvil y las características del propio dispositivo son dos elementos clave a tener en cuenta en el diseño de interfaces de aplicaciones.

En el caso del móvil, el entorno es cambiante, dinámico. El usuario puede estar distraído o tener prisa, por lo que la estructura de navegación tiene que ser muy simple y hay que evitar (más que nunca) los pasos innecesarios. Algunas personas, por ejemplo, compran las entradas de cine apresuradamente desde su móvil mientras hacen cola en el propio cine si sospechan que la sala se llenará antes de ser atendidos en la taquilla. También son frecuentes las consultas de saldo de una cuenta bancaria antes de realizar un compra (sobre todo si va a emplearse una tarjeta de débito). En ambos casos el usuario tiene mucha prisa y se encuentra en un lugar público.

Por otro lado, la tarea que está realizando el usuario puede interrumpirse por pérdida de cobertura, por una llamada entrante o por una simple distracción. Por lo tanto, el diseño debería permitir recuperar el proceso en curso tras la interrupción (adquiere especial importancia el principio de no hacer que el usuario tenga que recordar las cosas). Las distracciones, concretamente, son mucho más habituales de lo que uno podría pensar. Es habitual usar el móvil (para otros objetivos que no sean el de llamar) mientras se está esperando en un restaurante, en un andén o incluso en un semáforo. En estas situaciones se dan interrupciones por pura lógica: el camarero trae la comida o la bebida, llega el tren, el semáforo se pone verde.

Otros aspectos que actualmente hay que tener en cuenta son:

Los usuarios saben que pagan por tiempo o tráfico
Percepción de los usuarios respecto del medio: caro, ¿seguro?
Los teléfonos y el medio están optimizados para voz, no para datos
Se conectan para realizar tareas concretas, no para navegar. De hecho, un estudio de julio de 2003 realizado en Japón revela que el uso de Internet en los móviles (MobileNet) se concentra en el servicio de e-mail y chat (75,7%), seguido por la descarga de imágenes y tonos (5,2%). Ningún otro servicio superó el 4% (Noticias, información sobre el tráfico y el tiempo, entretenimiento, banca, compras, etc.).

Heterogeneidad de dispositivos

Los dispositivos en sí tienen unas características físicas que afectan negativamente a la usabilidad de una aplicación, como por ejemplo:

Tamaño de la pantalla
Tamaño de las teclas
Dificultad para escribir texto
Ancho de banda e inestabilidad de la conexión (esto, en realidad, atañe más al servicio que al dispositivo)

De todas formas, el problema más grave es la heterogeneidad de los dispositivos. A diferencia de un ordenador, que prácticamente si sabes usar uno enseguida eres productivo usando cualquier otro, aquí las limitaciones inherentes al dispositivo, junto con la heterogeneidad de los mismos son una fuerte barrera a la usabilidad:

Algunos tienen más líneas y caracteres por línea (los hay que sólo tienen 3 líneas de 14 caracteres de longitud)
Cada uno tiene puestas de una manera las hardkeys (controles hardware) y softkeys (controles programables que aparecen típicamente en la parte inferior de la pantalla). Esto hace que las teclas de borrar e ir atrás, por ejemplo, puedan estar mapeadas en lugares distintos en cada móvil.
Algunos usan fuentes proporcionales, otros no; algunos tienen negritas y otros estilos, otros no
Algunos pueden mostrar imágenes, otros no
Algunos soportan escritura predictiva, otros no
Los caracteres especiales (puntos, comas, paréntesis, acentos, etc.) cada modelo los tiene en teclas diferentes
Las paletas de colores pueden ser diferentes (si es que el móvil tiene colores)
Algunos tienen acceso a menús vía teclado numérico, otros no
El formato de los enlaces y de las barras de scroll puede diferir en función del móvil
Muchos fabricantes implementan extensiones propias del lenguaje estándar

En general se sigue un estándar para el mapeo de los números y de las letras, y también es habitual encontrar 2 softkeys. Otros controles no están tan estandarizados, como por ejemplo el número, posición y forma de las hardkeys, el mapeo de caracteres especiales (blanco, signos de puntuación, etc.) y las teclas de navegación (botón para ir atrás, menús con opciones, control de paginación).

Criterios fundamentales de diseño

1. Escribir es difícil

Tanto si es en modo triple tap como con escritura predictiva, esta tarea resulta difícil. Siempre es preferible la selección de opciones a la escritura, aunque lleve más pasos. Si no hay más remedio, es importante tener controlado el formato de entrada (evitar la escritura predictiva a menos que sea muy clara la ventaja de hacerlo).
Se recomienda preinformar campos siempre que sea posible predecir el valor más probable de entrada. En este sentido, hay que garantizar que si el usuario va hacia atrás no se �??limpien�?� los campos ya rellenados.

2. Menos es más

No hay que dar datos simplemente porque se tienen; sólo hay que dar información relevante. Por ejemplo, en la pantalla de lista de cuentas bancarias de un usuario no haría falta indicar los céntimos del saldo de cada cuenta (aunque sí habría que hacerlo en la consulta del detalle de la cuenta). Igual pasa en fechas: no dar minutos y segundos de una operación si no son relevantes. En este sentido también es recomendable usar abreviaturas y un estilo de escritura conciso.

La información más importante debe aparecer en la parte de arriba de la pantalla, y las acciones por defecto (mapeadas en las softkeys) deben de ser las más importantes.

Hay que vigilar con el uso del espacio en blanco, porque las líneas vacías pueden despistar e inducir al usuario a pensar que no hay nada más bajo ellas. Es mejor usar como separador una serie de guiones: �??-------�?�.

Hay que evitar contenidos multimedia, gráficos y efectos visualmente vistosos. Es preferible diferenciarse por la calidad de los contenidos y los servicios que ofrezca la aplicación, no por la interfaz de usuario.

3. El usuario es móvil

Partiendo de la idea de que gran parte de los usuarios se conectan con objetivos concretos y que pagan por tiempo o Bytes, hay que tener cuidado con alterar su camino principal de acción con publicidad, contenidos poco relevantes o pasos innecesarios.

4. Navegación

La estructura de la aplicación debe ser sencilla, ancha y baja. Es decir, que es preferible tener muchas categorías con poca profundidad.

La gestión de la navegación hacia atrás es crucial y no debería inhabilitarse:

Es importante conservar la información introducida anteriormente para no obligar al usuario a teclearla de nuevo.
Si un usuario ha realizado transacciones que ya han sido confirmadas no es conveniente que yendo hacia atrás pase por las pantallas de dichas transacciones. Es decir, que hay que intentar ahorrarle pasos atrás.

Afortunadamente, el lenguaje WML (Wireless Markup Language) tiene la funcionalidad de definir contextos (también conocidos como actividades o subrutinas), gracias a los cuales es posible agrupar un conjunto de pantallas en la pila de navegación, para desapilarlas de golpe si conviene, cuando el usuario navegue hacia atrás.

5. Cada pulsación de tecla empeora la usabilidad

Es aconsejable reducir el número de pulsaciones de tecla entre el principio y el final de cada tarea. Esto no sólo afecta a la introducción de texto, también requieren pulsación el scroll vertical, el despliegue de menús y las softkeys.

Ejemplo: wap.HotelDirect.de

Este sitio alemán de reserva de habitaciones ofrece un buen ejemplo de lista en la pantalla 1: en un primer nivel aparecen las opciones más importantes (las más usadas) y un enlace adicional permite acceder al resto de ciudades. Como se puede apreciar, no hay líneas en blanco.

No obstante, hay demasiados pasos hasta poder ver hoteles (pantallas 2 y 3). Es preferible hacer páginas con scroll que tener que navegar a otra página. Las pantallas 2 y 3 probablemente se podrían haber condensado en una misma página.

Para dispositivos en los que es posible crear menús activables directamente mediante el teclado numérico, en listas como la de la pantalla 5 es mejor mapear de forma consistente las letras tal y como lo están sobre el teclado numérico (ABC, DEF, etc.).

Otro problema es la ordenación de la pantalla 4, que no parece obedecer a ninguna regla entendible por el usuario. También en esta lista se aprecia el problema de usabilidad de los enlaces que ocupan más de una línea: resulta confuso identificar opciones (un mismo enlace puede parecer 2 opciones diferentes). En este sentido, es interesante permitir el acceso numérico a los elementos de la lista, si el teléfono lo permite. Así, por ejemplo, podríamos sustituir �??Dorint Hotel Schweizerhof�?� por �??1 Dorint H Schweizerhof�?�, �??Holiday Inn Garden Court�?� por �??2 Holiday Inn Garden Court�?�, etc.

Las cabeceras de las pantallas tampoco se han cuidado suficientemente. En la pantalla 4 se podría sustituir �??Select hotel�?� por �??HOTELS �?? 1 OF 7�?�. Y el título de la pantalla 3 podría reducirse a simplemente �??PRICE�?�, cosa que nos ahorraría una línea.

Otras consideraciones:

Importante: añadir un enlace a la función �??atrás�?� del navegador en todas las pantallas (aunque no se haya inhabilitado el atrás nativo). Es un problema habitual (y crítico) la dificultad de los usuarios para averiguar cómo realizar la función de �??atrás�?�.
Hay teléfonos que no permiten el uso de negrita, colores de fondo o imágenes, así que la única manera de identificar las softkeys es poniendo una etiqueta con texto en mayúscula (�??OK�?� en lugar de la imagen �??�?� y �??OPTIONS�?� en lugar de �??Options�?�).
Podrían usarse algunas abreviaturas. Por ejemplo en la pantalla con la lista de hoteles, donde es visible la falta de espacio, se puede sustituir �??Hotel�?� por �??H�?� en los nombres de los hoteles, y también puede ponerse el número de estrellas de otra forma: �??4*�?� en lugar de �??****�?�.
Es acertado hacer que el texto fluya, porque el scroll horizontal suele provocar efectos bastante negativos (texto que corre de forma automática, sin que el usuario se dé cuenta). Puedes permitirte forzar a que no fluya si se trata de una opción que seguro que el usuario ya conoce, y en cualquier caso cuando los primeros 11 caracteres son suficientes para identificar a dónde lleva esa opción.
La URL es un poco larga, y si el usuario no la tiene en sus favoritos tendrá que teclear demasiado. Sería ideal contar, además de este dominio, con otro del tipo wap.hd.de .

Particularidades del test de usuarios

La observación de usuarios reales resulta bastante complicada debido a las reducidas dimensiones de los terminales y a la posición en que estos se usan (los usuarios sujetan el móvil con una mano y apoyan el brazo en el cuerpo, dejando muy poco espacio entre la pantalla y ellos).

Nuestro objetivo es capturar la pantalla, el teclado (para poder ver el movimiento de los dedos) y las expresiones faciales del usuario. El usuario debería de poder sostener el teléfono en su mano tal y como lo haría en condiciones normales. Si fijamos el teléfono a una mesa estaremos alterando el test: es incómodo, algunos usuarios teclearían con las 2 manos, etc. Una alternativa es usar apliques de cámaras como los que se muestran en la imagen siguiente.

Las desventajas son el precio y que no deja de ser incómodo: la plataforma es demasiado grande, los cables dificultan el movimiento y no acaba de dar libertad al usuario. También es un problema el hecho de que el móvil pueda moverse en cualquier dirección, porque no podemos controlar los reflejos (es necesario usar luz indirecta en la sala).

Nosotros recomendamos emplear un montaje como el de la figura de abajo, que consiste en una webcam, una mesa y una zona marcada con cinta de pintor. Es económico y bastante cómodo: el usuario puede estar con el brazo bastante pegado al cuerpo, y (curiosamente) sostendrá el teléfono dentro de la zona marcada. Es importante usar software que permita invertir la imagen (para que los observadores la puedan ver). La desventaja es que la movilidad está acotada, cosa que inhabilita este sistema para testear aplicaciones en situaciones de movimiento del usuario.

En cuanto a los dispositivos a utilizar, no se recomiendan los simuladores de teléfonos en un ordenador. Es mejor usar teléfonos representativos de los que usen las personas a las que va dirigida la aplicación. A pesar de que no queremos testear la usabilidad de los teléfonos, sino la de nuestra aplicación, es importante testear con varios teléfonos representativos. La usabilidad de los teléfonos condiciona la experiencia global del usuario: testear con varios teléfonos representativos nos puede ayudar a detectar diseños mejorables. No se debe disociar aplicación de teléfono.

También es interesante provocar interrupciones en el transcurso del test. Es uno de los pocos casos en los que interrumpir al usuario puede ser deseable, para simular la realidad de los escenarios de uso de un teléfono móvil. En este caso, mejor que interrumpir al usuario en una sala de test para simular un escenario determinado, es preferible aprovechar que estamos en un entorno móvil y realizar el test en el propio escenario. Por ejemplo, ir con el usuario a una cafetería, y pedir que realice una serie de tareas mientras esperamos que nos traigan un café, y que le interrumpa el camarero cuando venga con el café. O llamarle por teléfono mientras está haciendo una de las tareas. La idea es observar cómo la aplicación ayuda a recuperar el proceso abandonado tras la interrupción.

Conclusiones

Las limitaciones del medio, del dispositivo y del navegador hacen que la usabilidad se vuelva crítica. El medio es lento y percibido como caro. El dispositivo tiene unas pantallas muy pequeñas, unos mecanismos de navegación extraños y la dificultad de entrada de datos es enorme. Y el navegador a menudo utiliza extensiones no estándar o simplemente no soporta alguna de las más comunes.

Estas limitaciones, unidas a la heterogeneidad de dispositivos y navegadores, implican que el modelo de diseñar una versión genérica (al estilo web) que funcione bien para todos, para el caso del teléfono móvil, llevará a que todos tengan una experiencia de usuario inferior a lo aceptable. Es decir, que el diseño genérico es malo para todos. Por lo tanto, es muy recomendable personalizar las aplicaciones, entendiendo �??personalizar�?� como:

Adaptar la interfaz al dispositivo/navegador de cada usuario, para explotar al máximo sus características.
Ofrecer información y funciones relevantes para cada usuario. Por ejemplo, en un site de reservas de avión, si el usuario sólo tiene un vuelo reservado, no ponerle en el menú inicial una opción a �??Reservas�?�, que llevaría a la pantalla de lista de reservas; en su lugar, ponerle directamente la opción �??BCN-MAD 17Jun�?�.