Usable y accesible

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

2012-03-15T15:01:00.167+01:00

Novedad 19/3/2012

Descarga de excel para ayudar en una evaluación de usabilidad según WUEP (Web Usability Evaluation Process), proceso explicado en el artículo y que se basa en la ISO 25000 (SQUARE).

Ver WUEP (Web Usability Evaluation Process)

26/03/2012: ampliado el contenido sobre la ISO 9241-151

Índice

Qué es un estándar
Tipos de estándares
Estándares formales de usabilidad
Aplicación práctica de los estándares formales en la evaluación heurística de una web
Qué es un estándar
“Estándar” es definido por la ISO (Organización Internacional de Estandarización) como:
documento establecido por consenso y aprobado por una institución reconocida, que prevé, para uso común y repetido, reglas, directrices y características para actividades o sus resultados, encaminada a la consecución del grado óptimo de definición en un contexto dado. Nota: las normas deben basarse en los resultados consolidados de la ciencia, la tecnología y la experiencia, y tener por finalidad promover beneficios óptimos.
[ISO/IEC Guide 2:2004, definición 3.2]
Tipos de estándares
Existen tres tipos de estándares:
- los oficiales o “de jure”. Los estándares oficiales son aquellos que han sido aprobados y sancionados por un organismo oficial de estandarización.
  Como organismos oficiales de estandarización podemos destacar:
  - En España, el organismo nacional de normalización es AENOR (Asociación Española de Normalización y Certificación) que elabora normas técnicas españolas (UNE)
  - A nivel europeo está el Comité Europeo de Normalización (CEN)
  - A nivel internacional la Organización Internacional de Estandarización (ISO) compuesta por representantes de los organismos de normalización (ON's) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO
  Los estándares oficiales son a veces de obligado cumplimiento. De hecho en España no se puede hacer referencia en la legislación a estándares que no provengan de un organismo oficial de estandarización. Por ejemplo en España es obligatorio por ley que determinados tipos de sitios web cumplan con la Norma UNE 139803 que asegure su accesibilidad.
- los “de facto”. Son aquellos que son promulgados por comités guiados por una entidad, organismo o compañía, se usan por voluntad propia o conveniencia y tienen una amplia aceptación, aunque no hayan sido sancionados por un organismo de estandarización.
  El caso más claro es el W3C (World Wide Web Consortium) que crea estándares ampliamente aceptados y que a veces pasan a ser reconocidos como estándares oficiales (por ejemplo la Norma UNE 139803 se basa en las WCAG del W3C; y hay muchos países que en su legislación establecen que los sitios web cumplan con las WCAG)
- Estándares propietarios de una corporación o entidad.
En el caso de la accesibilidad web son muy conocidos los estándares existentes, posiblemente porque son de obligado cumplimiento en muchos países.
Sin embargo los estándares de usabilidad no son tan conocidos. En el siguiente apartado se explica de manera sencilla y comprensible cuáles son los estándares oficiales de usabilidad. En el último apartado se abordará cómo se pueden aplicar en la práctica dichos estándares para realizar evaluaciones heurísticas de usabilidad.
Estándares formales de usabilidad
Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction
Está compuesta por 17 partes. La 1 y 2 es una introducción y guías para el empleo del estándar. De la 3 a la 9 tratan los requisitos y guías relacionadas con el hardware que impactan en el funcionamiento del software. De la 10 a la 11 se centran en los aspectos del software.
En realidad la norma se llamaba Ergonomic requirements for office work with visual display terminals (VDTs) pero en 2006 se le simplificó el nombre; y además se renumeraron sus partes para poder cubrir más temas como la interacción táctil (ISO 9241-920:2009) , la interacción con formularios (ISO 9241-143:2012) o interfaces web (ISO 9241-151:2008)
La ISO 9241-11:1998 “Guidance on usability”, define la usabilidad como:
La medida con la que un producto se puede usar por usuarios determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso concreto.
Por tanto, los tres factores, los tres atributos de calidad son:
- Efectividad: exactitud e integridad con la que los usuarios alcanzan los objetivos especificados, y por tanto implica la facilidad de aprendizaje, la ausencia de errores del sistema o la facilidad del mismo para ser recordado. Las métricas definidas son:
  - Número de tareas importantes realizadas
  - Porcentaje de funciones relevantes utilizadas
  - Porcentaje de tareas completadas con éxito al primer intento
  - Número de referencias a la documentación
  - Número de llamadas para soporte
  - Número de accesos a la ayuda
  - Número de funciones aprendidas
  - Porcentaje de usuarios capaces de aprender sus características
  - Porcentaje de errores corregidos o reportados por el sistema
  - Número de errores de los usuarios tolerados
  - Porcentaje de palabras leídas correctamente a una distancia de visualización normal
- Eficiencia: recursos empleados (esfuerzo, tiempo, etc.) en relación con la exactitud e integridad con la que los usuarios alcanzan los objetivos especificados. Las métricas definidas son:
  - Eficiencia relativa en comparación con un usuario experto
  - Tiempo empleado en el primer intento
  - Eficiencia relativa en el primer intento
  - Tiempo empleado en reaprender funciones
  - Número de errores persistentes
  - Tiempo productivo
  - Tiempo para aprender características
  - Tiempo para reaprender características
  - Eficiencia relativa durante el aprendizaje
  - Tiempo empleado en la corrección de errores
- Satisfacción: un factor subjetivo que implica una actitud positiva en el uso del producto. Las métricas definidas son:
  - Calificación (por parte del usuario) de su satisfacción con las características importantes
  - Tasa de uso voluntario del producto
  - Frecuencia de reutilización del producto
  - Calificación (por parte del usuario) de la facilidad de aprendizaje
  - Calificación (por parte del usuario) del tratamiento de errores
La ISO 9241‐11 recomienda un enfoque basado en procesos para evaluar la usabilidad, a través del Diseño Centrado en el Usuario (DCU). Por ello la ISO 9241 debe aplicarse en conjunto con la ISO 13407.

La ISO 9241-151:2008 “Guidance on World Wide Web user interfaces” referencia a la 9241-11 para la evaluación de criterios y a la ISO 13407 como guía de Diseño Centrado en el Usuario, puesto que señala que el diseño de interfaces web debe seguir un proceso de DCU.
Se pueden consultar comparativas de la 9241-151 con HHS Guidelines [USABILITY.GOB] en [BEVAN, 2005] y actualizado en [BEVAN, 2007]
Dentro de la ISO 9241-151 podemos destacar las siguientes directrices (viene cada una explicada y con ejemplos, y se puede encontrar una checklist para la evaluación al final del documento de la ISO):
- 6. High-level design decisions and design strategy (11 directrices evaluables)
- 7. Content design
  - 7.1 Conceptual content model (5 directrices evaluables)
  - 7.2 Content objects and functionality (19 directrices evaluables, 5 de las cuales referentes al 7.2.8 Privacy and business policies; y 7 al punto 7.2.9 Indivudualisation and user adaptation)
- 8. Navigation and search
  - 8.1 General
  - 8.2 General guidance on navigation (5 directrices evaluables)
  - 8.3 Navigation structure (11 directrices evaluables, varias de ellas relativas a Splash screens)
  - 8.4 Navigation components (16 directrices evaluables)
  - 8.5 Search (22 directrices evaluables)
- 9. Content presentation
  - 9.1 General
  - 9.2 Observing principles of human perception (1 directrices evaluables)
  - 9.3 Page design issues functions (17 directrices evaluables)
  - 9.4 Link design (15 directrices evaluables)
  - 9.5 Interaction objects (3 directrices evaluables)
  - 9.6 Text design (6 directrices evaluables)
- 10. General design aspects
  - 10.1 Designing for cultural diversity and multilingual use (5 directrices evaluables)
  - 10.2 Providing help (1 directrices evaluable)
  - 10.3 Making Web user interfaces error-tolerant(2 directrices evaluables)
  - 10.4 URL names (1 directrices evaluable)
  - 10.5 Acceptable download times (1 directrices evaluable)
  - 10.6 Using generally accepted technologies and standards(1 directrices evaluable)
  - 10.7 Supporting common technologies(1 directrices evaluable)
  - 10.8 Making Web user interfaces robust(1 directrices evaluable)
  - 10.9 Designing for input device independence(1 directrices evaluable)
  - 10.10 Making the user interface of embedded objects usable and accessible
ISO 13407:1999. Human centred design processes for interactive systems
La ISO 13407:1999 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems.
La ISO 13407 proporciona una guía para alcanzar la calidad en el uso mediante la incorporación de actividades de naturaleza iterativa involucradas en el Diseño Centrado en el Usuario (DCU).
El Diseño Centrado en el Usuario (DCU) lo describe como una actividad multidisciplinar, que incluye factores humanos y conocimientos y técnicas de ergonomía con el objetico de mejorar la efectividad y eficiencia, las condiciones de trabajo y contrarrestar los posibles efectos adversos de su uso.
Describe los cuatro principios del Diseño Centrado en el Usuario:
- Involucrar activamente a los usuarios
- Asignación adecuada de funciones al sistema y el usuario
- Soluciones de diseño iterativas
- Diseño multidisciplinar
Y las cuatro actividades del Diseño Centrado en el Usuario:
- Entender y especificar el contexto de uso
- Especificar los requisitos del usuario y de la organización
- Producir más de una solución de diseño candidata
- Contrastar los diseños con los requisitos
Figura 1. Imagen tomada de [MONTERO, 2008, pág.6]
Como he dicho, la ISO 13407 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems que describe seis principios clave que caracterizan al Diseño Centrado en el Usuario [TRAVIS, 2011]:
- El diseño está basado en una comprensión explícita de usuarios, tareas y entornos.
- Los usuarios están involucrados durante el diseño y el desarrollo.
- El diseño está dirigido y refinado por evaluaciones centradas en usuarios.
- El proceso es iterativo.
- El diseño está dirigido a toda la experiencia del usuario.
- El equipo de diseño incluye habilidades y perspectivas multidisciplinares
Orientados al producto: ISO 9126 e ISO 14598
ISO 9126 Software engineering — Product quality
Es un estándar para evaluar la calidad del software. Esta dividida en cuatro partes:
- ISO/IEC 9126‐1: 2001 : presenta el modelo de calidad que clasifica la calidad del software en un conjunto estructurado de características: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
  Define la usabilidad como la capacidad que tiene un producto software para ser entendido, aprendido, operable, atractivo para el usuario y conforme a estándares/guías, cuando es utilizado bajo unas condiciones específicas.
  Por ello la usabilidad se divide en las siguientes subcaracterísticas:
  - Fácil de aprender: capacidad para ser aprendido en su manejo
  - Fácil de entender: capacidad del producto de ser entendido por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
  - Fácil de operar: capacidad del producto de ser operado y controlado en cualquier momento.
  - Atractivo: capacidad del producto de ser atractivo para sus usuarios.
  - Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
  Figura 2. Modelo de calidad ISO/IEC 9126-1
- ISO/IEC 9126‐2:2003 : describe las métricas externas que se pueden utilizar para evaluar el comportamiento del software cuando es operado por el usuario.
- ISO/IEC 9126‐3:2003 : describe las métricas internas que se pueden utilizar para describir propiedades estáticas de la interfaz, que puede ser evaluadas por la inspección sin poner en funcionamiento el software.
- ISO/IEC 9126‐4:2004 : describe las métricas de calidad que se pueden utilizar para evaluar el efecto del producto software cuando son operados por el usuario en determinados contextos de uso. Las métricas definidas son:
  - Efectividad (el método de aplicación definido para las tres es el test con usuarios)
    - Efectividad de las tareas: ¿qué proporción de objetivos de las tareas son logrados correctamente?
    - Tareas completadas, ¿qué proporción de tareas son completadas?
    - Frecuencia de los errores
  - Productividad (el método de aplicación definido para todas es el test con usuarios)
    - Tiempo de las tareas, ¿cuánto tiempo lleva completar una tarea?
    - Efectividad de las tareas, ¿cuán eficientes son los usuarios?
    - Productividad económica, ¿cómo de rentable es el usuario?
    - Porcentaje de producción, ¿qué proporción de tiempo dedica el usuario a acciones productivas?
    - Eficiencia relativa de los usuarios, ¿cómo de eficiente es el usuario comparado con un experto?
  - Seguridad (el método de aplicación definido para todos es el uso de estadísticas)
    - Salud y seguridad del usuario, ¿cuál es la frecuencia de problemas de salud entre usuarios del producto?
    - Seguridad de las personas afectadas por el uso del sistema, ¿cuál es la frecuencia de peligro para las personas afectadas por el uso del sistema?
    - Daños ergonómicos, ¿cuál es la frecuencia de daños ergonómicos?
    - Daños del software, ¿cuál es la frecuencia de la corrupción del software?
  - Satisfacción
    - Escala de satisfacción, ¿cómo de satisfecho está el usuario?
    - Cuestionario de satisfacción, ¿cómo de satisfecho esta el usuario con características específicas del software?
    - Uso discrecional, ¿qué proporción de potenciales usuarios eligen el uso del sistema? El método de aplicación definido es la observación del uso.
Puesto que la ISO 9126 se limita a la especificación de un modelo de calidad general, esta se debe aplicar en conjunto con la ISO 14598.
ISO 14598 Information technology — Software product evaluation
La ISO 14598 es un estándar que proporciona un marco de trabajo para evaluar la calidad de todo tipo de producto software e indica los requisitos para los métodos de medición y el proceso de evaluación. Consta de seis partes:
- ISO/IEC 14598‐1: 1999 : provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126
  Figura 3. Imagen de [Férnandez-Martinez, 2009]
- ISO/IEC 14598‐2: 2000 : contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de la evaluación del producto del software.
- ISO/IEC 14598‐3: 2000 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo en paralelo con el desarrollo por parte del desarrollador.
- ISO/IEC 14598‐4:1999 : provee los requisitos y guías para que la evaluación del producto software sea llevada a cabo en función a los compradores que planean adquirir o reutilizar un producto de software existente o predesarrollado.
- ISO/IEC 14598‐5: 1998 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo por evaluadores independientes.
- ISO/IEC 14598‐6:2001 : provee las guías para la documentación del módulo de evaluación.
Ventajas y desventajas de la definición de usabilidad como proceso y como producto
[Férnandez-Martinez, 2009] explica las ventajas y desventajas de la definición de la usabilidad como proceso o como producto vistas en el conjunto de normas anteriores:
Ventajas de la definición usabilidad como proceso:
- Se identifican aspectos de usabilidad y componentes del contexto de uso que deben tenerse en cuenta en las fases de especificación de requisitos, diseño y evaluación de usabilidad.
- El rendimiento y la satisfacción del usuario proporcionan medidas directas de usabilidad en un contexto específico.
- Las medidas obtenidas proporcionan una base para comparar la usabilidad de varios diseños en un mismo contexto.
Desventajas de la definición usabilidad como proceso:
- La usabilidad está estrictamente tratada desde una perspectiva de proceso, no centrada en el producto.
- No tiene en cuenta la característica de “facilidad de aprendizaje”, siendo esta recomendada por otros estándares y expertos en usabilidad.
- No tiene en cuenta aspectos de seguridad, considerados importantes por expertos del dominio.
Las ventajas de la definición de usabilidad como producto:
- Existe un marco claramente definido y acordado en el modelo, que aclara la
- Definición de usabilidad, y propone métricas para proporcionar evidencia objetiva de los logros.
- Se puede utilizar como una referencia para los acuerdos contractuales entre un comprador y un proveedor de software, pudiendo ser utilizados además, para eliminar una serie de malentendidos entre el comprador y el proveedor.
- Se propone un proceso de evaluación que puede ser adaptado a compradores, desarrolladores y evaluadores externos.
Desventajas de la definición de usabilidad como producto:
- El conjunto de métricas se proporciona para sub‐características que a su vez engloban conceptos difícilmente medibles si no se descomponen en atributos
- Existe superposición de conceptos, al definir usabilidad como una característica de calidad interna‐externa, y llamar calidad en uso a otras características también vinculadas a la usabilidad.
- El tener por separado dos normas que se aplican conjuntamente produce inconsistencias en los ciclos de vida de ambas dificultando su uso.
ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598
La ISO 25000:2005 se conoce como SQUARE (Software Quality Requirement Evaluation) y básicamente se trata de una unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598.
Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad.
Figura 4. Imagen de [ISO25000.com]
La norma está formada por las siguientes divisiones [ISO25000.com, b]:
- División de gestión de calidad (ISO/IEC 2500n): los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE.
- División del modelo de calidad (ISO/IEC 25001n): el estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.
- División de mediciones de calidad (ISO/IEC 25002n): los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.
- División de requisitos de calidad (ISO/IEC 25003n): los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado ó como entrada para un proceso de evaluación.
- División de evaluación de la calidad (ISO/IEC 25004n): estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.
En el modelo de calidad hay tres vistas del modelo según el contexto: modelo de calidad de software, modelo de calidad de datos y modelo de calidad en uso, que puede tener distintas vistas según la parte beneficiaria que consideremos (usuario final, organización y soporte técnico)
Considerando la vista del usuario final tendríamos una definición de usabilidad más cercana a la planteada en la ISO 9241‐11.
Figura 5. Imagen [Férnandez-Martinez, 2009]
En el modelo de calidad de software la usabilidad se mantiene como una característica más del producto, pero que se llama operabilidad, y tiene alguna diferencia respecto a la ISO 9126, siendo sus subcaracterísticas:
- Fácil de aprender: capacidad para ser aprendido en su manejo
- Fácil de entender: capacidad del producto de ser entendida por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
- Fácil de usar: capacidad del producto de ser operado y controlado en cualquier momento.
- Atractivo: capacidad del producto de ser atractivo para sus usuarios.
- Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
- Facilidad de ayuda: hace referencia al grado con el que el producto ofrece ayuda a los usuarios cuando la necesitan, algo que en la ISO 9126 se consideraba implícita en la facilidad de aprender.
- Accesibilidad técnica: hace referencia a cómo el producto software puede ser usado por personas con discapacidad.
Tanto [Férnandez-Martinez, 2009, pp. 48 y ss] como [RUIZ MORILLA, 2009] comparan y enumeran las ventajas y desventajas de la ISO 25000 frente a sus predecesoras ISO/IEC 9126 y ISO/IEC 14598.
Aplicación práctica de los estándares formales en la evaluación heurística de la web
Hemos visto que la ISO 9126 es un estándar oficial de usabilidad orientado al producto que ha sido revisado en la ISO 25000.
Por otra parte, hemos visto que en estas normas se definen una serie de características y subcaracterísticas de la usabilidad.
¿Cómo podemos aplicarlo de forma práctica en la evaluación heurística de una web?
Una buena respuesta es mediante WUEP (Web Usability Evaluation Process), la tesina de Adrián Fernández Martínez [FERNANDEZ-MARTINEZ, 2009]
WUEP (Web Usability Evaluation Process)
La WUEP define un proceso genérico de usabilidad para metodologías de desarrollo Web basadas en modelos. Presenta una guía detallada para realizar evaluaciones de usabilidad integrando todos los atributos de usabilidad posibles desde la perspectiva del concepto de usabilidad que ofrece la ISO 25000 (SQUARE)
El modelo de usabilidad web tiene en cuenta la división en subcaracterísticas y el modelo de calidad propuesto por SQuaRE. Como están subcaracterísticas son muy genéricas y están a un alto nivel de abstracción, descompone dichas subcaracterísticas en atributos cercanos al dominio Web, intentando que las definiciones de las atributos se solapen lo mínimo posible entre ellas, con el objetivo de obtener un modelo de usabilidad lo más amplio posible centrado en el ámbito de las aplicaciones Web.
En esa extensión del modelo hacia productos Web se tienen en cuenta los criterios ergonómicos de [BASTIEN y SCAPIN, 1993], las pautas de usabilidad del Gobierno de EEUU [USABILITY.GOB] (conocidas como las HHS Guidelines), y otras métricas generalmente aceptadas con el objetivo de proveer un conjunto de métricas genéricas que puedan ser operacionalizadas en distintos niveles de abstracción y en distintos métodos de desarrollo Web.
Cada métrica tiene asociada un único atributo, pudiendo pertenecer este a cualquier vista del modelo, con el objetivo de descubrir problemas de usabilidad en base a los valores obtenidos de la métrica, pudiendo además cuantificar cómo dicho atributo afecta al nivel de usabilidad de la aplicación Web.
En este modelo hay dos tipos de evaluaciones uno sería el equivalente a una evaluación heurística, que a su vez puede ser de tres tipos: PIM o independiente de la plataforma, PSM o específico de una plataforma y CM o informe de usabilidad de la aplicación final; el segundo tipo de evaluación sería el de la evaluación de calidad en uso con test de usuarios.
Por otra parte, señalar que WUEP extiende y adapta el método de evaluación de calidad de la ISO 25004n para su integración en evaluaciones de usabilidad:
Otras propuestas
Mplu+a
En el año 2004, Toni Granollers i Saltiveri [GRANOLLERS, 2004], profesor de la Universidad de Lleida, presentaba su tesis doctoral: "MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona-Ordenador y la Accesibilidad en el contexto de equipos de desarrollo multidisplinares", una metodología que emplea los estándares ISO/IEC 9126 e ISO/IEC 9241, así como las guías de accesibilidad propuestas por el World Wide Web Consortium (W3C). La trate con detenimiento en [CARRERAS, 2008]
WebQEM
[OLSINA y ROSSI, 2002] especifican características y atributos basados en la norma ISO/IEC 9126-1, aplicando métricas para cuantificar los atributos.
WQM (Web Quality Model)
[CALERO et al.] establece características de calidad basadas en la ISO/IEC 9126-1 y los procesos del ciclo de vida de un sitio Web basándose en la ISO/IEC 12207. Incorpora un total de 326 métricas Web que han sido validadas teórica y/o empíricamente, indicando cuáles de ellas se prestan mejor a automatizar su cálculo. Ver la clasificación de sus métricas
QUIM (Quality in Use Integrated Measurement)
[Seffah et al.] se basa en la ISO 9241-11 y establece 10 subcaracterísticas que se descomponen en 26 atributos o criterios medibles. En el tercer nivel encontramos 127 métricas de usabilidad asociadas a los atributos. Posee una herramienta de gestión llamada QUIM Editor [STRIKE, 2003]
Referencias
AENOR (Asociación Española de Normalización y Certificación)
BASTIEN, J. M.; SCAPIN, D. L. (1993): “Ergonomic Criteria for the Evaluation of Human-Computer Interfaces”, version 2.1
BEVAN, N. (2005): "Guidelines and Standards for Web Usability"
- (2006): “International Standards for HCI” , mayo 2006
- BEVAN, N. , SPINHOF, L. (2007): “Are guidelines and standards for web usability comprehensive?”
- Nivel Began Published Papers: http://www.nigelbevan.com/cart.htm
CALERO, C.; RUIZ, J.; PIATTINI, M. (2005): “Classifying Web metrics using the Web Quality Model”. Emerald Group Publishing Limited. ISSN: 1468‐4527. Vol.29, nº 3, pp. 227‐248,
CARRERAS MONTOTO, O. (2008), “Metodología DCU MPlu+a”, marzo 2008
Comité Europeo de Normalización (CEN)
FERNANDEZ MARTINEZ, A. (2009): “WUEP: Un Proceso de Evaluación de Usabilidad Web Integrado en el Desarrollo de Software Dirigido por Modelos”
GRANOLLERS, T. (2004): “MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona‐Ordenador y la Accesibiiad en el contexto de equipos de desarrollo multidisciplinares”. Tesis Doctoral, Departament de Llenguatges i Sistemas Informàtics. Universitat de Lleida
ISO25000.com: “Calidad del Producto Software y la norma ISO/IEC 25000”,
- [ISO25000.com, b]: “La Norma ISO/IEC 25000:2005”,
MONTERO SIMARRO, F. (2008): “Tema 2. El diseño centrado en el usuario”
OLSINA, L.; ROSSI, G. (2002): “Measuring Web Application Quality with WebQEM”. IEEE Multimedia, Vol. 9, nº 4, pp. 20‐29.
Organización Internacional de Estandarización (ISO)
RUIZ MORILLA, J.J. (2009): “ISO 9126 vs. SQuaRE”
SCALONE, F. (2006): “Estudio comparativo de los modelos y estándares de calidad del software”, junio de 2006
TRAVIS, D. (2011): “ISO 13407 is dead. Long live ISO 9241-210!”, Userfocus, 6/6/2011
SEFFAH, A.; Donyaee, M.; Kline, R.B.; Padda, H.K. (2006): Usability measurement and metrics: A consolidated model . Software Quality Journal 14(2), pp. 159-178.
STRIKE, J. (2003): “QUIM Editor: a Tool for Quality in Use Measurement”
USABILITY.GOB: “Research-Based Web Design & Usability Guidelines”
USABILITYNET (2006): “International standards for HCI and usability”
Normas ISO referenciadas:

Sirius. Nuevo sistema para la evaluación de la usabilidad web

2011-07-20T02:14:00.014+02:00

Última actualización: 06/09/2011

Novedad septiembre 2011

Nueva versión de la excel para la evaluación de la usabilidad web según la metodología Sirius.

Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3

Formato: Excel, 87 KB

Licencia: descarga directa. No require aceptación de contrato Coloriuris.

En esta nueva versión el cálculo del porcentaje de usabilidad del sitio evaluado se realiza completamente de forma automática. Ya no es necesario rellenar manualmente la columna relevancia ni es necesario habitar macros.

Las mejoras de esta nueva versión han sido realizadas por Cecilio Sánchez.

Más información sobre la excel

El objetivo de este artículo es doble:

por un lado difundir el nuevo sistema de evaluación de la usabilidad web propuesto por Mª del Carmen Suárez Torrente en su tesis: Sirius: Sistema de Evaluación de la Usabilidad Web Orientado al Usuario y basado en la Determinación de Tareas Críticas (PDF, 3.39 MB) de febrero de 2011
compartir una excel que ayude a evaluar la usabilidad de los sitios web según la nueva metodología: Checklist para la evaluación de la usabilidad web según la metodología Sirius (Novedad: versión 3 de la excel con cálculo completamente automático del porcentaje de usabilidad del sitio evaluado)

¿En que consiste el nuevo sistema de evaluación?

Es un sistema de evaluación de la usabilidad web que parte de la evaluación heurística pero que aúna una serie de características que la diferencia de otras propuestas:

se aplica a cualquier tipo de sitio web
es aplicable durante todo el ciclo de vida del sitio
da como resultado un valor porcentual del nivel de usabilidad del sitio evaluado, un dato por tanto cuantitativo, lo cual permite:
- cuantificar y comparar la mejora de usabilidad de un sitio en el tiempo
- comparar la usabilidad de diferentes portales de un mismo sector o que por ejemplo compitan por un premio de usabilidad
- establecer clasificaciones y rankings en base a la usabilidad
- comparar el nivel de usabilidad obtenido por un sitio en el tiempo con los resultados de las ventas obtenidas por dicho sitio en ese periodo de tiempo. En la tesis se incluye un ejemplo de este tipo, comprobando que efectivamente la mejora de la usabilidad impacta en las ventas y en qué medida.
- determinar la relación entre usabilidad y accesibilidad (si a mayor nivel de accesibilidad el portal consigue un mejor resultado en su valor de usabilidad)
se tiene en cuenta el tipo de sitio evaluado, de manera que la relevancia de los errores está relacionado con el tipo de sitio.
permite inferir los elementos a subsanar en el sitio atendiendo a su prioridad, pudiéndose ordenar por este criterio aquellas mejoras que son críticas.
permite desarrollar una herramienta de evaluación que dé soporte al sistema de evaluación planteado y facilite la validación empírica de la propuesta de evaluación.

Puesto que su propuesta se basa en la evaluación heurística, en el capítulo 3 repasa todas las propuestas de heurísticas y métricas asociadas más relevantes que existen, la de Shneiderman, Nielsen, Constantine, Instone, Tognazzini, etc. indicando por cada una de ellas sus limitaciones, que según cada caso pueden ser:

que no permitan obtener un valor cuantitativo de la usabilidad del sitio
que no proporcionen una relación de items a evaluar asociados a las heurísticas propuestas
que no sean aplicables a cualquier tipo de sitio web
que no tengan en consideración el tipo de sitio evaluado, en función del cual el impacto del incumplimiento de una heurística debería ser diferente

Este repaso constata además que diversos autores han propuesto diferentes conjuntos de heurísticas o principios a través de los cuales realizar la evaluación, lo cuál hace difícil actualmente poder establecer una sistemática en la evaluación.

Clasificación de sitios web

Como he indicado, la evaluación tiene en cuenta el tipo de sitio web, pues la relevancia del cumplimiento o no de un criterio será diferente en función del tipo de sitio.

Por ello realiza una clasificación de sitios web con el objetivo de:

Adaptar los resultados de la evaluación de un sitio a la categoría del mismo, ponderando los valores obtenidos en función del tipo de sitio considerado.
Determinar por cada tipo de sitio las tareas que se consideran críticas y el perfil de usuario más habitual del mismo. De esta manera, se facilita el diseño de las pruebas de evaluación que sería preceptivo realizar con los usuarios del sitio tras la realización de la evaluación heurística propuesta en el trabajo (y una vez subsanados los errores encontrados)

Ante la falta de consenso en las clasificaciones existentes, que repasa en el capítulo 4, elabora una nueva clasificación en base a su funcionalidad (cuya metodología para elaborarla explica en el capítulo 6):

Por cada uno de estos tipos determina su audiencia y las tareas críticas o relevantes en el mismo (páginas 112-115)

Heurísticos y subheurísticos

Se establece una única relación de elementos a evaluar denominados criterios (subheurísticas), agrupados en aspectos (heurísticas) que será utilizada por todos los expertos implicados en el
proceso de evaluación. Con una única relación de elementos a evaluar se consigue unificar los criterios para llevar a cabo una evaluación heurística de un sitio web.

Los heurísticos definidos y sus criterios evaluables son:

Aspectos generales

Elementos relacionados con los objetivos del sitio, el look & feel, coherencia y nivel de actualización de contenidos.

AG1: Objetivos del sitio web concretos y bien definidos
AG2: Contenidos y servicios ofrecidos precisos y completos
AG3: Estructura general del sitio web orientada al usuario
AG4: Look & feel general se corresponde con los objetivos del sitio web
AG5: Diseño general del sitio web reconocible
AG6: Diseño general del sitio web coherente
AG7: Se utiliza el idioma del usuario
AG8:Se da soporte a otro/s idioma/s
AG9: Traducción del sitio completa y correcta
AG10: Sitio web actualizado periódicamente

Identidad e Información

Elementos relacionados con la identidad del sitio, la información proporcionada sobre el proveedor y la autoría de los contenidos.

II1: Identidad o logotipo significativo, identificable y suficientemente visible
II2: Identidad del sitio en todas las páginas
II3: Eslogan o tagline adecuados al objetivo del sitio
II4: Información sobre sitio web, empresa
II5: Existen mecanismos de contacto
II6: Se ofrece información sobre la protección de datos de carácter personal o los derechos de autor de los contenidos del sitio web
II7: Se ofrece información sobre el autor, fuentes y fechas de creación y revisión del documento en artículos, noticias, informes

Estructura y Navegación

Elementos relacionados con la idoneidad de la arquitectura de la información y la navegación del sitio.

EN1: Se ha evitado pantalla de bienvenida
EN2: Estructura de organización y navegación adecuadas
EN3: Organización de elementos consistente con las convenciones
EN4: Control del número de elementos y de términos por elemento en los menús de navegación
EN5: Equilibrio entre profundidad y anchura en el caso de estructura jerárquica
EN6: Enlaces fácilmente reconocibles como tales
EN7: La caracterización de los enlaces indica su estado (visitados, activos)
EN8: Se ha evitado la redundancia de enlaces
EN9: Se ha evitado la existencia de enlaces rotos
EN10: Se ha evitado que haya enlaces que lleven a la misma página que se está visualizando
EN11: En las imágenes de enlace se indica el contenido al que se va a acceder
EN12: Existe un enlace para volver al inicio en cada página
EN13: Hay elementos de navegación que orienten al usuario acerca de dónde está y cómo deshacer su navegación (migas, pestañas coloreadas)
EN14: Existe mapa del sitio para acceder directamente a los contenidos sin navegar

Rotulado

Elementos relacionados con la significación, corrección y familiaridad del rotulado de los contenidos.

RO1: Rótulos significativos
RO2: Sistema de rotulado controlado y preciso
RO3: Título de las páginas, correcto y planificado
RO4: URL página principal correcta, clara y fácil de recordar
RO5: URL de páginas internas claras
RO6: URL de páginas internas permanentes

Layout de la página

Elementos relacionados con la distribución y el aspecto de los elementos de navegación e información en la interfaz.

LA1: Se aprovechan las zonas de alta jerarquía informativa de la página para contenidos de mayor relevancia
LA2: Se ha evitado la sobrecarga informativa
LA3: Es una interfaz limpia, sin ruido visual
LA4: Existen zonas en blanco entre los objetos informativos de la página para poder descansar la vista
LA5: Uso correcto del espacio visual de la página
LA6: Se utiliza correctamente la jerarquía visual para expresar las relaciones del tipo "parte de" entre los elementos de la página
LA7: Se ha controlado la longitud de página
LA8: La versión impresa de la página es correcta
LA9: El texto de la página se lee sin dificultad
LA10: Se ha evitado el texto parpadeante/deslizante

Entendibilidad y facilidad en la interacción

Elementos relacionados con la adecuación y calidad de los contenidos textuales, iconos y controles de la interfaz.

EF1: Se emplea un lenguaje claro y conciso
EF2: Lenguaje amigable, familiar y cercano
EF3: Cada párrafo expresa una idea
EF4: Uso consistente de los controles de la interfaz
EF5: Metáforas visibles reconocibles y comprensibles (ej. iconos)
EF6: Si se usan menús desplegables, orden coherente o alfabético
EF7: Si el usuario tiene que rellenar un campo, las opciones disponibles se pueden seleccionar en vez de tener que escribirlas

Control y retroalimentación

Elementos relacionados con libertad del usuario en la navegación y la información proporcionada al
mismo en el proceso de interacción con el sitio.

CR1: El usuario tiene todo el control sobre la interfaz
CR2: Se informa al usuario acerca de lo que está pasando
CR3: Se informa al usuario de lo que ha pasado
CR4: Existen sistemas de validación antes de que el usuario envíe información para tratar de evitar errores
CR5: Cuando se produce un error, se informa de forma clara y no alarmista al usuario de lo ocurrido y de cómo solucionar el problema
CR6: Se ha controlado el tiempo de respuesta
CR7: Se ha evitado que las ventanas del sitio anulen o se superpongan
a la del navegador
CR8: Se ha evitado la proliferación de ventanas en la pantalla del usuario
CR9: Se ha evitado la descarga por parte del usuario de plugins adicionales
CR10: Si existen tareas de varios pasos, se indica al usuario en cual está y cuantos faltan para completar la tarea

Elementos multimedia

Elementos relacionados con el grado de adecuación de los contenidos multimedia al sitio web.

EM1: Fotografías bien recortadas
EM2: Fotografías comprensibles
EM3: Fotografías con correcta resolución
EM4: El uso de imágenes o animaciones proporciona algún tipo de valor añadido
EM5: Se ha evitado el uso de animaciones cíclicas
EM6: El uso de sonido proporciona algún tipo de valor añadido

Búsqueda

Elementos relacionados con el buscador implementado en el sitio web.

BU1: Si es necesaria, se encuentra accesible desde todas las páginas del sitio
BU2: Es fácilmente reconocible como tal
BU3: Se encuentra fácilmente accesible
BU4: La caja de texto es lo suficientemente ancha
BU5: Sistema de búsqueda simple y claro
BU6: Permite la búsqueda avanzada
BU7: Muestra los resultados de la búsqueda de forma comprensible para el usuario
BU8: Asiste al usuario en caso de no poder ofrecer resultados para una consultada dada

Ayuda

Elementos relacionados con la ayuda ofrecida al usuario durante la navegación por el sitio.

AY1: El enlace a la sección de Ayuda está colocado en una zona visible y estándar
AY2: Fácil acceso y retorno al/del sistema de ayuda
AY3: Se ofrece ayuda contextual en tareas complejas
AY4: FAQs (si la hay), es correcta tanto la elección como la redacción de las preguntas
AY5: FAQs (si la hay), es correcta la redacción de las respuestas

Métrica de evaluación

A la hora de valorar un criterio se establecen dos tipos de valores de medición (se aplica uno u otro según las características de cada criterio):

una escala de 0-10 que indica el grado de conformidad del evaluador con el cumplimiento del criterio. Se propone una escala proporcional a la que será el resultado de la métrica de evaluación del sitio (un valor comprendido entre 0-100) indicando nula o máxima usabilidad.
un valor textual, que indica si el criterio se cumple o no y en qué extensión del sitio web se detecta el problema en el caso de que el criterio no se cumpla. Este valor lo asigna el evaluador pero, a efectos de cómputo, se aplica el mismo intervalo de medición (de 0-10):
- NTS: no se cumple en todo el sitio (valor de 0)
- NEP: no se cumple en los enlaces principales (valor de 2.5)
- NPP: no se cumple en la página principal (valor de 5)
- NPI: no se cumple en alguna página interior (valor de 7.5)
- S: se cumple el criterio (valor de 10)
- NA: criterio no aplicable en el sitio

En las páginas 134 y siguientes se incluye la relación completa de aspectos, criterios y elementos de evaluación para llevar a cabo la evaluación. Por ejemplo, la tabla para el heurístico “Aspectos generales” sería:

Para la obtención de la medida cuantitativa del nivel de usabilidad y la indicación de la urgencia o prioridad en la mejora de los criterios en los que se ha detectado el fallo, se determinan los
valores de severidad de los aspectos y los criterios en función de los diferentes tipos de sitios considerados en el sistema de evaluación.

Este nivel de severidad es un indicador del nivel de importancia que tiene el incumplimiento de un criterio; al contrario que en otras propuestas NO es el evaluador el que asigna éste valor a la heurística revisada; en esta propuesta el evaluador únicamente se ocupa de cuantificar el incumplimiento, no la severidad o relevancia del mismo.

La relevancia de los aspectos (heurísticas), en función del tipo de sitio se pueden consultar en la tabla de la página 123 y se clasifican en muy alta, alta, media y baja.

La relevancia de los criterios (subheurísticos) en función del tipo de sitio se pueden consultar en las tablas de las páginas 125-131. Se clasifican en:

crítica (CR): el problema identificado es severo. El usuario no podrá completar la tarea y podría no desear seguir utilizando el sitio Web.
mayor (MA): es posible que el usuario complete la tarea pero tendrá mucha dificultad, frustración o incluso tendrá que ejecutar muchos pasos innecesarios. Podrá superarlo después de que se le haya mostrado cómo hacerlo.
media (ME): en la mayoría de casos, el usuario podrá completar la tarea, realizando un moderado esfuerzo para evitar el problema. Pueden necesitar investigar algunos enlaces para determinar que opción les permitirá completar la tarea propuesta. En navegaciones posteriores del sitio, los usuarios probablemente recordaran cómo ejecutar la tarea.
moderada (MO): el problema ocurre de manera intermitente y puede ser fácilmente superado, aunque es irritante para el usuario. Debido principalmente a problemas estéticos.

El valor de relevancia de los aspectos matizará los resultados de la evaluación, de manera que ante dos criterios de igual criticidad, será la relevancia del aspecto al que pertenecen la que determine cuál de ellos será prioritario en su arreglo.

Por último, la fórmula para obtener el valor cuantitativo considera los siguientes conceptos:

Factor de corrección: valor de ajuste que se aplica a cada uno de los criterios evaluados con el fin de obtener diferentes niveles de usabilidad dependiendo de la relevancia de los mismos en función del tipo de sitio web en evaluación. Los valores resultantes al aplicar este factor de corrección debieran llevar a obtener valores de usabilidad comprendidos siempre entre 0 y 100, por tratarse de un porcentaje.
Cálculo del Factor de Corrección: partiendo de los valores correspondientes a los diferentes niveles de relevancia de un criterio, el factor de corrección se calcula dividiendo cada valor de relevancia entre la suma de todos los valores de relevancia de los criterios evaluados.

La fórmula es la siguiente:

nce: número de criterios evaluados. Será como máximo 83, que son los propuestos en este sistema de evaluación. Se considera que alguno de los criterios pueda no ser aplicable al sitio en evaluación y, por lo tanto, no se evalúe.
vc: Valor de evaluación de un criterio (entre 0 y 10).
fc: Factor de corrección aplicado al criterio evaluado. El valor del factor de corrección de cada uno de los criterios evaluados se obtiene de la siguiente manera:

rc : Valor de relevancia que corresponde a un criterio

En este gráfico se resume el sistema de evaluación Sirius:

Herramienta de soporte al sistema de evaluación

La aplicación web que ha desarrollado Mª del Carmen Suárez Torrente como soporte al proceso de evaluación se llama Prometheus y entre sus características destacan:

presenta los criterios a chequear
proporciona el porcentaje de usabilidad obtenido por el sitio
proporciona la relación de criterios a mejorar ordenados por su prioridad, de manera que el primero de la lista es el que mayor incremento de la usabilidad proporcionará
permite visualizar los valores asignados por los evaluadores a cada uno de los criterios evaluados así como las observaciones realizados por los mismos durante el proceso de evaluación.
obtener un informe en formato EARL

Tiene gestión de usuarios, gestión de sitios (un dato básico es el tipo de sitio, que puede ser hibrido), consulta de los resultados de evaluaciones previas, etc.

Mientras la aplicación no sea pública, he preparado una excel para facilitar la aplicación de la metodología Sirius en la evaluación de la usabilidad web.

Excel para ayudar a la evaluación de usabilidad según la metodología Sirius

Se puede descargar de forma gratuita en: Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3 (Excel, 87 KB)

Las mejoras de esta nueva versión han sido realizadas por Cecilio Sánchez.

Versiones anteriores:

Versión 2 (27.07.11): Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 2
Versión 1 (20.07.11): Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 1

Descripción general de la Excel

La excel está compuesta por diferentes pestañas:

Datos del sitio: en esta pestaña se rellenan los datos generales de la evaluación y del sitio evaluado. El dato "Tipo del sitio" se selecciona de un desplegable. Son los tipos de sitio definidos por la metolología Sirius, la relevancia de los criterios a evaluar dependerá del tipo de sitio que se indique.
Pestaña de la 2-11: hay una pestaña por cada heurístico. En cada una se enuncian los criterios a evaluar. El evaluador debe valorar cada criterio seleccionando las opciones disponibles en la columna "Valor". Estas opciones son las definidas por la metodología y se seleccionan de un desplegable, cuya leyenda puede consultarse en cada pestaña. No debe rellenarse ningún campo más, el resto de valores se calculan automáticamente. Sí se pueden añadir comentarios a cada criterio. Se recomienda poner la referencia a un documento de texto externo donde se expliquen y se documenten.
Pestaña "Cálculo de % de usabilidad": una vez valorados los criterios de los 10 heurísticos se puede consultar en esta pestaña la puntuación que ha obtenido el sitio.
Las pestañas "Tabla de relevancia" y "Valores" sólo contienen datos para los cálculos del porcentaje de usabilidad.

Las limitaciones, frente a lo que sería la aplicación, serían:

no genera el informe EARL
no proporciona la relación de criterios a mejorar ordenados por su prioridad
está orientado a un único evaluador y por tanto no permite comparar las evaluaciones de varios evaluadores

La autora me ha confirmado que se encuentra desarrollando la nueva versión de la aplicación web.

Últimos artículos

Servicios relacionados

Consultoría de usabilidad web: evaluación heurística.

Arquitectura de información. Fundamentos

2011-07-14T11:30:00.007+02:00

Arquitectura de información, usabilidad, accesibilidad… todas ellas son disciplinas diferentes aunque íntimamente relacionadas, englobadas en una macrodiscisciplima denominada Experiencia de usuario (UX) que aglutina la arquitectura de información y la mayoría de las disciplinas cercanas a ella [1].

El objetivo de este artículo es introducir los fundamentos de la arquitectura de información (AI), es decir, los principios y cimientos de la disciplina. Para estructurar el contenido he tomado como guión uno de los mejores libros que existen sobre el tema “Arquitectura de información en entornos web” de Mario Pérez-Montoro Gutiérrez (Pérez-Montoro, 2010).

Para los que ya lo han leído, este artículo puede servir de esquema resumen. A los demás os animo a leerlo, pues en él se desarrollan en profundidad todos los apartados con gran rigor y muy bien documentados.

¿Qué es la arquitectura de información?

Disciplina (arte y ciencia) encargada de estructurar, organizar y etiquetar los elementos que conforman los entornos informacionales para facilitar de esta manera la localización (o el acceso) de la información contenida en ellos y mejorar, así, su utilidad y su aprovechamiento por parte de los usuarios (Pérez-Montoro 2010).

El arquitecto de información es la persona que debe identificar la misión (los objetivos) y la visión (las expectativas de los usuarios) de la pagina web, determinar los contenidos y funcionalidades de la página, facilitar el acceso mediante sistemas de organización, etiquetado, navegación y búsqueda y planificar en previsión de futuras modificaciones y crecimiento de la página (Morville y Rosenfeld, 1998)

Durante la fase de “estrategia” identifica los objetivos, en la fase de “alcance” las necesidades de los usuarios, en la fase de “estructura” especifica las funcionalidades y requerimientos de la web, en la fase de “esqueleto” el diseño de los sistemas de navegación, organización, etiquetado y búsqueda y en la fase de “interfaz” prototipa la página (Garret, 2003)

Tipos de necesidad de información

El objetivo habitual de un usuario al acceder a una web es satisfacer una necesidad de información y/o realizar una transacción (por ejemplo comprar un billete de tren). Desde el punto de vista de las necesidades informativas, se pueden distinguir tres tipos:

Necesidad de información concreta (NIC): por ejemplo, “¿qué precio tiene este producto?”
Necesidad de información orientada a problemas (NIOP), por ejemplo, “¿cuál es la relación entre la usabilidad y la arquitectura de información?”
Necesidad de información exploratoria (NIE), por ejemplo “quiero escoger un buen hotel para este fin de semana”
Necesidad de información sobre búsquedas previas (NIBP), es decir, localizar información que ya había localizado previamente.

Las estrategias de las que dispone un usuario para satisfacer estas necesidades de información en una página web son:

Búsqueda, utiliza la caja de búsqueda y analiza e interacciona con los resultados.
Navegación, explora a partir de los enlaces de la web.
Ayuda, por comodidad o desesperación reclama que se le oriente y señale dónde se encuentra el contenido.

El usuario utiliza una de estas estrategias - o una combinación de ellas- para localizar información que asimila y evalúa para así reformular o refinar su necesidad de información, hasta que considera que ha quedado resuelta. Es lo que se conoce como el modelo berrypicking o recolección de bayas (Bates, 1989). Ver también modelo pearl-growing

Componentes o anatomía de la arquitectura de información

Una buena arquitectura de información se sustenta en tres pilares: el contexto organizacional en el que se desarrolla, el contenido que alberga y los usuarios que la visitan y consultan (Morville y Rosenfeld, 2006)

Los sistemas, estructuras o recursos para estructurar una web y que definen la AI de un sitio se llaman componentes o anatomía de la arquitectura de información y son los siguientes:

Sistemas de organización
Sistemas de etiquetado
Sistemas de navegación
Sistemas de búsqueda
Vocabularios o lenguajes documentales

Todos ellos son los responsables en gran de media de la findability de la página y los contenidos que alberga.

Sistemas de organización

Dependiendo de cómo organicemos la información contenida en una web lograremos que los contenidos que alberga sean más fáciles de encontrar por los usuarios. Para hacer un diseño adecuado del sistema de organización es necesario desarrollar correctamente los componentes que lo conforma:

Esquemas de organización: sistemas que organizan los grupos de ítems de información contenidos en una página web en grupos a partir de un criterio concreto:
- Exactos: grupos bien definidos y mutuamente excluyentes, sirven para conocer cosas previamente conocidas:
  - Alfabéticos
  - Cronológicos
  - Geográficos
- Ambiguos, para localizar contenidos que no conocemos:
  - Tema
  - Tarea
  - Audiencia
  - Metáfora, de la que no hay que abusar, pues si no está bien desarrollada su alta ambigüedad desorienta al usuario.
  - Híbrido, utilización de varios de los esquemas anteriores.
Estructuras de organización: sistemas que organizan los grupos de ítems de información resultantes de los esquemas mostrando las dependencias lógicas que existen entre ellos:
- Estructura jerárquica, una buena arquitectura de información incluye una jerarquía o taxonomía entre sus componentes. Permiten al usuario ubicarse y obtener un modelo mental de la estructura del sitio que visita:
  Consejos:
  - Diseñarla teniendo en cuenta a los usuarios.
  - Las opciones principales deben estar siempre visibles.
  - Combinarla con los otros tipos de estructuras para ofrecer al usuario flexibilidad a la hora de localizar la información.
  - Las categorías que la conforman deben ser mutuamente excluyentes. Si muchos contenidos pertenecen a varias categorías la taxonomía termina perdiendo su valor para localizar la información.
  - Sobre la anchura (nº de ítems al mismo nivel) y profundidad de la estructura (niveles de división verticales) recomendada se han escrito ríos de tinta [2]
  - Definir la estructura pensando en la escalabilidad del portal, que sea posible incluir nuevas categorías sin modificarla sustancialmente, sin provocar cambios en la imagen mental que tiene el usuario que ya la ha visitado y sin tener que introducir modificaciones visuales en la home.
- Basada en registros (o en el modelo de base de datos), idóneo para los contenidos bien estructurados y homogéneos
- Estructura hipertextual (o en red), que debe ser complemento de otros tipos de estructuras y no la única opción de organización de la información. Permite reflejar relaciones menos estructuradas y más creativas existentes entre los contenidos.
- Estructura secuencial, con un principio y un final claro y un único itinerario de consulta o exploración
- Estructura en tabla (o matriz), sólo para aquellos contenidos que admitan su representación en una tabla, y debe ser utilizado en combinación con otras estructuras.

Algunos problemas que debemos resolver al diseñar el sistema de organización son:

La ambigüedad del propio lenguaje lingüístico.
La heterogeneidad de los contenidos.
Las diferentes perspectivas, siendo imprescindible tener en cuenta a nuestro público objetivo.
Los intereses de la organización, que es necesario conocer a fondo.

El mejor consejo es que, dependiendo del contexto y los usuarios, elegir y articular aquellos sistemas que sean realmente útiles, intentando simultanear esquemas exactos y ambiguos para ofrecer al usuario diferentes vías para acceder y localizar la información. La combinación de diferentes estructuras, si se combinan adecuadamente, permiten obtener un sistema sólido, coherente y flexible.

Sistemas de etiquetado

A la hora de definir el sistema de etiquetado debemos tener cuidado con:

La ambigüedad intrínseca al lenguaje, tanto sintáctica, léxicas (sinonimia y polisemia) como semántica (uso de metáforas, ironía, etc.)
La arbitrariedad, evitando utilizar términos con un significado diferente con el que normalmente se asocian.
La desorientación que producen las etiquetas que no anticipan ni dan pista sobre lo que esconden.
Las etiquetas que utilizamos se asociación al branding de la empresa, y unas etiquetas mal elegidas pueden dar una mala impresión de la misma.

Todo ello puede suponer que el usuario abandone la página porque no encuentra lo que necesita.

Las etiquetas pueden ser textuales o icónicas, estas deben utilizarse siempre junto a las primeras porque son intrínsecamente ambiguas.

Los sistemas de etiquetado con formato textual que deben planificarse son:

Enlaces contextuales. Deben identificarse visualmente como tales, diferenciar los que sean externos y utilizarse de forma consistente. No deben ser ambiguos y se debe tener en cuenta el contexto en el que se insertan, siendo además independientes del mismo.
Títulos. Deben estructurar coherentemente el contenido y su diseño debe reflejar su jerarquía. Tienen que ser descriptivos y coherentes con los literales utilizados en los otros sistemas de etiquetado. Deben ser consistentes a lo largo del sitio tanto en su ubicación como en su aspecto.
Opciones del sistema de navegación. Deben ser consistentes y coherente siguiendo un mismo patrón visual y de ubicación a lo largo de todo el sitio. Deben describir adecuadamente los contenidos que incluyen y ser entre ellos lo más excluyentes posibles.
Términos de indización. Son el conjunto de etiquetas utilizadas para describir cualquier tipo de contenido en un entorno web y facilitar su localización, búsqueda y recuperación. Su enlace permite acceder al listado de todos los contenidos indizados con ese término y además alimentan el índice inverso del sistema de búsqueda. Cuando los propios usuarios o los autores de los contenidos proponen las etiquetas (tag) hablamos de marcadores sociales. Una folksonomía es el resultado de la agregación de las etiquetas o tags propuestos por uno más usuarios. Se pueden visualizar en forma de listado, nubes de etiquetas, los más populares, etc.

Consejos y recomendaciones

Acotar el significado de las etiquetas teniendo en cuenta a los usuarios.
Diseñar el sistema de etiquetado de forma global y no etiquetas de forma aislada.
Mantener la consistencia tanto en el literal como en el formato.
Usar el mismo registro: si usas “linfoma” no uses “dolor de cabeza” sino “cefalea”.
Reconocibles por ser conceptos familiares, el usuario no debe tener que aprender su significado.
Utilizar estrategias para desambiguar las etiquetas, por ejemplo mediante el contexto (acompañada de otros elementos similares; mediante un texto que la acompañe, etc.)

Orientaciones metodológicas

Crear una tabla con tres columnas: etiqueta, explicación de la etiqueta y contenido que representa, para detectar inconsistencias y duplicidades.
Involucrar a los autores de contenidos.
Involucrar a los usuarios con pruebas de cardsorting.
Ver cómo etiquetan nuestros contenidos los usuarios por ejemplo en Del.icio.us
Analizar los términos que utilizan los usuarios en el buscador de nuestra web.
Aprovechar tesauros y vocabularios controlados ya existentes que podamos adaptar y refinar, pero siempre deben coincidir con nuestra audiencia.

Sistemas de navegación

Son estructuras que ordenan y agrupan los contenidos de una página web bajo unas categorías que forman una clasificación. Nos permiten:

Identificar las relaciones entre los contenidos de la web y entre esos contenidos y la página que se está visitando en ese momento.
Habilitar y facilitar la navegación entre esos contenidos
Orientarnos, saber dónde estamos, que hay aquí, de dónde venimos y cómo podemos ir hacia donde deseamos ir.
Formar una imagen mental del tamaño y estructura del sitio.

Los usuarios pueden navegar de formas muy distintas: con dirección, cuando buscan una información determinada, sin dirección, cuando ojean la web sin un objetivo claramente preestablecido, además puede navegar en amplitud o en profundidad.

Tipos de sistemas de navegación

Sistemas básicos
- Sistemas integrados
  - Sistemas constantes (o globales)
  - Sistemas locales, deben estar correctamente articulados con el sistema constante.
  - Sistemas contextuales, que permiten identificar contenidos relacionados y enlazar con ellos. Es importante que los contenidos o páginas críticas se enlaces desde otros contenidos.
  Se deben articular estos tres sistemas sin saturar de enlaces y sin que ocupen todo el espacio de la página. Deben situarse de forma consistente, fija y diferenciada entre ellos.
- Sistemas complementarios, son recursos para localizar información y para orientarse que suelen ser páginas propias e independientes.
  - Mapa del sitio
  - Índices, listado de términos que representan el contenido del sitio, normalmente ordenados alfabéticamente
  - Guías, para introducir a los nuevos usuarios en los contenidos y la funcionalidad de una parte concreta del sitio: wizards, configuradores, visitas guiadas, tutoriales, etc.
Sistemas no básicos
- Sistemas de personalización, estructuras de navegación proactivas que se autodiseñan en función de lo que espera el usuario, ofreciéndole enlaces a partir de su perfil. El principal problema es que los comportamientos pasados no son garantía de inferir sus comportamientos futuros.
- Sistemas de customización: estructuras reactivas que permiten que el usuario pueda diseñar su propio sistema de navegación. El principal problema es que a los usuarios les pasen desapercibidas estas opciones, que si sus necesidades cambian deben redefinirlas o que simplemente no tengan tiempo de hacerlo.
- Sistemas de navegación visual, permiten explorar usando recursos icónicos o visuales.
- Sistemas de navegación social, inferidos a partir del comportamiento de la mayoría de usuarios que visitan la página (lo más popular, lo más comprado, etc.)

Recomendaciones

Utilizar recursos de contextualización que permitan al usuario saber dónde se encuentra, adónde puede ir y la relación del contenido con el resto del sitio: incluir siempre el logo de la organización, marcar visualmente las opciones de menú donde nos encontramos, incluir migas de pan, etc.
No anular funcionalidades del navegador. Al posicionar el cursor sobre un enlace la URL debe verse en el pie del navegador; no eliminar las barra de menú del navegador al abrir una ventana nueva; no impedir al usuario que utilice el menú contextual del botón derecho; no impedir que la página muestre el scoll cuando sea necesario; permitir que los enlaces visitados cambien de color, etc.
Diseño de navegación: incluir siempre un mapa web. Si se usan menús desplegables es mejor que se desplieguen al activarlos y se mantengan desplegados (Chaparro, Minnaert y Phipps, 2000).

Sistemas de búsqueda

Utilizados normalmente para localizar información a partir de una necesidad concreta. Ofrecen los resultados que coinciden con los definidos por el usuario en la ecuación de búsqueda. Los problemas a superar son:

Ruido: contenidos recuperados no pertinentes, se mide con el índice de precisión.
Silencio: documentos pertinentes no recuperados, se mide con el índice de exhaustividad.

Los sistemas de búsqueda pueden ser:

Reactivos: reaccionan frente a la conducta informativa del usuario.
Proactivos: ofrecen proactivamente la información al usuario sin que tenga que reclamarla continuamente:
- Sistemas de difusión selectiva de información (DSI), ofrecen una actualización informativa automatizada sobre un tema concreto a partir de la sindicalización de contenidos.
- Sistemas de workshop, suministran automáticamente la información dentro de un proceso a partir del perfil del usuario.
- Agentes inteligentes: infieren el perfil de interés informacional de un usuario a partir de criterios como su histórico de comportamiento o su similitud con el de otros usuarios.
RSS, es reactivo porque has de suscribirte y proactivo porque desde ese momento los recibes automáticamente.

Recomendaciones

Evaluar la necesidad de un vocabulario controlado y definir los metadatos implicados en su descripción.
Seleccionar como términos de indización ciertos componentes de los contenidos (título, url, etiquetas de los enlaces o títulos de las imágenes)
Si se indiza el texto completo de todos los contenidos, introducir recursos como la búsqueda por campos para refinar el resultado y evitar una tasa de ruido elevada.
Evaluar si se indiza sólo algunos contenidos, algunas zonas de esos contenidos o algunos componentes determinados de ellos.
Indizar los contenidos según el tipo de usuario o audiencia al que va dirigido.
Inferir patrones en el comportamiento de los usuarios.
Tratar de indizar las páginas según el tipo de contenido.
Incluir siempre que se pueda:
- corrector ortográfico: corrigen automáticamente la ortografía dando alternativas.
- herramientas fonéticas: para identificar términos con grafías diferentes pero fonéticamente idénticas
- herramientas de procesamiento del lenguaje natural: obvian las palabras vacías e introducen AND entre los términos propuestos.
- en función del proyecto, evaluar la inclusión de sugerencias de términos en la caja de búsqueda, que se va adaptando a lo que se escribe y que permiten identificar las búsquedas con más resultados.
Poder refinar y mejorar manualmente los resultados de las búsquedas más habituales.
Formar a los autores del contenido sobre cómo deben redactar los títulos o etiquetar el contenido.
La caja de búsqueda debe estar identificada como tal y cerca del sistema de navegación.
Diseñar la interfaz de búsqueda teniendo en cuenta a los usuarios, el tipo de necesidad informativa, la cantidad de información recuperada y el tipo de contenidos a recuperar.
En la página de resultado:
- indicar los términos por los que se ha buscado
- indicar el número de resultados mostrados y encontrados
- poner en negrita las coincidencias
- permitir refinar la búsqueda (no solo semánticamente sino por fecha, lengua, tipo de documento, etc.)
- permitir realizar búsquedas sólo en los resultados.
- permitir personalizar el número de resultados a mostrar.
- poder imprimir o enviar por email los resultados
- poder guardar la búsqueda, para ello es necesario que sea mediante GET para que tenga una URL propia.
- ofrecer opciones de ordenación (por precio, por relevancia, por cronología, etc.)

Vocabularios o lenguajes documentales

La indización es la operación en la que se asigna a cada contenido una serie de términos (palabras clave) que representan el tema o temas sobre los que versa. Es una operación de análisis. La clasificación es la operación por la cual se asigna a cada contenido un único término que representa el tema principal sobre el que versa ese documento. Es una operación de síntesis.

La información resultante de la indización y la clasificación suele incorporarse al contenido mediante metadatos asociados para que funcione con los sistemas de organización, etiquetado, navegación y búsqueda.

Un lenguaje documental se constituye a partir de un subconjunto de términos del lenguaje natural (acompañados a veces de números como en el caso de las clasificaciones) para facilitar la búsqueda y recuperación de la información contenida en los documentos.

Aunque el uso de un lenguaje documental reduce el ruido y el silencio en las búsquedas, su construcción y mantenimiento lleva asociado un coste de personal y de tiempo importante, además de que hay que asegurar que se hace correctamente. Por ello hay que evaluar con criterio la necesidad de ese esfuerzo y su viabilidad.

Un lenguaje documental está formado por:

El vocabulario del lenguaje documental: subconjunto del lenguaje natural. Se distingue:
- el término de indización principal (descriptor): es unívoco. Identifica la representación estándar de ese concepto. Por ejemplo, “sacerdote”.
- término de indización secundario: es sinónimo del principal y una buena representación del concepto que el primero también representa, pero se decide no identificarlo como la representación estándar. Por ejemplo: “cura”, “clérigo”
Relaciones semánticas entre los términos de indización, que pueden ser de:
- Equivalencia: sinónimos, acrónimos, abreviaciones, variantes léxicas, posibles errores ortográficos, cuasisinónimos.
- Jerarquía, que puede ser:
  - Genérica: soltero-hombre
  - Relación parte-todo: rueda-coche
  - Relaciones de instanciación: Mediterráneo-mar
- Asociativa: por afinidad semántica o evocación. Por ejemplo, veneno-toxicidad.

Tipos de lenguajes documentales

Libres, por ejemplo extraer automáticamente de un texto las palabras que no pertenecen al fichero de palabras vacías.
Controlados:
- Anillos de sinónimos, entre los términos se establecen relaciones de equivalencia pero no de jerarquía ni de asociación. Al hacer una búsqueda se recuperan también los indexados por sus sinónimos. Reduce el silencio en las búsquedas pero aumenta el ruido.
- Fichero de autoridades, listado de términos principales (con sus respectivos sinónimos) para describir y normalizar un conjunto de entidades (personas, organizaciones, lugares geográficos) ante la variedad de homónimos, sinónimos o nombres con los que puede ser denominada una persona, entidad, obra, tema o concepto. Se utiliza especialmente en la catalogación de los fondos de las bibliotecas.
- Lista de encabezamientos de materia (LEM), en el cual el encabezado condensa el tema del documento con uno o varios términos. Presentan relaciones asociativas, jerárquicas y de equivalencia. Se usan preferentemente en las bibliotecas y en los centros de documentación cuyos fondos son esencialmente enciclopédicos.
- Taxonomías, sus términos presentan relaciones de equivalencia y jerarquía pero no asociativas.
- Clasificación, representa entre sus términos relaciones asociativas, jerárquicas y de equivalencia y algunas veces asocia un código identificativo a cada uno de sus términos.
  La más utilizada en web es la clasificación facetada para poder clasificar simultáneamente desde distintos puntos de vista, o a partir de diferentes criterios, un mismo conjunto de objetos.
  Cada una de las clasificaciones o facetas es paralela a las demás en un mismo nivel semántico. Cada faceta sería una etiqueta del sistema de navegación global, o un campo de la base de datos; y las categorías de esa faceta serían las de uno de los sistemas de navegación local, o las de los posibles valores de un campo de la base de datos. Por ejemplo, cada faceta seria (corriente literaria, género literario, etc.) y las categoría (realismo, modernismo,…; novela, poesía,…).
- Tesauro, se encuentran integrados en los sistemas de navegación y búsqueda. Sus términos presentan relaciones asociativas (términos relacionados, TR), jerárquicas (términos genéricos, TG y términos específicos, TE) y de equivalencia.

En este apartado recomiendo también la lectura de dos artículo de Yusef Hassan Montero:

Bibliografía

BATES, M.J. (1989): “The Design of Browsing and Berrypicking. Tecniques for the Online Search Interfaces”, Online Reviews, vol. nº3, pp. 407-424

CHAPARRO, B., G.MINNAERTS y C.PHIPPS (2000): “Limitations of Using Mouse-Over with Menu Item Selection”, Human Factors and Ergonomics Society Annual Meeting Proceedings

GALLETTA, D., R. HENRY, S.McCOY y P.POLAK (2006), “When the Wait isn’t So Bad: The Interacting Effects of Website Delay, Familiarity, and Breadth”, Information Systems Research, vol. 17, núm. 1, pp. 20-37”

GARRET, J. (2003): The Elements of User Experience. User-Centered Design for the Web, Nueva York: American Institute of Graphic Arts

JACKO, J.A y G. SALVENDY (1996): “Hierarchical Menu Design: Breadth, Depth and Task Complexity”, Perceptual and Motor Skills, vol. 82, pp. 1187-1201

KRUG, S (2000): Don’t Make Me Think: A Common Sense approach to Web Usability, Indianápolis (Indiana): New Riders

MORVILLE, Peter y ROSENFELD, Louis (1998): Information Architecture for the World Wide Web, Sebastopol (California): O’Reilly Media Inc.

- (2006): Information Architecture for the World Wide Web, 3ª edición, Sebastopol (California): O’Reilly Media Inc.

MILLER, D.P (1981): “The Depth/Breadth Tradeoff in Hierarchical Computer Menus”, Proceedings of the Human Factors Society 25^TH Annual Meeting, pp. 296-300

MILLER, C. y R.REMINGTON (2002): “Effects of Structure and Label Ambiguity on Information Architecture”, Conference on Human Factors in Computing Systems, pp. 630-631

- (2004): “Modeling Information Navigation: Implications for Information Architecture”, Human-Computer Interaction, vol. 19, núm.3, pp. 225-271

PEREZ-MONTORO, Mario (2010): Arquitectura en entornos web, Gijón: Ediciones Trea

SNOWBERRY, K., S. PARKINSON y N. SISSON (1983): “Computer Display Menus”, Ergonomics, vol. 26, núm.7, pp. 699-712

[1] Consultar "Disciplinas relacionadas con la usabilidad"

[2] Miller, 1981 indica que el máximo de enlaces que retenemos mentalmente cuando navegamos es de 7.

Pero Krung, 2000 defiende que el número de enlaces que recordamos depende de lo que se tenga que recordar. Lo importante es utilizar etiquetas adecuadas al nivel cultural y profesional de los usuarios y discriminar visualmente lo principal de lo secundario.

Porter, 2003 demostró que la regla de los 3 clics es falsa y por tanto no debe fundamentarse en ella la selección de jerarquías anchas y poco profundas, pues lo importante es que cada clic sea significativo y no ambiguo (Krug 2000). Hay que tener en cuenta que las jerarquías muy anchas y poco profundas exigen un mayor esfuerzo cognitivo del usuario para elegir entre todas las opciones del mismo nivel, mientras que las jerarquías estrechas exigen menor esfuerzo cognitivo al tener que elegir entre pocas opciones, de modo que a medida que se avanza, se van desambiguando y da sensación de ser una web menos compleja (ver modelo modelo pearl-growing).

Miller, 1981 defiende que hay que buscar un equilibrio entre la anchura y la profundidad de la estructura. Si el usuario se encuentra demasiadas opciones en el menú principal, en una jerarquía muy ancha y poco profunda, tiene la sensación de escasez de contenido, y si es muy profunda puede sentirse perdido.

Snowberry, Parkison y Sisson, 1983 defienden las jerarquías anchas. Las profundas reclaman mayor memoria a corto plazo, y las anchas transmiten más sensación de orientación, aunque exigen mayor habilidad de análisis visual para identificar las correlaciones semánticas entre los contenidos categorizados.

Galletta, Henry, McCoy y Polak, 2006 defienden las estructuras planas cuando la web es lenta, concluyendo que lo importante realmente es la familiaridad de los contenidos que es lo que más reduce el tiempo de localizar la información.

Jacko y Salvendy, 1996 especifican que el tiempo para completar un tarea aumenta tanto en estructuras anchas como profundas (en este caso más) pero que minimizar la profundidad reduce la percepción de complejidad.

Si la ventaja de las jerarquías anchas es la sensación de orientación, Miller y Remington, 2002, 2004 defienden que un buen sistema de etiquetado no ambiguo en una estructura profunda alteraría la máxima de que las planas son más eficientes, que completaría la tesis de Galletta, Henry, McCoy y Polak, 2006 de que los efectos negativos de la estructura ancha se mitigan con se establece una relación de familiaridad con sus contenidos.

Últimos anteriores

Servicios relacionados

Análisis de interfaz (AI & UX): Arquitectura de información. Diseño de interacción. Prototipado. Experiencia de usuario.

Imprescindibles (18)

2009-12-12T17:49:00.000+01:00

Estos son los artículos que llamaron últimamente mi atención (no tienen porque ser recientes):

Serie "Imprescindibles" (recopilación de artículos de interés)

Reseña "Just Ask: Integrating Accessibility Throughout Design"

2009-11-10T12:30:00.017+01:00

Artículos relacionados:

En este artículo voy a resumir los puntos esenciales del libro "Just Ask: Integrating Accessibility Throughout Design" de Shawn Lawton Henry (2007), el cual está disponible en versión online en español ("Simplemente pregunta: Integración de la accesibilidad en el diseño").

El libro trata sobre los fundamentos de la inclusión de la accesibilidad en los procesos de Diseño Centrado en el Usuario (UCD).

Este libro es recomendado como guía de referencia por la WAI.

Matizan, como también se hace a menudo a lo largo del libro, que incluir a las personas con discapacidad en la evaluación reporta muchos beneficios pero no determina por sí mismo si un sitio es accesible, siempre debe combinarse con la evaluación conforme a las WCAG.

Principios básicos

Integrar la accesibilidad al principio y a lo largo de todo el proyecto.
Tener en cuenta la accesibilidad al principio en un proyecto de diseño es mucho más fácil, eficaz y barato que hacerlo posteriormente.
Contar con la participación de personas con discapacidad en tu proyecto
Los estándares y pautas son sólo una parte de la ecuación en lo que se refiere al adecuado desarrollo de productos accesibles. La otra parte es comprender los problemas de accesibilidad, y la mejor forma de hacerlo es trabajar con personas con discapacidad para saber cómo interactúan con tus productos.
Relacionarse con personas con discapacidad. Recomendaciones para relacionarse con las personas con discapacidad

Contexto: Accesibilidad en el Diseño Centrado en el Usuario

En este capítulo se introducen los conceptos básicos de accesibilidad, usabilidad y DCU.

El objetivo de incorporar la accesibilidad al Diseño Centrado en el Usuario es seguir un "proceso de creación de productos (dispositivos, entornos, sistemas y procesos) que sean usables para personas cuyas capacidades estén dentro del segmento más amplio posible y que se encuentren en situaciones (entornos, condiciones y circunstancias) dentro del espectro más amplio posible, siempre y cuando sea práctico desde el punto de vista comercial".

El proceso de Diseño Centrado en el Usuario se divide en tres fases principales: análisis, diseño y evaluación.

El DCU es un proceso para diseñar productos usables y la accesibilidad de los interfaces de usuario puede considerarse un subgrupo dentro de la usabilidad. Por tanto, se deduce que los diseñadores pueden utilizar el DCU para diseñar productos que sean accesibles. En la práctica, las técnicas de diseño accesible encajan bien con los procesos de DCU ya establecidos.

Después de añadir y adaptar algunos aspectos, los equipos de diseño pueden utilizar las prácticas típicas del DCU para centrar el diseño en la accesibilidad. Integrar la accesibilidad al DCU significa que los diseñadores deben tener en cuenta la muestra de usuarios y situaciones más amplia posible.

Análisis

Es la primera fase de un proceso de DCU.

Ten cuidado y no des por sentado que los comentarios de una persona con discapacidad se pueden aplicar a todas las personas con discapacidad. Una persona que tenga una discapacidad no tiene por qué saber necesariamente cómo van a interactuar otras personas con su misma discapacidad con esos productos, ni tiene por qué saber lo suficiente sobre otras discapacidades como para poder proporcionar consejos válidos sobre otros problemas de accesibilidad.

En este apartado se aborda cómo tener en cuenta los aspectos relacionados con la accesibilidad en la definición de perfiles de grupos de usuarios, en la creación de personajes y en la creación de escenarios.

Diseño

Es la segunda fase de un proceso de DCU.

Los diseñadores de productos a los que se les exige que cumplan con unos estándares de accesibilidad específicos suelen pasar directamente a la parte técnica del estándar sin llegar a entender los problemas de accesibilidad. Intentar cumplir con los estándares de accesibilidad sin entender qué es la accesibilidad no es sólo frustrante, sino que no da resultado.

[...]

Usar estándares y pautas te ayudará a garantizar que se tienen en consideración todos los problemas de accesibilidad y contar con la colaboración de personas con discapacidad te ayudará a abordarlos de una forma eficiente y eficaz.

[...]

Evaluar prototipos iniciales te ayudará a validar ciertos aspectos del diseño que funcionan correctamente y a encontrar barreras potenciales de accesibilidad en un momento en el que todavía es relativamente fácil y poco costoso arreglarlas.

Evaluación

Es la tercera fase de un proceso de DCU.

La evaluación de la accesibilidad suele verse limitada a la comprobación de la conformidad con los estándares de accesibilidad.

La conformidad con estos estándares es importante: en algunos casos es un requisito legal y en otros es sólo una buena forma de comprobar que se han tenido en cuenta, adecuadamente, todos los problemas de accesibilidad.

Sin embargo, cuando se presta atención solamente a los aspectos técnicos de la accesibilidad, el factor de la interacción humana puede llegar a perderse. Los métodos de evaluación de la usabilidad pueden comprobar la accesibilidad usable para garantizar que tus soluciones de accesibilidad son usables para las personas con discapacidad.

Técnicas de filtrado

Las técnicas de filtrado implican la utilización de estrategias de adaptación, dispositivos de ayuda y tecnologías de apoyo.

Por ejemplo, que un diseñador de software apague su monitor y utilice un lector de pantalla para interactuar con su aplicación o que un especialista en usabilidad utilice un puntero bucal o desenchufe su ratón para hacerse una idea de cómo de usable es su producto para las personas que no puede usar los brazos o las manos.

Las técnicas de filtrado no son simulaciones de discapacidades. Es probable que a las personas con discapacidad les resulte más fácil utilizar el producto que a las personas que estén utilizando técnicas de filtrado.

Se utilizan porque son fáciles, rápidas y económicas y identifican problemas potenciales de diseño en la fase inicial, lo que evita altos costes de rediseño y retrasos en el proceso.

Por ejemplo en "Preliminary Review of Web Sites for Accessibility" de la WAI se citan determinadas técnicas de filtrado.

Planificación de las pruebas de usabilidad

Los cuatro grupos más habituales de discapacidades (visuales, auditivas, físicas y cognitivas) no son suficientes para categorizar las características de los participantes en un estudio de usabilidad, debido a la diversidad que existe dentro de cada categoría (la discapacidad puede ser temporal o permanente, puede haber nacidocon ella o no, pueden usar diferentes tecnologías de apoyo, etc.).

Por otra parte, el número de participantes con discapacidad que forman parte de una prueba de usabilidad concreta suele estar determinado por los limitados recursos de un proyecto.

Teniendo en cuenta estas dos variables, el autor nos da una serie de consejos sobre la selección de las personas, siendo importante recalcar que hay que evitar cometer el error de pensar que un participante los representa a todos.

Cómo completemento proporciona un Formulario de selección de participantes que se utiliza para determinar si un participante potencial encaja con las características de usuario definidas en el protocolo de la prueba de usabilidad

A la hora de decidir dónde se realizan las pruebas de usabilidad es importante tener en cuenta las tecnologías de apoyo, por ejemplo puede que los participantes no sepan cómo configurar las tecnologías de apoyo en tu laboratorio para poder trabajar, porque están acostumbrados a que funcionen de una forma determinada en sus sistemas.

También es importante planificar el tiempo y los descansos en base a las características de cada discapacidad.

Preparación de las pruebas de usabilidad

En este capítulo se dan muchos consejos prácticos para la preparación de las pruebas (instalaciones, materiales, etc.)

Realización de las pruebas de usabilidad

En este capítulo se abordan las cuestiones que permitirán realizar con éxito las pruebas (acondicionamiento de la sala, orientación del participante, recogida de datos, etc.)

Elaboración de informes

Para analizar los datos y realizar informes sobre un estudio de usabilidad que ha contado con participantes con discapacidad, hay que tener en cuenta las siguientes consideraciones:

Distinguir entre los problemas de usabilidad (es decir, que influyen a todos los usuarios por igual, independientemente de sus características) y de accesibilidad (es decir, reducen el acceso de las personas con discapacidad a un producto).
Incluir parámetros relevantes del estudio, por ejemplo las estrategias de adaptación y tecnologías de apoyo que utiliza cada usuario y su experiencia con productos similares.
Tener cuidado con las categoriaciones y las comparaciones, especialmente si la amplitud del muestreo es pequeño.
Elaborar conclusiones claras. Hay que dejar claro qué afirma el informe y qué no. Por ejempplo, unos resultados positivos en las pruebas de usabilidad no garantizan que el producto sea accesible para todas las personas con discapacidad, ni que cumpla los estándares de accesibilidad.
Utilizar un lenguaje apropiado para referirse a las personas con y sin discapacidad.

Lista de verificación para las pruebas de usabilidad

Este apartado es muy útil porque resume todos los puntos tratados en los capítulos referidos a la fase de Evaluación en una checklist.

Recursos

Selección de recursos y enlaces de interés (no se actualiza desde 2004)

Artículos relacionados:

Faz nº2: artículos que han llamado mi atención

2008-08-27T09:00:00.000+02:00

Tres son los artículos que más han llamado mi atención en el número 2 de la revista Faz.

1

En "Evaluación de Valencia y Contenido Emocional Para Interfaces Web Gráficas: Un Caso de Estudio en Banca Chilena", Claudio Lavín y René San Martín sintetizan un estudio cuyo objetivo ha sido evaluar las reacciones emocionales generadas por el nuevo sitio Web de una de las principales instituciones bancarias de Chile, y el desafío metodológico que ello les ha supuesto.

Como las emociones son un fenómeno dinámico y multicausado, la herramienta ideada es una batería de pruebas que han denominado "batería para la evaluación de emociones elicitadas por interfaces Web gráficas (BEEI Web)".

Estas pruebas son:

"Contraste de sitios". Esta prueba operacionaliza la valencia emocional (1) en término de expresiones de agrado y desagrado hacia las interfaces Web gráficas.

Resumido muy, muy escuetamente, se proyectan imágenes de páginas web y en tres segundos los participantes deben decidir si les agrada o no cada imagen.

“Elicitación de conceptos” permite evaluar el componente semántico asociado a las emociones. Dicho componente semántico dice relación con los conceptos y el significado que se asocia a una interfaz Web gráfica.

Resumiendo de nuevo, consiste en proyectar imágenes de webs y que los participantes escriban los cinco primeros conceptos que les vienen a la mente en relación con las mismas.

2

En "Diez heurísticos emocionales" Eva de Lera y Muriel Garreta-Domingo explican su estudio piloto.

En el análisis de evaluación de la interfaz se consideraron las tres dimensiones.

La dimensión cognitiva se analizó a través del número de clics, el tiempo que se necesitó para llevar a cabo la tarea y el número de errores.

La percepción emocional del usuario se obtuvo a través del cuestionario de respuesta y la dimensión afectiva se observó a través de los diez signos emocionales. Asímismo se registraron las expresiones y los comentarios de los usuarios para complementar los resultados de la evaluación.

Un equipo multidisciplinario observó las pruebas: un director de la experiencia del usuario, un psicólogo y un diseñador gráfico.

En el análisis realizado por los observadores, tanto de las interacciones como de las observaciones registradas, se llegó a la conclusión de que los signos emocionales, junto con los datos objetivos, aportaban una comprensión más precisa sobre la experiencia del usuario y su nivel de satisfacción que el cuestionario rellenado al final de la prueba.

Los diez heurísticos son:

Fruncir el ceño

Elevar las cejas

Desviar la mirada

Sonreír

Apretar los labios

Mover la boca

Expresarse oralmente

Tocarse la cara con las manos

Reclinarse hacia atrás

Inclinar el cuerpo hacia adelante

3

En "Aprendiendo de los videojuegos" Joaquín Márquez Correa nos hace una propuesta muy interesante: levantar la cabeza de la mesa de trabajo y mirar alrededor. Abrir la mente para ofrecer nuevas soluciones.

Propone observar el diseño de otro tipo de productos para buscar inspiración y buenas ideas para el diseño de interfaz. Como ejemplo, en el artículo habla de las cuatro características que tiene todo videojuego y que deberíamos tener en cuenta también en el diseño de nuestros portales:

Adaptación a la tarea: abandono y retomo cuando quiero

Apoyando el proceso de aprendizaje: más experto, más opciones

Personalización estandarizada: mis preferencias siempre conmigo

Modo arcade v/s modo historia; tareas simples v/s tareas complejas

Notas
(1) Capacidad de los objetos que percibimos para provocar una emoción, y que es prácicamente automática.

Metodología DCU MPlu+a

2008-03-07T09:14:00.008+01:00

En el año 2004, Toni Granollers i Saltiveri, profesor de la Universidad de Lleida, presentaba su tesis doctoral: "MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona-Ordenador y la Accesibilidad en el contexto de equipos de desarrollo multidisplinares", que está disponible en la red en 5 PDF.

Aunque no está concebida como un manual, lo cierto es que esta tesis de 562 páginas se convierte en un auténtico manual de Diseño Centrado en el Usuario y Usabilidad gracias a todos los temas que trata y a su claridad.

Lo recomiendo a todos aquellos que buscan referencias de calidad gratuitas sobre estas disciplinas.

La parte central de la tesis se centra en su propuesta de metodología que bautiza como MPlu+a:

[...] modelo de diseño y desarrollo de sistemas interactivos centrado en los usuarios al que hemos denominado “Modelo de Proceso de la Ingeniería de la Usabilidad y de la Accesibilidad, MPIu+a”.

Este modelo de proceso, que se fundamenta en la disciplina de la Interacción Persona-Ordenador (IPO) y también en las Ingenierías del Software y de la Usabilidad, proporciona la manera de proceder organizada y formalizada para conseguir usabilidad y accesibilidad en el diseño de interfaces de usuario durante el desarrollo de un sistema interactivo.

El esquema de la metodología es el siguiente:

[D-1]
[Ver imagen "Esquema de la metodología MPlu+a" más grande]

Dentro del apartado dedicado a la fase de prototipado, además de explicar los distintos tipos que existen, aporta un modelo de prototipado nuevo muy interesante que bautiza con el nombre de StoryBoard Navegacional:

Con esta técnica se representan en un espacio bidireccional (con papel, en una pizarra, con impresiones de pantalla y flechas con rotulador, etc.) todos los estados de las interfaces (pantallas…) de la parte del sistema que se examinará y todas las posibilidades a nivel interactivo desde cada uno de estos estados para visualizar las posibles acciones o movimientos que el usuario puede realizar mientras interacciona con la interfaz.

[D-2]
[Ver imagen "Ejemplo de storyboard navegacional" más grande]

De la misma manera, Granollers explica las diversas técnicas de evaluación de la usabilidad que existen, aportando una nueva que bautiza como Recorrido cognitivo con usuarios, que se explica con detalle a partir de la página 38 del tercer PDF de la tesis.

Hay que destacar que el modelo de proceso metodológico está basado en la participación en el mismo de un equipo de personas multidisciplinares. En este esquema se muestra cómo participan en las diversas fases las distintas disciplinas:

[D-3]
[Ver imagen "Participación multidisciplinar en MPlus+a" más grande]

Otra aportación de la tesis es un nuevo concepto: el Esfuerzo de Usabilidad (EU), con el que se pretende medir el nivel de usabilidad del sistema implementado, y que se define como:

[...] medida que indica los recursos empleados y las actividades realizadas durante el desarrollo de una aplicación interactiva con la finalidad de conseguir un determinado nivel de usabilidad.

Con ello se pretende tener al final de cada implementación un número que revele “la cantidad de esfuerzo realizado” para conseguir la tan deseada usabilidad, obteniendo así una medida cuantitativa indicadora de la usabilidad del sistema a partir de las actividades realizadas durante la consecución del sistema.

Supone la primera aproximación conocida de valorar la usabilidad de un sistema a partir de ligar el procedimiento con el resultado.

Para el cálculo de este valor se utiliza la HT-DC (Hoja de Trabajo de la Gestión de la Configuración) en la que se incluye por orden cronológico todas las actividades realizadas. En esta imagen se ve un ejemplo de HT-DC:

[D-4]
[Ver imagen "Ejemplo HT-DC" más grande]

Las fórmulas para el cálculo matemático se explican a partir de la página 30 del cuarto PDF.

Es interesante que "el valor del EU no es equivalente al dinero invertido en la usabilidad del sistema. Esto es debido a que la metodología seguida para conseguir este valor puntúa la realización de las actividades y no el precio que cuesta realizarlas. Lo importante son las actividades bien realizadas, pues su coste económico puede variar mucho en función de parámetros como la aptitud del evaluador, su experiencia o su “caché” personal."

El EU mínimo es un valor comprendido en el rango [1200, 1600] aunque los valores comprendidos entre [2200, 2500] son los que mejor recogen la experiencia del usuario y contribuyen a optimizar la usabilidad del sistema.

Granollers propone un conjunto de ciclos básicos de la aplicación del modelo de proceso, con el que han constatado que se consiguen resultados considerablemente buenos con un esfuerzo que suele encajar en los márgenes presupuestarios de cada proyecto, y que se refleja en este esquema:

[D-5]
[Ver imagen "Ciclos básicos del modelo" más grande]

Se explica cada ciclo a partir de la página 43 del cuarto PDF.

Puedes también consultar el portal donde los miembros GRIHO (Grupo de Investigación de la Disciplina de la Interacción Persona-Ordenador) de la Universidad de Lleida, al que pertenece el doctor Granollers, presentan su modelo de DCU MPIu+a.

Artículos relacionados
[01-10-07] La usabilidad como metodología para el desarrollo ...

Reseña: “Pensar primero”

2007-12-11T16:24:00.000+01:00

Todos los caminos son buenos para quién no sabe a dónde va
Lewis Carroll

El otro día pasé un buen rato leyendo "Pensar primero" de Daniel Mordecki, libro que te puedes descargar gratuitamente en PDF.

No es un libro que le vaya a enseñar nada nuevo a un profesional de la usabilidad, pero sí que debería ser leído por todas las personas involucradas en el desarrollo de software como una excelente y amena introducción al Diseño de Interacción. Se lee en unas cuatro horas y sin duda te arrancará bastantes sonrisas.

Resumo a continuación el contenido del libro, que como digo gira entorno al Diseño de Interacción. Quizás algún programador se sienta ofendido, por ello comentaré primero que el autor afirma que:

Los programadores son gente inteligente, desarrollan una tarea extremadamente exigente, que les requiere muchas veces jornadas muy largas de trabajo bajo la presión de cronogramas y fechas límites. No se empecinan en mantener interfaces pobres porque sí, sino porque en el acierto o en el error están absolutamente convencidos que son las más adecuadas. Las pruebas de usabilidad son uno de los pocos caminos para revertir estas opiniones cuando están equivocadas y probablemente sean la de mejor relación costo/beneficio.

El autor, lo que realmente defiende, es que el programador debe poder dedicar el 100% de su tiempo a programar, que no deben recaer sobre él tareas que habitualmente realiza y para las cuales no está formado.

Los objetivos de la programación y del diseño de interacción van por caminos separados, por lo que no es viable que quién esté programando sea capaz de diseñar (no hablamos de diseño gráfico). No sólo se trata de tareas disjuntas en el tiempo, dado que el diseño antecede a la programación, sino que las metodologías, objetivos y requisitos son completamente distintos.

Describe situaciones habituales en las que los programadores suelen poner el foco en la tarea misma, seguros de que cuántas más tareas sea capaz de realizar una aplicación más feliz va a ser el usuario, incapaces de entender a los que están al otro lado de la pantalla. Achacan los problemas de una aplicación a que los usuarios no leen los manuales, a que los usuarios deberían formarse más, ser más cuidadosos o prestar más atención.

[Ojo, son palabras del autor, aunque he de decir que he vivido situaciones similares a las que cuenta, y yo misma he oído a menudo comentarios del tipo bueno, pues si el usuario hace eso peor para él, ya se dará cuenta de que no debe hacerlo]

El objetivo del libro es mostrar que los problemas no residen en los usuarios sino en el propio software.

El diseño de la interacción está focalizado en las necesidades de los seres humanos, la programación está centrada en las necesidades de las computadoras. Unas y otras son bien distintas. Mientras que los humanos somos imprecisos, nos equivocamos, somos ambiguos y cambiamos de opinión y gusto, las computadoras son exactas, precisas, inequívocas, lógicas y repetitivas.

El diseñador de la interacción se preocupará de que el software hable el lenguaje de quien lo va a usar y no el lenguaje de la computadora.

El autor hace hincapié en que demasiado a menudo se empieza a programar antes de diseñar la aplicación, insistiendo en que el Diseño de la Interacción debe realizarse obligatoriamente antes de programar: "diseñar primero, programar después", es la máxima del libro.

Si pensáramos en sentido inverso y aplicáramos los usos y costumbres informáticos a la ingeniería civil, entonces después de una reunión de dos o tres horas, donde le indican al gerente de proyecto que se va a construir un edificio con 30 apartamentos de dos dormitorios, cocina, living comedor y otras facilidades, de 75m2 cada uno, con 15 cocheras y de categoría media, éste se dirige al terreno y sentencia: "muchachos, vayan haciendo un pozo acá de más o menos 5 metros como la vez pasada, creo que con eso va a alcanzar, así adelantamos mientras yo hago los planos. Si después hay alguna diferencia vemos".

Diseñar antes de programar es menos costoso, genera software de mejor calidad y usuarios más satisfechos, todo lo cual se traduce en una relación costo/beneficio excelente comparada con las metodologías que no lo hacen así:

diseñar reduce la cantidad de cambios a realizar sobre la marcha

los programadores podrán concentrarse exclusivamente en su tarea: programar

el software tendrá menos parches, con un modelo de datos más refinado, con menos opciones ocultas, desarrollado por programadores focalizados 100% en la tarea, sin duda será más compacto y eficiente, y por lo tanto tendrá menores requerimientos de equipamiento

El código es como el hormigón: una vez que está escrito, la estructura endurece y los cambios se volverán inviables […] Los cambios se plasmarán en parches al código que, a pesar de que desarrollan la función solicitada por el cliente, aumentarán la probabilidad de introducir errores y dificultarán enormemente en el futuro el mantenimiento de la aplicación […]

El proceso de Diseño de la Interacción aplicado antes de la programación genera pues usuarios más satisfechos, entendiendo que la satisfacción de un cliente no es el resultado abstracto de un producto "bueno", sino la relación entre su percepción del producto que recibe y las expectativas que tenía antes de recibirlo.

Cinco son objetivos del Diseño de la Interacción:

Definir el producto final: sin esta definición es imposible saber cuándo está el producto acabado.

Acotar y minimizar los costos: el costo no se dispara porque fue mal estimado, sino porque se estimó el costo de una solución muy distinta a la que se terminará implementado.

Poner el foco en el usuario.

Sacar la presión que el diseño implica para el equipo de programación.

Hacer creíbles y "cumplibles" los cronogramas.

Las tres herramientas del Diseño de Interacción son:

Los personajes

Los objetivos

Los escenarios

Personajes

Daniel menciona las típicas reuniones que todos hemos vivido en que gerente, programador, diseñador, etc. defiende con vehemencia que el usuario preferirá tal o cual solución. En realidad todos ven a un usuario completamente distinto… extremadamente parecido a sí mismo, a un amigo o a un conocido, y discute encarnizadamente para imponer su visión de lo que es mejor.

La solución son los personajes, que tendrán nombre propio, y dicho nombre sustituirá al término "usuario" que hay que desterrar. Los personajes son personas ficticias (nunca reales) pero con una descripción lo suficientemente detallada para que pueda contestar a las preguntas de qué necesita el usuario, para lo cual deberán ser representativos de las personas que usan el programa.

Tendremos tantos personajes como roles distintos. Además de los personajes principales podrá haber personajes secundarios, que no son destinatarios finales pero también tienen su relevancia.

Hay que tener en cuenta que cuantos menos personajes mejor, puesto que cada personaje agrega una enorme cantidad de complejidad adicional: si tiene más de 5 o 6 personajes, entre principales y secundarios, lo más probable es que esté haciendo las cosas mal.

Objetivos

Realizamos tareas, anhelamos objetivos. Es necesario reposicionar el foco y pasar del software que hace cosas al software que ayuda a quien lo usa a conseguir objetivos.

Diseñar es encontrar dentro del espectro de objetivos de nuestros personajes el nivel justo de detalle que los comprenda y describa de forma útil para el desarrollo de la aplicación. […] Los objetivos de los usuarios potenciales deben jugar el rol de equilibrar y amalgamar las funcionalidades del software en un todo único.

Escenarios

La función de los escenarios es vincular los objetivos de los usuarios con las acciones concretas que desarrollan al utilizar la aplicación. Cada uno de los objetivos debe ser analizado minuciosamente para encontrar la lista completa de las tareas que hay que realizar para alcanzarlo.

Cada tarea debe ser puntuada del 1 al 5 en tres atributos para más adelante ordenarlas y ubicarlas:

Nivel de importancia: cuán importante es la tarea para alcanzar el objetivo.

Nivel de dificultad de implementación: en combinación con el nivel de importancia, el nivel de dificultad nos va ayudar a ponderar el esfuerzo de diseño y programación que hay que poner en una tarea determinada.

Frecuencia: la frecuencia con que repetimos una tarea tiene una importancia vital para el diseño.

Existen distintos tipos de escenarios:

Los de uso diario: son la quintaesencia del diseño de aplicaciones porque es allí donde los usuarios serán infinitamente felices o rabiosamente desdichados.

Los de uso periódico: son aquellos que responden a algún objetivo de algún personaje, pero no son utilizados a diario sino de forma esporádica.

Los de uso necesario: no existen para satisfacer necesidades de los usuarios, sino necesidades de la aplicación, como por ejemplo las pantallas de configuración, que deberían ser eliminadas. Programe para averiguar la información que necesita en vez de preguntarla.

Situaciones límite: desde el punto de vista de la programación son vitales, desde el punto de vista del usuario no, siempre y cuando este conserve el trabajo realizado hasta el momento.

Daniel parte de que se debe proponer una metodología práctica que permita enfrentarnos a problemas concretos, con presupuestos concretos y otras restricciones también concretas. Por eso propone dedicar, desde el punto de vista del Diseño de Interacción: el 75% del esfuerzo para los escenarios de uso diario, el 20% para los de uso periódico, 5% para los de uso necesario y nada para los de caso límite.

Si está diseñando un sitio Web, dibuje un recuadro para cada página que tendrá que diseñar, verifique que están todas, y pinte con un color distinto cada página según pertenezca a un escenario de uso diario, periódico, necesario o de caso límite. Verificará con sorpresa que va a dedicar el 70% del tiempo en el diseño del 10% de las páginas.

Una vez completado el proceso de definición de los personajes, descriptos sus objetivos, desglosados estos objetivos en tareas que se agrupan en escenarios, estamos en condiciones de especificar cómo se presentará el sitio ante los ojos de los usuarios.

Especificar la interfaz es dar el paso siguiente y determinar unívocamente, sin ambigüedad alguna, cómo será cada uno de los elementos de la interacción del sitio.

Para ello se propone dos técnicas: o desarrollar un esqueleto estático o un StoryBoard.

En ambos casos deben estar comentados al detalle, puesto que los programadores están acostumbrados a ir añadiendo/modificando/improvisando elementos del interfaz a medida que lo programan, adaptando la interacción a la implementación, y el resultado acaba alejándose del diseño original.

El esqueleto estático es una colección de páginas Web vinculadas entre sí que simulan el funcionamiento que tendrá el sitio una vez que esté terminado, definiendo a la vez, de forma unívoca, la interacción del sitio con sus visitantes. No es un prototipo, puesto que los prototipos no son completos y el esqueleto sí: tiene el 100% de las páginas. Además los prototipos no contemplan todos los detalles pero el Diseño de Interacción debe necesariamente contemplarlos todos.

Siempre es mejor contar con el diseñador gráfico (aunque siempre hay quien decide que si no llama al diseñador tendrá un contendiente menos para discutir) al especificar la interacción, tendríamos así la maqueta completa, que le pasaríamos a los programadores.

El StoryBoard consiste en crear las pantallas del sitio en imágenes, es más rápido de crear y modificar o de hacer distintas versiones, pero también resulta menos preciso, más lineal y es más difícil representar la interacción.

Daniel pasa entonces de la disciplina del Diseño de Interacción al de la Usabilidad:

El diseño de la interacción es la herramienta para construir un sitio o una aplicación desde cero. La usabilidad testeará lo que el diseño construyó primero. Y las distintas soluciones a los problemas son producto del diseño, la usabilidad encuentra los problemas pero no los resuelve, esta es tarea del diseño de la interacción.

El desafío de la Usabilidad es entender cómo ven el software quienes lo utilizan, qué piensan cuando lo usan, qué pistas le otorgan a los usuarios las respuestas que el software les da, entender por qué toman sus decisiones cuando se deciden por una u otra opción. La Usabilidad tiene como objetivo analizar el nivel de coincidencia que el modelo de representación de una aplicación o sitio Web expresa a través de su interfaz, con el modelo mental del usuario que está sentado frente a ella.

Para ello es necesario realizar test de usuarios. Daniel, de forma muy pragmática, indica que siempre es mejor un test improvisado, con cualquier compañero no involucrado en el proyecto, que no realizar ningún test. Aunque afirma que cualquier cosa no puede ser considerada una prueba de usabilidad decente, cree que una prueba mínima, con cualquiera que encontremos en el pasillo, posiblemente nos mostrará errores obvios que tuvimos delante de nuestras narices 18 meses sin verlos.

La usabilidad produce dos entregables:

Un análisis de la aplicación que encuentra las debilidades que alejan a los usuarios de sus objetivos cuando interactúan con ella.

Una sistematización de lo aprendido en las pruebas de usabilidad para encontrar patrones de problemas, guías de usabilidad basadas en el análisis empírico de las distintas situaciones.

Los test de usabilidad no prueban una tesis a partir de una hipótesis como en un teorema, sino que constituyen un insumo vital, que sumado a la experiencia, conocimientos y sentido común del diseñador, le permitirán perfeccionar el comportamiento interactivo de una aplicación.

Por último, me hace gracia cómo consuela a los diseñadores con una gran verdad:

Cuanto mejor es el diseño, menos se nota, y por lo tanto menos elogios recibirá. El buen diseño de la interacción produce aplicaciones y sitios Web sencillos, directos, de comprensión inmediata: no recibirá ningún elogio por ellos, salvo de algún experto que conozca lo difícil que es alcanzar un resultado de calidad. Eso sí, no intente explicar que el éxito se debe al excelente diseño, todos le contestarán al unísono: "¿esas paginitas con dos o tres gif son un 'excelente diseño'?".

Como dice Daniel, eso es posiblemente lo que le pasó al diseñador de Google.

La usabilidad como metodología para el desarrollo de una aplicación

2007-10-01T19:05:00.005+02:00

Artículos relacionados
[15/03/2012] Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística
[07-03-08] Metodología DCU MPlu+a
[11-03-08] Wireframes
[15-11-07] Disciplinas relacionadas con la usabilidad

Introducción

Cuando preguntas dentro del mundo de la informática "¿qué es la usabilidad?" dirigiéndote a aquellos que no son expertos en la materia, puedes obtener cualquier respuesta. Desde un "ni idea", a un "me suena", a un "¿lo del Nielsen ese?". Puede parecer imposible a los que nos dedicamos a esto, pero es la realidad.

Muchas personas confunden además los términos "usabilidad" y "accesibilidad", que sin bien están estrechamente relacionados, ni son sinónimos ni antónimos. Creo además que hay mucha más gente que sabe lo que es la accesibilidad (aunque lamentablemente lo reduzcan a "que los ciegos puedan acceder a una aplicación") que los que saben realmente qué es la usabilidad.

Cuando encuentras a alguien (hablo siempre de personas que no son profesionales de la usabilidad) que afirma que sí sabe lo que es la usabilidad, lo más habitual es que te digan que "se trata de conseguir que una aplicación sea fácil de usar" y muchos aluden a varias "reglas" para conseguirlo.

Para la mayoría de los profanos la usabilidad se reduce a una serie de reglas, reglas como "que los enlaces estén subrayados", "que los menús estén siempre en el mismo sitio", "poner migas de pan y un mapa del sitio".

Por supuesto es cierto que toda persona dedicada a la usabilidad debe, no ya conocer, sino tener interiorizadas unas pautas de usabilidad, pero la usabilidad es más que unas pautas, que unas leyes o que determinados estudios y personajes, la usabilidad supone toda una metodología de trabajo.

¿Por qué fracasó ese portal web?

Parecía el portal perfecto. Tanto los desarrolladores como los clientes estaban más que satisfechos. Era precioso, tenía mucha información, era rápido, no había errores, estaba exquisitamente programado, incluso era accesible doble-A.

Y sin embargo, cada vez recibía menos visitas, éstas abandonaban rápidamente el portal, nadie realizaba trámites o compras online…

Ese portal fracasó por una única razón, porque estaba centrado "en el cliente". El cliente redactó los textos, el cliente decidió cómo estructurar el portal, el cliente, el cliente, el cliente…

¿Y el usuario?

El portal no resultaba útil a los usuarios, quienes se sentían perdidos, incapaces de encontrar la información o realizar las tareas para las que entraron.

La usabilidad como metodología de trabajo: Diseño Centrado en el Usuario(UCD)

El Diseño Centrado en el Usuario(UCD) es una metodología estructurada de desarrollo de producto que implica a los usuarios a través de todas las etapas de desarrollo del mismo. El objetivo es crear un producto que aúne los objetivos de negocio de una organización y resuelva las necesidades de los usuarios.

Los beneficios son conocidos por todos: aumenta la productividad, la satisfacción del cliente y las ventas, se reducen costes, etc.

Podría basarme en muchas fuentes o citar mucha bibliografía para desarrollar el tema de la usabilidad como metodología de trabajo, pero voy a centrarme en una única fuente que me encanta y que creo que debería ser la web de cabecera de todo jefe de proyecto: la metodología desarrollada por el gobierno de EEUU en materia de usabilidad que se recoge en usability.gov

Seguramente tú hubieras escogido otras fuentes, ¿las compartes en los comentarios?

Esta metodología consta de 4 pasos:

Plan
Analyze
Design
Test & Refine

- Step-by-Step Usability Guide -

Voy a resumir brevemente cada paso. Para desarrollar cada apartado, ver ejemplos, etc. podéis acudir directamente a usability.gov

Plan

Think About the Process

Reflexiona sobre la audiencia que deseas atraer al portal y clasifícala por grupos, por roles en relación con el portal, etc.

Verifica tus presunciones previas acerca de los usuarios del portal: qué necesidades tienen, qué expectativas, qué nivel de conocimientos sobre el tema que trata, qué experiencia con sitios similares, etc.

Follow Research-Bases Guidelines

En este apartado se recogen las pautas de usabilidad que toda persona involucrada en la creación de un portal web (diseñadores, maquetadores, especialistas de usabilidad, etc.) debe interiorizar:

Develop a Plan

Se trata de realizar el Project Plan, establecer el alcance del proyecto, los objetivos, entender los requisitos, establecer el timeline, pensar en los recursos necesarios y los costes.

Assemble a Project Team

El siguiente paso lógico es crear el equipo de trabajo correctamente dimensionado y con los perfiles necesarios: especialistas en usabilidad y arquitectos de la información, diseñadores gráficos, escritores web, programadores, especialistas en la materia sobre la que trata el portal, etc.

Hold a Kick-Off Meeting

Kick-off meeting hace referencia aquí a la reunión interna de comienzo del proyecto, con tu equipo, para aunar criterios. Por kick-off meeting yo suelo entender la reunión con el cliente para hablar sobre los requerimientos del proyecto, los objetivos, sus usuarios, etc.

Lo más interesante de este apartado en la lista de preguntas que no pueden faltar en el kick-off meeting y que nos sirve para ambos casos.

Write a Statement of Work (SOW)

En este apartado se recoge el caso de que se vaya a subcontratar el diseño y las tareas de usabilidad, en cuyo caso es necesario redactar un SOW (se incluyen ejemplos) describiendo el trabajo que se debe realizar, el timeline, etc. de modo que el empresa aspirante pueda realizar una oferta. Se apunta también cómo valorar esa oferta.

Hire a Usability Specialist

Especifica cómo seleccionar a un experto cualificado en usabilidad, indicando qué conocimientos y experiencia es necesario que tenga.

Analyze

Evaluate Your Current Site

Se trata de evaluar el portal actual de la organización y contestar a tres preguntas: ¿cumple con los objetivos de la organización? ¿satisface las necesidades de los usuarios? ¿sigue las pautas de usabilidad?

Para contestar a estas preguntas se proponen distintas acciones: revisión de logs, test de usabilidad, revisión heurística, etc.

Learn About Your Users

Es este apartado se explican las diferentes técnicas para recopilar toda la información posible sobre los usuarios del portal: test de usabilidad, entrevistas contextuales, focus groups, etc.

Conduct Task Analysis

Se trata de estudiar las tareas que se pueden realizar en el portal, las que los usuarios intentar realizar y cómo las realizan. De este modo se puede establecer qué tareas son necesarias, refinando la navegación o la búsqueda para facilitar la manera más eficiente de realizarlas y emparejándolas con las metas de los usuarios.

Develop Personas

Este punto me encanta. Gracias a todo lo anterior tenemos claramente identificados a los grupos de usuarios de nuestro portal. Bien, pues se trata de que cada grupo sea representado por un personaje ficticio.

Se debe crear una ficha para cada uno de estos personajes, una ficha con foto, nombre y apellidos, datos personales (su edad, educación o etnia), datos profesionales (cargo y responsabilidades), datos referentes a sus objetivos, metas y tareas en relación con el portal, etc. Y por supuesto colgar estas fichas en la pared a la vista de todo el equipo.

¿Por qué se hace esto? Por muchas razones:

De este modo las metas y necesidades de los usuarios se convierten en el objetivo común de todo el equipo
El equipo se concentra en diseñar un portal para un número manejable de personajes que saben que representan las necesidades de muchos usuarios
Los diseños se evalúan constantemente contra los personajes
Los desacuerdos sobre el diseño se resuelven referenciándolos a los personajes
Etc.

Según Forrest muchas compañías como Microsoft desarrollan personajes porque permiten:

Una comprensión mejor de los clientes
Ciclos más cortos de diseño
Mejor calidad del producto

Write Scenarios

En este apartado se detalla cómo elaborar los escenarios. Un escenario es una historia corta sobre un usuario específico con una meta concreta en el portal, por qué viene al sitio y qué desea hacer.

Es crítico para el diseño del portal, puesto que si tienes los panoramas más comunes antes de construir el sitio, estarás centrándote en el usuario y las tareas que este desea realizar en el portal antes que en la organización y la estructura interna del mismo. Sabrás qué contenido debe tener el sitio y qué contenidos deben ser los más fáciles de encontrar y entender.

Set Measurable Usability Goal

Se trata de establecer metas mensurables de usabilidad en cuanto al tiempo para realizar una tarea, la exactitud con la que se realiza y el éxito en su realización.

Un ejemplo de meta mensurables sería: que el 95% de los viajeros sean capaces de realizar una reserva online en menos de dos minutos.

Design

Determine Web Site Requeriments

Antes de empezar el diseño, es necesario tener claros los requisitos, es decir, las características, las funciones y el contenido del portal, todo lo que debe tener y lo que debe admitir que los usuarios hagan.

El resto de pasos del diseño te ayudan a cerciorarte de que el sitio está organizado, escrito, y diseñado para satisfacer los requisitos

Conduct a Content Inventory

Se trata de realizar una lista de todo el contenido del sitio, que incluya todas las páginas, e indicar por cada contenido determinados datos: url, título, descripción, quién escribió la página, responsable de su actualización, etc.

Se puede organizar por categorías o por fechas, de manera que permita saber: en un portal nuevo, todo el contenido que es necesario desarrollar de una manera controlada y metódica; en la actualización de un portal nuevo, revisar qué contenidos faltan, sobran o deben ser revisados.

Perform Card Sorting

Descripción detalla de la técnica card sorting, técnica que permite construir la estructura del portal y etiquetar las categorías de forma que la organización del sitio sea lógica para los usuarios.

Define the Information Architecture

Da las claves para definir la navegación del sitio, de manera que refleje el propósito primario de la organización y ayude a los usuarios a encontrar rápidamente la información, por ejemplo recogiendo en la home lo más importante y las tareas más realizadas. Explica cómo crear un mapa del sitio y un wireframe.

Writing for the Web

Este es un punto fundamental que muchas veces se deja de lado: escribir para la web no es lo mismo que escribir para una publicación impresa, por ello necesitamos profesionales especialistas en la redacción para la web, que conozcan las particularidades de este medio. Asimismo es necesario reflexionar sobre el contenido que se incluye, ¿es relevante ese contenido para los usuarios, es lo que desean o necesitan? El usuario no quiere leer, quiere recabar información.

Use Parallel Design

Se propone preparar varios diseños de interfaz alternativos para que después el equipo los evalúe, compare y se puedan fusionar en un diseño final mejorado.

Develop a Prototype

Llega el momento de preparar el prototipo, bien de baja-fidelidad o de alta-fidelidad, que permita comprobar la usabilidad en una etapa temprana y poder realizar modificaciones a tiempo con el menor impacto en el proyecto.

Program the Site

Ya podemos llevar a cabo la maquetación y la programación de la aplicación. Hay que destacar que es en este punto donde se deben aplicar las pautas de accesibilidad de la WAI que aseguren un resultado accesible.

Test&Refine

Learn About Evaluations

Se explica la diferencia entre evaluaciones de usabilidad como la evaluación heurística, en la que no interviene los usuarios sino expertos en usabilidad y que predicen los problemas o éxitos que tendrán los usuarios con nuestra web, de los test o pruebas de usabilidad con usuarios que indicarán si las predicciones fueron válidas.

Se deben realizar en etapas tempranas del proyecto, desde el momento en que se tiene un prototipo.

Learn About Usability Testing

En este apartado se explica en profundidad qué es un test de usuarios.

Develop the Test Plan

Se desarrolla cómo preparar el plan de pruebas de usabilidad, en el que se ha de definir el número de participantes, el número de sesiones y su duración, etc.

Create Final Scenarios

Una vez establecido y aprobado el plan de pruebas, hay que preparar los escenarios, las tareas que los usuarios van a intentar realizar en el test de usuarios.

En este apartado se explica cómo crear un buen escenario, que se entienda sin dificultad, que podría ser por ejemplo ¿En qué edificio del Gobierno puedes encontrar el cuadro que pintó Bertrand Adams en 1937 denominado "Primeros Colonos de Dubuque"?, de manera que el usuario debe encontrar esa información en nuestro portal sin ninguna pista de cómo lograr la tarea.

Recruit Participants

Se explica qué tipo de usuarios deben participar en el test de usuarios y cómo preparar un cuestionarios para seleccionarlos, especialmente útil si se contrata para esta tarea los servicios de una empresa externa. Ejemplo de cuestionario.

Set Up for the Test Sessions

Antes de comenzar el test de usuarios, ¿qué revisar? Que el prototipo funciona, que los ordenadores van bien, que tenemos preparadas las autorizaciones mediante las cuales los participantes autorizan ser grabados, que las cámaras y micrófonos funcionan, etc. o incluso hacer una prueba piloto con uno de los usuarios.

Conduct the Usability Test

Da las claves para conducir un test de usuarios: cómo tratar a los participantes, cómo contestar a las preguntas permaneciendo neutral, cómo tomar las notas (ejemplo de notas), etc.

Analyze the Results

Detalla cómo analizar los resultados, tanto los datos cuantitativos que permitirán extraer datos estadísticos como los cualitativos, en los que habrá que buscar patrones y clasificarlos según su importancia y su carácter global o local.

Prepare the Usability Test Report

Explica como preparar el informe final del test de usuarios, en el que prive la concreción, los resultados y las recomendaciones (ver ejemplo de plantilla).

Implement and Retest

Llega el momento de aplicar las recomendaciones resultantes del test de usuarios y definir el número de iteraciones necesarias para asegurar que los usuarios logran las metas con eficacia.

Artículos relacionados
[07-03-08] Metodología DCU MPlu+a
[11-03-08] Wireframes
[15-11-07] Disciplinas relacionadas con la usabilidad

Usable y accesible

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

Índice

Qué es un estándar

Tipos de estándares

Estándares formales de usabilidad

Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction

ISO 13407:1999. Human centred design processes for interactive systems

Orientados al producto: ISO 9126 e ISO 14598

ISO 9126 Software engineering — Product quality

ISO 14598 Information technology — Software product evaluation

Ventajas y desventajas de la definición de usabilidad como proceso y como producto

ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598

Aplicación práctica de los estándares formales en la evaluación heurística de la web

WUEP (Web Usability Evaluation Process)

Otras propuestas

Mplu+a

WebQEM

WQM (Web Quality Model)

QUIM (Quality in Use Integrated Measurement)

Referencias

Sirius. Nuevo sistema para la evaluación de la usabilidad web

¿En que consiste el nuevo sistema de evaluación?

Clasificación de sitios web

Heurísticos y subheurísticos

Aspectos generales

Identidad e Información

Estructura y Navegación

Rotulado

Layout de la página

Entendibilidad y facilidad en la interacción

Control y retroalimentación

Elementos multimedia

Búsqueda

Ayuda

Métrica de evaluación

Herramienta de soporte al sistema de evaluación

Excel para ayudar a la evaluación de usabilidad según la metodología Sirius

Descripción general de la Excel

Artículos relacionados

Últimos artículos

Servicios relacionados

Arquitectura de información. Fundamentos

¿Qué es la arquitectura de información?

Tipos de necesidad de información

Componentes o anatomía de la arquitectura de información

Sistemas de organización

Sistemas de etiquetado

Consejos y recomendaciones

Orientaciones metodológicas

Sistemas de navegación

Tipos de sistemas de navegación

Recomendaciones

Sistemas de búsqueda

Recomendaciones

Vocabularios o lenguajes documentales

Tipos de lenguajes documentales

Bibliografía

Artículos relacionados

Últimos anteriores

Servicios relacionados

Imprescindibles (18)

Usabilidad

SEO

Móvil

Reseña "Just Ask: Integrating Accessibility Throughout Design"

Principios básicos

Contexto: Accesibilidad en el Diseño Centrado en el Usuario

Análisis

Diseño

Evaluación

Técnicas de filtrado

Planificación de las pruebas de usabilidad

Preparación de las pruebas de usabilidad

Realización de las pruebas de usabilidad

Elaboración de informes

Lista de verificación para las pruebas de usabilidad

Recursos

Faz nº2: artículos que han llamado mi atención