Diseño centrado en el usuario

La metodología del diseño centrado en el usuario (DCU) sitúa a la persona en el núcleo del proceso de diseño de la interfaz. Atiende especialmente a los aspectos cognitivos que intervienen la interacción entre personas y cosas, de manera que permite optimizar la usabilidad de cualquier objeto con el que las personas interactúen cotidianamente.

La DCU implica al usuario desde los primeros pasos del proceso de desarrollo de una aplicación interactiva y se desarrolla a lo largo de varias etapas, algunas de las cuales son iterativas.

Etapas de desarrollo de una aplicación interactiva

Índice

Diseño centrado en el usuario

1.Análisis

Tal como se ha descrito hasta aquí, esta etapa consiste en la recopilación de información sobre las características de los usuarios potenciales, los objetivos de la aplicación y los requisitos técnicos del desarrollo. Recapitulando conceptos anteriores y situándonos en la piel del diseñador, las principales preguntas a las que éste debe responder en esta fase son las siguientes:

1.1.¿A qué tipo de usuario va dirigida? ¿Cuáles son sus necesidades?

El tipo de usuario determina el diseño en los siguientes aspectos:

Ámbito de difusión. Puede tratarse de un producto de difusión general (usuarios con un rango de intereses muy variable y con diferentes niveles de conocimiento del entorno informático) o de un sistema dirigido a un público altamente especializado (usuario de perfil reconocido, con un nivel de conocimiento de la herramienta determinable). Las posibilidades intermedias son infinitas y variables en cada caso.
Edad del usuario. El público objetivo puede ser infantil, juvenil, adulto o universal. Si el sistema puede ser utilizado por personas de edad muy avanzada, es importante priorizar los factores de accesibilidad. Con el objetivo de definir con la mayor exactitud posible las características del usuario, suelen utilizarse métodos de indagación, que permiten conocer a fondo a la audiencia potencial para adaptar el diseño y orientarlo a la máxima satisfacción del usuario.
Necesidades del usuario. Una vez identificado el destinatario de la aplicación, el diseñador debe plantearse el ejercicio de obtener una imagen clara de sus necesidades. Para ello deberá decidir cómo recoger y mostrar esa información, qué métodos y procedimientos utilizar, así como qué tiempo y recursos disponer para esta tarea.

1.2.¿Cuál es el contenido de la aplicación?

Hace referencia al tipo y extensión del contenido de la aplicación. El tipo de contenido determina el género, puesto que puede corresponder, por ejemplo, a un sistema de formación, a un juego, a una enciclopedia, a un producto promocional o a la presentación de una empresa, aunque los géneros aparecen en muchas ocasiones mezclados. Respecto a la extensión de los contenidos, el volumen puede determinar la necesidad de utilizar recursos más o menos sofisticados de motivación del usuario, así como la organización de los contenidos.

1.3.¿Cuál es el soporte de la aplicación?

¿Estamos preparando una aplicación que se distribuirá en CD-ROM, se trata de una web o estará en un punto de información fijo? Según cuál sea la respuesta a esta pregunta, el diseño debe ser distinto.

Pensemos por ejemplo en los problemas con los que, aún hoy en día, se encuentran muchos usuarios en el proceso de descarga de información de internet. Si la web está destinada al gran público deberá ser necesariamente más ligera que si se dirige a un grupo de usuarios limitado y definible, de los que se sabe que disponen de mejores recursos técnicos.

En un punto de información, por otra parte, no suele utilizarse el ratón como herramienta de acceso a los datos, sino que existen otros sistemas. El más difundido es la pantalla táctil, en el que las opciones de navegación se controlan mediante pulsaciones de los dedos que no son tan precisos como el puntero del ratón; así, el tamaño de las zonas activas debe estar en relación con las características del dispositivo de entrada.

1.4.¿Qué determinantes aportan los otros miembros del equipo de producción?

El diseñador debe tener en cuenta los determinantes definidos por lo siguiente:

El equipo encargado de la gestión de la producción, que establece las condiciones relativas a recursos económicos, tiempo de desarrollo y equipo humano y técnico disponible.
Programadores y técnicos, para conocer los límites y capacidades de la herramienta de programación así como del soporte de la aplicación.
El equipo de documentación y los guionistas, que preparan el contenido y lo estructuran de acuerdo con las características del producto final.

1.5.¿Cuáles son los requisitos definidos por el cliente?

El cliente suele tener un papel importante en el planteamiento del diseño de una aplicación, aunque su grado de implicación puede variar mucho de un caso a otro. Además de otras cuestiones, el diálogo con el cliente puede referirse a aspectos relativos a:

Tipo de usuario de la aplicación. ¿A quién quiere dirigirse?
Objetivo. ¿Qué quiere conseguir con el producto?
Estilo. El cliente suele tener una idea definida de la imagen que desea mostrar. En caso de que se trate de una organización o de una gran empresa, pueden existir requisitos de imagen que deben respetarse.

1.6.¿Cuáles son los recursos humanos disponibles?

El equipo humano disponible para el diseño de una aplicación determina las condiciones de diseño en dos aspectos:

Número de personas disponibles.
Grado de especialización. Es posible que dentro del equipo existan personas muy especializadas (como fotógrafos o diseñadores gráficos) así como personas con poco nivel de especialización (dedicadas a las tareas de edición como recorte de gráficos, retoque de imágenes o integración).

1.7.¿Cuál es el tiempo de vida del producto?

Una aplicación multimedia puede tener un tiempo de vida corto (por ejemplo, si sirve para promocionar un producto en lanzamiento) o largo (por ejemplo, una enciclopedia). En general, un tiempo de vida largo suele implicar un tratamiento más conservador de la interfaz (que debe seguir siendo visualmente válida en el transcurso del tiempo), mientras que un tiempo de vida corto puede permitir un planteamiento visualmente más arriesgado y sujeto a modas o corrientes estilísticas.

1.8.¿Deben actualizarse los contenidos?

El contenido de una aplicación multimedia puede tener que actualizarse con cierta periodicidad. Es importante conocer dos factores fundamentales:

Periodicidad de las actualizaciones. El diseño de la aplicación debe ser lo suficientemente flexible como para permitir las actualizaciones necesarias. El análisis de las necesidades implícitas en la actualización conduce a la definición de soluciones-patrón que puedan responder a todas las posibilidades previstas. Este análisis es tanto más necesario cuanto mayor sea la frecuencia de actualización.
¿Quién va a realizar las actualizaciones? En algunos casos, la actualización de los contenidos la realiza el mismo equipo que ha llevado a cabo la producción. En otros, se deja en manos del cliente o de un equipo externo dedicado a esta tarea; en tal caso, el número y grado de especialización de las personas encargadas de llevar a cabo esta tarea puede determinar las características del diseño.

2.Diseño

El diseño de la aplicación, tanto funcional como gráfico, debe responder a las características definidas en el proceso de análisis. Como se ha especificado antes, el diseño es revisable de acuerdo con los resultados de la evaluación posterior.

La etapa de diseño consta de diferentes fases.

2.1.Modelado del usuario

En esta fase se reúne la información sobre los usuarios potenciales obtenida en la etapa de análisis y se definen los perfiles de usuario teniendo en cuenta atributos comunes como las necesidades de información, la experiencia y conocimientos o las condiciones de acceso a la aplicación. De esta manera, el diseñador puede trabajar para una audiencia con unas características definidas, que le permitirán adaptarse a unos objetivos concretos y optimizar el grado de satisfacción del usuario.

Personas

Si la audiencia prevista es muy heterogénea, puede resultar muy complejo definir los patrones de conducta, objetivos y necesidades. En estos casos, suele trabajarse con unos arquetipos llamados personas (concepto popularizado por Alan Cooper), que son descritos de manera narrativa y a los que se atribuye una identidad concreta (con nombre y fotografía, entre otros). El objetivo de la utilización de personas consiste en que el diseñador tenga en mente a un usuario real, con unas características determinadas.

Todas las características de la persona deben ser coherentes con la información obtenida acerca de la audiencia en la fase de análisis. Pueden definirse diferentes tipos de personas:

Focal. Es el principal tipo de usuario al que nos dirigimos y en cualquier proceso de diseño debería existir al menos una persona focal. Si existen más de tres personas focales, entonces es recomendable dividir la interfaz definiendo diferentes perfiles de usuario (por ejemplo, administrador y usuario).
Secundaria. Los usuarios secundarios también utilizan el producto y deben usarlo satisfactoriamente aunque, en caso de conflicto de intereses, se priorizarán las necesidades del usuario focal.
No prioritario. Usuarios infrecuentes, no autorizados o de baja prioridad.
Involucrado. No utiliza el producto, pero puede verse afectado por los resultados.

Por ejemplo, las personas que conviven en un domicilio pueden implicarse en el resultado de una operación de compra por internet.

Excluido. Usuario para el que no se está diseñando.
Promotores. Pueden generarse minipersonas que correspondan a los intereses de los promotores del proyecto (como cliente, inversores o publicistas) con el objetivo de garantizar que se tendrán en cuenta sus requisitos.

La descripción de una persona debería incluir los siguientes detalles:

Perfil geográfico. Lugar de residencia y de trabajo, así como el nivel de vida.
Perfil demográfico. Incluye por ejemplo edad, sexo, familia, ingresos, ocupación o educación.
Perfil psicosocial. Clase social, estilo de vida, aficiones y características personales.
Relación entre la persona y el producto. La persona, ¿es un cliente, un empleado o un socio? Puede distinguirse entre el desarrollo de una intranet o una extranet o en la definición de diferentes perfiles de usuario.
¿Cuál es el nivel de relación entre la persona y la aplicación? Puede tratarse de un usuario ocasional o de un usuario frecuente. El diseñador debe definir qué tipo de relación espera que la persona mantenga con el producto.
¿Qué porcentaje del uso total representa la persona? En economía existe una regla según la cual generalmente un 20% de los clientes de una empresa representa el 80% de las ventas; es importante conocer qué porcentaje de uso de la aplicación representa la persona.

Scenarios

Para poder contextualizar el proceso de interacción entre la persona y la aplicación, pueden definirse scenarios. Éstos describen casos concretos de utilización, teniendo en cuenta las tareas que el sistema debe llevar a cabo y el contexto en el que la persona va a utilizar la aplicación. Todos los detalles deben ser coherentes con la información obtenida en la fase de análisis.

La descripción del scenario debe realizarse utilizando un lenguaje narrativo y directo; se evitan las referencias directas a la tecnología, excepto en los casos en los que ésta impone alguna restricción significativa al diseño. Debe incluir detalles referidos a:

Contexto de utilización. Por parte del usuario, ¿existe alguna preparación previa para utilizar la aplicación? La regla más segura consiste en pensar que la mayoría de usuarios no supera el nivel de inexperto.
Condiciones detalladas del contexto de utilización. ¿Cuándo y dónde lleva a cabo el usuario una tarea? ¿Con quién? ¿Cuál es el contexto ambiental? (como la hora del día o las condiciones ambientales). ¿Existen limitaciones en el equipo de acceso? ¿Existe necesidad de confidencialidad? ¿Existen riesgos de seguridad? ¿Dispone el usuario de algún tipo de ayuda? ¿Existen restricciones legales?
Desarrollo de la interacción. ¿Con qué frecuencia se lleva a cabo la interacción? ¿Se realiza regularmente? La interacción, ¿es continua o interrumpida? ¿Es el proceso de interacción tan intenso que requiere toda la atención de la persona? ¿A qué velocidad debe la persona interactuar? ¿Qué nivel de complejidad tienen las acciones? ¿Quién conduce la interacción: las personas o agentes externos?
Información implicada. Se trata del tema desarrollado en la aplicación, del volumen y complejidad de la información y del nivel de detalle informativo requerido.
Características emocionales. Estilo y estado emocional de la persona. ¿Qué cosas le resultan atractivas? ¿Qué tipo de experiencia espera de la interacción? ¿Quiere vivir una aventura, prefiere sentir libertad, seguridad, sensualidad, confianza o poder?

Nombre: Eva

Edad: 45 años

Profesión: enfermera

Descripción de la persona:

Eva está casada y tiene tres hijos, de 9, 11 y 20 años. Vive en un pueblo de 50.000 habitantes cerca de Madrid. Todos los días se desplaza a la ciudad para trabajar como enfermera durante una jornada de seis horas y en el hospital utiliza habitualmente el ordenador para gestionar los datos de los pacientes.

En casa dispone de acceso a internet por ADSL, aunque no suele conectarse a menudo. Quienes utilizan el ordenador en casa con más frecuencia son su marido y su hijo mayor. Ella prefiere leer o practicar deporte, aunque dispone de muy poco tiempo libre.

Cada quince días realiza la compra en un supermercado on-line. Siempre compra en el mismo supermercado porque es el que le da mayor sensación de seguridad y confianza, aunque el proceso de selección de productos y de compra le parece bastante lento.

Descripción del scenario:

Es un viernes a las 20.15 h y, después de una semana de trabajo, Eva no tiene muchas ganas de ponerse delante del ordenador. Hoy le toca hacer la compra por internet. No dispone de mucho tiempo porque debe preparar la cena; además, debe vigilar al mismo tiempo a los niños.

Accede al supermercado on-line, se identifica y consulta directamente la lista que tiene almacenada como modelo. Esta lista le resulta muy útil para agilizar el proceso de compra porque sólo tiene que añadir o suprimir productos, en caso de que sea necesario. Después confirma el pedido e introduce los datos de la tarjeta de crédito; éste es el momento en el que Eva prefiere que la transacción se realice lo más ágilmente posible porque tiene una confianza relativa en los sistemas de seguridad por internet.

2.2.Diseño conceptual

La fase del diseño conceptual se refiere a la definición de la arquitectura de información de la aplicación, es decir, al esquema de organización y navegación por los contenidos. Determina qué relaciones existen entre los diferentes apartados, así como las posibilidades de desplazamiento entre ellos y entre las diferentes pantallas o páginas. Una vez que se ha definido la estructura de la aplicación, se documenta mediante diagramas. El diagrama debe describir la macroestructura con el detalle adecuado para que los miembros del equipo de producción puedan compartir una visión general. El diseñador determinará cuál es el nivel adecuado de detalle. El detalle específico de cada página, o microestructura, debe ser descrito en otros documentos que no son generalmente responsabilidad del diseñador.

El diagrama debe indicar cómo navega el usuario a través de tareas determinadas y qué pasos en particular existen dentro de cada una de estas tareas. Los detalles gráficos de la interfaz no aparecen representados.

Card sorting

El card sorting es una de las técnicas más útiles para definir la estructura de una aplicación interactiva. Permite comprobar cómo las personas tienden a agrupar unidades de información para desarrollar estructuras que maximicen la probabilidad de que los usuarios encuentren la información que requieren.

Se trata de una técnica fácil de conducir, de bajo coste, que permite identificar las unidades de información que pueden resultar difíciles de categorizar y encontrar y que permite detectar si la terminología es confusa o poco explicativa.

Aunque existen varias maneras de conducir un card sorting, en términos generales se lleva a cabo imprimiendo en tarjetas individuales los nombres de los ítems que se van a categorizar. Las tarjetas deben ser suficientemente grandes como para que los participantes puedan leerlas a distancia, en una mesa (la tipografía debe ser al menos de 14 puntos).

Se pide a los participantes que agrupen –de modo individual– los ítems de manera que para ellos tenga sentido. También se les pide que nombren los grupos resultantes.

Una vez que todos los participantes han completado el ejercicio, se anotan los resultados y se comentan en grupo. Generalmente existe acuerdo general en las agrupaciones, pero si existe algún caso especial en el que no haya consenso, debe comentarse a fondo para decidir si es necesario renombrar el ítem o si éste debería incluirse en más de una categoría.

Los participantes deberían ser representativos de los usuarios focales de la aplicación. Cuantos más participantes, mejor será el resultado, aunque el número mínimo recomendado es de seis. Aunque pueden colaborar entre sí, es recomendable que los participantes realicen las agrupaciones de manera individual para no llegar a conclusiones sesgadas, fruto del consenso general más que de un razonamiento individual.

Pueden realizarse variaciones sobre la técnica básica; por ejemplo, si las tarjetas son lo suficientemente grandes, pueden añadirse preguntas para saber si el nombre del ítem se entiende claramente o se puede permitir al participante sugerir nombres alternativos, entre otros.

2.3.Diseño visual

En esta fase se definen las características gráficas de la interfaz, teniendo en cuenta la información recopilada en las fases de análisis, modelado del usuario y diseño conceptual. Los pasos que se siguen en el desarrollo del diseño visual de la aplicación suelen ser los siguientes (con las variables inherentes a cada caso):

Análisis del libro de estilo (si existe) o de los determinantes gráficos aportados por el cliente.
Documentación gráfica. Antes de empezar a definir las cuestiones relacionadas con el diseño visual, se realiza un análisis de la documentación gráfica (por ejemplo de fotografías, esquemas, gráficas e ilustraciones) que se integrará en la aplicación.
Por otra parte, el diseñador se documenta acerca del tratamiento previo de contenidos similares, buscando ejemplos de aplicaciones que previamente hayan abordado el mismo tema o que se hayan dirigido al mismo tipo de usuario. La observación de producciones existentes es importante porque permite compendiar ideas y tener en cuenta aspectos que de otra manera se hubieran podido pasar por alto.
Elección de la gama cromática. A partir de los determinantes estilísticos o del tratamiento que se quiere dar a los contenidos, se define el tono cromático general de la aplicación, según el tema, el tono general que se quiere transmitir y el tipo de usuario. Si existe un libro de estilo o una imagen de marca, normalmente la aplicación deberá respetar la gama de colores predeterminada.
Elección de la tipografía. Junto con la gama cromática, la tipografía determina el tono general de la aplicación. En líneas generales, se aconseja utilizar un máximo de dos tipos de letra distintos, ya que la mezcla de muchas variaciones puede implicar poca legibilidad y un aspecto visual caótico. En todo caso, si se utilizan dos tipos de letra distintos, es importante que sean lo suficientemente distintos como para percibirse como tales (las combinaciones que ofrecen mayor contraste son las de un tipo de palo seco con un tipo romano). Si existe un libro de estilo deberemos ceñirnos –salvo en casos excepcionales– a sus directrices.
Diseño de la retícula. Forma parte de la definición de los elementos principales del diseño (color y tipografía) y es fundamental definir desde el principio la retícula en la que se basará la aplicación. La importancia del establecimiento de una retícula está en relación directa con el volumen de los contenidos y con su grado de actualización; a mayor volumen y mayor frecuencia de actualización, el establecimiento de una retícula resulta más importante, ya que posibilita una mejor coordinación del equipo de edición.
Generación de los principales elementos del diseño. A partir de la división y asignación de espacios de pantalla, se concretan los principales elementos, que incluyen los siguientes:
- El tratamiento de los fondos.
- La definición de los principales bloques de texto (títulos, subtítulos, índices y menús). Se define el tipo, el color y el tamaño de letra de cada categoría de texto.
- La integración de logotipos (si existen).
Generación de los elementos secundarios. Una vez concretados los elementos que caracterizarán la aplicación, se pasa a detallar el diseño de los elementos secundarios, tales como los siguientes:
- Opciones. El tratamiento de las opciones de pantalla debe ser coherente con el estilo visual de la aplicación.
- Texto de contenido. Se define el tipo, el tamaño y el color de la letra del texto correspondiente al contenido de la aplicación.
- Imágenes de contenido. Se determinan los formatos y las diferentes aplicaciones de las imágenes de contenido. En aplicaciones de gran volumen, es importante determinar un número máximo de variaciones de formato y localización para facilitar el trabajo del equipo de edición.
- Elementos ornamentales, si existen.

2.4.Diseño de contenidos

La redacción de los contenidos destinados a una aplicación multimedia tiene una naturaleza especial, ya que debe aprovechar las posibilidades de interactividad y tener en cuenta al mismo tiempo las limitaciones de la lectura en pantalla. Las características que deben cumplirse al diseñar contenidos para una aplicación son las siguientes (Nielsen, 2000):

Brevedad. La lectura en pantalla es más lenta que la lectura en papel y además resulta más incómoda para el lector. Como regla general, hay que escribir un 50% menos de texto. Las páginas deben ser breves y los contenidos sucintos y concretos, aunque no exentos de estilo.

Lectura en diagonal. Los usuarios tienden a no leer por entero el texto en pantalla, sino que suelen rastrear visualmente la página para encontrar las palabras clave y leer los fragmentos de texto relacionados. Para facilitar este rastreado, se recomienda:
- Estructurar los contenidos en dos (o tres) niveles de titular (encabezado y subencabezados). Los encabezados deben ser significativos.
- Utilizar listas con viñetas para enumerar elementos en lugar de incluirlos en bloques de texto uniformes.
- Incluir negritas para destacar las palabras claves; también puede utilizarse texto coloreado, aunque en este caso el color elegido debe ser distinto al de los vínculos para no confundir al usuario.
Lenguaje estructurado. Las páginas deben organizarse en pirámide: lo más importante debe encontrarse al principio, de manera que el usuario no se vea forzado a leer toda la página para encontrar la conclusión. Puesto que muchos lectores sólo leen la primera frase de cada párrafo, es importante aplicar la regla de "una idea, un párrafo". Las frases deben ser sencillas.
Fragmentación. Aunque el texto deba ser conciso, el contenido puede mantener profundidad y dividir la información en nodos interconectados. Pueden incluirse páginas secundarias con contenido extenso y detallado de manera que los usuarios que deseen profundizar en los contenidos puedan acceder voluntariamente a ellas. Es recomendable no fragmentar excesivamente el texto, ya que supone que el usuario debe navegar entre múltiples páginas, lo que aumenta las posibilidades de que se desoriente.
Títulos de página. Los títulos de página suelen utilizarse como referencia principal y son los que quedan almacenados si la página se incluye en la lista de favoritos. Deben ser explicativos y breves (se recomienda un máximo de seis palabras). Cada página debería presentar un título distinto para ser válido como referencia.
Legibilidad. Además de confeccionar correctamente los contenidos, el diseñador debe asegurarse de que el texto es siempre legible. Los factores que favorecen la legibilidad son:
- El contraste entre el texto y el fondo. La legibilidad máxima se obtiene con un texto negro sobre fondo blanco, aunque la opción inversa es también correcta.
- Los fondos deben ser de colores claros y, si contienen gráficos o imágenes, éstos deben ser muy sutiles.
- La tipografía debe presentar un tamaño relativamente grande (a partir de 11 puntos) para que sea legible incluso para personas con dificultades de visión.
- A tamaño pequeño, se recomienda utilizar una tipografía de palo seco; a menos de 11 puntos, el texto no debe suavizarse (debe aparecer pixelado).
- El texto debería aparecer estático; las animaciones dificultan mucho la lectura.
- Para bloques de texto extensos, es recomendable utilizar la alineación a la izquierda.

3.Prototipo

El prototipo es un elemento clave en el proceso de diseño, puesto que permite detectar en un primer estadio aquellas cuestiones que deben ser revisadas o corregidas y revela si es necesario añadir algún elemento que no se ha tenido en cuenta con anterioridad.

3.1.Clasificación de los prototipos

Los prototipos suelen ser de baja fidelidad o de alta fidelidad:

De baja fidelidad

Se realiza en un primer estadio.
Dista del diseño final.
Puede realizarse sobre papel o en ordenador y esquematiza una propuesta de estructura de pantalla.
Permite realizar los primeros tests de usabilidad.

En el entorno de arquitectura de la información, se trabaja con wireframes, prototipos de baja fidelidad que permiten organizar los elementos de la pantalla y evaluar cuál es la mejor solución posible.

De alta fidelidad

Se realiza por ordenador y representa un aspecto muy similar al del diseño final.

Prototipos de baja fidelidad (izquierda) y de alta fidelidad (derecha).
Fuente: https://www.guuui.com/issues/03_05.php

3.2.Fases del prototipado

Prototipo gráfico u horizontal

Consiste en la preparación gráfica, en alta fidelidad, de las pantallas clave.

En una aplicación normal suele corresponder al menú principal, a varias pantallas de contenido (se eligen las más significativas como exposición de todas las posibilidades) y al tratamiento de otras pantallas que puedan existir, según el caso, como el índice o la ayuda.

En una web, se acostumbra a preparar la home (página de inicio), el menú principal (si es distinto a la home) y las pantallas interiores más representativas.

Las opciones suelen representarse tanto en estado normal como en rollover (aspecto de la opción cuando el usuario pasa el cursor por encima).

De esta manera, se obtienen una serie de gráficos que permiten ver si la distribución de los elementos es correcta y si puede responder realmente a los contenidos previstos. Un prototipo gráfico no implica todavía la integración mediante un sistema de autor o la preparación del código HTML (o el sistema que se vaya a utilizar en el caso de una web).

El prototipo gráfico es un elemento primordial en la evaluación del diseño, en varios aspectos:

El equipo de producción puede comprobar si la propuesta se adapta realmente a las necesidades del sistema y a la capacidad de los recursos disponibles.
Permite realizar evaluaciones de usabilidad para corregir problemas antes de pasar a niveles avanzados de desarrollo.

Prototipo funcional o vertical

Supone la preparación de una versión temprana y reducida de la aplicación en la que se desarrollan los caminos más significativos. El usuario tiene la capacidad de navegar por el sistema mediante las mismas opciones que contendrá la aplicación final, aunque no puede acceder realmente a todos los contenidos.

Es importante saber elegir correctamente qué opciones necesitan ser desarrolladas en este prototipo, puesto que es un medio fundamental para la detección de errores en el diseño funcional.

El prototipo vertical, al igual que el horizontal, permite realizar evaluaciones de usabilidad para detectar posibles problemas. Las modificaciones que surjan a partir de los prototipos pueden suponer un retorno al estadio de análisis de la aplicación. Puesto que el desarrollo se encuentra en un estadio temprano, es importante realizar una evaluación exhaustiva de los aspectos de diseño, ya que las correcciones efectuadas en estadios posteriores suelen resultar problemáticas y llegan a desajustar todas las previsiones de producción.

Asimismo, el prototipo funcional se presenta al cliente, que tiene una primera muestra de lo que va a ser la aplicación, mediante la que puede aportar sugerencias o realizar correcciones que en esta fase del proyecto son fácilmente realizables.

El tiempo dedicado a la preparación del prototipo y a su evaluación y rediseño debe estar claramente especificado en los calendarios de producción, puesto que no debería extenderse excesivamente, con lo que se reduciría el tiempo reservado al desarrollo posterior de la aplicación.

4.Evaluación de la usabilidad

La evaluación de la usabilidad es la fase más importante del proceso de diseño centrado en el usuario. Puede llevarse a cabo en varias etapas, tanto durante como después del proceso de diseño y desarrollo.

Existen distintos métodos de evaluación de la usabilidad y pueden clasificarse en dos grandes grupos: los que recogen datos de los usuarios reales y los que pueden llevarse a cabo sin los usuarios reales.

La elección de un método u otro depende básicamente de tres factores: el presupuesto reservado a la evaluación, la adecuación al tipo de proyecto y las limitaciones de calendario.

4.1.Los métodos de evaluación de la usabilidad

Los principales métodos son los que se describen en los aparatados siguientes.

Paseo cognitivo (cognitive walkthrough)

Puede ser realizado en cualquier fase del diseño utilizando un prototipo, un borrador o el producto final.

Teniendo en cuenta los objetivos de los usuarios, los evaluadores reúnen un grupo de tareas significativas y las descomponen en los pasos necesarios para realizarlas. A continuación se ejecuta cada tarea, analizando si puede resultar difícil para el usuario identificar y utilizar el elemento de la interfaz más adecuado para su objetivo y si la respuesta que devuelve el sistema es lo suficientemente clara.

El paseo cognitivo tiene en cuenta los factores que intervienen en el proceso mental de toma de decisiones por parte del usuario, así como la memoria de trabajo y la habilidad para razonar.

Este método es muy adecuado para comprobar la usabilidad de un sistema orientado a usuarios con poca o ninguna experiencia, que operan de modo exploratorio para aprender a utilizar la aplicación.

Análisis de tareas

Este método evalúa cómo las personas consiguen sus objetivos mediante el software.

Mediante la observación y entrevistas con los usuarios, un analista determina el conjunto de objetivos de los usuarios previstos. A continuación se definen las tareas que permiten conseguirlos y se ordenan de acuerdo con la importancia del objetivo y la frecuencia de ejecución de la tarea.

Las tareas prioritarias se descomponen en pasos individuales. El nivel de descomposición puede variar dependiendo del sistema evaluado. A continuación, el análisis sugiere cómo puede realizarse la tarea más con más eficacia o propone nuevas tareas que puedan alcanzar más efectivamente los objetivos.

El análisis se realiza siempre desde la perspectiva del usuario final.

Grupos focales (focus groups)

Este método es muy adecuado para obtener opiniones de los usuarios y comprobar las reacciones iniciales a un diseño; también resulta muy eficiente para detectar en qué medida el diseño difiere de las expectativas de los usuarios.

Es un método de bajo coste; aunque la dirección de un grupo focal puede ser complicada, permite sacar a la luz cuestiones excepcionales, que en un análisis de tareas no serían descubiertas. Para contrastar resultados, se recomienda evaluar al menos dos grupos por proyecto.

El director del focus group redacta los comentarios e impresiones de los grupos y sugiere las cuestiones que se deben mejorar.

GOMS

Se trata de un conjunto de técnicas definidas por Card, Moran y Newell en 1983 para modelar y describir el proceso humano de ejecución de tareas. El acrónimo GOMS se refiere a:

Objetivos (goals) que el usuario intenta conseguir, especificados jerárquicamente.
Operadores (operators) o microoperaciones que el usuario lleva a cabo para obtener su objetivo.
Métodos (methods) o secuencias de operadores agrupadas para conseguir un objetivo determinado.
Reglas de selección (selection), que se utilizan para decidir qué método se utilizará para resolver un objetivo, cuando existen varias posibilidades.

Inspección de la usabilidad

Las inspecciones son siempre llevadas a cabo por expertos en usabilidad a partir de una serie de premisas o guías que derivan de estudios en interacción hombre-ordenador, ergonomía, diseño gráfico, diseño de información y psicología cognitiva.

Los expertos se centran especialmente en las áreas que puedan resultar problemáticas para los usuarios. El método de inspección más utilizado en la evaluación de sistemas interactivos es el de la evaluación heurística.

Test con usuarios

Éste es el método más utilizado cuando se quieren conocer los problemas de usabilidad con los que puede encontrarse el usuario final. Se basa en la observación de los usuarios mientras ejecutan unas tareas representativas. La repetición del test con varios usuarios permite descubrir qué aspectos del diseño necesitan mejorarse.

4.2.Paseo cognitivo (cognitive walkthrough)

El paseo cognitivo es un método de bajo coste que permite validar el diseño desde sus primeras fases de desarrollo y evaluar los aspectos generales de la navegación. Puede llevarse a cabo sobre los primeros esbozos en papel.

Preparación

Basándose en los scenarios definidos en el proceso de diseño, se describe un conjunto de tareas representativas. Es importante que en ellas intervenga el mayor número de elementos de la interfaz, especialmente aquellos que se sospecha que pueden resultar problemáticos.

Las tareas deben describirse en un lenguaje sencillo y directo, sin hacer referencia a ningún aspecto de la interacción entre pantallas.

Los participantes deben tener características similares a las de los usuarios finales, aunque pueden incluirse algunos diferentes para obtener distintas perspectivas.

Es importante realizar una sesión piloto para detectar problemas en la descripción de las tareas o de las pantallas o la falta de pasos o de datos.

Desarrollo

Se reparte a cada participante una carpeta o bloc que contiene las tareas que debe realizar y las pantallas de la aplicación (una por hoja). Se le pide que anote en cada hoja qué acciones cree que debería realizar en la pantalla para ejecutar la tarea descrita.

Después de que los participantes hayan revisado individualmente la primera pantalla, se comenta en grupo y se detallan las cuestiones que pueden presentar problemas. El moderador anota o registra los comentarios.

A continuación, el moderador explica qué acción realizaría un usuario hipotético para pasar a la siguiente pantalla, que se comenta de la misma manera. El paseo continúa hasta que se han revisado todas las pantallas.

Al final de la sesión, es recomendable distribuir un cuestionario anónimo para confirmar que los participantes encajan en el perfil demográfico requerido y para obtener comentarios subjetivos.

Duración

Una sesión de paseo cognitivo suele durar aproximadamente dos horas.

Recomendaciones

Los participantes deben tener claro que se está evaluando la interfaz, no sus capacidades.
El moderador debe reunir todos los comentarios realizados y escribir sus observaciones personales tan pronto como sea posible después del paseo.
El comentario en grupo de cada pantalla debe comenzar sólo cuando todos los participantes han terminado de escribir sus anotaciones personales.
Es recomendable que otros miembros del equipo de desarrollo estén presentes en la sesión.
El moderador debe evitar que los participantes cambien de opinión basándose en los comentarios de otros participantes.
Las pantallas deben tener un aspecto representativo pero sencillo para que los participantes no se entretengan en aspectos gráficos.

4.3.Evaluación heurística

La evaluación heurística es un método de inspección, es decir, es realizada por un grupo de expertos en usabilidad, que examinan la interfaz y determinan el grado de cumplimiento de los principios de usabilidad (o heurísticas).

Desarrollo

Durante la sesión, el evaluador recorre la interfaz varias veces, examina los elementos de interacción y los compara con los principios de usabilidad (heurísticas). El evaluador puede añadir principios de usabilidad adicionales u otras cuestiones que sean relevantes para la interfaz evaluada.

Cada evaluador decide por sí mismo cómo quiere evaluar la interfaz, aunque se recomienda que recorra toda la aplicación al menos dos veces (la primera para obtener una visión de conjunto y la segunda para entrar en detalle).

Puesto que los evaluadores no están utilizando la aplicación para realizar una tarea real, la evaluación heurística puede llevarse a cabo en las primeras fases de desarrollo, incluso en el diseño sobre papel.

El resultado de la evaluación heurística debe ser una lista detallada de cada uno de los problemas de usabilidad hallados en la interfaz, con referencias a los principios que no se han respetado en cada caso y a las opiniones del evaluador.

Después de la evaluación, puede realizarse una puesta en común de los resultados en la que participen los evaluadores, los observadores y miembros del equipo de diseño. La reunión puede tener carácter de brainstorming y resulta muy útil para proponer soluciones a los problemas detectados, así como para comentar los aspectos positivos del diseño.

Duración

Una sesión de evaluación heurística suele durar una o dos horas por evaluador. Si la interfaz es muy compleja, puede dividirse en varias sesiones, cada una de ellas dedicada a una parte de la interfaz.

Recomendaciones

La evaluación heurística debería ser realizada por más de un experto, ya que uno solo difícilmente podría encontrar todos los problemas de usabilidad existentes en la interfaz. Según Jakob Nielsen, el número ideal de evaluadores es de tres a cinco, superar este grupo no suele conducir a información adicional.
Cada evaluador examina la interfaz individualmente. Sólo cuando todos los evaluadores hayan expuesto su inspección, podrán comunicarse entre sí para comentar los resultados. Es importante mantener el aislamiento inicial para que los resultados de cada evaluador sean independientes y no sesgados.
Para registrar los resultados de la evaluación, puede pedirse a cada evaluador que escriba un informe o bien pueden grabarse los comentarios del evaluador a medida que examina individualmente la interfaz.
Puede existir un observador que ayude a los inspectores a utilizar la interfaz en caso de problemas; este observador puede encargarse de anotar los comentarios de los evaluadores de manera que éstos no tengan que redactar informes. En todo caso, el observador debe limitarse a registrar los comentarios sin realizar interpretaciones personales.
El observador puede responder a las preguntas de los evaluadores acerca del contexto de utilización de la interfaz; también puede ayudarlos en caso de problemas graves, aunque en tal caso no debe tomar nunca la iniciativa, sino esperar a que el evaluador solicite la ayuda.

Heurísticas

Los diez principios generales de usabilidad son los siguientes:

Visibilidad del estado del sistema. El sistema debe mantener siempre informado al usuario de lo que está ocurriendo y proporcionarle respuesta en un tiempo razonable.
Consistencia entre el sistema y el mundo real. El sistema debe utilizar el lenguaje del usuario, con expresiones que le resulten familiares. La información debe aparecer en un orden lógico.
Control del usuario. El usuario debe disponer de la capacidad de abandonar en cualquier momento una situación indeseada o accidental. Asimismo, debe disponer de la capacidad de deshacer o repetir una acción.
Consistencia y estándares. El lenguaje utilizado debe ser coherente con las convenciones del sistema operativo.
Prevención de errores. Es importante prevenir la existencia de errores. Si, a pesar de todo, deben aparecer mensajes de error, éstos tienen que contener opciones de confirmación antes de ejecutar las acciones de corrección.
Es mejor reconocer que recordar. Para que el usuario no se vea obligado a memorizar continuamente detalles de la navegación, los objetos, acciones y opciones deben estar a la vista. El usuario no tiene que recordar información de una parte de una ventana de diálogo a la siguiente. Las instrucciones de uso o la ayuda del sistema deben estar a la vista o ser fácilmente accesibles.
Flexibilidad y eficiencia de uso. El sistema debe estar preparado para satisfacer tanto a los usuarios novatos como a los experimentados. Para éstos, resulta muy recomendable incorporar atajos de teclado, que permiten acelerar el proceso de interacción. Los usuarios deben poder configurar sus propios atajos de teclado para acciones frecuentes.
Diseño práctico y sencillo. Las pantallas o páginas no deben contener información innecesaria o irrelevante, ya que distrae al usuario y entorpece la navegación. Si aun así es necesario incluir información auxiliar, ésta puede colocarse en páginas distintas, accesibles a través de enlaces.
El usuario debe disponer de ayuda para reconocer, diagnosticar y deshacer errores. Los mensajes de error deben presentarse con un lenguaje sencillo, indicando el problema de manera precisa, y sugerir las posibles soluciones.
Ayuda y documentación. Aunque es mucho mejor que el usuario pueda navegar sin ayuda, la complejidad de un sistema puede recomendar incluir documentación de ayuda. Esta documentación debe ser fácil de encontrar, centrarse en la tarea del usuario, enumerar claramente los pasos que deben llevarse a cabo y no ser extensa.

4.4.Test con usuarios

Este método se basa en la observación y el análisis de las acciones de un grupo de usuarios y permite anotar los problemas que se presenten para poder resolverlos posteriormente. Es útil para garantizar que el sistema pueda llevar a cabo las tareas previstas de manera eficiente y satisfactoria.

Este método puede llevarse a cabo en las primeras etapas de diseño de la aplicación, incluso sobre los prototipos. En todo caso, siempre debería realizarse después de una evaluación heurística, que puede detectar los primeros problemas de usabilidad.

Preparación

La evaluación debe llevarse a cabo en un local o laboratorio en el que exista un ordenador para realizar la prueba y en el que no haya interferencias externas o ruidos imprevistos.

Debe contarse con al menos cinco participantes; pueden ser amigos o compañeros de trabajo, entre otros, aunque es preferible que tengan un perfil similar al del usuario focal de la aplicación. Cada participante realiza la prueba por separado, acompañado por un observador.

El observador debe disponer de un bloc para anotar las observaciones. Asimismo, pueden asistir como observadores otros miembros del equipo de desarrollo, aunque es recomendable que permanezcan en una habitación distinta.

El evaluador debe estar atento no sólo a lo que el usuario dice, sino también a sus expresiones y gestos. Para ello resulta muy útil contar con una cámara que registre la sesión, previo consentimiento del usuario.

El observador dirige la prueba mediante un guión que especifica qué tareas debe llevar a cabo el participante; deben seleccionarse tareas derivadas de los scenarios definidos en la etapa de diseño y priorizar las que sean susceptibles de ocasionar problemas de usabilidad. No es imprescindible seguir estrictamente el guión establecido, ya que puede utilizarse solamente como medio de orientación.

Desarrollo

El evaluador ejecuta la aplicación. La primera información que va a obtener es el grado de entendimiento, de manera que en una primera fase se pide al usuario que, sin hacer todavía nada, observe lo que ve y explique cuál cree que es el contenido y el objetivo de la aplicación y que exprese sus opiniones personales, aunque las opiniones acerca de cuestiones estéticas son poco relevantes.

A continuación, se analiza la facilidad de uso de la aplicación. Para ello, se le comenta al usuario cuántas tareas va a tener que realizar y se le describe la primera (por ejemplo, "debería obtener información sobre el curso de diseño html, ¿cómo lo haría?"). Se le pide que piense siempre en voz alta.

Cuando el usuario finaliza una tarea se le describe la siguiente, hasta realizarlas todas. Si el usuario no consigue realizar una, se le debe dejar claro que el problema está en el diseño, no en sus acciones, y se pasa a la siguiente.

Es aconsejable anotar el tiempo que el usuario invierte en la realización de cada tarea.

Al final del test, puede solicitarse al usuario que rellene un formulario con datos estadísticos (el cuestionario es anónimo, no incluye el nombre del participante) sobre edad, profesión, nivel académico y frecuencia de uso de internet.

Además, el cuestionario puede contener preguntas concretas acerca del diseño, valoradas en una escala del uno (completamente de acuerdo) al cinco (completamente en desacuerdo).

Ejemplo de preguntas concretas acerca del diseño

El producto es fácil de utilizar.
Siempre sé que estoy dentro de la aplicación.
Es fácil perderse.
Es difícil aprender a utilizarla.
No tengo suficiente formación para utilizarla.
La ayuda es útil.

Finalmente, el evaluador debe redactar un informe con todo lo que se haya anotado durante las pruebas. Este informe debe indicar qué problemas de usabilidad se han encontrado.

Recomendaciones

Antes de empezar, es importante establecer un ambiente amigable con el participante, que seguramente estará inquieto. Para ello:

Se explicarán claramente los objetivos de la prueba. El participante debe tener muy claro que no se están evaluando sus capacidades, sino la aplicación; si existe algún problema durante la prueba, no será por su culpa sino por culpa del diseño.
En ningún caso deben explicarse las características de la aplicación, ya que uno de los objetivos del test es comprobar si el diseño es eficaz y fácil de comprender.
Se indica al usuario que su nombre no figurará en el registro del test, es decir, que es anónimo.
El local en el que se realiza la prueba debe ser tranquilo, sin ruidos que puedan distraer al participante.
No deben comentarse aspectos personales del participante; todos los comentarios deberían referirse a la aplicación.
Se debe motivar al usuario para que exprese en voz alta cualquier pensamiento, opinión o problema.
El observador no ayuda al usuario a solucionar problemas de uso de la interfaz; su función es simplemente la de observador silencioso.

Índice

Enlaces de interés