Arquitectura y

wireframes
PID_00245396

Jordi Flamarich Zampalo

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

© FUOC • PID_00245396 Arquitectura y wireframes

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.
© FUOC • PID_00245396 Arquitectura y wireframes

Índice

Introducción............................................................................................... 5

Objetivos....................................................................................................... 6

1. Arquitectura de la información.................................................... 7
1.1. Clasificación de la información .................................................. 8
1.1.1. Inventario de contenidos .............................................. 8
1.1.2. Ordenación de tarjetas .................................................. 8
1.2. Estructuras de navegación .......................................................... 9
1.2.1. Estructura jerárquica ...................................................... 11
1.2.2. Estructura lineal ............................................................. 12
1.2.3. Estructura de hub............................................................ 13
1.2.4. Estructura en pestañas ................................................... 14
1.2.5. Estructura de red ........................................................... 15
1.3. Representación de la información .............................................. 15
1.3.1. Diseño del contenido .................................................... 16

2. Diseño para la interacción.............................................................. 18

2.1. Galería de gestos ......................................................................... 18
2.1.1. Toque .............................................................................. 18
2.1.2. Toque largo .................................................................... 19
2.1.3. Deslizar ........................................................................... 20
2.1.4. Arrastrar ......................................................................... 21
2.1.5. Separar y pellizcar con dos dedos .................................. 22
2.1.6. Rotar ............................................................................... 23
2.1.7. Girar y rotar el dispositivo ............................................ 23
2.1.8. Mover ............................................................................. 26
2.1.9. Apretar ............................................................................ 27
2.2. Elementos gráficos ...................................................................... 28
2.2.1. Tipografía ....................................................................... 29
2.2.2. Iconos ............................................................................. 30
2.2.3. Widgets............................................................................. 31
2.2.4. Notificaciones ................................................................ 33

3. Principios para el diseño de interfaces móviles........................ 35

3.1. Simplicidad .................................................................................. 35
3.2. Eficiencia ..................................................................................... 36
3.3. Consistencia ................................................................................ 36
3.4. Interacción ................................................................................... 37
3.5. Metáforas ..................................................................................... 38
3.6. Respuesta ..................................................................................... 38
© FUOC • PID_00245396 Arquitectura y wireframes

4. Sketching y wireframes...................................................................... 41
4.1. Prototipado en baja fidelidad ..................................................... 42

Bibliografía................................................................................................. 49
© FUOC • PID_00245396 5 Arquitectura y wireframes

Introducción

Una vez sentadas las bases del diseño centrado en el usuario y su aplicación
en el diseño de interfaces para dispositivos móviles, y como continuación en
el proceso de desarrollo de una aplicación o producto interactivo, en este se-
gundo módulo vamos a trabajar la forma en que los usuarios van a poder a
acceder a la información, contenidos o servicios que les queremos ofrecer. En
concreto, estudiaremos estrategias para diseñar la arquitectura de la informa-
ción de nuestro producto y empezaremos a «darle forma» mediante técnicas
de prototipado rápido. Y como en el módulo anterior, lo haremos teniendo
siempre en cuenta las necesidades y objetivos de nuestros usuarios.
© FUOC • PID_00245396 6 Arquitectura y wireframes

Objetivos

Los objetivos que el estudiante deberá alcanzar con el estudio de este módulo
son:

1. Conocer qué es la arquitectura de la información y su relación con la ex-

periencia de usuario.

2. Conocer técnicas para clasificar y representar la información, así como

para estructurar la navegación en nuestra aplicación.

3. Entender qué es el diseño para la interacción.

4. Revisar los principios que inspiran el diseño de aplicaciones móviles.

5. Conocer técnicas de prototipado rápido de nuestras ideas y su utilidad

dentro del proceso de diseño.
© FUOC • PID_00245396 7 Arquitectura y wireframes

1. Arquitectura de la información

La arquitectura de la información (AI) es el arte y la ciencia de organizar

espacios de información con el fin de ayudar a los usuarios a satisfacer
sus necesidades de información.

Según Rosenfeld y Morville, pioneros de la disciplina, la arquitectura de la

información:

• Clarifica la misión�y�visión del producto. Lectura complementaria

• Determina qué contenidos�y�funcionalidades tendrá el sitio.
L.�Rosenfeld;�P.�Morville
• Indica el modo en que los usuarios encontrarán la información mediante (2000). Arquitectura de la in-
la definición de sistemas de organización,�navegación,�rotulado�y�bús- formación para el WWW. Mé-
xico: McGraw-Hill.
queda de la misma.
• Proyecta el modo en que el sitio se adaptará�al�cambio�y�el�crecimiento
con el paso del tiempo.

En definitiva, los arquitectos de la información ayudan al usuario a encontrar

y gestionar la información de forma efectiva. Encontramos arquitectura de la
información en páginas web, en el diseño de interfaces de aplicaciones para
móvil y software en general, todo tipo de gadgets, máquinas dispensadoras,
incluso en material impreso.

Aunque para la mayoría de usuarios «la interfaz es la aplicación», debemos

entender la arquitectura de la información como una disciplina íntimamente
relacionada�con�la�experiencia�de�usuario, ya que la usabilidad de la apli-
cación no va a depender solo del diseño de la interfaz, sino también de la es-
tructura y organización de la información que contiene, o en otras palabras,
del «componente no visible del diseño» (Hassan y Martín, 2004).

La arquitectura de la información se encarga, por tanto, de incidir en los si-

guientes aspectos:

• Cómo se va a clasificar�la�información. En una primera fase, el arquitecto

de la información va a tener que analizar toda la información disponible y
determinar en qué grado se puede desmenuzar en unidades más pequeñas,
pero plenamente dotadas de sentido.
• Cómo va a ser la estructura�de�navegación, la jerarquía entre contenidos
y la relación entre nodos de información.
• Cómo se van a etiquetar las diferentes opciones disponibles.
• Cómo va a ser el sistema�de�búsqueda.
© FUOC • PID_00245396 8 Arquitectura y wireframes

Una vez más, colocaremos al usuario en el centro de este proceso y diseñare-

mos la arquitectura de nuestra aplicación teniendo muy en cuenta en todo
momento quién�es�nuestra�audiencia y cuáles son sus objetivos, así como
también el contexto�de�uso de nuestra aplicación, ya que condicionarán la
forma en que organizaremos y mostraremos los contenidos.

Lecturas complementarias

R.� Ronda� León (2008, 28 de abril). «Arquitectura de la información: análisis históri-

co-conceptual» [en línea]. No solo usabilidad: Revista sobre Personas, Diseño y Tecnología.

Y.�Hassan;�F.�Martín;�G.�Iazza (2004). «Diseño web centrado en el usuario: usabilidad

y arquitectura de la información». Hipertext.net. Anuario Académico sobre Documentación
Digital y Comunicación Interactiva (n.º 2).

The�Information�Architecture�Institute. Sitio web oficial http://www.iainstitute.org/.

L.� Rosenfeld;� P.� Morville;� J.� Arango (2015). Information Architecture: For the Web and
Beyond. Sebastopol: O’Reilly Media.

1.1. Clasificación de la información

Existen algunas técnicas para trabajar en la arquitectura de la información

de nuestra aplicación adaptándonos al modelo mental de los usuarios. Las
examinamos a continuación.

1.1.1. Inventario de contenidos

Mediante esta técnica procedemos a identificar todas las «piezas del rompeca-
bezas» que vamos a construir. Normalmente, lo haremos listando todas y cada
una de las secciones (o pantallas) que necesitará nuestra aplicación. Resulta
recomendable ser lo más detallado posible, sin preocuparnos en este punto
por agrupar los contenidos de acuerdo a categorías –inexistentes aún, ya que
todavía no las hemos decidido– o a sus características.

Será inevitable, sin embargo, que en este punto ya empecemos a organizar y

jerarquizar el contenido de acuerdo a su relevancia, dando así los primeros
pasos en la confección del árbol�de�navegación de nuestro producto.

1.1.2. Ordenación de tarjetas

Con la ordenación de tarjetas (card sorting), conseguiremos agrupar la infor-

mación en nuestra aplicación basándonos en el modelo mental del usuario,
ya que van a ser los�propios�usuarios�quienes�participen�en�la�categoriza-
ción�y�clasificación del contenido. Para ello, les presentaremos una serie de
tarjetas (una por cada unidad de contenido, pantalla o categoría, según nues-
tras necesidades) y les pediremos que las ordenen, agrupen y jerarquicen de
acuerdo a su criterio e instinto.

Existen dos variantes para esta técnica:

© FUOC • PID_00245396 9 Arquitectura y wireframes

1)�Abierta: los usuarios pueden agrupar los contenidos y crear ellos mismos
las categorías, según su conveniencia.

2)�Cerrada: los usuarios ordenan el contenido de acuerdo con una lista cerrada
de categorías.

La técnica del card sorting resulta especialmente recomendable en aplicaciones

de complejidad media y elevada.

1.2. Estructuras de navegación

Los sistemas de navegación tienen que ayudar a los usuarios a responder a tres
preguntas fundamentales:

1)�¿Dónde�estoy? El usuario debe saber en todo momento dónde está, por lo

que es imprescindible que todas las pantallas de la aplicación estén correcta-
mente identificadas.

2)� ¿Dónde� he� estado? En el entorno web resulta habitual cambiar el tono
de color de los enlaces visitados o guiar al usuario mediante «migas de
pan» (breadcrumbs). En el móvil, sin embargo, estos recursos resultan más com-
plicados de implementar; en el móvil es más habitual responder a la pregunta
¿de�dónde�vengo? mediante el uso de elementos de navegación (botón atrás)
o transiciones para mostrar la relación entre pantallas.
© FUOC • PID_00245396 10 Arquitectura y wireframes

Navegación en un dispositivo Android

Fuente: developer.android.com

3)�¿Dónde�puedo�ir? Todos los elementos de navegación (botones, enlaces,

menús) deben ser claramente identificables y no ofrecer dudas sobre su des-
tino. En aplicaciones con varios niveles de profundidad en la navegación, re-
sulta recomendable mantener siempre un botón a la vista que permita volver
rápidamente a la pantalla principal (Home).

Para diseñar la estructura de navegación de nuestra aplicación, podemos recu-

rrir al clásico árbol�de�navegación�o�sitemap de una página web, establecien-
do el diagrama�de�flujo entre las diferentes pantallas, representadas mediante
rectángulos. En este punto, conviene señalar que no�existe�una�única�manera
correcta�de�estructurar�la�información, sino maneras más o menos idóneas.

Nuestro trabajo aquí, una vez más, es decidir cuál será la mejor estructura de
acuerdo con las necesidades y objetivos de nuestros usuarios. Y hacer que esta
sea consistente�y�predecible, de tal manera que los usuarios se sientan cómo-
dos y no pierdan tiempo intentando descubrir cómo se utiliza la aplicación.

A continuación veremos algunas de las estructuras más habituales en aplica-

ciones para dispositivos móviles.
© FUOC • PID_00245396 11 Arquitectura y wireframes

1.2.1. Estructura jerárquica

Se trata tal vez de la estructura más parecida a la de una página web, donde la
información se organiza en forma de árbol a partir de una pantalla o página
principal. Es una estructura recomendable en caso de grandes volúmenes de
información, ya que ayuda al usuario a encontrar rápidamente lo que busca y
orientarse fácilmente en la navegación.

Los diferentes niveles de profundidad del árbol de navegación deben seguir

siempre este principio: contenido generalista en los niveles superiores y más
específico en los inferiores. Para no complicar en exceso la navegación, una
práctica habitual consiste en no�superar�los�tres�niveles�de�profundidad a
partir de la página principal.

Estructura de navegación jerárquica

Fuente: gráfico adaptado de McVicar (2012)

© FUOC • PID_00245396 12 Arquitectura y wireframes

1.2.2. Estructura lineal

También denominada nested doll (en referencia a las muñecas rusas), la estruc-
tura lineal proporciona un acceso secuencial a la información, ordenado de
forma jerárquica, pasando de lo más general o lo más específico.

Estructura de navegación lineal

Fuente: gráfico adaptado de McVicar (2012)

Ejemplo de estructura de navegación lineal en un Apple Watch

Fuente: apple.com

La navegación de este tipo resulta sencilla y muy intuitiva en primera instan-

cia. Permite al usuario orientarse fácilmente y saber en todo momento dón-
de está gracias a que solo puede moverse adelante y atrás. Sin embargo, tam-
bién puede llegar a hacerse muy pesada, ya que obligamos al usuario a estar
avanzando o retrocediendo por pantallas constantemente. De nuevo, resulta
recomendable�no�superar�los�tres�niveles�de�profundidad desde la pantalla
principal.

Para mejorar la navegación en esta estructura podemos recurrir a:

• Botón�de�inicio: para permitir al usuario saltar a la página principal sin

necesidad de deshacer todo el camino hecho.
• Menú�de�navegación: para permitir al usuario saltar ágilmente entre ca-
tegorías.
© FUOC • PID_00245396 13 Arquitectura y wireframes

1.2.3. Estructura de hub

Muy habitual en juegos o aplicaciones multitarea, la estructura de hub resulta

idónea para crear un índice en la página inicial desde el cual los usuarios se
moverán a las diferentes secciones de la aplicación. No�debemos�confundir�la
estructura�de�hub�con�un�menú, ya que mientras en un menú las diferentes
opciones disponibles forman parte de un mismo producto, con un hub facili-
tamos el acceso a herramientas bien diferenciadas, sin relación entre sí. Por
este motivo tampoco�existe�una�jerarquía entre las diferentes opciones, más
allá de su posición en la rejilla.

Estructura de hub

Fuente: gráfico adaptado de McVicar (2012)

© FUOC • PID_00245396 14 Arquitectura y wireframes

Una vez que el usuario se encuentra dentro de una de las opciones, esta solu-
ción permite desarrollar otras estructuras de navegación (jerárquica o lineal,
por ejemplo). Para cambiar de una opción a otra, el usuario deberá pasar siem-
pre por el hub.

1.2.4. Estructura en pestañas

La estructura en pestañas (tabs) resulta conveniente para mostrar contenidos

que están a un�mismo�nivel�jerárquico.

Estructura de navegación en pestañas

Ejemplo�de�estructura�de�navegación�en
hub�de�la�aplicación�móvil�de�Swiss�Air�para
iPhone

Fuente: gráfico adaptado de McVicar (2012)

Algunas recomendaciones para el uso de esta estructura:

• Tenemos que mostrar claramente cuál es la pestaña que está activa, cuán-
tas pestañas hay disponibles y cuál es el contenido detrás de cada pestaña.

• Es aconsejable que cada pestaña tenga un título que permita identificar el

contenido que hay detrás de esta. Si no cabe, podemos truncar el texto,
aunque no sea del todo aconsejable (en estos casos podemos hacer, por
ejemplo, que el texto vaya circulando por la pestaña como si fuera una
marquesina cuando esta está seleccionada).

• Si tenemos más pestañas de las que la pantalla puede mostrar, tenemos que
indicar claramente que el usuario puede desplazarlas lateralmente, usando
por ejemplo flechas.

• Las pestañas funcionan bien en horizontal, ya que en vertical no suelen

ser bien interpretadas por los usuarios.
Ejemplo�de�navegación�por�pestañas�de�la
aplicación�para�móvil�Headspace�(Android)

• Debemos seguir las guías�de�diseño de cada sistema operativo en cuanto

al uso y ubicación de las pestañas. En este sentido, resulta habitual en
Android e iOS permitir la navegación entre pestañas deslizando el dedo
lateralmente sobre la pantalla (además de pulsando sobre el título de la
© FUOC • PID_00245396 15 Arquitectura y wireframes

pestaña), siempre que este gesto no interfiera con la interacción con el

contenido en la aplicación.

1.2.5. Estructura de red

Heredera de las páginas web y el hipertexto, la estructura de red solemos en-

contrarla en juegos o productos experimentales, en los que no�existe�ni�orden
ni�jerarquía entre los diferentes contenidos representados. El usuario puede
navegar libremente por las secciones, pero sin un índice que las ordene, lo que
puede llegar a provocarle cierta desorientación y problemas al querer recupe-
rar un contenido.

Estructura de red

Fuente: elaboración propia

1.3. Representación de la información

Transmitir de forma eficaz cualquier información es un reto que empieza en el

mismo instante en que empezamos a representarla. Knemeyer (2003) describe
las pautas a seguir cuando diseñamos información:
© FUOC • PID_00245396 16 Arquitectura y wireframes

• La información no tiene valor por sí misma, solo tiene valor si se comunica Lectura complementaria
con éxito. Si no se entiende o no se puede acceder a ella, no sirve para nada.
D.�Knemeyer (2003). «Infor-
mation Design: The unders-
• Hemos de mantenernos fieles a los objetivos marcados, los motivos por los tandig discipline». Boxes and
Arrows.
que queremos transmitir la información, y buscar la mejor manera para
conseguirlos.

• Debemos tener siempre presente a quién nos dirigimos, cómo se va a ex-

perimentar la información y cuál será su contexto de consumo.

Para conseguir que la información alcance al usuario de forma efectiva, trata-

remos de dotarla de estas propiedades:

• Relevante. No solo desde el punto de vista de lo que el usuario quiere, sino

también de lo que el usuario necesita.

• Clara. La información debe ser fácil de integrar y entendible. Debemos

eliminar todas las barreras que dificulten o impidan la comprensión.

• Memorable. En un mundo caracterizado por el exceso de información

disponible, solo aquella información que queda en nuestra memoria es-
tá causando un verdadero impacto. Una información bien diseñada, por
tanto, destacará sobre el «ruido» informativo imperante.

1.3.1. Diseño del contenido

De la misma manera que al representar una obra de teatro nos gustaría que el
público saliera hablando de la historia y no de lo bonitos que eran los vesti-
dos, el contenido va a ser la primera clave del éxito de nuestro producto, por
delante de la navegación, el diseño o sus funcionalidades. Y al igual que estos,
es imprescindible diseñar el contenido de nuestro producto con los mismos
criterios de eficiencia,�eficacia�y�satisfacción que definen la usabilidad de
nuestro proyecto.

Al hablar de diseño de contenidos podemos distinguir entre:

1) Aspectos puramente formales, como, por ejemplo, la maquetación, tipo-

grafía, uso de colores, estilos, interlineado, etc.

a)�Tamaño�y�espaciado: uno de los clásicos problemas con la lectura en un

dispositivo móvil es el tamaño de la letra, que a menudo obliga al usuario
a hacer zoom para poder leer cómodamente. Por ello, la letra en un móvil
ha de ser proporcionalmente mayor a la que usaríamos en la pantalla de un
ordenador, de la misma manera que el interlineado ha de ser sensiblemente
mayor.
© FUOC • PID_00245396 17 Arquitectura y wireframes

b)�Facilidad�de�lectura�y�contraste: para evitar esfuerzos innecesarios al usua-

rio, nos aseguraremos que el texto en nuestra aplicación puede leerse cómo-
damente en diferentes situaciones ambientales.

Versión para iPhone (iOS)

Para leer lo más cómodo posible, en la aplicación Pocket el usuario puede seleccionar entre diferentes opciones de visualización
del texto (brillo de pantalla, fondo, tamaño y tipo de letra).

2) Aspectos relacionados con el estilo�de�redacción: que el contenido sea cla-

ro y entendible, bien redactado y sin ambigüedades. Las tres características
siguientes sirven para guiar la plasmación de esa idea:

a)�Estructura�piramidal: lo más importante, el núcleo del mensaje, debe ir al

principio. En el móvil, el tercio superior de la pantalla es la zona más visible
para el usuario.

b)� Sé� breve,� preciso� y� escaneable: debemos tratar cada párrafo como una
unidad informativa (un párrafo = una idea), evitando el uso de expresiones
vacías. Para facilitar una lectura rápida resulta recomendable usar recursos co-
mo la negrita�para�las�palabras�clave o las listas para facilitar el escaneado
del texto. Conviene recordar que al usuario no le gusta leer en pantalla.

c)�Sé�entendible�y�cercano: el lenguaje ha de adaptarse a los objetivos del Lecturas

proyecto, pero debe ser siempre sencillo, fácilmente entendible y familiar para complementarias

el usuario. Los mensajes nunca deben culpar al usuario ni hacerlo sentir mal J.�J.�Garret (2002, 6 de mar-
consigo mismo. zo). «Un vocabulario visual
para describir arquitectura de
información y diseño de in-
teracción». jjg.net.
D.�Knemeyer (2003). «Infor-
mation Design: The unders-
tandig discipline». Boxes and
Arrows.
E.�McVicar (2012, 25 de sep-
tiembre). «Designing for mo-
bile, Part 1: Information Ar-
chitecture». UX Booth.
© FUOC • PID_00245396 18 Arquitectura y wireframes

2. Diseño para la interacción

Con el auge de los teléfonos móviles inteligentes y las tabletas hemos entrado
en una nueva era del diseño para la interacción. Como hemos estudiado en el
módulo anterior, durante los últimos cuarenta años hemos usado los mismos
paradigmas para la interacción entre personas y ordenadores, prácticamente
la misma metáfora del escritorio. Estos paradigmas están todavía plenamente
vigentes, pero están siendo progresivamente sustituidos por otros, basados en
nuevas formas, más�directas, de relacionarnos con la tecnología.

Como dice Dan Saffer, estamos ante una oportunidad que se presenta solo Lectura complementaria
una vez por generación: es ahora cuando apenas estamos empezando a dise-
D.�Saffer (2008). Designing
ñar nuevas formas de interactuar con nuestros dispositivos, nuestro entorno gestural interfaces. Sebastopol:
e incluso entre nosotros. O’Reilly.

2.1. Galería de gestos

A continuación presentamos el conjunto de gestos más habituales que se em-

plean para la interacción con las interfaces de dispositivos móviles.

2.1.1. Toque

El toque (tap) es el gesto más natural que se puede hacer sobre una pantalla, el
más primario y, por lo tanto, el más importante, puesto que con él se llevan a
cabo la mayor parte de acciones sobre un dispositivo táctil: abrir aplicaciones,
accionar botones, seleccionar elementos, etc. Para quien no ha interactuado
nunca con una pantalla táctil, el toque es el� gesto� más� fácil� de� aprender,
puesto que le recordará al clic que se hace con un ratón de ordenador.

Toque

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

© FUOC • PID_00245396 19 Arquitectura y wireframes

Variantes de este gesto son el doble toque (double tap) y el triple toque (triple
tap), aunque este último es muy poco habitual y hay que justificar muy bien su
uso, puesto que puede resultar difícil de ejecutar por parte de algunos usuarios.

Doble toque

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

2.1.2. Toque largo

En este gesto, el toque largo (tap and hold), el usuario tiene que tocar un ele-
mento en pantalla y no levantar el dedo durante un par de segundos, hecho
que desencadena acciones�alternativas o el despliegue de menús sobre este
elemento. En algunos casos, el toque largo se puede comparar al clic con el
botón secundario del ratón, aunque sus usos son variados en función del sis-
tema operativo o la aplicación en la que se use. Por ejemplo, sobre un teclado,
este gesto permite tener acceso a los caracteres acentuados, mientras que sobre
un icono de aplicación, nos permite arrastrarla y cambiarla de lugar.

Toque largo

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

© FUOC • PID_00245396 20 Arquitectura y wireframes

Captura de pantalla de un teclado de iPhone

Al hacer un toque largo sobre el teclado, aparecen caracteres alternativos o acentuados.

2.1.3. Deslizar

Después del toque, la acción de deslizar (swipe) el dedo sobre la pantalla es el

otro gesto más natural que podemos hacer sobre un dispositivo táctil y con
el que se pueden llevar a cabo las más variadas acciones. La más básica es
desplazar el contenido de la pantalla en vertical, como si lo hiciéramos con
la rueda giratoria de un ratón, para continuar leyendo una página web, por
ejemplo. En horizontal, este gesto es habitual para pasar las imágenes de una
galería o cambiar de página en la pantalla de inicio.

Deslizar

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

Las variantes de este gesto tienen que ver con:

• La�velocidad con que se haga. De hecho, es el propio usuario quien, una

vez acostumbrado al movimiento de deslizar el dedo sobre la pantalla, em- Ejemplo�de�deslizamiento�en�vertical
En la versión móvil de Flipboard (iOS), el
pezará a hacerlo cada vez más rápido y más corto para minimizar esfuerzos. usuario puede ir «pasando páginas» con
noticias deslizando el dedo verticalmente sobre
la pantalla.
Este movimiento rápido del dedo sobre la pantalla en una dirección recibe
el nombre de flick y se puede usar para pasar páginas de un libro, fotogra-
fías de una galería, desplazarnos rápidamente por una página web, etc.

• El�número�de�dedos que hacemos deslizar a la vez sobre la pantalla. Po-

demos diseñar acciones para dos, tres e incluso cuatro dedos deslizándose
© FUOC • PID_00245396 21 Arquitectura y wireframes

al mismo tiempo y en la misma dirección sobre la pantalla, aunque pa-

ra teléfonos –dado el tamaño de sus pantallas– resulta recomendable no
pasar de dos. Por otro lado, en tabletas no hay que abusar de gestos con
tres o cuatro dedos, puesto que resultan incómodos y estorban la visión
de buena parte de la pantalla.

2.1.4. Arrastrar

Con el gesto de arrastrar (drag) se puede tanto mover un elemento dentro de la

pantalla (por ejemplo, trasladar un icono a una nueva ubicación o reordenar
los elementos de una lista) como desplazar el foco de la propia pantalla cuando
tenemos una imagen ampliada al máximo.

Arrastrar
Versión�de�Google�Maps�para�iPhone
En Google Maps, podemos cambiar la
perspectiva del mapa (y ver así edificios en
relieve) deslizando dos dedos verticalmente
sobre la pantalla.

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

Hasta cierto punto, este gesto se puede confundir con el de hacer deslizar el
dedo (swipe) sobre la pantalla: cuando arrastramos, sin embargo, normalmen-
te estamos interactuando con un elemento concreto (un icono, una imagen
ampliada), mientras que el gesto de deslizar se hace normalmente para nave-
gar o desplazarnos.
© FUOC • PID_00245396 22 Arquitectura y wireframes

En función de dónde se inicia el gesto de arrastrar también se usa para mostrar

las notificaciones (arrastrando en vertical, de arriba abajo y empezando fuera
de la pantalla) o el menú dentro de una aplicación (arrastrando en horizontal,
empezando desde fuera de la pantalla).

2.1.5. Separar y pellizcar con dos dedos

El gesto de separar con dos dedos (spread) se ha acabado convirtiendo en si-

nónimo de ampliar (zoom in) aquello que tenemos en pantalla, y como tal es
un comportamiento esperado por los usuarios, sobre todo cuando visualizan
fotografías, consultan un servicio de mapas o usan el navegador web. Su con-
trario, es decir, hacer el gesto de pellizcar la pantalla (pinch), hace la acción a
la inversa, alejando (zoom out) aquello que tengamos en pantalla.

Pellizcar
Cierre�de�aplicación
Para cerrar una aplicación, el usuario de iOS
debe pulsar dos veces sobre el botón de inicio
y arrastrar la correspondiente miniatura hacia
fuera de la pantalla.

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

Separar

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

© FUOC • PID_00245396 23 Arquitectura y wireframes

Hay aplicaciones que están usando los gestos de separar y pellizcar con otras
finalidades, más allá de ampliar o reducir lo que tenemos en pantalla. Por
ejemplo, en Google Fotos podemos usar los gestos de pellizcar y separar con
los dedos sobre la pantalla para reducir o ampliar el tamaño de las fotos en el
timeline de la aplicación, abrir y cerrar fotos...

2.1.6. Rotar

Con este gesto hacemos rotar (rotate) sobre su eje el contenido mostrado en
pantalla. Es un gesto habitual cuando se visualizan mapas y que, combinado
con el de separar y pellizcar, permite controlar la interfaz con agilidad y pre-
cisión.

Rotar

Captura�de�la�versión�de�Google�Fotos�para
iOS
Google Fotos usa los gestos de pellizcar y
separar con los dedos para alternar diseños en
la vista principal de la aplicación.

Fuente: adaptado de https://material.google.com/patterns/gestures.html#gestures-touch-mechanics.

2.1.7. Girar y rotar el dispositivo

El acelerómetro y el giroscopio que incorporan la mayoría de dispositivos mó-

viles son capaces de detectar cambios en su orientación, de vertical (Portrait)
a horizontal (Landscape) o viceversa.

Aunque no es un gesto que se haga directamente sobre la pantalla, este cam-

bio de orientación de la pantalla se ha ido convirtiendo rápidamente en un
comportamiento esperado por parte de los usuarios, sobre todo al visualizar
fotografías o vídeos.
© FUOC • PID_00245396 24 Arquitectura y wireframes

Girar y rotar el dispositivo

Fuente: elaboración propia

Este gesto, sin embargo, se puede usar para más cosas que para permitir una
visión más cómoda de la pantalla:

1) Se pueden diseñar vistas alternativas de la interfaz en función de la orien-

tación del dispositivo. Este recurso puede ir más allá de la simple reordena-
ción de los elementos mostrados en pantalla, ofreciendo nuevas funciones al
usuario. Un buen ejemplo lo tenemos en la calculadora, que en vertical ofrece
los controles básicos, mientras que en horizontal –al disponer de más espacio
para situar botones– ofrece los controles de una calculadora científica:

Ejemplo de vista alternativa en función de la orientación del dispositivo en la aplicación de

calculadora para iPhone

Otro ejemplo es el calendario del iPhone, que con el dispositivo en vertical

muestra un solo día, mientras que en horizontal muestra cinco:
© FUOC • PID_00245396 25 Arquitectura y wireframes

Vistas alternativas en el calendario de un iPhone en función de la orientación del dispositivo

Hay que dejar muy clara al usuario la disponibilidad de estas vistas alternativas,
puesto que de otro modo podrían pasar del todo inadvertidas. Si bien es cierto
que puede haber usuarios que disfruten descubriendo estas opciones por sí
solos, la mayoría agradecerá siempre recibir información clara sobre qué puede
hacer y qué no con su dispositivo.

Mensaje en una Samsung Galaxy Tab

Algunos dispositivos Samsung (Android) permiten controlar el zoom en pantalla inclinando el dispositivo.

2) También se pueden usar el acelerómetro y el giroscopio para convertir el

propio dispositivo en un mando, un recurso habitual en juegos que permite
a los usuarios, por ejemplo, controlar la dirección de un vehículo sobre una
carretera simplemente girando el dispositivo.
© FUOC • PID_00245396 26 Arquitectura y wireframes

Configuración de controles en el juego de motociclismo SBK16 para iPhone (iOS)

3) En aplicaciones de realidad aumentada (AR; augmented reality), este gesto

se convierte en la principal manera de interactuar con la interfaz, puesto que
es girando el dispositivo cómo este le muestra, como si fuera una ventana, la
capa de información sobre las imágenes que proporciona la cámara.

Ejemplo de realidad aumentada

El juego Pokémon Go para móviles permite buscar y capturar estas criaturas sobre escenarios reales, mediante realidad
aumentada. Fuente: http://mediad.publicbroadcasting.net/p/shared/npr/styles/x_large/nprshared/201606/483862852.jpg).

2.1.8. Mover

El acelerómetro también nos permite detectar cuándo el usuario mueve late-

ralmente y de forma reiterada (shake) su dispositivo, un recurso que podemos
aprovechar para activar una acción determinada, crear atajos a funciones ha-
bituales (por ejemplo, reproducir o parar el reproductor de música, descartar
una llamada) o facilitar la interacción o el intercambio de información con
otros dispositivos.
© FUOC • PID_00245396 27 Arquitectura y wireframes

Mover

Fuente: elaboración propia

Por ejemplo, en el sistema operativo iOS, el gesto de mover de este modo el

dispositivo permite deshacer (undo) la última acción, mientras que en aplica-
ciones como Line (mensajería instantánea), permite añadir nuevos contactos
sin necesidad de tenerlos que introducir manualmente.

2.1.9. Apretar

Este gesto se ha popularizado a partir de la aparición en el mercado del Apple

Watch y los modelos iPhone 6S y iPhone 6S Plus. Sus pantallas permiten de-
tectar la intensidad con que el usuario presiona la pantalla, reconociendo así
hasta tres tipos de interacciones: el clásico toque y los gestos de peek y pop.

Apretar

Sacudir
La aplicación de mensajería Line permite
añadir nuevos contactos simplemente
sacudiendo el teléfono. Fuente: https://articles-
images.sftcdn.net/wp-content/uploads/
sites/3/2013/08/2013-08-13-14.24.29-319x568.png).

Fuente: elaboración propia

Podríamos traducir peek como «fisgonear», o lo que es lo mismo: echar una

ojeada rápida. Se trata de la presión menos profunda, con la que podemos, por
ejemplo, previsualizar una fotografía del carrete o presionar sobre un enlace
para previsualizar la página que hay en él sin salirnos de la pantalla en que
estemos. Una vez desplegada esta vista rápida, al deslizar el dedo hacia arriba
accedemos a las opciones disponibles, levantando el dedo de la pantalla la
cerramos y apretando aún más fuerte (hacer pop) abrimos definitivamente el
elemento seleccionado.
© FUOC • PID_00245396 28 Arquitectura y wireframes

Así, como si de una burbuja se tratara, el gesto de pop equivale a hacer «explo-
tar» la vista previa y traer el contenido a primer plano. Se trata, por tanto, de
la presión más firme sobre la pantalla.

Ejemplos de peek y pop en un iPhone 6S

Con los gestos de peek y pop en un iPhone 6S podemos seleccionar una opción concreta antes de abrir una aplicación
(izquierda) o hacer una vista previa de un enlace mientras navegamos por internet (derecha).

Debido a las múltiples posibilidades que ofrece esta nueva forma de interac-
ción, cabe esperar que se extienda rápidamente a otros dispositivos y siste-
mas operativos, y que los desarrolladores de aplicaciones le encuentren nue-
vos usos. Por contra, presionar una pantalla con diferentes niveles de fuerza
requiere de cierto entrenamiento y pericia por parte de los usuarios, lo que
puede dificultar su adopción masiva y que se convierta en un comportamiento
esperado como ha sucedido con otros gestos.

2.2. Elementos gráficos

A continuación pasamos a describir algunos de los elementos gráficos que po-

demos encontrar habitualmente en las interfaces de dispositivos móviles.
© FUOC • PID_00245396 29 Arquitectura y wireframes

2.2.1. Tipografía

El texto es el elemento básico con el que construiremos el contenido de nues-

tras aplicaciones. Lo usaremos en todas partes: en el cuerpo de nuestros men-
sajes, en menús y barras de navegación, en los botones... Realizar una buena
elección de tipografía y cuidar cuestiones como el interlineado o el espaciado
redundará en una mejor legibilidad de nuestra aplicación y, por tanto, una
mayor comodidad para nuestros usuarios.

Los sistemas operativos suelen contar con una tipografía estándar (Roboto pa-
ra Android, San�Francisco para iOS y Segoe para Windows Phone), aunque no
es obligatorio usarla en nuestros productos. En caso de querer diferenciarnos Ejemplos�de�la�fuente�Roboto
Fuente: material.google.com
de las guías marcadas por los sistemas operativos, algunas pautas y consejos:

• Mejor�sin�serifa. Las tipografías de palo seco, sin serifa, resultan más lim-
pias y cómodas de leer en pantalla, sobre todo cuando esta es pequeña. Si
el diseño lo permite, podemos jugar con dos tipos de letra diferentes (por
ejemplo, uno para los títulos y otro para el cuerpo del texto).

• Tamaño�de�la�fuente. Debe ser lo suficientemente grande como para ser

leída cómodamente (debemos evitar a toda costa que el usuario sienta la
necesidad de hacer zoom con los dedos para ampliar la letra), aunque sin
excedernos: un texto demasiado grande provocará muchos saltos de línea,
dificultando la lectura. Una sencilla manera de calcularlo es contando el
número de caracteres que caben en una línea: entre treinta y cuarenta
caracteres por línea es un buen punto de partida.

• Color�y�contraste. Aunque parezca ir contra el sentido común, no es ne-

cesario recurrir siempre al «negro sobre blanco» para conseguir un texto
legible. De hecho, en algunos casos, puede incluso que el negro puro sobre
blanco dificulte la lectura o fatigue al usuario. Para suavizar el contraste,
se pueden usar tonos de gris (tanto para el fondo como para la letra). Por
ejemplo, en lugar de un texto negro «puro» (#000000), podemos usar to-
nos oscuros de gris, como #0D0D0D o #0F0F0F para la letra, o tonos muy
claros.

• Jerarquías. Mientras que en la web nos hemos acostumbrado al uso de

múltiples niveles (H1, H2, H3, H4, etc.), en pantallas pequeñas a menudo
nos bastará con dos niveles para organizar jerárquicamente nuestro texto;
para facilitar el tema, podemos jugar con variaciones (negrita, itálica) para
tener mayor riqueza tipográfica.

• Espaciado. Al igual que en el punto anterior, en pantallas pequeñas au-

mentaremos ligeramente el espaciado –tanto entre palabras como entre
líneas– para mejorar la legibilidad del texto. Este aumento de espacio tam-
bién lo podemos aplicar entre párrafos, ayudando así al lector a identifi-
car mejor los bloques de texto. De nuevo, tampoco conviene pasarse por
© FUOC • PID_00245396 30 Arquitectura y wireframes

exceso: un texto con demasiado espacio blanco entre palabras o líneas re-
sulta incómodo de leer.

• Tipografía�responsiva. Si nuestra aplicación va a utilizarse en diferentes

tamaños de pantalla, resulta conveniente cerciorarse que tanto el tamaño
de la fuente como el espaciado se escalan convenientemente.

• Alineación. La norma básica es evitar el texto justificado, ya que en de-

terminadas ocasiones puede dejarnos líneas con demasiados espacios en
blanco. Para el resto de alineaciones, las recomendaciones generales son:
– Alineación�a�la�izquierda. Se trata de la alineación preferente, ya que
funciona muy bien en toda ocasión, incluso con grandes bloques de
texto.

– Texto�centrado. Resulta conveniente usarlo con moderación. Funcio-

na bien con títulos, dentro de botones o en pequeños bloques de texto.

– Alineación�a�la�derecha. También conviene usarla con moderación y

en pequeños bloques de texto.

Lecturas complementarias

B.�Moss (2015, 4 de febrero). «7 simple rules for mobile typography».

H.álvarez (2014, 6 de agosto). «Choosing the Right Font: A Guide To Typography and
UX». User Testing Blog.

C.Cousins (2014, 5 de marzo). «Tips for designing Better Mobile Typography». Design
Shack.

Google. Guía y recomendaciones de uso para la fuente Roboto.

Apple. iOS Typography Guidelines.

Microsoft. Fonts for UWP apps.

2.2.2. Iconos

Los iconos se acostumbran a usar como atajos tanto para acceder a aplicacio-
nes desde la pantalla de inicio como para acceder a elementos o funciones
específicas una vez dentro de estas. Es aconsejable que los iconos estén acom-
pañados de texto para su fácil identificación. Esta etiqueta suele estar situada
bajo el icono y centrada respecto a la imagen. La etiqueta no debería ocupar
más de una línea; en caso de ser demasiado larga, se puede truncar el texto o
hacerlo pasar como si fuera una marquesina.

Podemos encontrar varios tipos de icono:

1)�Iconos�fijos: representan con una imagen el elemento o función a la que

dan acceso. La imagen tiene que ser muy clara y entenderse al primer vistazo.
© FUOC • PID_00245396 31 Arquitectura y wireframes

Juego de iconos del sistema operativo iOS

Fuente: developer.apple.com

2)�Iconos�interactivos: no sirven para acceder a aplicaciones, sino para llevar

a cabo acciones directas, como, por ejemplo, conectar el WiFi o el GPS, ajustar
el brillo de la pantalla, etc. Su diseño tiene que permitir visualizar rápidamente
el estado del elemento.

Iconos interactivos en el centro de control de un iPhone (iOS)

2.2.3. Widgets

Si tuviéramos que definirlos de alguna manera, los widgets son como «peque-
ñas ventanas» que nos permiten consultar el contenido de una aplicación sin
necesidad de abrirla.

En Android, los widgets juegan un papel esencial en la personalización de la

pantalla de inicio del usuario. Para los desarrolladores, los widgets representan
una oportunidad tanto de promoción de la aplicación como de fidelización
del usuario: un widget en la pantalla de inicio del usuario es un fantástico
«anzuelo» para captar su atención y animarlo a abrir nuestra aplicación.

Podemos clasificar los widgets de acuerdo con las siguientes categorías:

© FUOC • PID_00245396 32 Arquitectura y wireframes

1)�Widgets�de�información: se usan para mostrar contenido variable o sobre

el cual el usuario quiere hacer un seguimiento rápido en su pantalla de inicio.
Ejemplos típicos de widgets de información son el de la meteorología o el reloj.
Al tocar sobre el widget, se abre la aplicación asociada con una vista ampliada
de la información.

Widget de la meteorología en Android

Fuente: developer.android.com

2)�Widgets�de�colección: como su nombre indica, este widget muestra múlti-

ples elementos de una misma clase (por ejemplo: correos electrónicos, fotogra-
fías...). Este tipo de widgets acostumbran a permitir el desplazamiento vertical
para navegar por el contenido. Al tocar sobre el widget, se abre la aplicación
asociada con una vista ampliada de la información o contenido seleccionado.

Widget de colección

Fuente: developer.android.com

3)�Widgets�de�control: su uso es parecido al de un interruptor, permitiendo al

usuario activar o desactivar ciertas funciones o parámetros de configuración
sin necesidad de abandonar la pantalla de inicio. Un ejemplo típico lo encon-
tramos en los ajustes rápidos de Android o en el widget que permite controlar
la reproducción de audio en el dispositivo.

Widget de ajustes rápidos

Fuente: developer.android.com
© FUOC • PID_00245396 33 Arquitectura y wireframes

4)�Widgets�híbridos: son aquellos que combinan dos o más de las anteriores

categorías. Por ejemplo, un widget para controlar la reproducción de música
puede al mismo tiempo ser un widget de control (con botones para iniciar o
detener la reproducción, saltar pistas...) y uno de información (mostrando el
nombre del artista, nombre de canción, título de álbum...).

Widget de reproducción de música en Android

Fuente: developer.android.com

2.2.4. Notificaciones

Las notificaciones sirven para advertir al usuario de alertas�o�cambios�en�el

estado del sistema y aplicaciones. El ejemplo más claro es el aviso de una lla-
mada perdida o la llegada de un nuevo mensaje de chat, pero las notificacio-
nes también se pueden usar para mostrar al usuario el siguiente acontecimien-
to marcado en su agenda o alertarlo sobre nuevas actualizaciones disponibles
para el sistema.

Normalmente, es el propio sistema operativo quien marca cómo y dónde se

muestran las notificaciones, con las características generales siguientes:

1) Como mínimo la notificación incluye el icono�de�la�aplicación que la ha

generado, un título�y�texto con el contenido de la notificación y una marca
de�tiempo del momento en que se generó. Es habitual que las notificaciones
vengan acompañadas de un sonido para llamar la atención del usuario.

«Anatomía» de una notificación en Android

Fuente: developer.android.com

2) Algunos sistemas operativos permiten una vista�«expandida» de la notifi-

cación, que en determinados casos permite incluso realizar acciones directa-
mente sobre la notificación, evitando tener que abrir la aplicación (por ejem-
plo, responder a un mensaje o retrasar una alarma).
© FUOC • PID_00245396 34 Arquitectura y wireframes

Notificación expandida en Android Wear

Fuente: developer.android.com

3) Ante una nueva notificación, el usuario tiene que poder decidir si quiere
atenderla o dejarla para más tarde. Lo más habitual es mostrar las notificacio-
nes solo�durante�unos�segundos mediante una tira, animada o no, que apa-
rece durante unos segundos en la parte superior de la pantalla.

4) En caso de mostrar la notificación por medio de una ventana emergente

(pop-up), hay que ofrecer al usuario las opciones de atender el mensaje o dejarlo
para más tarde.
© FUOC • PID_00245396 35 Arquitectura y wireframes

3. Principios para el diseño de interfaces móviles

Exponemos a continuación los principios básicos para el diseño de interfaces

móviles.

3.1. Simplicidad

Andando por la calle, bajando unas escaleras, en la sala de espera del dentista,
en el autobús camino al trabajo... los usuarios usan sus dispositivos móviles
en las más variadas situaciones, sometidos a constantes interrupciones y muy
a menudo sin prestarles el 100 % de su atención. Es por este motivo que las
interfaces móviles tienen que ser fáciles�de�usar�desde�el�primer�momento:
en general, el usuario percibirá como un contratiempo tener que pararse en
medio de la calle para descubrir cómo funciona la aplicación que se acaba de
descargar.

Conseguiremos la simplicidad en nuestros diseños cuando cualquier persona

pueda entender y usar la interfaz con independencia de su experiencia pre-
via, formación o nivel de concentración. Para ello, tendremos que presentar al
usuario en primer término solo aquellas opciones imprescindibles para con-
seguir su objetivo o completar la tarea central de la aplicación. Una�interfaz
llena�de�botones�y�opciones�desconcertará�al�usuario. En cambio, si le da-
Ejemplo�de�simplicidad
mos pocas opciones, el usuario aprenderá rápidamente los gestos necesarios Tal vez esta aplicación no sea excepcional en
el apartado de diseño, pero con tres botones
para manipular con éxito la interfaz, haciendo que le resulte cada vez más al pie de la pantalla el usuario tiene más
que suficiente para usar su teléfono como
agradable de usar. El resto de opciones pueden quedar escondidas detrás de grabadora.

un menú o ir apareciendo progresivamente, a medida que el usuario vaya uti-

Reflexión
lizando la aplicación.
La mayoría de usuarios de dis-
positivos móviles no valoran la
complejidad, sino que sus apli-
Si podemos prescindir de un elemento y su ausencia no afecta a la com- caciones hagan bien –y rápi-
do– una sola cosa.
prensión del sistema por parte del usuario, entonces su presencia no es
necesaria.

Otras pautas básicas para la simplicidad son identificar y titular claramente los
controles y elementos de navegación, ofrecer una respuesta clara para todas
las acciones o asegurarnos de que los mensajes y textos de nuestra interfaz no
son ambiguos y se entienden bien a�la�primera.
© FUOC • PID_00245396 36 Arquitectura y wireframes

3.2. Eficiencia

La eficiencia de una interfaz viene definida por el número de pasos que tiene
que dar el usuario para conseguir un determinado objetivo. Las tareas más im-
portantes, por tanto, tienen que estar claramente accesibles y ser completadas
con el menor número de toques o movimientos sobre la pantalla.

En este sentido, podemos aprovechar los sensores del dispositivo para evitarle
al usuario tener que introducir datos manualmente (por ejemplo, ofreciéndole
automáticamente la previsión del tiempo de la ciudad donde se encuentre) o
bien recordar sus preferencias de una sesión para otra, aprender del uso que
haga de la aplicación o incluso prever su próxima acción, todo con el objetivo
de facilitarle el trabajo.

3.3. Consistencia

De acuerdo con el principio de consistencia, los usuarios aprenderán a mane-

jar una interfaz más fácilmente cuando puedan transferir conocimientos pre-
vios en nuevos contextos. De esta manera, la interfaz de nuestra aplicación
tiene que ser consistente consigo misma, con el dispositivo y con el sistema
operativo donde se instalará, y si es posible, con el resto de aplicaciones con
las que convivirá.
Captura�de�pantalla�de�la�aplicación�de
Google�en�un�iPhone
El asistente Google Now aprende de la
Esto no quiere decir que nuestra aplicación tenga que ser como todas las de- actividad del usuario, hasta el punto de ofrecer
respuestas incluso antes de que el usuario se
más, sino que, aunque sea innovadora, el usuario tendrá que encontrar la apli- haga las preguntas.

cación fácil de usar porque�respeta�los�estándares�y�paradigmas�del�sistema

operativo del dispositivo.

Existen cuatro tipos de consistencia:

• Consistencia�estética: se refiere a la apariencia visual (logos, colores, ti-

pografías, recursos gráficos), lo que permite un rápido reconocimiento del
sistema por parte del usuario.

• Consistencia�funcional: es la que permite al usuario aplicar conocimien- Ejemplo�de�consistencia�funcional

Gracias a la consistencia funcional en el diseño,
tos previos en un nuevo contexto. Por ejemplo, los controles en una apli- el usuario de Android reconocerá el patrón y
funcionamiento de este desplegable aunque lo
cación de vídeo replican los «viejos» símbolos usados en aparatos de vídeo encuentre en diferentes colores o situaciones.
Fuente: developer.android.com
VHS (reproducción, pausa, retroceso, avance...), lo que facilita al usuario
su control desde el primer momento.

• Consistencia�externa: en el caso de aplicaciones móviles, se refiere a la

coherencia de la aplicación con los principios de diseño del sistema ope-
rativo o el respeto a los patrones de diseño afianzados.

• Consistencia�interna: se refiere a la coherencia del diseño de la aplicación,

su unidad visual y funcional, lo que proporciona tranquilidad y confian-
za al usuario mientras la maneja. Por ejemplo, los botones se encuentran
© FUOC • PID_00245396 37 Arquitectura y wireframes

siempre en el mismo lugar y tienen el mismo comportamiento en todas

las pantallas.

3.4. Interacción

En los humanos, el sentido del tacto es una herramienta indispensable para

interactuar con nuestro entorno, quizá la más intuitiva. Hasta hace muy poco,
esta forma de interactuar no era posible en entornos virtuales. Con el auge
de las pantallas táctiles en los dispositivos móviles, la interacción háptica (del
griego haptikos, ‘relativo al sentido del tacto’) se ha popularizado, puesto que
permite a los usuarios manipular directamente los objetos que hay en la pan-
talla. Este hecho aumenta su sensación de control sobre la interfaz y les per-
mite una rápida y mejor comprensión sobre las consecuencias de sus acciones.

Capturas de pantalla de la aplicación Microsoft Outlook para iPhone

La aplicación para gestionar el correo electrónico Microsoft Outlook permite configurar gestos sobre las filas en la bandeja de
entrada para marcar como leído, borrar, archivar o posponer fácilmente el correo recibido.

Para reforzar esta sensación, hace falta que el dispositivo responda fielmente a
los movimientos del usuario. En este sentido, el usuario también puede recibir
una respuesta�háptica a sus acciones, normalmente a través de la vibración
del dispositivo cuando usa el teclado virtual o pulsa un botón en la pantalla.
En dispositivos como el iPhone 6S o el Apple Watch, este tipo de respuesta
se ha visto potenciada con la introducción de la tecnología Force Touch, que
permite el reconocimiento de la presión del dedo del usuario sobre la pantalla.
© FUOC • PID_00245396 38 Arquitectura y wireframes

Finalmente, la interacción con los dispositivos móviles puede darse tanto to-
cando la pantalla como moviendo el propio aparato (por ejemplo, rotando la
pantalla), gracias a los sensores de movimiento que incorporan.

Siempre que sea posible, facilitaremos que el usuario interactúe directa-

mente con el contenido sin la intermediación de botones, menús, ba-
rras, etc.

A la hora de diseñar la interfaz, es aconsejable tener siempre en cuenta todas

las maneras en que el usuario intentará interactuar con ella, no solo aquellas
que nosotros hayamos pensado y diseñado.

3.5. Metáforas

Si presentamos los objetos y las acciones en la interfaz como una metáfora de

objetos y acciones en el mundo real, los usuarios aprenderán rápidamente a
interactuar con la interfaz y la encontrarán más atractiva.

El ejemplo clásico en este sentido es la carpeta: la gente usa carpetas en el

mundo real para guardar documentos; en la interfaz, por lo tanto, una carpeta
será rápidamente identificada como un elemento contenedor. Otras metáforas
habituales en las interfaces son la caja de herramientas o los engranajes para
representar las opciones de configuración, un sobre de carta para el correo
electrónico, un auricular para el teléfono, etc.

No es necesario que estas metáforas se limiten al diseño de iconos u otros ele-

mentos gráficos: por ejemplo, también se pueden usar para diseñar los gestos
que después tendrá que hacer el usuario, como, por ejemplo, pasar las páginas
de un libro con el dedo, encender o apagar interruptores o cambiar la fecha
en una rueda giratoria.

3.6. Respuesta Pantalla�de�bloqueo�de�una�tableta�Android

El candado se acostumbra a usar como
metáfora para indicar que el dispositivo está
bloqueado.
La sensación de control derivada de la manipulación directa de la interfaz por
parte de los usuarios se tiene que ver reforzada en todo momento por una
respuesta rápida, inmediata, a sus acciones. Esta respuesta confirma al usuario
la acción realizada, quien de otra manera podría sentirse frustrado o intentar
la misma acción sucesivas veces, produciendo distorsiones en la entrada de
datos.

Compra de billetes de avión mediante el teléfono móvil

Imaginemos por ejemplo alguien que quiere comprar billetes de avión a través de su
teléfono móvil. Mediante un formulario parecido al que encontraría en una página web,
introduce origen, destino, número de pasajeros y las fechas de ida y vuelta deseadas. A
continuación, pulsa el botón que activa la búsqueda, pero no parece que ocurra nada.
Espera unos cuantos segundos, y lo vuelve a pulsar, fijándose esta vez en si el botón
responde de alguna manera al toque de su dedo, cosa que no sucede. Entonces empieza
a dudar de si la aplicación funciona, pulsa el botón de buscar un par de veces más y a
© FUOC • PID_00245396 39 Arquitectura y wireframes

continuación intenta entrar de nuevo, también sin éxito, en los campos del formulario.
Parece que la aplicación se ha quedado efectivamente «colgada». Pero justo en aquel
momento, la pantalla cambia mostrándole los resultados de su búsqueda.

En este ejemplo, podemos distinguir dos tipos de respuesta a la acción del usuario que
han fallado. En primer lugar, el usuario no ha advertido ninguna reacción cuando ha
pulsado el botón de búsqueda, cosa que le ha hecho desconfiar. En segundo lugar, cuando
ha pulsado el botón de nuevo, ha visto que este no reaccionaba a su gesto, y esto le ha
hecho desconfiar aún más.

La velocidad de respuesta ante una acción del usuario no significa que el sistema tenga
que ser igualmente rápido procesando su petición. Dicho de otro modo: es posible que
el usuario no obtenga al instante aquello que pide del sistema, pero sí tiene que saber al
momento que el sistema está trabajando en ello.

En el ejemplo que acabamos de ver, el hecho de pulsar repetidamente el botón

de búsqueda no tiene consecuencias negativas para el usuario, pero si esto
mismo sucediera en otro lugar de la aplicación, por ejemplo, a la hora de pagar
los billetes, bien podría ser que el usuario acabara pagando sus billetes dos
veces o más.

Por otro lado, la sensación de respuesta va más allá de usar indicadores de res-
puesta. En pantallas táctiles, la sensación de respuesta se puede conseguir me-
diante cambios en la posición, orientación, color e iluminación del elemento
accionado, animándolo de forma sutil con sonidos o incluso activando bre-
vemente el mecanismo de vibración del dispositivo. Buena parte de estas res-
puestas vienen predeterminadas por el sistema operativo mismo, de forma que
con su uso continuado devienen comportamientos esperados por parte de los
usuarios.

Indicadores�de�espera�durante�una�búsqueda
En este sentido, hay que tener en cuenta que el usuario valorará la velocidad en�la�aplicación�de�Vueling�(versión�para
iPhone)
en la respuesta de su dispositivo por encima de la estética, de modo que, an- Nótese el cuidado en el diseño de la rueda de
espera, para la que se han usado un par de
tes de diseñar animaciones complejas, tendremos que tener bien claro que el aviones volando en círculo.

dispositivo será capaz de llevarlas a cabo con fluidez.

© FUOC • PID_00245396 40 Arquitectura y wireframes

Botones en Android
Lecturas
complementarias

Guía para el diseño de inter-

faces de Apple: iOS human
interface guidelines.
Principios de diseño para An-
droid.
W.�Lidwell;�K.�Holden;
J.�Butler (2011). Universal
Principles of Design. Beverly:
Rockport Publishers.

Los botones en Android tienen diferentes estados, cambiando de aspecto y color cuando el usuario los toca. Fuente:
developer.android.com
© FUOC • PID_00245396 41 Arquitectura y wireframes

4. Sketching y wireframes

El prototipado es la piedra angular del proceso de diseño y requiere de

elevadas dosis tanto de creatividad como de practicidad. Gracias al pro-
totipado, nuestras ideas salen de la cabeza y toman vida propia, empe-
zando a evolucionar.

Sin embargo, no existe un momento idóneo para empezar a prototipar nues-

tras ideas. De hecho, se debate tanto sobre cuándo empezar a prototipar como
sobre cómo prototipar. Si lo planteamos de forma lineal, el proceso sería algo
parecido a esto:

1)�Sketching: empezamos a dar forma a nuestras ideas realizando rápidos es-

bozos en papel. Es la etapa más inicial, de brainstorming, donde las ideas deben
fluir con libertad.

2)�Wireframes: las ideas empiezan a tomar forma y las empezamos a organizar

en cajas, listas, menús, etc. En esta etapa es cuando empezamos a jerarquizar
la información, diseñando el árbol de navegación de nuestra aplicación.

3)�Mockups: añadimos detalle a nuestros wireframes: color, tipografías, fotos

y otros elementos visuales para dotar al diseño de mayor realismo. Eventual-
mente, añadimos interacción a las pantallas diseñadas, bien enlazándolas en-
tre ellas para simular una navegación real o bien añadiendo otras animacio-
nes/interacciones para conseguir un prototipo avanzado.

4)�Desarrollo: de forma muy resumida, diremos que en esta fase se trata de es-
cribir el código fuente en el lenguaje de programación escogido para convertir
el prototipo en un producto real.

Las dos primeras fases corresponden al prototipado en baja fidelidad, mientras

que en la tercera (mockups) ya estaríamos hablando de prototipado en alta fi-
delidad. No obstante, en todas ellas debemos trabajar siguiendo los principios
del diseño centrado en el usuario, iterando nuestros diseños de acuerdo con
el esquema que vimos en el módulo anterior:
© FUOC • PID_00245396 42 Arquitectura y wireframes

Fuente: elaboración propia

Así pues, cuando nos referimos a «fidelidad», estamos hablando de detalle

visual e interacción en nuestros prototipos. De ahí que los prototipos en baja
fidelidad sean habituales (y recomendados) en las primeras etapas de nuestro
proyecto, donde convertimos nuestras ideas en algo tangible. Los prototipos
en alta fidelidad, por su parte, son habituales en iteraciones más avanzadas,
cuando las ideas están más claras y queremos refinar nuestros diseños.

Aun así, existen otros factores que afectan al nivel de fidelidad con que traba-
jaremos nuestros prototipos. Por ejemplo:

• Presupuesto�disponible para el proyecto, tanto en dinero como en tiem-

po. Si no tenemos mucho de lo uno o de lo otro, nuestros prototipos se-
rán rápidos y en baja fidelidad, lo justo para trazar las líneas maestras del
proyecto.

• Recursos�y�habilidad del equipo de diseño y desarrollo: los prototipos en

alta fidelidad requieren de personal especializado que domine las herra-
mientas de prototipado.

4.1. Prototipado en baja fidelidad

Como hemos visto, los prototipos en baja fidelidad (sketches y wireframes) se

suelen hacer en las primeras etapas de desarrollo, justo cuando empezamos
a pensar en cuáles serán las funciones de la aplicación. Se pueden empezar a
hacer con lápiz y papel, sin preocuparnos mucho por el diseño. En esta fase
lo más importante es visualizar qué es lo que realmente queremos conseguir
y cómo queremos hacerlo.
© FUOC • PID_00245396 43 Arquitectura y wireframes

Prototipo a lápiz y papel

Fuente: Flickr
Para ayudarnos a visualizar todavía mejor lo que hacemos, podemos elaborar
estos primeros dibujos dentro del marco de un dispositivo móvil para hacernos
una idea de los tamaños y proporciones de los elementos que colocamos en
pantalla. En la red se pueden encontrar multitud de plantillas imprimibles –
a tamaño real–, tanto de teléfonos como de tabletas, que facilitarán nuestro
trabajo.

Fuente: «iPhone Wireframe Templates for Sketching»

Empezar a trabajar en baja fidelidad nos ofrece tres�ventajas�básicas:

© FUOC • PID_00245396 44 Arquitectura y wireframes

• Velocidad: las iteraciones y mejoras del diseño se suceden rápidamente.

Basta con arrancar la página y volver a empezar.

• Eficiencia: al no centrarnos en los detalles visuales, nuestros diseños van

directos al grano, facilitándonos de esta forma dirigir toda la atención ha-
cia los puntos clave de nuestro producto.

• Colaboración: cualquiera sabe dibujar con papel y lápiz. Compartir los

primeros esbozos con todos los participantes en el proyecto nos permitirá
recoger fácilmente ideas y mejoras por parte de todos los miembros del
equipo.

También podemos diseñar el árbol�de�navegación de la aplicación en baja

fidelidad, donde plantearemos todos los posibles caminos de pantallas que
podrá recorrer el usuario.

Fuente: SimplePocket Wireframes

El árbol de navegación puede inspirarse en los diagramas�de�flujo de un pro-
grama informático o bien en el sitemap� de� una� web, en el que se indican
todas las pantallas y los caminos que puede realizar el usuario entre ellas.
© FUOC • PID_00245396 45 Arquitectura y wireframes

Algunas herramientas recomendadas para trabajar con wireframes son:

1)�Balsamiq: tal vez la más clásica, que empezó como herramienta de proto-
tipado de páginas web y ahora se usa también para aplicaciones móviles. Per-
mite crear y compartir prototipos de forma fácil y rápida, simplemente arras-
trando y colocando los elementos desde el menú de herramientas superior. El
resultado final parece como si se hubiera realizado a mano, lo que nos permite
centrarnos más en la estructura de navegación que en el diseño.

Paleta de herramientas en balsamiq

Fuente: balsamiq.com
Se puede instalar en el ordenador –el coste de la licencia para un usuario es
de 89 dólares– o usarlo directamente en su web, con un coste de suscripción
básico de 12 dólares al mes (extraído de https://balsamiq.com/buy/#d; fecha
de consulta: 21 de noviembre de 2012).

2)�NinjaMock: herramienta en línea que permite crear fácilmente prototipos

y compartirlos en línea para su testeo o evaluación. Las páginas del prototipo
se pueden enlazar entre sí, facilitando su navegación. Incluye paleta de herra-
mientas y stencils para Android, iOS y Windows Phone. NinjaMock es gratuita
y plenamente funcional, si bien los proyectos en la versión gratuita son públi-
cos y llevan la marca de la compañía.
© FUOC • PID_00245396 46 Arquitectura y wireframes

NinjaMock

3)�Pop: esta original aplicación nos permite fotografiar con el móvil nuestros
wireframes hechos a papel y lápiz y añadirles interacciones mediante enlaces,
de modo que nuestros dibujos cobren vida. Los prototipos resultantes se pue-
den compartir con otros usuarios para que aporten feedback. Disponible de
forma gratuita para iOS y Android.
© FUOC • PID_00245396 47 Arquitectura y wireframes

Versión para android de POP

Fuente: play.google.com

4)� Draw.io: herramienta en línea gratuita (funciona incluso sin registro de

usuario) que permite crear rápida y fácilmente diagramas de flujo, árboles de
navegación e incluso prototipos en baja fidelidad de nuestras aplicaciones.
Permite guardar los proyectos en servicios de alojamiento en la nube, como
Google Drive, Dropbox o OneDrive, así como exportar los diagramas en dife-
rentes formatos (.gif, .png, .jpg, .pdf...).
© FUOC • PID_00245396 48 Arquitectura y wireframes

Diagrama de flujo en draw.io

Ved también

En el módulo dedicado al di-

seño y prototipado, veremos
herramientas y técnicas para
el desarrollo de prototipos�en
alta�definición con el objetivo
de testear nuestras ideas más
allá del papel.
© FUOC • PID_00245396 49 Arquitectura y wireframes

Bibliografía
Álvarez, H. (2014, 6 de agosto). «Choosing the Right Font: A Guide To Typo-
graphy and UX» [en línea]. User Testing Blog. [Fecha de consulta: 01 de diciembre de
2016]. <https://www.usertesting.com/blog/2014/08/06/choosing-the-right-font-a-guide-to-
typography-and-user-experience/>.

Apple. iOS human interface guidelines [en línea]. <https://developer.apple.com/ios/hu-

man-interface-guidelines/>.

Cousins, C. (2014, 5 de marzo). «Tips for designing Better Mobile Typography» [en línea].
Design Shack. [Fecha de consulta: 01 de diciembre de 2016]. <https://designshack.net/arti-
cles/typography/tips-for-designing-better-mobile-typography/>.

Garret, J. J. (2002, 6 de marzo). «Un vocabulario visual para describir arquitectura

de información y diseño de interacción» [en línea]. jjg.net. <http://www.jjg.net/ia/visvo-
cab/spanish.html>.

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.; Iazza, G. (2004). «Diseño web centrado en el usuario: usabilidad
y arquitectura de la información» [en línea]. Hipertext.net. Anuario Académico sobre Documen-
tación Digital y Comunicación Interactiva (n.º 2). <https://www.upf.edu/hipertextnet/nume-
ro-2/diseno_web.html#3>.

Knemeyer, D. (2003). «Information Design: The understandig discipline» [en línea]. Bo-
xes and Arrows. [Fecha de consulta: 21 de noviembre de 2016]. <http://online.sfsu.edu/
jkv4edu/2DMG/projects/infodesign_boxarrows.pdf>.

Lidwell, W.; Holden, K.; Butler, J. (2011). Universal Principles of Design. Beverly: Rockport
Publishers.

McVicar, E. (2012, 25 de septiembre). «Designing for mobile, Part 1: Information Ar-

chitecture» [en línea]. UX Booth. [Fecha de consulta: 21 de noviembre de 2016]. <http://
www.uxbooth.com/articles/designing-for-mobile-part-1-information-architecture/>.

Microsoft. Fonts for UWP apps [en línea]. <https://msdn.microsoft.com/en-us/win-

dows/uwp/style/fonts>.

Moss, B. (2015, 4 de febrero). «7 simple rules for mobile typography» [en línea]. [Fecha
de consulta: 01 de diciembre de 2016] <http://www.webdesignerdepot.com/2015/02/7-sim-
ple-rules-for-mobile-typography/>.

Ronda León, R. (2008, 28 de abril). «Arquitectura de la información: análisis histórico-con-

ceptual» [en línea]. No solo usabilidad: Revista sobre Personas, Diseño y Tecnología. <http://
www.nosolousabilidad.com/articulos/historia_arquitectura_informacion.htm>.

Rosenfeld, L.; Morville, P. (2000). Arquitectura de la información para el WWW. México:

McGraw-Hill.

Rosenfeld, L.; Morville, P.; Arango, J. (2015). Information Architecture: For the Web and
Beyond. Sebastopol: O’Reilly Media.

Saffer, D. (2008). Designing gestural interfaces. Sebastopol: O’Reilly.

The Information Architecture Institute. Sitio web oficial: <http://www.iainstitute.org/

>.