English version of this post

Jakob Nielsen acuño el término usabilidad (o interacción persona-ordenador) de “guerrilla” para referirse a las técnicas de usabilidad que pueden aplicarse en proyectos de desarrollo de una manera informal, rápida y con pocos recursos consiguiendo resultados aceptables y evitando la barrera que supone introducir ese tipo de técnicas.

Esa usabilidad de guerrilla tiene como ventaja que puede realizarse con (relativamente) poca implicación del equipo de desarrollo, y es por tanto aplicable en el caso de desarrollos de sitios web tradicionales. Por su naturaleza, los sitios web tienen que ser autoexplicativos y tener un funcionamiento que siga los estándares existentes, ya que su público potencial es habitualmente muy variado y no puede confiarse en conocimientos avanzados o una formación previa.

Por ejemplo, puede aplicarse perfectamente la usabilidad de guerrilla en la evaluación de un sitio web de comercio electrónico, o en el de una universidad, ya que (en principio) no necesitan mayores conocimientos previos.

Sin embargo, existen situaciones en las que no es tan sencillo…

Al abordaje

En ocasiones, los expertos de usabilidad se ven enfrentados (por no decir arrojados) a proyectos de desarrollo en los que el sistema que se está construyendo les es poco (o nada) familiar; puede tratarse de una aplicación de escritorio, una intranet o una aplicación web especializada. En estos casos es difícil plantear directamente las técnicas de usabilidad de guerrilla, ya que el experto muchas veces no conoce aspectos básicos del sistema como son el perfil de sus usuarios, sus tareas más importantes, o el contexto de uso.

En estas situaciones es necesario practicar una “usabilidad de abordaje“, en la que el experto tiene que “alcanzar” al equipo de desarrollo y “subirse a su barco” para conocer los objetivos y el estado del desarrollo, y así poder realizar una mejora de la usabilidad del sistema, “corrigiendo el rumbo” si hace falta.

Con este fin, propongo aplicar una serie de técnicas muy básicas y sencillas de entre las que se consideran generalmente como de Diseño Centrado en el Usuario:

1. Roles de usuario (y personas).
2. Casos de uso (esenciales).
3. Prototipado de interfaces.

1. Roles de usuario (y personas):
¿quién va a usar la aplicación?

Resulta curioso que, en muchos procesos de desarrollo, el perfil de los usuarios del sistema está implícito en el conocimiento de los desarrolladores, pero no existe documentación explícita al respecto. En estas situaciones, propongo que lo primero que se desarrollen sean documentos describiendo las características básicas de los roles de usuario que van a utilizar el sistema; curiosamente, en esa fase a menudo se descubre que los roles de usuario no están tan claros como parecía, o incluso aparecen nuevos roles.

Con ese propósito, una de las plantillas que pueden utilizarse es esta desarrollada por Constantine & Lockwood

User Role Model (PDF, 145 KB)

No es imprescindible seguir fielmente esa estructura; lo fundamental es que, al menos, se identifiquen los roles de usuarios de la aplicación y sus características principales.

Idealmente, esta documentación (y toda la que se describe en este artículo) debería basarse en un formato que permita su consulta y actualización de modo rápido y sencillo.

Una vez identificados esos roles es posible plantear la técnica de “personas” para tener un referente más realista de los usuarios del sistema; sin embargo, considero que es una técnica que necesita de una buena disposición por parte de los desarrolladores para ser efectiva.

2. Casos de uso (esenciales):
¿cómo será la interacción con el sistema?

Cuando existen, los requisitos del sistema están en muchas ocasiones escritos en forma de lista de funcionalidades (“la aplicación debe permitir…”), pero sin ninguna indicación de cómo debe ser la interacción entre el sistema y el usuario. Eso hace que el diseñador de las pantallas (muchas veces el mismo programador de la aplicación) tenga que hacer muchas suposiciones en el momento de la implementación, lo que a menudo produce problemas de usabilidad.

La documentación mediante casos de uso permite describir esas funcionalidades de un modo más estructurado. Existen multitud de descripciones sobre cómo deben documentarse los casos de uso; en concreto, propongo utilizar los llamados “casos de uso esenciales” definidos también por Constantine & Lockwood, en los que se utiliza una descripción semiestructurada (en modo de diálogo) y de alto nivel de la interacción entre el usuario y el sistema. Esta es la plantilla:

Essential Use Case (PDF, 146 KB)

Empezar identificando y definiendo los casos de uso más importantes y/o problemáticos del sistema ayuda a hacerse una idea más aproximada de su propósito y permite centrar los esfuerzos en aquellos puntos en los que se obtendrán  resultados más efectivos.

Además, este tipo de casos de uso tiene estas ventajas:

• Permite refinar la especificación de requerimientos, detectando problemas, inconsistencias e indefiniciones en un momento temprano del desarrollo.
• Sirve de referencia para el creador de la interfaz; la especificación de alto nivel permite que el diseñador tenga libertada a la hora de elegir tecnologías y elementos concretos.
• Serán la guía para las posteriores técnicas de usabilidad.

3. Prototipado de interfaces:
¿cómo deben ser las pantallas?

El prototipado de interfaces es una técnica ampliamente conocida y utilizada. Sin embargo, lanzarse a hacer prototipado de una aplicación sin tener una definición clara de quiénes son los usuarios y cuáles deben ser los detalles de la interacción puede ser realmente complicado. Si se han utilizado las técnicas previamente descritas, la creación de prototipos (ya sea para la creación de nuevas interfaces o el rediseño de los existentes) será mucho más efectiva.

En nuestro caso, un uso obvio del prototipado de interfaces podría ser la creación de las interfaces más críticas de la aplicación (a partir de los casos de uso más importantes), o bien la modificación de interfaces existentes (para la corrección de problemas de usabilidad).

Y a partir de ahí…

Con la ayuda de las técnicas descritas, el acercamiento a la aplicación será menos traumático y los métodos específicos de usabilidad resultarán más productivos y fáciles de aplicar: por ejemplo, las evaluaciones heurísticas se centrarán en los aspectos más importantes de la aplicación y en las características de los usuarios potenciales; y los tests con usuarios tendrán una referencia clara para el reclutamiento de usuarios en los roles de usuario, y para la definición de los escenarios y tareas en los casos de uso.

En cualquier caso, la documentación y conocimientos generados con la ejecución de esas técnicas resultarán útiles para todo el proceso de desarrollo, y no únicamente para el diseño de interfaces o las técnicas de usabilidad. En general, una de las ventajas de aplicar métodos de usabilidad en un desarrollo es que ayudan a mejorar también la calidad de los propios procesos de desarrollo y de su documentación.