Usabilidad en aplicaciones para telÃ©fonos mÃ³viles

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â?.