Diseño y Prototipado

Diseño y
prototipado
PID_00245397
Jordi Flamarich Zampalo
Tiempo mínimo de dedicación recomendado: 7 horas

© FUOC • PID_00245397 Diseño y prototipado
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Usabilidad y diseño de la experiencia de usuario..................... 7

1.1. Diseñar para varias plataformas .................................................. 8
2. Patrones de diseño............................................................................. 10
2.1. Navegación .................................................................................. 10
2.1.1. Pantalla de inicio ........................................................... 10
2.1.2. Paginación ...................................................................... 11
2.1.3. Menús ............................................................................. 14
2.1.4. Elementos de control .................................................... 16
2.2. Mostrar información ................................................................... 19
2.2.1. Listados .......................................................................... 19
2.2.2. Pestañas .......................................................................... 22
2.2.3. Tarjetas ........................................................................... 22
2.2.4. Cuadrícula ...................................................................... 24
2.2.5. Pila .................................................................................. 25
2.2.6. Pase de diapositivas ....................................................... 26
2.2.7. Anotación ....................................................................... 26
2.3. Entrada de datos ......................................................................... 29
2.3.1. Teclado ........................................................................... 29
2.3.2. Voz ................................................................................. 30
2.3.3. Campos de texto y formularios ..................................... 31
2.3.4. Botones .......................................................................... 35
2.3.5. Interruptores, barras y selectores ................................... 36
2.4. Buscar y filtrar información ........................................................ 39
2.4.1. Búsqueda dinámica ........................................................ 42
2.4.2. Autocompletado ............................................................. 42
2.4.3. Búsqueda con filtros ...................................................... 43
2.4.4. Últimas búsquedas ......................................................... 45
2.4.5. Formulario de búsqueda ................................................ 45
2.4.6. Búsqueda por geoposición ............................................. 46
2.4.7. Ordenar los resultados ................................................... 47
2.5. Respuesta al usuario .................................................................... 48
2.5.1. Confirmación ................................................................. 48
2.5.2. Mensajes de error .......................................................... 51
2.5.3. Indicadores de espera .................................................... 52
2.6. Ayuda ........................................................................................... 57
2.6.1. Diálogo ........................................................................... 58
2.6.2. Consejo .......................................................................... 59

2.6.3. Instrucciones .................................................................. 60
2.6.4. Visita guiada .................................................................. 61
2.6.5. Transparencias ................................................................ 62
2.6.6. Vídeo ayuda ................................................................... 63
3. Consejos y buenas prácticas para un buen diseño.................... 64
4. Prototipado en alta definición...................................................... 73
5. Introducción a la evaluación de la usabilidad.......................... 77

5.1. Análisis heurístico ....................................................................... 77
5.2. Test con usuarios ......................................................................... 78
Bibliografía................................................................................................. 81
© FUOC • PID_00245397 5 Diseño y prototipado
Introducción
Una vez estudiadas las técnicas para estructurar la información en nuestra apli-
cación, en este tercer y último módulo nos centraremos en la cara más «visi-
ble» del diseño y profundizaremos en cuestiones como la usabilidad o el dise-
ño de una buena experiencia de usuario. También realizaremos un recorrido
por los patrones de diseño más habituales en el diseño de aplicaciones móviles
y, siguiendo con las técnicas de prototipado planteadas en el módulo anterior,
daremos un paso más y veremos técnicas de prototipado en alta definición.
Finalmente, realizaremos una introducción a la evaluación de la usabilidad de
nuestra aplicación.
Objetivos
Los objetivos que el estudiante deberá alcanzar con el estudio de este módulo
son:
1. Profundizar en los conceptos de usabilidad y experiencia de usuario.
2. Revisar los patrones de diseño más habituales en aplicaciones móviles.
3. Entender cuándo estamos ante un buen diseño y cuándo no.
4. Conocer herramientas para el prototipado en alta definición de nuestras

aplicaciones.
5. Introducirnos en la evaluación de la usabilidad como una etapa más del

proceso de diseño.
1. Usabilidad y diseño de la experiencia de usuario
Como hemos visto en los módulos anteriores, en el diseño centrado en el

usuario, las necesidades del usuario están por delante de todo, incluso por
delante de la estética del sistema. Cada vez más, sin embargo, los usuarios
piden que, además de ser fáciles de usar, las interfaces con las que interactúan
sean visualmente atractivas y agradables, de tal manera que «apetezca» usarlas
una y otra vez.
Por tanto, a la hora de diseñar una aplicación distinguiremos entre dos con-
ceptos que están íntimamente ligados. Por un lado, tendremos la usabilidad,
definida como la propiedad que hace que un producto o interfaz sea fácil de
usar, y, por otro, la experiencia�de�usuario, que es la manera como el usuario
percibe y experimenta sensaciones cuando ve y manipula el producto.
La usabilidad trata de cómo interactuamos con el producto; la experien-

cia de usuario, en cambio, trata de cómo nos sentimos mientras lo uti-
lizamos.
Los objetivos básicos de la usabilidad, de acuerdo con Jakob Nielsen, son:
1)�Eficacia: se trata del objetivo más básico, puesto que persigue que el sistema Lectura complementaria
cumpla efectivamente la tarea para la cual ha sido diseñado.
J.�Nielsen (2012, 4 de enero).
«Usability 101: Introduction
2)�Eficiencia: lograremos este objetivo cuando, además de ser eficaz, el sistema to Usability». Nielsen Nor-
man Group.
cumpla la tarea especificada con rapidez, requiriendo el menor número de
pasos.
3)�Seguridad: una interfaz se considera segura cuando minimiza las posibili-

dades de que el usuario cometa un error e incluye además mecanismos de re-
cuperación de la información para los casos en que el error se produzca. Por
ejemplo, la opción «Deshacer» la última acción realizada es un mecanismo de
seguridad.
4)�Utilidad: hace referencia a las funciones disponibles en la aplicación, que

permiten que el usuario pueda hacer más o menos cosas con ella. En el entorno
móvil, hay que limitar al máximo el número de funciones disponibles sin que
la aplicación pierda su utilidad.
5)�Facilidad�de�aprendizaje: por norma general, los usuarios de dispositivos

móviles se rigen por la ley del mínimo esfuerzo, de manera que conviene no
diseñar aplicaciones que requieran muchas horas de aprendizaje para empe-
zar a usarlas. Esto se puede conseguir minimizando el número de funciones

disponibles, automatizando procesos y situando en primer término solo aque-
llas opciones imprescindibles para completar la tarea principal. La facilidad de
aprendizaje no es, sin embargo, sinónimo de simplicidad: podemos diseñar
aplicaciones complejas, pero con una curva de aprendizaje muy suave, de for-
ma que el usuario se encuentre cómodo y obtenga resultados pasados tan solo
unos cuantos minutos.
6)�Memorabilidad: hace referencia a la capacidad de recordar cómo funciona

un sistema una vez hemos aprendido a usarlo. Pasado un tiempo sin usarlo,
¿cuánto tardará el usuario en recordar cómo funcionaba? Este objetivo resulta
importante en aplicaciones o funciones que se usan poco.
En cuanto a la experiencia�de�usuario (también denominada UX, user expe-

rience), resulta evidente que estamos hablando de un hecho totalmente subje-
tivo, difícilmente medible. Puede variar mucho en función de la persona, su
estado de ánimo, las experiencias previas o de las expectativas que pueda te-
ner. No es de extrañar, por lo tanto, que la experiencia de usuario sea un cam-
po multidisciplinar donde entre en juego el saber de diversos profesionales,
como psicólogos, antropólogos, sociólogos, ingenieros, diseñadores gráficos,
diseñadores industriales, comunicadores y creativos, entre otros.
La experiencia de usuario alcanza tanto el momento concreto de uso

de la aplicación como la imagen previa que se había hecho el usuario
junto al recuerdo posterior que le queda.
Aplicada a los dispositivos inteligentes, una buena experiencia de usuario pide

cada vez más el desarrollo de aplicaciones que sean divertidas, entretenidas,
sorprendentes, motivadoras, satisfactorias, agradecidas o estéticamente atrac-
tivas, a la vez que logran con mayor o menor medida los objetivos de usabi-
lidad antes descritos.
Uno de los recursos más habituales para conseguir una mejor experiencia de
usuario es recurrir a técnicas de gamificación, esto es, introducir dinámicas
propias de los juegos y el ocio en actividades no recreativas, convirtiendo así
una actividad a priori «aburrida» en una que motive a la persona a participar
en ella.
1.1. Diseñar para varias plataformas
Diseñar una experiencia de usuario implica comprender y diseñar la experien-

cia de principio a fin, y no solo el aspecto estético o las funcionalidades de
nuestro producto. Más aún cuando el usuario puede acceder a nuestra aplica-
ción o producto en diversos dispositivos y plataformas. A continuación cita-

mos algunos criterios para diseñar una buena experiencia de usuario entre di-
ferentes plataformas, de acuerdo con Jakob Nielsen:
• Continuidad�visual: las interfaces de usuario pueden variar para adaptarse Lecturas

a las guías de la plataforma, pero nuestro diseño tiene que parecerse lo complementarias
suficiente de una plataforma a otra para que el usuario lo reconozca al J.�Nielsen (2011, 29 de agos-
instante y no se sienta perdido. to). «Transmedia Design for
the 3 Screens (Make That 5)».
Nielsen Norman Group.
• Continuidad�en�las�funciones: por muy pequeño que sea el dispositivo Información y recursos sobre
experiencia de usuario: All
para el que diseñemos, el usuario ha de tener la sensación de que las fun- about UX.
ciones principales de nuestra aplicación están igual de disponibles que en Investigación, análisis y ar-
tículos sobre usabilidad y ex-
sus «hermanos mayores». periencia de usuario: Nielsen
Norman Group.
Y.�Hassan;�F.�J.�Martín
• Continuidad�en�los�contenidos: deberemos usar el mismo tono y lengua- (2005, 7 de septiembre). «La
je en todas las plataformas, de modo que el usuario «nos reconozca» en experiencia del usuario». No
Solo Usabilidad: Revista Sobre
todas ellas. Personas, Diseño y Tecnología.
• Continuidad�en�los�datos: la información proporcionada por el usuario

ha de estar disponible y actualizada al instante en todas las plataformas y
dispositivos, sin necesidad de que este tenga que hacer nada para que la
información se sincronice.
2. Patrones de diseño
A la hora de diseñar interfaces, los patrones nos resultan de gran utilidad,

puesto que:
• Nos ayudan a ahorrar trabajo porque proponen soluciones a problemas ya

resueltos. Y si los aplicamos bien, nos ayudan a resolver otros problemas
parecidos.
• Hacen que nuestra interfaz sea fácil de usar, dado que, una vez aplicados
de forma generalizada por la comunidad de diseñadores y desarrolladores,
acaban convirtiéndose en modelos mentales para los usuarios.
2.1. Navegación
A continuación comentamos los principales elementos de navegación que po-

demos hallar en dispositivos móviles.
2.1.1. Pantalla de inicio
Si en los ordenadores nos hemos acostumbrado a hablar de escritorio para

hacer referencia a la pantalla principal del sistema, en los dispositivos móviles
hablamos de pantalla de inicio. Es ahí donde se encuentran los accesos directos
a las aplicaciones y funciones del sistema.
La pantalla de inicio puede constar de varias páginas, donde el usuario ordena

los iconos de acceso a las aplicaciones y funciones disponibles en el sistema.
Para pasar de página en la pantalla de inicio, el usuario tiene que deslizar con
el dedo lateralmente.
En el sistema operativo móvil de Apple, iOS, esta pantalla recibe el nombre de

Springboard y con el tiempo ha resultado un patrón para pantallas de inicio de
otros sistemas operativos. En el sistema operativo Android, además de iconos,
el usuario puede situar sobre la pantalla de inicio widgets, con información
que se actualiza constantemente (previsión del tiempo, noticias, redes sociales,
etc.).
Finalmente, en la parte inferior de la pantalla hay una parte fija (llamada dock)
que no cambia cuando el usuario pasa de página y es donde se pueden fijar
los accesos a las aplicaciones más utilizadas.
Pantallas de inicio en iOS (izquierda) y Android (derecha)
2.1.2. Paginación
El usuario tiene que poder navegar y saber en todo momento su posición ante
un contenido organizado por páginas. En ocasiones, la paginación también
puede servir para navegar dentro del contenido y permitir que el usuario salte
fácilmente de una página a otra. Disponemos de varias maneras para hacerlo: a
partir de puntos, botones, barra de desplazamiento, miniaturas, menús, menú
desplegable o menú fijo.
Puntos
El sistema más básico, convertido ya en un estándar en los dispositivos móvi-

les, es mostrar la posición a través de unos pequeños círculos o puntos al pie
o en la cabecera de la página. Es el sistema habitual en pantallas de inicio o
slideshows, donde la navegación se hace deslizando lateralmente con el dedo.
Número de páginas de La Vanguardia
Los puntos muestran el número de páginas en este tutorial de la aplicación del diario La Vanguardia para iPad (iOS).
Este sistema no permite al usuario navegar por las páginas, simplemente le

muestra el número de páginas existente (una por cada punto) y su situación
en estas (punto destacado). Por lo tanto, resulta un sistema bastante limitado,
que conviene no usar cuando tenemos muchas páginas.
Barra de navegación
La barra de navegación la encontramos en la parte superior de la pantalla y

cumple una doble función. En primer lugar, incluye el título de la página o
sección en la que se encuentra el usuario, evitando así que se desoriente. En
segundo lugar, esta barra acostumbra a incluir elementos que permiten la na-
vegación en la aplicación. En Android, por ejemplo, esta zona de la pantalla
recibe el nombre de «App Bar» y, además del título, permite el acceso a otros
elementos de navegación, como el botón atrás, el menú o la búsqueda dentro
de la aplicación.
«App Bar» en Android
Fuente: developer.android.com
Para facilitar una experiencia inmersiva, las barras de navegación pueden des-
aparecer temporalmente cuando se muestra contenido a pantalla completa,
reapareciendo cuando el usuario toca de nuevo la pantalla. Las guías de dise-
ño de cada sistema operativo acostumbran a incluir indicaciones sobre cómo
tienen que ser y comportarse las barras de navegación.
Botones
Con este sistema, el usuario puede pasar páginas hacia delante y hacia atrás
mediante botones. Adicionalmente, se puede mostrar el número de página en
el que se encuentra. Este sistema es heredero de la web y está en decadencia,
dado que el usuario preferirá siempre realizar un gesto sobre cualquier parte
de la pantalla antes que ir pulsando un botón.
Barra de desplazamiento
Mediante este sistema, el usuario puede ver rápidamente su posición respecto

del total del contenido y trasladarse fácilmente adelante y atrás, con mayor
velocidad de la que conseguiría haciendo scroll sobre la pantalla. La barra de
desplazamiento puede usarse en horizontal o en vertical. Para un mejor con-
trol, resulta conveniente mostrarle el número de página durante el desplaza-
miento.
Barra de desplazamiento vertical en la aplicación PDF Expert para iPad (iOS)
Miniaturas
Este sistema permite navegar por las páginas a la vez que se visualizan las
miniaturas, facilitando la tarea de identificar rápidamente el contenido.
Miniaturas
La aplicación de La Vanguardia para iPad (iOS) permite navegar a través de las páginas del diario viendo sus miniaturas.
2.1.3. Menús
Al igual que en cualquier programa informático o sistema operativo de orde-

nador, los menús son un elemento imprescindible para mostrar las diferentes
opciones o funciones disponibles en un dispositivo móvil. La falta de espacio
disponible en pantalla, sin embargo, puede condicionar mucho la manera en
que se accede o se visualizan. Encontramos dos soluciones básicas, que se pue-
den presentar alternativamente o a la vez en una misma aplicación.
Menú desplegable
Para no sacrificar espacio en pantalla, el menú aparece cuando el usuario activa

un botón convenientemente identificado o hace un gesto determinado sobre
la pantalla (normalmente, arrastrando con un dedo desde el lateral):
Menú desplegable en la aplicación del portal Idealista
Captura de la versión para iPhone (iOS)
Con el tiempo se ha extendido tanto el uso de tres líneas paralelas para identi-
ficar el menú que ha acabado convirtiéndose en un estándar, de manera que es
rápidamente identificado por los usuarios. A este recurso también se le llama
coloquialmente «botón�hamburguesa» y se ubica normalmente en la parte
superior izquierda de la pantalla, dentro de la barra de navegación.
También se tiene que prever la manera de volver a «esconder» el menú una

vez desplegado, ya sea tocando la pantalla fuera de su superficie (para casos de
menús que aparecen en ventanas emergentes), activando de nuevo el mismo
botón que lo hizo aparecer –o uno nuevo fácilmente identificable– o, en caso
de usar gestos, haciendo el movimiento contrario al que abrió el menú.
Menú fijo
En este caso sacrificamos parte del espacio disponible en pantalla para mostrar
el menú al usuario en todo momento. Normalmente, este elemento se sitúa
arriba o abajo de la pantalla, en forma de barra de navegación (para el usuario
de teléfono, el lugar más cómodo será siempre la parte inferior de la pantalla,
fácilmente accesible con el pulgar cuando sujeta el dispositivo con una mano).
De nuevo, las limitaciones de espacio pueden hacer que el menú fijo se use en
combinación con el escondido, de forma que una de las opciones del primero
permita el acceso al segundo, como en este ejemplo:
Menú fijo de la aplicación de Facebook
La aplicación de Facebook incluye un menú inferior fijo cuyo último botón esconde un segundo menú con más opciones. En la
imagen, captura de la versión para iPhone (iOS)
Tal y como indica su nombre, este menú es fijo, es decir, no se puede mover
cuando el usuario desplaza el resto de la pantalla, ya sea vertical u horizontal-
mente.
En tabletas, donde el espacio disponible en pantalla es superior, se puede re-

currir a uno u otro menú en función de la orientación del dispositivo. Así, en
posición horizontal, el menú se puede encontrar siempre visible a un lado de
la pantalla, mientras que en posición vertical puede esconderse y mostrarse de
nuevo con un gesto para no estorbar la vista principal.
2.1.4. Elementos de control
Dado el reducido espacio de que disponemos en el entorno móvil, el usuario

necesitará elementos de control que le permitan lograr rápidamente sus ob-
jetivos. En general, estos elementos tendrán que presentar las características
siguientes:
• Tener cierto parecido con la función que cumplen: siempre será mejor usar
unos botones con «+» o «–» para ampliar o reducir la información mos-
trada en pantalla que otros etiquetados de otra manera. El uso de metáfo-
ras, como, por ejemplo, una lupa, también resulta conveniente para que
el usuario identifique rápidamente para qué sirve el elemento de control.
• Ser visibles: si queremos que el usuario interactúe de forma natural con la

interfaz, tiene que ser plenamente consciente de la existencia de los ele-
mentos de control a su disposición. Su ubicación tiene que ser la misma
en todo momento para no despistar al usuario. En caso de necesidad, se
pueden esconder los controles para que no estorben (por ejemplo, escon-
demos los controles de reproducción cuando el usuario está viendo un
vídeo), pero estos tienen que volver a mostrarse rápidamente en caso de
que el usuario los vuelva a necesitar (por ejemplo, cuando vuelve a tocar
la pantalla).
• Dar respuesta rápidamente: los elementos de control tienen que dar seña-
les inequívocas de que han sido activados (cambiando de tamaño o de
color, mediante un sonido o vibración, etc.), puesto que de otra manera
el usuario puede pensar que no lo ha hecho bien e intentarlo de nuevo, y
provocar entradas duplicadas. Si la acción requiere cierto tiempo de proce-
samiento por parte del sistema, además de cambiar el estado del elemento
de control, resulta conveniente mostrarle un indicador de espera.
A continuación presentamos los elementos de control más habituales: despla-

zamiento, aumento y acceso rápido.
Desplazamiento
Aunque normalmente la función de desplazamiento (scroll) es contemplada

por el propio sistema operativo para los casos en los que el contenido es mayor
que el espacio disponible en pantalla, sí que deben tenerse en cuenta algunos
principios a la hora de usar este elemento:
1) Siempre que sea posible, mostraremos la barra de desplazamiento para

orientar al usuario.
2) El tamaño de la barra tiene que ser inversamente proporcional a la canti-

dad de contenido por el cual estamos navegando (es decir, más corta cuanto
más largo sea el desplazamiento y prácticamente igual de larga que la pantalla
cuando el contenido supere por unos cuantos píxeles el tamaño de esta).
3) Para no estorbar y ocupar espacio innecesario en la pantalla, la barra puede

aparecer solo cuando el usuario está desplazando el contenido, desapareciendo
pasados unos segundos de inactividad.
4) Por norma general, la barra de desplazamiento no tiene que servir para

navegar por el contenido, puesto que el usuario lo hará tocando la pantalla
en cualquier punto.
5) Es aconsejable limitar el desplazamiento a un solo eje, preferentemente el

vertical, puesto que es al que están acostumbrados los usuarios.
6) En determinados casos, como, por ejemplo, cuando se amplía una imagen,

los dos ejes (vertical y horizontal) serán igualmente importantes. En estos casos
resulta aconsejable mostrar la barra de desplazamiento en ambos sentidos.
7) A veces puede resultar útil combinar los dos desplazamientos para mostrar
el contenido, de forma que dentro de un desplazamiento vertical se puedan
consultar partes de contenido en desplazamiento horizontal.
8) La inercia en el desplazamiento se ha convertido en un comportamiento

esperado por el usuario: con un gesto rápido del dedo en una dirección, el
contenido tiene que seguir desplazándose hasta que el usuario lo detenga to-
cando de nuevo la pantalla. Si la pantalla es muy larga, se puede frenar poco a
Desplazamientos�horizontal�y�vertical
poco la velocidad de desplazamiento, requiriendo un nuevo movimiento por combinados�en�la�tienda�de�aplicaciones�de
iOS
parte del usuario.
Aumento
El aumento (zoom) permite al usuario cambiar el nivel de detalle sobre la in-

formación mostrada en pantalla. Se trata de un elemento de control habitual
en la visualización de mapas, imágenes, etc. La manera más habitual de resol-
ver esta función, hasta el punto de poderlo considerar ya un comportamiento
esperado por parte del usuario, es mediante el gesto de separar dos dedos sobre
la pantalla.
Alternativamente, para casos en que usar el gesto con dos dedos estorbe la
visión en pantalla, se puede usar una barra (slider) que, además de permitir
cambiar el aumento deslizando con un dedo, informe sobre los niveles de au-
mento disponibles y zoom actual. Para no molestar, esta barra se puede mos-
trar solo cuando el usuario toque la pantalla, haciéndola desaparecer pasados
unos segundos.
Acceso rápido
Zoom�en�la�aplicación�de�cámara
Para no estorbar la visión en pantalla, el usuario
Para ahorrarle al usuario tenerse que desplazar por listados muy largos, se pue- puede hacer zoom en la aplicación de cámara
tanto usando dos dedos sobre la pantalla como
usando la barra inferior, etiquetada con los
den establecer métodos de acceso rápido que lo trasladen de un salto a la parte símbolos «–» y «+». En la imagen, captura de la
cámara de un iPhone (iOS).
deseada de la lista. Se trata de un elemento típico en listas ordenadas alfabéti-
camente, como, por ejemplo, la libreta de contactos.
El propio sistema operativo acostumbra a ofrecer soluciones para el acceso

rápido en listas, como en este ejemplo de Windows Phone:
El acceso rápido se puede usar tanto en desplazamientos verticales como hori-

zontales, permitiendo al usuario, por ejemplo, saltar rápidamente de páginas
en una pantalla de inicio.
En este otro ejemplo de Android, el usuario puede desplazarse verticalmente El usuario puede navegar por el listado de
aplicaciones instaladas en su dispositivo
desplazándose verticalmente (imagen
hasta encontrar la aplicación deseada o bien hacerlo rápidamente tocando las de la izquierda). El listado está ordenado
alfabéticamente, y un cuadro con la inicial
iniciales en la barra inferior: correspondiente sirve a la vez de separador y
de botón de acceso rápido. Tocando una letra
(imagen de la derecha), el sistema muestra
al usuario todo el alfabeto, lo que le permite
acceder rápidamente a las aplicaciones por su
Acceso rápido en el menú de aplicaciones de un teléfono Android inicial, sin necesidad de desplazarse por toda
la lista. Las letras sin contenido (es decir, no
hay aplicaciones instaladas que empiecen por
aquella letra) aparecen oscurecidas, indicando
al usuario que no están activas.
2.2. Mostrar información
Pasamos a describir los elementos que sirven para mostrar información.
2.2.1. Listados
Los listados (lists) –también denominados tablas– son la forma más eficiente de
mostrar información en formato texto, opciones de un menú o los resultados
de una búsqueda, puesto que permiten escanear rápidamente su contenido
y hacer selecciones. Pueden incluir más de una línea de texto, aunque no es
recomendable pasar de tres líneas para no dificultar la lectura.
Ejemplo de listado en la aplicación de correo electrónico Gmail para Android
Fuente: play.google.com
El desplazamiento a lo largo de listados es siempre en vertical y su movimiento

tiene que ser suave, píxel a píxel, para permitir un buen control por parte del
usuario.
Listado infinito
En los listados infinitos, la información no está almacenada en local y se tiene

que ir cargando progresivamente, «fuera de la vista» del usuario. En condicio-
nes ideales, el usuario la percibirá como una lista vertical. Pero se tiene que
prever el caso de que el usuario llegue al final del listado y todavía se tengan
que cargar más elementos (hará falta un indicador de espera) o se haya produ-
cido un error en la carga. Una alternativa es poner un botón al final del listado
para permitir la carga de más datos.
Ejemplo de listado infinito en la aplicación de TripAdvisor
El enlace al final de la lista permite la carga de más resultados.
Listado con miniaturas
Los listados con miniaturas incorporan un elemento gráfico (normalmente en

la parte izquierda de la pantalla), que permite al usuario identificar más rápi-
damente los elementos del listado. Es un recurso habitual para listar contactos;
en este caso la miniatura suele ser la fotografía o avatar de la persona.
Ejemplo de listado con miniaturas, en este caso iconos, de la aplicación Runtastic para Apple
Watch
Fuente: apple.com
Listado con foco
El listado con foco permite ver más información del elemento que tenemos
seleccionado dentro de una lista sin necesidad de abrirlo.
2.2.2. Pestañas
Como ya hemos visto, además de servirnos para organizar la navegación de

cualquier aplicación, también podemos usar las pestañas puntualmente para
mostrar información en un apartado concreto. Las recomendaciones de uso
aquí son exactamente las mismas que las vistas en el módulo «Arquitectura y
wireframes» y a ellas nos remitimos.
2.2.3. Tarjetas
Las tarjetas (cards) sirven como punto de partida para mostrar información
más detallada. Una tarjeta puede contener un título, texto, imagen, un enlace
o botón... Ha sido Android, con el estilo de diseño Material�Design, el que ha
popularizado este patrón de diseño, rápidamente adoptado por los diseñadores
gracias a su versatilidad y consistencia entre dispositivos.
Dos ejemplos del uso de tarjetas en Android
Fuente: material.google.com
Algunos consejos sobre el uso y comportamiento de las tarjetas:
• La tarjeta debe ser tratada como una unidad, donde la información se or-
ganiza jerárquicamente, colocando lo más importante en la parte superior
o usando diferentes tamaños de letra para enfatizar el contenido principal.
• Si usamos una imagen como fondo, debemos asegurarnos de que el texto

sobreimpresionado se pueda leer sin problemas.
• Las tarjetas soportan dos gestos básicos: el desplazamiento vertical para

navegar por una colección de tarjetas y el gesto de deslizar lateralmente
(swipe) para descartarlas.
• La zona activa de una tarjeta es la propia tarjeta en su conjunto, más allá

de que ofrezcamos acciones secundarias usando iconos, texto u otros con-
troles, normalmente en la parte inferior de la tarjeta.
Ejemplo de acciones secundarias en una tarjeta, en este caso, para puntuar un álbum
Lectura complementaria
Más información:
Sobre el uso y comporta-
miento de las tarjetas en An-
droid, podéis consultar este
enlace: Cards.
2.2.4. Cuadrícula
La cuadrícula (grid) sirve para mostrar de forma ordenada (sobre un eje ver-
tical u horizontal) un conjunto de elementos (normalmente, imágenes), sin
mostrar ninguna otra información, que en cambio sí se puede revelar cuando
el usuario selecciona uno de ellos. Es el patrón más habitual en galerías de
imágenes.
Fotos organizadas en cuadrícula en la aplicación Google Fotos
2.2.5. Pila
La pila de elementos (stack of items) se acostumbra a usar cuando tenemos una

serie de elementos, como, por ejemplo, fotografías o vídeos que se pueden
mostrar en miniatura. En lugar de mostrar las carpetas contenedoras, los mos-
tramos como si estuvieran literalmente amontonados los unos sobre los otros.
Es importante, para ser identificada como tal, que la pila esté mal ordenada,
es decir, que por debajo de la primera miniatura se puedan ver las esquinas y
márgenes del resto de miniaturas. Visualmente, sin embargo, la pila no tiene
que ocupar mucho más espacio que el de una sola miniatura.
Al igual que con los iconos, es aconsejable que las pilas estén etiquetadas para
su correcta identificación. Al abrir una pila –normalmente, dando un solo to-
que sobre el primer elemento de la pila–, todos los elementos pasan a mostrar-
se sobre una cuadrícula. Este patrón requiere de buenas animaciones, tanto
cuando la pila se despliega en una cuadrícula como cuando vuelve al estado
original.
2.2.6. Pase de diapositivas
El pase de diapositivas (slideshow) sirve para mostrar en pantalla completa una

serie de imágenes. El usuario pasa de una imagen a la otra haciendo el gesto de
deslizar lateralmente con el dedo. Se puede animar ligeramente el cambio de
imagen, ya sea desplazando las imágenes hacia los lados o encadenándolas.
2.2.7. Anotación
El elemento anotación (anotation) nos ayuda a mostrar más información u op-

ciones de un elemento sin abandonar la pantalla en la que nos encontramos.
Es un recurso habitual en mapas y gráficas, o en situaciones en las que tenemos
varias capas de información que no se pueden mostrar a la vez. Para hacerlo,
tenemos dos recursos básicos, la etiqueta expansiva y la franja fija:
1)�Etiqueta�expansiva: en este patrón, cuando el usuario interactúa con el

elemento (normalmente, con un toque), la anotación se despliega para mos-
trar la nueva capa de información.
Etiqueta expansiva en la aplicación Yelp
Al tocar sobre un resultado en el mapa, la etiqueta muestra más detalles sobre el restaurante. En la imagen, captura de la
versión para iPhone (iOS).
2)� Franja� fija� (banner): aquí la anotación se muestra siempre en el mismo

lugar (normalmente, al pie o en la cabecera de la pantalla) y la información
varía en función del elemento seleccionado. Se acostumbra a usar cuando hay
muchos elementos en pantalla o mucha información para mostrar.
Ejemplo de franja fija en la aplicación de Trivago
La información de los hoteles seleccionados sobre el mapa se muestra siempre en la parte inferior de la pantalla. En la imagen,
captura de la versión para iPhone (iOS).
3)�Etiqueta�desplegable: en este caso, la anotación puede desplegarse estiran-

do hacia arriba con el dedo, permitiendo de esta manera ver casi tanta infor-
mación como la que se mostraría abriendo una nueva página.
Etiqueta desplegable en la aplicación Mapas de iOS
Tocando sobre un resultado en el mapa, se muestra la etiqueta, que puede desplegarse progresivamente (en tres posiciones).
Para cerrarla, el usuario puede hacer el gesto contrario o bien pulsar el botón de cierre.
Las anotaciones pueden presentarse en múltiples formatos: solo texto; título,

texto e imagen; solo una imagen... Todo depende de la información que se
tenga que mostrar. Incluso se pueden incluir enlaces hacia otras pantallas o
aplicaciones.
2.3. Entrada de datos
Los principales elementos que pueden proporcionar entrada de datos en las

interfaces para dispositivos móviles pueden ser el teclado, la voz, los campos
de texto y formularios, los botones, y los interruptores, barras y selectores.
2.3.1. Teclado
Ya sea para enviar correos electrónicos, mensajes, hacer búsquedas en internet

o llenar un formulario, los usuarios necesitan un sistema que les permita es-
cribir con la mayor facilidad y fiabilidad posible, ya sea a través de un teclado
físico –cada vez menos habitual en los dispositivos móviles–, o a partir de uno
virtual.
1) La disposición del teclado suele venir definida por el sistema operativo, de

forma que cualquier cambio puede desconcertar al usuario o dificultarle la en-
trada de texto al tener que aprender un nuevo sistema. En este sentido, la tra-
dicional disposición impuesta por el teclado numérico de los primeros teléfo-
nos móviles ha dado paso al sistema QWERTY, aunque muchos desarrollado-
Teclado�Minuum
res trabajan en disposiciones alternativas, plenamente adaptadas a las carac- Para aprovechar al máximo el espacio
disponible en pantalla, el teclado Minuum se
terísticas de las pantallas táctiles. reduce a una sola línea (fuente: minuum.com).
2) Para facilitar la entrada de texto –sobre todo en teclados táctiles– se pueden

ofrecer ayudas, como, por ejemplo, la autocorrección, sugerencias o autocom-
pletado de palabras de acuerdo con el diccionario definido por el usuario. Se
tiene que evitar, sin embargo, que estas ayudas funcionen de forma automá-
tica: tiene que ser el usuario quien, en última instancia, acepte la sugerencia o
corrección que le ofrece el sistema. En la misma línea, estas ayudas se tienen
que poder desactivar totalmente en el caso de que el usuario no las quiera usar.
3) La entrada de texto se hace normalmente pulsando las teclas, una detrás

de la otra, aunque hay aplicaciones o dispositivos que permiten la entrada de
palabras deslizando el dedo por encima del teclado.
4) Muchas veces el sistema operativo permite predeterminar o limitar los mo-

Escritura�de�palabras�mediante
dos de teclado disponibles en función de las características del campo de texto deslizamiento
Para escribir palabras, el usuario tiene que
donde se va a usar, tanto para facilitarle el trabajo al usuario como para evitar deslizar el dedo sobre el teclado enlazando
cada una de las letras.
errores en la introducción de datos (por ejemplo, en un campo para introducir
direcciones de correo se desactiva el teclado de emoticonos).
2.3.2. Voz
Hasta hace relativamente poco, la idea de poder hablar con las máquinas era
cosa de ciencia ficción, como HAL 9000 en el clásico 2001: A Space Odyssey, de
Stanley Kubrick. Con la mejora de las técnicas de reconocimiento de voz, sin
embargo, cada vez es más habitual encontrarse este sistema como una opción
más, a menudo junto al teclado, para escribir mensajes, tomar notas o hacer
búsquedas en internet.
Si tenemos en cuenta que una de las máximas a la hora de diseñar interfaces

móviles es facilitar al máximo el trabajo a los usuarios agilizando la entrada
de datos, parece lógico pensar que pronunciar en voz alta una frase siempre
será más cómodo que escribirla letra a letra en un teclado virtual. Ahora bien,
hay que estar seguro de que la tecnología de reconocimiento de voz funciona
a la perfección antes de eliminar la opción del teclado. De igual manera, es
aconsejable que el usuario pueda editar con el teclado aquello que el sistema
haya «entendido» mal.
Por otro lado, sistemas como Siri, de la compañía Apple o Google Now en
Android, están llevando el reconocimiento de voz un paso más allá, pasando
de la simple transcripción de lo que el usuario ha dicho a interpretar órdenes
o dar respuesta a preguntas. El potencial de esta tecnología es muy elevado,
hasta el punto de convertir los dispositivos móviles en auténticos asistentes
personales con los que mantendremos conversaciones.
Ejemplo�de�voz
Siri es el asistente personal de Apple, con el que
el usuario interactúa mediante la voz.
El extremo en este punto lo encontramos en Amazon�Echo, un dispositivo

doméstico con el que solo podemos interaccionar mediante voz y que respon-
de ofreciendo información, noticias, reproduciendo música, reservando mesa
en un restaurante...
Aunque hablar con una máquina se nos haga extraño, cabe esperar que en
los años venideros la voz adquirirá un gran peso en nuestra relación con la
tecnología. En este sentido, Apple presentó en junio de 2016 SiriKit, con la
idea de que los desarrolladores de aplicaciones puedan ofrecer sus servicios y
contenidos a través del asistente personal en iOS, un movimiento estratégico
que seguro que impulsará la aparición de nuevos e interesantes usos para Siri. Y
desde el punto de vista del diseñador, obligará a repensar la relación del usuario
con su producto o servicio, prescindiendo de teclados, botones o formularios.
Amazon�Echo
2.3.3. Campos de texto y formularios Fuente: Amazon.com
Al igual que en los ordenadores de sobremesa, los campos de texto son un ele-
mento imprescindible para permitir la entrada de texto al usuario, por ejem-
plo, en un formulario de registro.
Formulario de registro en la aplicación de Idealista
Dando un toque con el dedo sobre el campo de texto, este se activa y aparece
el teclado para que el usuario pueda escribir. Si el sistema operativo lo permi-
te, podemos ahorrar trabajo al usuario mostrándole el modo de teclado más
apropiado a los datos que tiene que introducir; por ejemplo, teclado numérico
cuando lo que tiene que escribir es un número de teléfono o una cantidad.
La introducción de datos en un formulario es una de las tareas más

habituales y también una de las más críticas, debido al elevado número
de errores que cometen los usuarios sobre el teclado virtual.
Ejemplo de teclado numérico
Para introducir el número de tarjeta de crédito, la aplicación de Vueling muestra directamente un teclado numérico. En la
imagen, captura de la versión para iPhone (iOS).
Algunas recomendaciones para el uso de campos en los formularios:
1) Hay que identificar bien en todo momento cuál es el campo activo, ya sea
destacando el borde del marco, colocando un cursor, resaltando el color de
fondo o con otro efecto que lo diferencie del resto de campos.
2) En caso de formularios largos, se tiene que tener cuidado y resolver bien el

paso de un campo de texto a otro, puesto que es posible que el propio teclado
impida activar el siguiente campo con el dedo al superponerse a este.
3) Para ahorrar espacio en formularios, la etiqueta del campo de texto se puede

mover al interior de la caja, o también dejarla fuera, para añadir unas breves
instrucciones sobre cómo llenar el campo. En estos casos hace falta que este
título o instrucciones se diferencien bien del texto que después introducirá el
usuario (normalmente, esto se consigue haciendo aparecer el texto en cursiva
o de color gris).
Este formulario de registro acierta al mostrar instrucciones claras al usuario sobre cómo crear su contraseña y le facilita el trabajo
mostrándole los caracteres. Un botón permite ocultarlos y convertirlos en los clásicos puntos, en caso de ser necesario. Sin
embargo, este formulario falla al no validar el campo de correo electrónico, que no muestra ninguna señal de alerta. En la
imagen, captura de la aplicación Adobe Spark para iPhone (iOS)
4) Siempre que sea posible, es recomendable comprobar si el usuario ha intro-

ducido bien los datos en el mismo momento en que lo hace (por ejemplo,
indicándole cuántos caracteres le faltan para establecer una contraseña segu-
ra) o cuando salta al siguiente campo, de forma que pueda corregir el error lo
antes posible.
5) Para evitar errores, se recomienda no transformar caracteres de la contraseña

en puntos, sobre todo cuando el usuario se está dando de alta y creando la
contraseña por primera vez. Por defecto, mostraremos los caracteres tal cual,
ofreciéndole la posibilidad de ocultar su contraseña con un botón.
6) Para reducir el tiempo a la hora de rellenar un formulario, es conveniente

usar listas desplegables, casillas de verificación (checkboxes) y otros selectores
que faciliten el trabajo al usuario. Por ejemplo, siempre será más rápido elegir
un país de una lista que tenerlo que escribir letra por letra.
Formulario para la edición del perfil de usuario en Wallapop

Lectura complementaria
Para profundizar sobre la va-

lidación de formularios en
los dispositivos móviles, po-
déis leer:
S.�Hoober (2012, 3 de sep-
tiembre). «Mobile inline
form validation». Uxmatters.
El formulario para la edición del perfil de usuario en Wallapop dispone de un selector (picker) para introducir la fecha de
nacimiento. En la imagen, captura de la versión para iPhone (iOS).
2.3.4. Botones
Los botones son quizás el elemento más habitual de una interfaz y nos sirven
para iniciar acciones, modificar estados o validar la entrada de datos. Por lo
tanto, los botones tienen que ser fáciles de identificar y activar, sobre todo
cuando hablamos de dispositivos táctiles. Un recurso habitual es diseñar los
botones como si tuvieran relieve o añadiendo sombras. Otras maneras de mos-
trar su cambio de estado son modificando su color, brillantez, etc.
Con el auge del diseño plano, sin embargo, los botones están perdiendo a me-
nudo sus bordes o marcos, quedando reducidos a mero texto. Aún así, el área
activable debe seguir siendo la misma que antes, para facilitar su activación
por parte de los usuarios.
Diferentes estilos de botón en Android
2.3.5. Interruptores, barras y selectores
Los dispositivos táctiles ofrecen múltiples formas más interactivas de introdu-

cir datos y hacer selecciones, basadas en gestos sobre la pantalla, que van más
allá del uso del teclado virtual. Bien diseñados e implementados, estos contro-
les pueden facilitar el trabajo al usuario a la vez que pueden hacerle más intui-
tivo y agradable el uso del dispositivo. Cada sistema operativo suele definir sus
propios sistemas por defecto, pero nada impide que se puedan diseñar otros
nuevos para una aplicación en concreto, puesto que es en este tipo de detalles
donde se cuida la experiencia de usuario. En este sentido, es importante cuidar
la sensibilidad y velocidad de respuesta del sistema en las acciones que haga
el usuario, para evitarle frustraciones.
Interruptores
Los interruptores (switches) se usan sobre todo en menús de configuración,

donde hay opciones que solo permiten dos posiciones (activada y desactiva-
da). En lugar de mostrarle las dos opciones en una lista desplegable, lo que
hacemos es presentarle un interruptor, un elemento que reconocerá perfecta-
mente y que cambiará instintivamente de posición deslizando con el dedo:
Interruptores en iOS (izquierda) y Android (derecha)
Fuentes: apple.com y material.google.com
Barras
Las barras (sliders) se suelen usar cuando tenemos que seleccionar un valor
dentro de una escala determinada. Los ejemplos más claros son el control de
volumen del dispositivo o del brillo de la pantalla.
Barra para el control del brillo en iOS
Podemos encontrar barras para las más variadas funciones, por ejemplo, con-
trolar el punto de reproducción de una película o vídeo.
Barras de control de vídeo y volumen
El reproductor de vídeo de Netflix para tabletas muestra dos barras: una para controlar el vídeo y otra en la esquina superior
para el volumen. En la imagen, captura de pantalla de la aplicación de Netflix para iPad (iOS).
Selector
En lugar de hacer que el usuario introduzca, por ejemplo, una cita escribiendo
una fecha y una hora con el teclado numérico, podemos dejar que lo haga
girando una rueda o cambiando los números sobre la pantalla del dispositivo.
Selector en Android
El selector (picker) permite múltiples variantes y diseños, desde la ya clásica

rueda giratoria de iOS hasta otros que prescinden incluso de los botones para
ajustar los valores, como en este ejemplo de Windows Phone, donde el usua-
rio hace deslizar verticalmente, una a una, las columnas hasta dejarlas en la
posición deseada.
Captura de pantalla de un selector de fechas en Windows Phone
Prácticamente no hay límite a la hora de diseñar selectores para la entrada

de datos. Las únicas limitaciones, como siempre, son su facilidad de uso y la
velocidad de respuesta cuando el usuario los manipula.
2.4. Buscar y filtrar información
Los usuarios quieren acceder a la información guardada en sus dispositivos

móviles rápida y fácilmente. La función de buscar y filtrar, por lo tanto, es
crítica, sobre todo en aparatos con gran capacidad para almacenar informa-
ción en todo tipo de formatos (documentos de texto, fotografías, canciones,
contactos, correos electrónicos, aplicaciones, etc.). En este sentido, los patro-
nes más habituales a la hora de implementar esta función persiguen agilizar el

proceso de búsqueda para permitir al usuario lograr su objetivo con el mínimo
número de toques sobre la pantalla.
Buscar en el móvil implica introducir texto mediante el teclado táctil,

un trabajo no siempre fácil ni agradable para el usuario.
Algunas consideraciones generales sobre la búsqueda en los dispositivos mó-

viles:
1) El elemento más habitual para indicar la posibilidad de hacer una búsqueda

es una caja de texto, acompañada de un botón convenientemente identificado
para iniciar la acción con la etiqueta «Buscar» o un icono (normalmente, una
lupa). Para ahorrar espacio, podemos incluir tanto la etiqueta como el icono
dentro mismo de la caja:
Caja de búsqueda en la aplicación de LinkedIn para Android
El texto dentro de la caja indica al usuario qué tipo de búsquedas puede realizar.
2) Si la búsqueda se hace sobre varios tipos de documentos a la vez, resulta

conveniente presentar los resultados agrupados por tipología.
3) Cuando el usuario introduzca texto para hacer la búsqueda, hay que consi-
derar resaltar este texto (aunque sean tres letras) en los resultados.
4) En búsquedas relacionadas con la ubicación del usuario sobre el mapa, po-

demos obtener su posición automáticamente con el GPS para ahorrarle teclear
donde se encuentra a la hora de, por ejemplo, buscar rutas.
Aplicación Google Maps
La aplicación de Google Maps toma por defecto la ubicación del usuario como punto de partida para calcular rutas. En la
imagen, captura de pantalla de la aplicación para iPhone (iOS).
5) Los resultados de la búsqueda se pueden mostrar en formato de lista, con

miniaturas, sobre un mapa... En función de los contenidos, podemos ofrecer
diferentes formas de visualizar los resultados de la búsqueda.
6) Finalmente, en función de la rapidez del sistema (o de la conexión a la red),

habrá que usar patrones de respuesta como el de rueda de espera para advertir
al usuario que el sistema está trabajando buscando una respuesta a su petición.
2.4.1. Búsqueda dinámica
Con este patrón ahorramos trabajo al usuario evitándole tener que desplazarse
por un listado, permitiéndole filtrar los elementos de la lista a medida que va
escribiendo en la caja de búsqueda, de modo que tenga suficiente con las tres
o cuatro primeras letras para encontrar el elemento que busca. Es un patrón
habitual en libretas de contactos o bibliotecas de contenido multimedia.
Ejemplo de búsqueda dinámica en iOS
En los resultados se destacan en negrita las letras introducidas por el usuario. En la imagen, captura de un iPhone.
2.4.2. Autocompletado
En este patrón, heredado directamente de la web (el ejemplo clásico aquí es

Google), en cuanto el usuario empieza a escribir en la caja de búsqueda, se le
empiezan a sugerir posibles resultados. Ante esto, el usuario puede optar por
seleccionar una de las sugerencias que le hace el sistema o continuar escribien-
do su búsqueda. El comportamiento de este patrón puede parecer idéntico al
de la búsqueda dinámica, pero hay que tener en cuenta que mientras que en
la búsqueda dinámica discernimos elementos de una lista existente –es decir,
hacemos un tipo de filtrado–, en el patrón de autocompletado no hay ningu-

na lista previa, sino que se sugieren términos de búsqueda a medida que el
usuario escribe.
Autocompletado en una búsqueda en la tienda de aplicaciones Google Play (Android)
2.4.3. Búsqueda con filtros
A veces, el usuario encontrará más rápido aquello que busca si puede filtrar
los resultados por tipos de documento, categorías o bien estableciendo ciertas
condiciones que tienen que cumplir los resultados obtenidos. Es un patrón
habitual cuando nos encontramos ante gran cantidad de información, donde
la búsqueda devuelve demasiados resultados como para encontrar rápidamen-
te lo que buscamos. Este filtrado se puede hacer de forma previa a la búsque-
da o como sistema para refinar los resultados ya obtenidos con una búsqueda
más general.
Ejemplo de búsqueda con filtros
Los filtros ayudan al usuario a refinar su búsqueda fácilmente. En la imagen, captura de pantalla de la aplicación de Idealista
para iPhone (iOS).
Las variantes a la hora de presentar este patrón son múltiples, ya sea porque los
filtros se ofrecen en la misma pantalla donde el usuario ve los resultados o bien
a través de un formulario, una ventana emergente, un menú desplegable...
También son variadas las herramientas que podemos usar para permitir el fil-
trado: listas, selectores, barras, desplegables, interruptores...
Filtros de búsqueda en la aplicación de Trivago para iPhone (iOS)
2.4.4. Últimas búsquedas
Otra manera de ahorrarle tiempo al usuario es recordarle las últimas búsquedas

que ha hecho, por si quisiera repetir alguna. Este patrón se puede combinar
con otros, por ejemplo, el de autocompletado, de forma que al situarse sobre
el campo de búsqueda, antes de empezar a escribir, el usuario ve las últimas
búsquedas que ha hecho, y es al empezar a escribir cuando se le presentan las
opciones de autocompletado.
2.4.5. Formulario de búsqueda
En lugar de introducir una palabra o cadena de texto, a veces puede ser más
sencillo para el usuario establecer unos criterios o parámetros a través de un
formulario. Es un patrón habitual a la hora de buscar vuelos, alojamiento...
pero que también se puede usar para refinar la búsqueda en grandes bases de
datos.
Formulario de búsqueda en la aplicación de Booking.com para iPhone (iOS)
2.4.6. Búsqueda por geoposición
La mayoría de dispositivos móviles son capaces de detectar su posición sobre

el mapa, hecho que podemos aprovechar para ofrecer búsquedas basadas en la
geoposición del usuario. Este es un patrón que se ofrece normalmente como
alternativa o complemento a otros métodos de búsqueda más «clásicos», por
ejemplo, la búsqueda por texto o mediante categorías, pero que bien imple-
mentado, se convierte en un sistema muy eficaz para ofrecer resultados rele-
vantes. Para acelerar la búsqueda reduciendo el número de resultados sobre el
mapa, en este patrón también se pueden usar filtros por categorías, distancia
respecto al usuario, etc.
Ejemplo de búsqueda basada en la geoposición del usuario en la aplicación de Trivago
La posición del usuario está marcada con un punto azul sobre el mapa. En la imagen, captura de pantalla de la versión para
iPhone (iOS).
2.4.7. Ordenar los resultados
Una vez hecha la búsqueda, es importante decidir cuál será el criterio por de-
fecto con que ordenaremos los resultados. En caso de disponer de varias op-
ciones, podemos dejar que sea el propio usuario quien decida cómo quiere
ordenar los resultados de su búsqueda. Los patrones en este caso son los mis-
mos que podemos usar a la hora de filtrar (selector en pantalla, formulario,
ventana emergente, etc.).
Ejemplo de ordenación de los resultados de una búsqueda mediante un selector

Lecturas
complementarias
Para ampliar sobre los patro-

nes de búsqueda:
P.�Morville;�J.�Callender
(2010). Search patterns: De-
sign for discovery. Sebastopol:
O’Reilly.
Sobre la dificultad a la hora
de buscar con el móvil:
G.�Nudelman (2010, 8 de
marzo). «Designing mobile
search: Turning Limitations
into opportunities». Uxmat-
ters.
Una vez obtenidos los resultados, el usuario de El Tenedor puede ordenarlos mediante un selector. En la imagen, captura de
pantalla de la versión para iPhone (iOS).
2.5. Respuesta al usuario
Como ya hemos comentado anteriormente, el feedback al usuario resulta crí-

tico, sobre todo cuando este interactúa con la interfaz mediante una pantalla
táctil que no ofrece ningún tipo de respuesta háptica. En este subapartado es-
tudiaremos varios tipos de respuesta al usuario: confirmaciones, mensajes de
error e indicadores de espera.
2.5.1. Confirmación
Ante un dispositivo móvil es muy fácil despistarse o tocar algún botón de for-
ma accidental, de forma que hay que prever sistemas para confirmar determi-
nadas acciones por parte del usuario, sobre todo cuando es probable que esté
cometiendo un error o descuido. En estos casos, hay que interrumpir la tarea
e interrogar directamente al usuario para que confirme su acción.
Por otro lado, los mensajes de confirmación también nos pueden servir para
preguntar al usuario qué quiere hacer en aquellos casos en los que la acción
iniciada nos lleva a diferentes alternativas o para informarle de que una tarea
ha finalizado correctamente.
Tres ejemplos de acciones de confirmación
Primera acción (izquierda): mensaje para confirmar la desinstalación de una aplicación en iOS. Segunda acción (centro): para
decidir qué hacer con un correo cuando el usuario ha decidido no enviarlo. Tercera acción (derecha): para animar al usuario a
iniciar sesión o registrarse cuando ha decidido omitir este paso.
Lo más habitual es mostrar al usuario mensajes de confirmación con dos o tres

opciones (representadas con botones), aunque a veces se le pueden mostrar
mensajes con una o incluso ninguna opción.
No hay que abusar de los mensajes de confirmación, puesto que pueden

crear inseguridad en el usuario y lo frenan en su objetivo de cumplir
una tarea lo más rápido posible.
Es importante describir bien el motivo del mensaje, así como etiquetar correc-
tamente los botones que expresen las opciones disponibles, evitando el sim-
ple «Sí» o «No», sino describiendo la acción que se llevará a cabo si el usuario
elige esa opción.
Ejemplo de mensaje de confirmación
Este mensaje de confirmación en la aplicación de Pokémon Go podría mejorarse cambiando el texto de los botones por
las acciones «Transferir» y «Cancelar». Por otro lado, tratándose de una acción que no puede revertirse, tampoco debería
destacarse el botón del «Sí» por encima del «No».
Finalmente, insistiendo en la idea de no abusar de los mensajes de confirma-

ción, en muchas ocasiones podemos optar por ofrecer durante unos segun-
dos la opción de deshacer. De esta manera, no estaremos poniendo en duda
constantemente las acciones del usuario y le daremos una mayor sensación
de control sobre la interfaz.
Ejemplo de opción de deshacer la última acción
En lugar de requerir de un nuevo toque sobre la pantalla para confirmar el borrado de una foto como hace la aplicación nativa
de iOS (izquierda), la aplicación de Google Fotos (derecha) borra la fotografía al primer toque y muestra durante unos segundos
la opción «Deshacer».
2.5.2. Mensajes de error
Aunque indeseables, los mensajes de error son imprescindibles en cualquier

interfaz, ya sea para dar una salida ante comportamientos inesperados del sis-
tema o para alertar al usuario cuando algo ha ido mal.
Como norma general, los mensajes de error tienen que cumplir las caracterís-
ticas siguientes:
• Ser visibles. Lo peor que puede pasar es que algo vaya mal y el usuario no
se entere.
• Estar escritos en un lenguaje conciso y claro.
• Ser educados y no culpar al usuario por el error.
• Describir exactamente qué ha ido mal.
• Dar indicaciones claras sobre cómo resolver el error y, si es posible, ayudar
a corregirlo automáticamente.
En los dispositivos móviles, lo más habitual es mostrar los mensajes de error

abriendo un diálogo, aunque no es la forma más idónea, puesto que a menudo
la propia ventana emergente del mensaje de error puede estorbar la vista de
dónde está el error.
Diálogo de error en el inicio de sesión en TripAdvisor para iPhone (iOS)
Como ya hemos visto, una manera de reducir errores en este tipo de formularios es no ocultar por defecto el campo de la
contraseña.
2.5.3. Indicadores de espera
A medida que mejoran el hardware y las conexiones, el usuario le pide cada vez
más y más a su dispositivo. Pero por mucho que avance la tecnología, hay algo
que no cambia: a veces hay que esperar para obtener aquello que queremos.
Para evitar frustraciones, tenemos que ser capaces de mostrar claramente que el
dispositivo está procesando información, cargándola o simplemente buscando
lo que se le ha pedido.
Los indicadores de espera son un elemento habitual en cualquier sistema ope-

rativo, pero muchas veces habrá que diseñar uno nuevo, adaptado a las nece-
sidades de nuestra aplicación.
Los patrones básicos que presentamos aquí se pueden combinar y usar a la

vez. Por ejemplo, podemos cargar progresivamente el contenido a la vez que
superponemos una rueda de espera o mostramos una barra de progreso para
toda la página.
En todo caso, es siempre preferible que los indicadores de espera estén anima-
dos: el usuario interpretará a menudo un indicador inmóvil como que ha ha-
bido un problema. Así, si usamos una barra de progreso, además de hacerla
avanzar a medida que se completa la tarea, es aconsejable que la propia barra
tenga una animación interna que muestre actividad, sobre todo en casos de
cargas muy largas donde la barra avanza muy lentamente.
Finalmente, especialmente si la espera ha sido muy larga, es probable que el

usuario ya no esté mirando la pantalla cuando la tarea se haya completado.
Es conveniente, en estos casos, alertar al usuario con un sonido, vibración o
volviendo a iluminar la pantalla, etc., o una combinación de estos junto con
un mensaje (por ejemplo, un diálogo) que deje muy claro al usuario que el
proceso ha finalizado.
Rueda de espera
La rueda de espera se usa para esperas muy cortas o bien cuando no sabemos
seguro cuánto durará la espera. Se suele presentar como un gráfico animado,
sin final.
Rueda de espera mientras se procesa una búsqueda en la tienda de aplicaciones de iOS
Barra de progreso
La barra de progreso (progress bar) nos muestra el total que se tiene que alcanzar
como una barra vacía que se va llenando poco a poco a medida que avanza
la carga. Se puede acompañar de un contador que muestre el porcentaje de
carga alcanzado o el tiempo restante para completar la tarea. Este patrón es
habitual en esperas que pueden ser largas, por ejemplo, la descarga de datos. En
acciones que impliquen esperas potencialmente largas, es conveniente ofrecer
un botón para detener o cancelar la operación.
Barra de progreso durante la descarga de una aplicación en la tienda de aplicaciones de

Android
Carga progresiva
En este patrón, en lugar de mostrar una rueda o barra de progreso, se arranca

con una estructura de la página, sobre la que se va cargando el contenido, a
medida que está disponible.
Carga progresiva utilizando «pantallas esqueleto»
Fuente: http://www.lukew.com/.
Según Luke Wrobleski, diseñador y jefe de producto en Google, la ventaja de Lectura complementaria
este recurso es que hace que el usuario se centre en el contenido que se está
L.Wrobleski (2013, 17 de
cargando y no en el hecho de la espera en sí, como sucede con la rueda de septiembre). «Mobile Design
espera. De hecho, Wrobleski ha bautizado estas pantallas falsas de carga como Details: Avoid The Spinner».
LukeW Ideation + Design.
«pantallas esqueleto» (skeleton screens).
Pantalla esqueleto durante la carga inicial en la aplicación de Facebook para iPhone (iOS)
En el fondo, no se trata más que de distraer la atención del usuario: el tiempo

de espera va a ser el mismo, pero usando este truco, el usuario tendrá la sen-
sación de que todo carga más rápido. De hecho, para usar este patrón no hace
falta ni siquiera que el «esqueleto» se corresponda exactamente en tamaño y
forma con el contenido real que después ocupará su lugar.
2.6. Ayuda
Las interfaces tienen que ser fáciles de usar, intuitivas, pero aun así, siempre
se tiene que ofrecer algún tipo de ayuda al usuario, sobre todo cuando es la
primera vez que abre una aplicación. Los patrones para mostrar la ayuda son
variados y cada día encontramos formas más creativas de ofrecer esta infor-
mación al usuario.
Antes de empezar, tres recomendaciones básicas para diseñar una buena ayu-
da:
1)�Usa�poco�texto: aunque sintamos la necesidad de explicar nuestro produc-

to, siempre será mejor mostrarlo en acción, o mejor aún, dejar que los usuarios
aprendan mientras van usándolo.
2)�No�lo�expliques�todo�de�entrada: relacionado con el punto anterior, deja

espacio para que el usuario se sorprenda y descubra el funcionamiento por sí
mismo. Si damos demasiada información al principio, intimidaremos al usua-
rio, además de que no retendrá más que un par de ideas.
3)�Piensa�en�la�experiencia�del�usuario: es un tutorial, de acuerdo, pero...

¿de verdad tiene que ser aburrido?
2.6.1. Diálogo
Los diálogos (dialog boxes) se presentan en formato texto, a través de una ven-
tana que se cierra pulsando un botón (normalmente, «Aceptar», «Continuar»,
«De acuerdo»...). Es recomendable que el mensaje con las instrucciones sea
lo más breve y claro posible, puesto que el usuario muchas veces lo leerá por
encima o directamente lo ignorará.
Ejemplo de diálogo en la aplicación para iPhone (iOS) de AliExpress
No hay que abusar de los diálogos, puesto que se trata de un sistema

muy agresivo, que interrumpe la tarea que está llevando a cabo el usua-
rio y no le deja seguir hasta que cierra la ventana.
Por otro lado, ante el riesgo de que el usuario cierre por error la ventana sin
haberle dado tiempo a leer el contenido, es recomendable que este mensaje
se pueda recuperar en otro punto de la aplicación (por ejemplo, a través del
menú, en un apartado general de ayuda, etc.).
2.6.2. Consejo
El consejo (tip) se asemeja mucho al diálogo, pero se diferencia de este en el

hecho de que está más integrado en la interfaz, normalmente en forma de glo-
bo, que apunta hacia el elemento sobre el que da información. Suele presen-
tarse solo en formato texto y lo más habitual es que los consejos desaparezcan
en cuanto el usuario empieza a interactuar con la pantalla o toca el elemento
que explican.
Consejo en la aplicación de mensajería Hangouts de Google
El usuario puede descartar la ayuda bien tocando sobre el elemento mostrado o bien tocando sobre «Ignorar» (en la captura,
versión para iPhone).
Los consejos se muestran normalmente las primeras veces que el usuario usa
la aplicación, para ayudarlo a identificar las funciones principales.
2.6.3. Instrucciones
Las instrucciones (How To) son la forma que más se acerca a los manuales de
instrucciones de toda la vida. En función de su extensión, se pueden presentar
en una sola página o en forma de menú o listado navegable. Siempre que se
pueda, resulta conveniente usar una combinación de texto, capturas de pan-
talla, imágenes, gráficos, etc.
Instrucciones
Instrucciones (aquí llamadas «Información útil») para dominar las herramientas de retoque fotográfico en Snapseed. En la
imagen, captura de pantalla de Snapseed para iPhone (iOS).
2.6.4. Visita guiada
Con este sistema, el usuario puede hacer un recorrido rápido sobre las princi-
pales funciones y características de la aplicación. Es habitual mostrar la visita
guiada automáticamente la primera vez que el usuario abre la aplicación, pero
también es recomendable que esté disponible para futuras consultas.
La visita guiada (tour) puede combinar texto, capturas de pantalla, imágenes,

gráficos... La forma más habitual de presentarla es a través de un pase de dia-
positivas, que debe ser lo más breve posible.
Dos ejemplos de visita guiada, de las aplicaciones MindNode y Tally para iPhone (iOS)
2.6.5. Transparencias
Este sistema consiste en colocar una capa semitransparente con ilustraciones

explicativas encima de la interfaz de la aplicación, de forma que señalen y
expliquen su funcionamiento. Es una manera rápida y visual de ofrecer ayuda
(en este sistema suelen primar las ilustraciones por encima del texto). Como
en el caso de los consejos, esta capa de ayuda tiene que desaparecer pasados
unos segundos o en cuanto el usuario toca la pantalla.
Ejemplo de ayuda mediante transparencia en la aplicación PowerDirector
En la imagen, captura de la aplicación para Android.

2.6.6. Vídeo ayuda
Este sistema aprovecha las capacidades multimedia de los dispositivos móviles.

Bien realizado, es quizá la mejor manera de explicar el funcionamiento de
una aplicación, puesto que permite mostrarla en acción, tal y como después
la usará el usuario.
Ayuda en formato vídeo en la aplicación Today para dispositivos iPhone (iOS)
Es conveniente que los vídeos sean breves (si no es posible, se puede optar
por hacer un menú de instrucciones donde cada función esté explicada con
un breve clip de vídeo) y expliquen las funciones desde el punto de vista del
usuario. Obviamente, hay ofrecer los controles de reproducción básicos para
el vídeo (reproducción, pausa, volumen, etc.).
3. Consejos y buenas prácticas para un buen diseño
Conseguir un buen diseño o crear una gran experiencia para el usuario no son
fruto de la casualidad. Tendremos que trabajar duro e iterar una y otra vez
nuestros diseños hasta conseguir lo que buscamos. A continuación damos una
serie de consejos y buenas prácticas para obtener un buen diseño.
1)�Sigue�las�pautas�de�diseño. Los principales sistemas operativos tienen a

disposición de diseñadores y desarrolladores de aplicaciones gran cantidad de
documentación en línea sobre cómo crear las mejores experiencias de usuario
en sus respectivos entornos. En estos materiales, hacemos continua referencia
a estas pautas y, en caso de duda, conviene acudir una y otra vez a estas fuentes,
que se mantienen siempre actualizadas. Estas pautas se pueden encontrar en:
a)�Android
b)�iOS
c)�Windows 10
2)�Una�pantalla�para�cada�cosa. Una pantalla llena de botones y mensajes

despistará al usuario y hará que se desconcentre sobre lo que quiere hacer. Te-
nemos que analizar bien qué pondremos en cada pantalla y, al mismo tiempo,
preguntarnos si es lo que el usuario necesitará.
3)�Piensa�de�arriba�abajo. La parte superior de la pantalla es la más visible y,

por lo tanto, la más importante del dispositivo. Pero no debemos olvidar que
los usuarios tienen que sujetar el dispositivo de una manera que les permita
tanto ver el contenido de la pantalla como interaccionar con ella. Por tanto, al
diseñar una interfaz tendremos también en cuenta la ergonomía, las dimen-
siones del dispositivo y las características intrínsecas de las pantallas táctiles.
Sobre todo en los teléfonos móviles, donde el usuario suele sujetar el disposi-
tivo:
• con una sola mano y usando el pulgar de la misma mano para tocar la
pantalla;
• con una sola mano y usando el índice de la otra mano para tocar la pan-
talla;
• con las dos manos y usando los pulgares de ambas para tocar la pantalla.
De acuerdo con Steven Hoober, la mitad de los usuarios sujeta el móvil con Lectura complementaria
una mano y lo manipula con el pulgar, hecho que le llevó a definir la Thumb
Hoober,�S. (2012, 18 de fe-
Zone (‘la zona pulgar’), o lo que es lo mismo, ese espacio sobre la pantalla sobre brero). «How do users really
el cual el pulgar opera con comodidad. hold mobile devices?». Ux-
matters.
Dos maneras de sujetar el móvil con una mano
Fuente: Uxmatters.com
Tener presentes estas zonas de fácil alcance nos dará pistas sobre cómo orga-
nizar los contenidos en pantalla: las acciones habituales en las zonas más ac-
cesibles; las críticas, en las menos accesibles. Y también nos refuerza la idea de
que lo más importante tiene que estar en la parte superior de la pantalla, la
menos susceptible de quedar cubierta por la mano o dedo del usuario.
Ejemplo de facilitar el alcance a una zona superior
Para facilitar el alcance de la zona superior de la pantalla con una sola mano, los modelos iPhone 6 y 6 Plus de Apple permiten
desplazar la pantalla hacia abajo dando dos ligeros toques sobre el botón de inicio. Fuente: apple.com.
Las formas de sujetar una tableta son mucho más variadas (con dos manos,
sobre las piernas, en un soporte...), pero tenemos que tener claro que, sea un
teléfono o una tableta, el usuario siempre escaneará la pantalla de arriba abajo,
de modo que habrá que poner siempre lo más importante en la parte superior.
4)�Establece�relaciones�y�jerarquías�entre�pantallas. Cuando empezamos a

diseñar, hay que trabajar también el árbol de navegación de la aplicación, es
decir, plantear los posibles caminos de pantallas que podrá recorrer el usua-
rio. Como hemos estudiado en el módulo «Arquitectura y wireframes», es im-
portante tener muy definido este árbol antes de empezar con la fase de pro-
gramación, puesto que nos ayuda a establecer jerarquías entre las diferentes
pantallas y funciones de la aplicación y evita que el usuario pueda acabar en
algún atolladero.
5)�Haz�que�el�uso�sea�lo�más�obvio�posible. Tenemos que conseguir que el

usuario no tenga que pensar mucho para entender qué hace ni cómo tiene
que interactuar con nuestra aplicación. Esto lo podemos conseguir de varias
maneras:
• Situando en primer plano la función principal de la aplicación.

• Minimizando el número de botones y controles disponibles.
• Etiquetando bien los botones, de forma breve, clara y concisa.
• Informando en todo momento al usuario dónde se encuentra.
Ejemplo de uso fácil
En Shazam, el usuario solo tiene que pulsar el gran botón situado en la parte central de la pantalla para identificar la canción
que está sonando cerca de su dispositivo. En la imagen, captura de pantalla de la aplicación para iPhone (iOS).
6)�Minimiza�el�esfuerzo�para�introducir�datos. Las mejores aplicaciones son

las que facilitan el trabajo a los usuarios, de forma que si conseguimos que
introduzcan datos tocando un solo botón lo estaremos haciendo mejor que si
tienen que tocar dos. Selectores, listas o accesos rápidos son maneras sencillas
de facilitar la entrada de datos. Otras maneras son los códigos QR, sistemas de
geolocalización o los sistemas de reconocimiento de voz.
Ejemplo de minimizar el esfuerzo para introducir datos
Captura de un código de barras con la cámara de un iPhone (izquierda). En lugar de rellenar un formulario, los usuarios de
la aplicación Idealista (versión para iPhone) pueden dibujar directamente sobre el mapa en qué zona quieren que se haga la
búsqueda de inmuebles (derecha).
7)�Diseña�pensando�en�dedos�grandes. Aunque durante la presentación del

primer modelo de iPhone Steve Jobs aseguró que el dedo era el mejor puntero
que existe, debemos reconocer que el dedo humano es bastante impreciso, so-
bre todo comparado con un ratón de ordenador. Más aún cuando manipula-
mos la pantalla en las más variadas situaciones (sentados en un taxi, andando
por la calle, en el gimnasio, etc.). Esto, unido a la falta de relieve de los ele-
mentos con los que interactúa, hace que al usuario le resulte a menudo difícil
activar botones y controles. La receta para el desastre en este punto es diseñar
una aplicación llena de botones pequeños y muy juntos.
Ejemplos de áreas sensibles grandes
Aunque los elementos en pantalla sean más pequeños, el área sensible al toque debe respetar unos mínimos, como en estos
ejemplos de Android. Fuente: developer.android.com
Tenemos que diseñar pensando en dedos grandes, lo que implica tener en

cuenta no solo el tamaño, sino también la separación entre los diferentes ele-
mentos seleccionables. Las guías de diseño de los diferentes sistemas operati-
vos suelen incluir recomendaciones en este sentido. Por ejemplo, en Android
se recomienda un mínimo de 48 × 48 dp para las áreas interactivas y en iOS
el tamaño mínimo es de 44 × 44 pt.
El tamaño y la separación de los elementos interactivos cobran especial

importancia cuando nuestra aplicación puede ser utilizada por personas
con dificultades motrices o sensoriales, personas de avanzada edad o
niños pequeños.
8)�Sé�breve�y�clarificador. Cuando se trata de comunicarnos con el usuario,

tenemos que intentar ser lo más breves y concisos que podamos. Los usuarios
quieren hacer cosas, no pasar el rato leyendo mensajes o instrucciones. Algu-
nos consejos básicos:
• Sé�breve: si puedes decirlo en treinta caracteres, no lo hagas con cincuenta.

• Hazlo�fácil: el usuario no entiende el lenguaje de los informáticos. Usa
palabras cortas y verbos clarificadores.
• Sé�amable: procura no usar expresiones como Error o Cuidado; usa expre-
siones que describan de forma sencilla qué ha pasado.
• Lo�más�importante,�al�principio: las dos o tres primeras palabras del men-
saje tienen que incluir ya el motivo de este.
9)�El�contenido,�siempre�en�primer�plano. Si trabajamos con contenidos,

tenemos que hacer que estos sean los auténticos protagonistas de nuestra apli-
cación. Todo el resto (interfaz, botones, animaciones...) tiene que estar a su
servicio. Podemos conseguirlo de varias maneras:
• Minimizando el número de controles o disimulándolos para que no estor-

ben la visión del contenido.
• Haciendo aparecer los controles solo cuando el usuario toca la pantalla.
• Haciendo que el contenido sea la propia interfaz.
Ejemplo de contenido en primer plano
Flipboard es un buen ejemplo de aplicación que pone el contenido en primer plano, haciendo que el usuario pueda ver un
adelanto de lo que hay detrás de cada sección de la revista. En la imagen, captura de pantalla de la versión para iPhone (iOS).
10)�Pon�atención�a�los�pequeños�detalles. Como hemos visto anteriormente,

el usuario cada vez valora más aquello que siente y experimenta cuando usa
una aplicación. Un diseño atractivo, rapidez en la respuesta, unas animaciones
fluidas y muy logradas, formas diferentes y creativas de navegar por los con-
tenidos... Conseguir una buena experiencia de usuario es cuestión de resolver
bien los objetivos básicos de usabilidad, pero también de dedicar atención a
los pequeños detalles de nuestra aplicación, desde el icono hasta el sombreado
de los botones.
Ejemplo de atención a los pequeños detalles
En lugar de dejar la pantalla en blanco o con un simple «no hay llamadas», en Hangouts se llena este vacío con una simpática
ilustración. En la imagen, captura de pantalla de la versión para iPhone (iOS).
Asimismo, como sucede también en la vida real, la�primera�impresión�es�la

que�cuenta: si sabemos captar la atención del usuario en los primeros minu-
tos y causarle una buena impresión, tendremos mucho terreno ganado para
conseguir su fidelidad.
11)�Prepárate�para�las�interrupciones. Sabemos que los usuarios van a estar

sometidos a constantes interrupciones durante el uso de nuestra aplicación.
Por este motivo, deberemos diseñarlas de tal manera que se pueda interrumpir
la interacción y retomarla posteriormente de forma sencilla, y si es posible en
el mismo punto en que se dejó.
Esto suele conseguirse o bien pausando la interacción (por ejemplo, en los

juegos) o bien guardando el estado automáticamente (por ejemplo, en la crea-
ción de documentos).
12)�Las�normas�están�para�saltártelas. El diseño de aplicaciones para dispo-

sitivos inteligentes es un territorio en el que la innovación es obligada. No
olvides que cada día aparecen nuevas formas de presentar y navegar por con-
tenidos, acceder a la información o compartir conocimiento.
Los patrones de diseño que hemos visto ofrecen soluciones estándar a los pro- Lecturas
blemas más habituales cuando diseñamos una interfaz, pero no son ni mucho complementarias
menos la única solución posible. A veces hay que saltarse las normas estable- Creative�Bloq (2012, 15 de
cidas para poder avanzar. abril). «The 10 principles of
mobile interface design».
Creative Bloq.
N.Babich (2016, 12 de ju-
lio). «Mobile UX Design: Key
Principles». UX Planet.
4. Prototipado en alta definición
En el módulo «Arquitectura y wireframes» estudiamos la utilidad de los wirefra-

mes o prototipos en baja definición para empezar a estructurar nuestras ideas
y darles una primera forma a base de cajas, listas, menús, etc. A medida que
avanzamos con nuestro diseño, también avanzará el nivel de detalle de nues-
tros prototipos, hasta el punto de que querremos dotarlos de interacción.
Los prototipos en alta fidelidad (mockups) suelen ser más o menos interactivos,
lo que nos permite hacernos una idea bastante acertada de cómo funcionará la
aplicación. También suelen incluir la capa de diseño definitiva, de manera que
a simple vista puede costar diferenciar un mockup de la aplicación real misma.
Durante el desarrollo, los prototipos en alta fidelidad nos servirán para testear
nuestras ideas más allá del papel. Llegado el momento, también nos servirán
para hacer pruebas con usuarios reales, detectando�problemas de concepto,
diseño o usabilidad antes�de�entrar�en�la�fase�de�desarrollo.
Un prototipo en alta definición requiere tiempo. Cuanto más realista

sea, más tiempo le habremos dedicado, de forma que hay que encontrar
el equilibrio entre realismo y funcionalidad.
Para hacer un prototipo en alta fidelidad, no es necesario tener conocimientos Lectura complementaria
de programación. Cada vez hay más programas y aplicaciones que permiten
K.�Pernice (2016, 18 de di-
hacerlos de forma intuitiva, como quien va encajando piezas en un rompeca- ciembre). «UX Prototypes:
bezas. Los más sofisticados permiten incorporar animaciones y otros efectos Low Fidelity vs. High Fide-
lity». Nielsen Norma Group.
que proporcionan más realismo al prototipo. Los hay que funcionan sobre un
navegador web y también otros que se pueden instalar o probar directamente
sobre el dispositivo.
Algunos ejemplos de programas para hacer prototipos:
1)�Axure�RP: uno de los más potentes y versátiles, usado por muchos profesio-
nales. Permite crear prototipos con gran nivel de detalle e interacción, hasta
el punto de parecer réplicas del original. Contiene bibliotecas específicas para
hacer prototipos de aplicaciones, desde donde se van arrastrando y colocando
los elementos. Si bien la curva de aprendizaje es bastante dura al principio, la
web de Axure RP contiene multitud de tutoriales que enseñan a sacar partido
rápidamente de las funciones del programa.
Captura de pantalla de Axure RP
Fuente: Axure.com
En el caso de iOS, los prototipos hechos con Axure RP se pueden visualizar di-
rectamente sobre un iPhone o iPad, como si fueran una aplicación de verdad.
El programa permite una versión de prueba plenamente funcional durante
treinta días, tras la cual se exige un pago único para la compra de la licencia
o una suscripción mensual. Axure también ofrece licencias gratuitas para es-
tudiantes de diseño.
2)� Justinmind: esta empresa catalana trasladada a Silicon Valley ofrece un

programa que permite hacer y compartir prototipos de webs y aplicaciones
móviles. Ofrece bibliotecas de elementos específicas para dispositivos iPhone,
iPad, Android, Windows Phone, Blackberry...
Detalle de la barra de herramientas en Justinmind
Fuente: Justinmind.com
Justinmind está disponible en dos versiones, Free y Pro. La versión gratuita

permite crear prototipos ilimitados en alta fidelidad, si bien la interacción se
limita a enlazar pantallas del prototipo entre sí. La versión Pro es plenamente
funcional y permite crear interacciones más complejas.
También se puede descargar una versión de prueba (treinta días) de la versión

Pro del programa, que después pasa a convertirse en la versión gratuita.
3)�Invision: esta herramienta permite cargar nuestros diseños en alta fidelidad

y añadirles animaciones, gestos y transiciones, permitiéndonos así navegar
adelante y atrás por lo que antes eran imágenes estáticas. Incluye un práctico
sistema para invitar a otros usuarios a que prueben nuestro prototipo y pue-
dan ofrecer feedback. La versión gratuita es plenamente funcional, pero está
limitada a un solo proyecto.
Invision
Fuente: invisionapp.com
5. Introducción a la evaluación de la usabilidad
La iteración es un elemento clave del diseño�centrado�en�el�usuario y

se recomienda llevar a cabo pruebas y tests de usabilidad desde el primer
momento, para ayudarnos a corregir nuestros diseños en las primeras
etapas, con el consiguiente ahorro en tiempo y dinero.
Los métodos más habituales para evaluar la usabilidad de un producto o apli-

cación son el análisis heurístico y el test de usuarios.
Con preferencia, empezaremos siempre por el análisis heurístico, ya que nos

permitirá detectar fácilmente los errores más graves, para, una vez corregidos,
pasar después al test con usuarios, más costoso en términos de tiempo y pre-
supuesto.
5.1. Análisis heurístico
Este método implica someter el diseño a revisión de acuerdo a un conjunto

de reglas y principios de usabilidad establecidos previamente. Especialmente
célebres son las diez reglas heurísticas de Jakob Nielsen para el diseño de inter-
faces, pensadas en su origen para el diseño web, pero que fácilmente pueden
ser adaptadas al diseño de cualquier interfaz:
• Visibilidad�del�estado�del�sistema: el sistema debe informar en todo mo- Lectura complementaria

mento al usuario de lo que está ocurriendo, dando respuestas en un tiem-
J.�Nielsen (1995, 1 de enero).
po razonable. «10 Usability Heuristics for
User Interface Design». Niel-
sen Norman Group.
• Relación�entre�el�sistema�y�el�mundo�real: el sistema debe hablar el len-
guaje de los usuarios y seguir las convenciones del mundo real, y no hablar
el lenguaje de las máquinas.
• Control�y�libertad�del�usuario: hay ocasiones en que los usuarios elegirán

las funciones del sistema por error y necesitarán una «salida de emergen-
cia» claramente marcada. El sistema debe permitir las opciones de desha-
cer y rehacer.
• Consistencia�y�estándares: los usuarios no deberían cuestionarse si accio-

nes, situaciones o palabras diferentes significan en realidad la misma co-
sa. La interfaz ha de seguir las convenciones de la plataforma o sistema
operativo.
• Prevención�de�errores: un buen diseño que evita los errores será siempre

preferible a un buen mensaje de error.
• Reconocimiento�antes�que�recuerdo: las instrucciones para el uso del sis-

tema deben estar a la vista o ser fácilmente accesibles cuando sea necesario.
• Flexibilidad� y� eficiencia� de� uso: el sistema debe brindar caminos con

instrucciones claras para los usuarios novatos, sin dificultar el camino a
los usuarios avanzados. Permite atajos al usuario experto.
• Estética�y�diseño�minimalista: los diálogos no deben contener informa-

ción irrelevante. En un móvil, por ejemplo, cada pedazo de información
extra compite con lo importante y resta espacio en pantalla.
• Ayudar�a�los�usuarios�a�reconocer,�diagnosticar�y�recuperarse�de�erro-
res: los mensajes de error se deben entregar en un lenguaje claro y simple,
indicando de forma precisa el problema y mostrar una solución.
• Ayuda�y�documentación: la ayuda debe ser fácil de encontrar, estar diri-

gida a las tareas de los usuarios y ser entendible y breve. Mucho mejor si
está contextualizada: que se relacione con el paso en el que se encuentra
el usuario.
Resulta conveniente clasificar los errores detectados en cada una de las cate-
gorías de acuerdo con su gravedad. Por ejemplo, se puede hacer una escala del
1 al 4, donde:
• Nivel 1: no supone un problema para el usuario, más allá de provocarle

una incomodidad o reducir su satisfacción.
• Nivel 2: el problema es moderado y no tiene demasiada importancia.
• Nivel 3: el problema es grave y debe ser resuelto.
• Nivel 4: el problema es catastrófico y debe ser atendido de inmediato.
5.2. Test con usuarios
En general, los tests con usuarios nos van a permitir obtener información de
carácter cualitativo sobre nuestra interfaz: ¿está bien diseñada?, ¿se entiende
bien a la primera?, ¿es fácil conseguir los objetivos?
Los tests con usuarios se basan sobre todo en la observación (haremos pocas
preguntas), ya que se trata de saber qué haría el usuario estando a solas. No es
un estudio de campo, dado que la observación se lleva a cabo normalmente
en un laboratorio. El número ideal de usuarios está entre seis y ocho; con esta
asistencia encontraremos el 80 % de los problemas de usabilidad. La duración
recomendada es de una hora.
Para evaluar con usuarios reales, debemos definir bien qué propósito,
metas y objetivos nos marcamos con el test. Importante: estamos eva-
luando el producto, no al usuario.
El test con usuarios se puede hacer en cualquier fase del desarrollo, incluso
durante las fase de prototipado y sketching (de hecho, es recomendable hacer-
lo durante estas fases). Durante el test impondremos al usuario una serie de
tareas que deberá realizar, en las que habremos identificado los puntos donde
suponemos que puede�tener�problemas o bien aquellos que resultan críticos
para�nuestro�negocio (por ejemplo: compra un billete de avión para dos per-
sonas).
Mientras lleva a cabo el test, animaremos al usuario a que exprese en voz alta
lo que va pensando. También registraremos su lenguaje no verbal (expresiones
de la cara) para evaluar sus reacciones. Por este motivo resulta conveniente
grabar las sesiones en vídeo.
Sujetos en un test de usabilidad:
• Participante: el que hace el test.
• Facilitador: está con el participante y le asiste en las tareas, le pregunta,

etc. Su función es que el usuario se sienta cómodo y animarlo a transmitir
lo que está experimentando. Debe permanecer neutral y no responder a
las preguntas del participante, sino animarlo a completar las tareas como
si estuviera solo. No debe ayudar nunca al usuario.
• Observadores: están en otra sala y analizan todo lo que ocurre. Deben to-
mar notas durante la sesión, apuntando exactamente las palabras de los
usuarios. Es recomendable que estos sujetos realicen una observación par-
ticipativa y que durante la propia sesión apunten soluciones a los proble-
mas que se van detectando. La sesión será así mucho más productiva.
Bibliografía
All About UX. <http://www.allaboutux.org/>.
Apple. iOS human interface guidelines [en línea]. <https://developer.apple.com/ios/hu-

man-interface-guidelines/>.
Babich, N. (2016, 12 de julio). «Mobile UX Design: Key Principles» [en línea]. UX Planet.
[Fecha de consulta: 20 de diciembre de 2016]. <https://uxplanet.org/mobile-ux-design-key-
principles-dee1a632f9e6#.aty7anowr>.
Creative Bloq (2012, 15 de abril). «The 10 principles of mobile interface design» [en línea].
Creative Bloq. [Fecha de consulta: 20 de diciembre de 2016]. <http://www.creativebloq.com/
mobile/10-principles-mobile-interface-design-4122910>.
Google. Material Design [en línea]. <https://material.google.com/>.
Google. Principios de diseño para Android [en línea]. <https://developer.android.com/de-

sign/get-started/principles.html?hl=es>.
Hassan, Y.; Martín, F. J. (2005, 7 de septiembre). «La experiencia del usua-

rio» [en línea]. No Solo Usabilidad: Revista Sobre Personas, Diseño y Tecnología. <http://
www.nosolousabilidad.com/articulos/experiencia_del_usuario.htm>.
Hoober, S. (2012, 18 de febrero). «How do users really hold mobile devices?» [en línea].
Uxmatters. [Fecha de consulta: 01 de diciembre de 2016]. <http://www.uxmatters.com/mt/
archives/2013/02/how-do-users-really-hold-mobile-devices.php>.
Hoober, S. (2012, 3 de septiembre). «Mobile inline form validation» [en línea]. Uxmat-
ters. [Fecha de consulta: 01 de diciembre de 2016]. <http://www.uxmatters.com/mt/archi-
ves/2012/09/mobile-inline-form-validation.php>.
Hoober, S.; Berkman, E. (2012). Designing mobile interfaces. Sebastopol: O’Reilly.
Microsoft. Windows Apps. Design and UI [en línea]. <https://developer.microsoft.com/en-

us/windows/apps/design>.
Neil, T. (2012). Mobile design pattern gallery. Sebastopol: O’Reilly.
Nielsen, J. (1995, 1 de enero). «10 Usability Heuristics for User Interface Design». [en línea].
Nielsen Norman Group. <https://www.nngroup.com/articles/ten-usability-heuristics/>.
Nielsen, J. (2011, 29 de agosto). «Transmedia Design for the 3 Screens (Make That 5)» [en lí-
nea]. Nielsen Norman Group. <https://www.nngroup.com/articles/transmedia-design-for-3-
screens/>.
Nielsen, J. (2012, 4 de enero). «Usability 101: Introduction to Usability» [en línea]. Nielsen
Norman Group. [Fecha de consulta: 01 de diciembre de 2016]. <https://www.nngroup.com/
articles/usability-101-introduction-to-usability/>.
Nudelman, G. (2010, 8 de marzo). «Designing mobile search: Turning Limitations into op-
portunities» [en línea]. Uxmatters. <http://www.uxmatters.com/mt/archives/2010/03/desig-
ning-mobile-search-turning-limitations-into-opportunities.php>.
Morville, P.; CallenderJ. (2010). Search patterns: Design for discovery. Sebastopol: O’Reilly.
Pernice, K. (2016, 18 de diciembre). «UX Prototypes: Low Fidelity vs. High Fidelity» [en
línea]. Nielsen Norma Group. [Fecha de consulta: 20 de diciembre de 2016]. <https://
www.nngroup.com/articles/ux-prototype-hi-lo-fidelity>.
Wrobleski, L. (2013, 17 de septiembre). «Mobile Design Details: Avoid The Spinner» [en
línea]. LukeW Ideation + Design. <http://www.lukew.com/ff/entry.asp?1797>.

Diseño y Prototipado

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Diseño y Prototipado

Enviado por

Direitos autorais:

Formatos disponíveis

Diseño y

Jordi Flamarich Zampalo

Tiempo mínimo de dedicación recomendado: 7 horas

1. Usabilidad y diseño de la experiencia de usuario..................... 7

2.6.2. Consejo .......................................................................... 59

3. Consejos y buenas prácticas para un buen diseño.................... 64

4. Prototipado en alta definición...................................................... 73

5. Introducción a la evaluación de la usabilidad.......................... 77

1. Profundizar en los conceptos de usabilidad y experiencia de usuario.

2. Revisar los patrones de diseño más habituales en aplicaciones móviles.

3. Entender cuándo estamos ante un buen diseño y cuándo no.

4. Conocer herramientas para el prototipado en alta definición de nuestras

5. Introducirnos en la evaluación de la usabilidad como una etapa más del

1. Usabilidad y diseño de la experiencia de usuario

Como hemos visto en los módulos anteriores, en el diseño centrado en el

La usabilidad trata de cómo interactuamos con el producto; la experien-

Los objetivos básicos de la usabilidad, de acuerdo con Jakob Nielsen, son:

3)�Seguridad: una interfaz se considera segura cuando minimiza las posibili-

4)�Utilidad: hace referencia a las funciones disponibles en la aplicación, que

5)�Facilidad�de�aprendizaje: por norma general, los usuarios de dispositivos

zar a usarlas. Esto se puede conseguir minimizando el número de funciones

6)�Memorabilidad: hace referencia a la capacidad de recordar cómo funciona

En cuanto a la experiencia�de�usuario (también denominada UX, user expe-

La experiencia de usuario alcanza tanto el momento concreto de uso

Aplicada a los dispositivos inteligentes, una buena experiencia de usuario pide

1.1. Diseñar para varias plataformas

Diseñar una experiencia de usuario implica comprender y diseñar la experien-

ción o producto en diversos dispositivos y plataformas. A continuación cita-

• Continuidad�visual: las interfaces de usuario pueden variar para adaptarse Lecturas

• Continuidad�en�los�datos: la información proporcionada por el usuario

A la hora de diseñar interfaces, los patrones nos resultan de gran utilidad,

• Nos ayudan a ahorrar trabajo porque proponen soluciones a problemas ya

A continuación comentamos los principales elementos de navegación que po-

2.1.1. Pantalla de inicio

Si en los ordenadores nos hemos acostumbrado a hablar de escritorio para

La pantalla de inicio puede constar de varias páginas, donde el usuario ordena

En el sistema operativo móvil de Apple, iOS, esta pantalla recibe el nombre de

Pantallas de inicio en iOS (izquierda) y Android (derecha)

El sistema más básico, convertido ya en un estándar en los dispositivos móvi-

Número de páginas de La Vanguardia

Este sistema no permite al usuario navegar por las páginas, simplemente le

La barra de navegación la encontramos en la parte superior de la pantalla y

«App Bar» en Android

Mediante este sistema, el usuario puede ver rápidamente su posición respecto

Barra de desplazamiento vertical en la aplicación PDF Expert para iPad (iOS)

Al igual que en cualquier programa informático o sistema operativo de orde-

Para no sacrificar espacio en pantalla, el menú aparece cuando el usuario activa

Menú desplegable en la aplicación del portal Idealista

Captura de la versión para iPhone (iOS)

También se tiene que prever la manera de volver a «esconder» el menú una

Menú fijo de la aplicación de Facebook

En tabletas, donde el espacio disponible en pantalla es superior, se puede re-

2.1.4. Elementos de control

Dado el reducido espacio de que disponemos en el entorno móvil, el usuario

• Ser visibles: si queremos que el usuario interactúe de forma natural con la

A continuación presentamos los elementos de control más habituales: despla-

Aunque normalmente la función de desplazamiento (scroll) es contemplada

1) Siempre que sea posible, mostraremos la barra de desplazamiento para

2) El tamaño de la barra tiene que ser inversamente proporcional a la canti-

3) Para no estorbar y ocupar espacio innecesario en la pantalla, la barra puede

4) Por norma general, la barra de desplazamiento no tiene que servir para

5) Es aconsejable limitar el desplazamiento a un solo eje, preferentemente el

6) En determinados casos, como, por ejemplo, cuando se amplía una imagen,

8) La inercia en el desplazamiento se ha convertido en un comportamiento