User-centered design

The methodology of the user centered design (DCU) places the person at the heart of the process of interface design. Pays special attention to the cognitive aspects that intervene in the interaction between people and things, way that allows optimizing the usability of any object with which people interact daily.

The DCU involves the user from the first steps of the development of a interactive application and is developed over several stages, some of which which are iterative.

Etapas de desarrollo de una aplicación interactiva

Development stages of an interactive application

Index

Design user-centered

1.Analysis

As described so far, this stage consists of the information collection about the characteristics of potential users, the objectives of the application and the technical requirements of the development. Recapitulating previous concepts and placing ourselves in the skin of the designer, the main questions to which he must answer In this phase they are the following:

1.1.To what kind of user is directed? What are your needs?

The type of user determines the design in the following aspects:

Diffusion scope. It may be a general diffusion product (users with a range of interests very variable and with different levels of knowledge of the computing environment) or a system aimed at a highly specialized audience (user with a recognized profile, with a determinable level of knowledge of the tool). The intermediate possibilities They are infinite and variable in each case.
User age. The target audience can be children, youth, adults or universal. If the system can be used by very elderly people, it is important to prioritize accessibility factors. In order to define as accurately as possible characteristics of the user, inquiry methods are usually used, which allow know the potential audience in depth to adapt the design and orient it to the maximum user satisfaction.
User needs. Once the recipient of the application, the designer must consider the exercise of getting a clear picture of your needs. To do this you must decide how to collect and display that information, what methods and procedures to use, as well such as what time and resources to have for this task.

1.2.What is the app content?

It refers to the type and extent of the content of the application. The content type determines the gender, since it can correspond, for For example, to a system of training, a game, an encyclopedia, a promotional product or a presentation of a company, although the genres often appear mixed. Regarding to the content extension, the volume can determine the need to use more or less sophisticated resources of user motivation, as well as the organization of the content.

1.3.What is the application support?

Are we preparing an application that will be distributed in CD-ROM, it is a website or will it be at a fixed information point? Depending on the answer to this question, The design must be different.

Let us think, for example, of the problems with which, even Today, there are many users in the process of downloading information from the Internet. If the website is intended to the general public must necessarily be lighter than if it is addressed to a group of limited and definable users, who are known to have better resources technicians.

At an information point, on the other hand, no The mouse is often used as a tool of access to the data, but there are other systems. The most widespread is the screen touch, in which navigation options are controlled by presses of fingers that are not as precise as the mouse pointer; Thus, the size of the Active zones must be in relation to the characteristics of the input device.

1.4.what What determinants do the other members of the production team contribute?

The designer must take into account the determinants defined by the following:

The team in charge of the production management, which establishes the conditions related to economic resources, development time and human and technical equipment available.
Programmers and technicians, to know the limits and capabilities of the programming tool as well as of application support.
The documentation team and scriptwriters, who prepare the content and They structure it according to the characteristics of the final product.

1.5.What are the requirements defined by the client?

The customer usually plays an important role in the application design approach, although their degree of involvement can vary greatly from one case to another. In addition to others issues, the dialogue with the client can refer to aspects related to:

User type of the application. Who do you want to address?
Objective. What do you want to achieve with the product?
Style. The client usually has a defined idea of the image they want show. In case Whether it is an organization or a large company, there may be requirements image that must be respected.

1.6.What are the human resources available?

The human team available for the design of a application determines the conditions design in two aspects:

Number of people available.
Degree of specialization. It is possible that within the team there are very specialized people (such as photographers or graphic designers) as well as people with a low level of specialization (dedicated to editing tasks such as graphics cropping, image retouching or integration).

1.7.What is the product lifespan?

A multimedia application can have a lifespan short (for example, if it works to promote a product that is being launched) or long (for example, an encyclopedia). In general, a long life span usually implies more conservative treatment of the interface (which must remain visually valid over time), while a short lifespan may allow for a more visually appealing approach. risky and subject to fashions or stylistic currents.

1.8.Should they update the contents?

The content of a multimedia application may have to update with certain periodicity. It is important to know two fundamental factors:

Periodicity of the updates. The design of the application must be flexible enough to allow necessary updates. Analysis of needs implicit in the update leads to the definition of standard solutions that can respond to all the foreseen possibilities. This analysis is all the more necessary the higher the refresh rate.
Who is going to make the updates? In some cases, the updating of the contents is carried out by the same team that has carried out the production. In others, it is left in the hands of the client or a team external dedicated to this task; In such case, the number and degree of specialization of The people in charge of carrying out this task can determine the characteristics of the design.

2.Design

The design of the application, both functional and graphic, must respond to the characteristics defined in the analysis process. As specified before, the design is reviewable according to the results of the subsequent evaluation.

The design stage consists of different phases.

2.1.Modeling of user

In this phase, information about users is collected potentials obtained in the analysis stage and user profiles are defined taking into account attributes common such as information needs, experience and knowledge or conditions of access to the application. In this way, the designer can work for an audience with defined characteristics, which will allow it to adapt to specific objectives and optimize the degree of user satisfaction.

People

If the intended audience is very heterogeneous, you can be very complex to define the behavior patterns, objectives and needs. In these cases, we usually work with some archetypes called people (concept popularized by Alan Cooper), which are described narratively and to whom a specific identity is attributed (with name and photograph, among others). The objective of the use of people consists of the designer having in mind a real user, with some characteristics certain.

All the features of the person they must be consistent with the information obtained about the audience in the phase of analysis. Different types of people:

Focal. It is the main type of user we target and in any design process there should be at least one person focal. If there are more than three people focal points, then it is advisable to divide the interface by defining different profiles user (for example, administrator and user).
Secondary. Secondary users also use the product and must use it satisfactorily although, in the event of a conflict of interest, the user's needs will be prioritized focal.
Not priority. Infrequent, unauthorized or unregistered users priority.
Involved. You do not use the product, but it may be affected by results.

For example, people who live in a residence may be involved in the result of an online purchase operation.

Excluded. User for whom it is not being designed.
Promoters. They can be generated mini people that correspond to the interests of the project promoters (as client, investors or advertisers) to ensure that your requirements will be taken into account.

The description of a person should include the following details:

Geographic profile. Place of residence and work, as well as the level of life.
Demographic profile. Includes, for example, age, sex, family, income, occupation or education.
Psychosocial profile. Social class, lifestyle, hobbies and characteristics personal.
Relationship between person and the product. The person, is it a customer, an employee or a partner? A distinction can be made between the development of an intranet or an extranet or in the definition of different user profiles.
What is the level of relationship between the person and the application? can whether it is an occasional user or a frequent user. The designer must define what type of relationship he expects the person keep with him product.
What percentage of total usage does the person? In economics there is a rule according to which generally 20% of customers one company represents 80% of sales; It is important to know what percentage of application usage represents the person.

Scenarios

In order to contextualize the interaction process between the person and the application, can be defined scenarios. These describe cases specific conditions of use, taking into account the tasks that the system must perform and the context in which the person will use the application. All details must be consistent with the information obtained in the analysis phase.

The description of the scenario must be done using narrative and direct language; references are avoided direct to technology, except in cases where it imposes some restriction significant to the design. It must include details regarding:

Context of use. On the part of the user, is there any preparation previous to use the application? The safest rule is to think that the majority of users does not exceed the level of inexperienced.
Detailed conditions of the context of use. When and where does it lead out the user a task? With who? What is the environmental context? (like time of day or environmental conditions). Are there limitations on access equipment? Does it exist need for confidentiality? Are there security risks? Does the user have of some kind of help? Are there legal restrictions?
Development of interaction. How often is the interaction? Is it done regularly? Is the interaction continuous or interrupted? Is the process of interaction so intense that it requires the full attention of the person? to what speed must person interact? What level of complexity are the actions? Who conducts the interaction: the people or external agents?
Information involved. This is the theme developed in the application, the volume and complexity of the information and the level of information detail required.
emotional characteristics. Style and emotional state of the person. What things do you find attractive? What type of experience do you expect from the interaction? Do you want to live an adventure, do you prefer to feel freedom, security, sensuality, confidence or power?

Name: Eva

Age: 45 years

Profession: nurse

Description of the person:

Eva is married and has three children, ages 9, 11 and 20. years. Lives in a town of 50,000 inhabitants near Madrid. Every day he travels to the city to work as nurse during a six-hour day and in the hospital regularly uses the computer to manage patient data.

At home you have ADSL internet access, although it does not usually connect often. Those who use the computer at home most frequently are her husband and her eldest son. She prefers to read or play sports, although she has very little free time.

Every fifteen days you make the purchase in a supermarket online. You always buy in the same supermarket because it is the one that gives you greater feeling of security and trust, although the product selection and purchasing process It seems pretty slow.

Description of the scenario:

It's a Friday at 8:15 p.m. and, after a work week, Eva doesn't have many I want to get in front of the computer. Today it's your turn to make your purchase online. You don't have much time because you have to prepare dinner; In addition, you must monitor the same time to the children.

Access the supermarket online, if identifies and directly consults the list stored as a model. This list is very useful to speed up the purchasing process because it only has to add or delete products, if necessary. Then confirm the order and enter credit card details; this is the moment when Eva prefers that the transaction be carried out as quickly as possible because she has a relative confidence in internet security systems.

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: Adobe: low-fidelity vs. high-fidelity prototypes

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.

Enlaces de interés

Te recomentamos que visites los siguientes artículos: