Continuando con los bocetos anteriores, provocados por el post de Dani Torres Burriel, y siguendo la respuesta de Javier Cañada, ahora voy con mi kit de trabajo:

El detalle es el siguiente:

• Lápiz goma de vinilo, para borrar detalles
• Lápiz de grafito de 2.0 mm. para trazos gruesos y definitivos
• Lápiz de grafito de 0.5… sólo porque es muy lindo
• Lápices de tinta, puntas de 0.3 y 0.7 mm. para definir trazos
• Lápiz de grafito de 0.7, blando para esbozar
• Lápiz de grafito de 0.7, duro para líneas más finas y limpias
• Goma de borrar de vinilo, para cuando hay que hacer ‘undo’…

Tengo que agregar que se me quedó fuera de la foto un surtido de post-its que siempre resultan útiles tanto para hacer anotaciones como para armar prototipos un poco más elaborados, e incluso realizar diagramas.

Daniel Torres Burriel escribió una apasionada defensa del lápiz y el papel, lo que me motivó a compartir algunas páginas de mis propios bocetos, wireframes e interfaces en su estado más básico: en papel, con grafito, como ideas crudas en proceso de elaboración.

Independientemente del contexto en que se haya dicho, las expresiones de Mike Danseglio, program manager del grupo de Soluciones de Seguridad de Microsoft, son inaceptables:

Social engineering is a very, very effective technique. We have statistics that show significant infection rates for the social engineering malware. Phishing is a major problem because there really is no patch for human stupidity.

[traducción:] La ingeniería social es una técnica muy, muy efectiva. Tenemos estadísticas que muestran tasas de infección significativas para el malware de ingeniería social. Phishing es un problema mayor porque no existen parches para la estupidez humana.

Para ser justos, hay que reconocer el trabajo de equipos como el de Office 2007 y la labor de difusión de profesionales como Jensen Harris, Lead Program Manager del equipo de experiencia de usuario de Microsoft Office, pero lo de parches para la estupidez humana es demasiado.

Los usuarios no se contagian virus o gusanos porque son idiotas, es porque los programas no son lo suficientemente seguros. El compromiso entre usabilidad y seguridad es un problema permanente, pero si un sistema es vulnerado, no se puede culpar al usuario. Eso es pura irresponsabilidad.

Vamos, sé que saldrán ejemplos sobre usuarios incautos o irresponsables, pero no se trata de eso. Esto es sobre no aceptar la responsabilidad propia.

Cuando realizas evaluaciones de usabilidad, frecuentemente observas a usuarios manifestar que no han podido completar una tarea por culpa de ellos mismos. Nosotros sabemos que es por una falla de diseño y no por culpa del usuario. Y por eso estamos en esto, para solucionar esos problemas. Por eso, una afirmación como la de Danseglio es una idiotez monumental.

Tengo un interés especial en el gobierno electrónico y gran parte de mis proyectos se han desarrollado en esa área. Sin duda una de las experiencias más importantes fue participar en la evaluación de usabilidad para trámites en línea del Gobierno chileno durante el año pasado.

En esa oportunidad me hice cargo de la evaluación de 60 trámites de diversos servicios públicos, mediante evaluaciones heurísticas. Aparte de esto se desarrollaron testeos con usuarios y focus groups, aunque en ellos yo no participé.

La evaluación heurística de los sitios fue monstruosa en términos del esfuerzo que requirió:cada sitio fue evaluado tres veces por diferentes evaluadores y luego esas evaluaciones fueron consolidadas en un solo informe. Eso significa que se realizaron 180 evaluaciones en total. Esto no hubiera sido posible sin la ayuda de una herramienta que desarrollé para esa oportunidad. Se trata de una aplicación web que permitió gestionar las evaluaciones a cada uno de los evaluadores, evaluar en línea los trámites, controlar el total de evaluaciones y sus estados y generar informes automatizados, entre otras cosas.

Además de la experiencia directa que este proyecto significó, me dió la posibilidad de tener una visión que normalmente es muy elusiva: el aparato del Estado es una máquina enorme, con muchas dimensiones insospechadas y con un alcance impensable para la mayoría. Me refiero a que como ciudadano, uno normalmente tiene que realizar ciertos trámites, pero está limitado a un grupo muy concreto de tareas. La cantidad de trámites disponibles y la diversidad de ellos es sorprendente. En esto el Gobierno chileno ha realizado una labor de promoción importante. Es cierto que el nivel es aún muy desigual, y que incluso los servicios estrella, como el Servicio de Impuestos Internos, tienen importantes deficiencias de usabilidad. Pero el sólo hecho de haber comenzado con este camino ya es importante.

Pensaba contarles un poco más sobre la experiencia concreta y las observaciones particulares sobre los problemas de usabilidad de los sitios web de gobierno, de hecho inicialmente el título era otro, pero no había tenido oportunidad antes de hablarles de todo el proceso. De todos modos, me comprometo a escribir pronto sobre los problemas de usabilidad más frecuentes en los sitios de gobierno y los detalles de este proyecto en particular.

Aunque para muchos no tiene sentido hacer una distinción entre Diseño de Interacción yDiseño de Interfaces, yo creo que al menos desde la perspectiva de planificación de proyectos, es muy útil separarlos. Además, creo que es relevante tener en claro los límites y responsabilidades de diseño. En la prácica, sabemos que la línea que los separa es difusa, que forman parte de una misma cosa (el diseño de un producto) y que normalmente la misma persona va a tener la responsabilidad del diseño de interacción y del diseño de interfaces, entre otras tareas más. Pero tener una visión abstracta del proceso completo de desarrollo, ayuda a resolver problemas y a tener una visión del proyecto como una unidad.

Entonces, ¿Dónde está la diferencia entre diseño de interacción y diseño de interfaces? ¿Cómo es que dividir aún más ayuda a ver las cosas más unidas?

Enfrentar los problemas de interacción primero desde un nivel más abstracto obliga a pensar en todos los aspectos comunes del proyecto, cómo se resuelven situaciones similares en distintas circunstancias, qué reglas generales aplicaremos. Luego podemos dedicarnos aldetalle de implementar casa cosa por separado.

Hace unos días conversaba se esto con un grupo de alumnos y una forma de explicarles el problema me hizo mucho sentido: en el diálogo que se establece entre un sistema y el usuario, el diseño de interacción es el lenguaje, con su universo de reglas y restricciones y el diseño de interfaces es el vocabulario, con los verbos y términos concretos.

Exactamente esa es la relación, al menos desde mi perspectiva. El diseño de interacción es el diseño de los flujos, metáforas, las reglas y patrones generales. El diseño de interfaces se hace cargo del detalle, de la implementación de las piezas de interacción concretas: un patrón específico, un formulario determinado, con todas las decisiones que eso implica, las etiquetas, etc.

En suma, el diseño de interacción se refiere a lo general y el diseño de interfaces a lo específico. El primero produce diagramas de interacción, flujos y patrones. El segundo wireframes, storyboards y prototipos.

Hace cerca de 12 años comencé a trabajar en multimedia usando Director. Los productos típicos eran presentaciones interactivas, kioskos, y CD-ROMs interactivos. En este tipo de aplicaciones el concepto de página era tan flexible como el de las actuales RIA oaplicaciones ricas para internet. Una pantalla normalmente tenía más de un estado y los contenidos se cargaban directamente modificando sólo una zona sin necesidad de cambiar a otra página. Este es el mismo concepto de interacción de las RIA. Claro, para efectos deinteracción es irrelevante que estés realizando solicitudes asincrónicas al servidor (AJAX), o cargando contenido desde un lector de CD-ROM.

En esa época utilizábamos una herramienta prestada del mundo audiovisual para representar estas interacciones, estados y elementos dinámicos: el storyboard. El storyboard representa las pantallas, y se comentan los aspectos más relevantes, incluso las zonas interactivas o los diferentes estados. Si es necesario, se pueden representar estados especiales en hojas adicionales. En suma, todo se parece mucho a lo que Andrés Zapata presenta en The Guided Wireframe Narrative for Rich Internet Applications.

Andrés muestra una serie de wireframes con comentarios de diversos estados, la idea es flexibilizar los wireframes para adaptarse a los requerimientos de este nuevo contexto, las aplicaciones ricas usando AJAX o Flash. Pues bien, esto es prácticamente un storyboard y no es algo nuevo. De hecho, Andrés menciona en una oportunidad los storyboards, aunque tengo la impresión de que se refiere a su uso en animación.

Explorando con Google, encontré algunos recursos interesantes:

• Storyboarding Multimedia, de 1995
• Detalle de un storyboard simple
• Ejemplo de un storyboard para multimedia

Volveré más adelante sobre esto con algunos ejemplos prácticos, porque creo que será útil reflotar esta herramienta en tiempos de las RIA.

Estas ideas me vienen dando vuelta desde hace algún tiempo luego de escuchar algunos conceptos erróneos. No pretendo que sean frases para el bronce, sólo me pareció entretenido el formato:

• Usabilidad no es preguntarle a los usuarios qué hacer, es oirlos, observarlos e interpretar sus necesidades.
• Accesibilidad no es ponerle alt a las imágenes, es establecer una política organizacional que asegure la generación de contenido accesible.
• Diseño Centrado en el Usuario no es ponerse en el lugar de los usuarios, es observar a usuarios de verdad y aprender a conocerlos.

El análisis de uso del espacio en una página como herramienta de usabilidad fue coronado por Nielsen en su libro Homepage Usability: 50 Websites Deconstructed, en que analiza las portadas de 50 sitios. He utilizado este tipo de análisis varias veces, y siempre mi problema llegaba a la hora de calcular los porcentajes de las diferentes áreas. No es que sea algo difícil, incluso para los que no somos particularmente dotados con los números, pero es engorroso. Pues bien, hace un par de meses comencé a explorar una solución usando mi viejo amigo Director. Es que Lingo fue mi primer lenguaje de programación y trabajé bastante con él, y aún tengo una licencia no muy vieja de Director acumulando polvo. Puse manos a la obra y les muestro el resultado. Es de esas cosas que a veces se hacen casi por el puro placer de hacerlo. Sin embargo preveo una serie de usos, es más, acabo de utilizarla la semana pasada para evaluar 24 sitios para un benchmark. Casi demasiado jactanciosamente, les presento mi herramienta para analizar el uso de espacio en páginas. Todavía sin nombre, sus características son:

• Permite importar una captura de pantalla en diversos formatos: PNG, JPEG, BMP, GIF
• Permite dibujar múltiples zonas, eliminarlas o cambiar sus criterios
• Utiliza los criterios de Nielsen para definir las áreas
• Permite generar un gráfico de torta con los porcentajes para cada criterio y exportarlo como PNG, JPEG, BMP o GIF
• Puede exportar la captura de pantalla con las áreas dibujadas en los mismos formatos
• Puede exportar los datos en un archivo CSV para uso en planillas de cálculo

Aún faltan muchos detalles por pulir, pero funciona. Aquí van algunas pantallas:

La definición de Technorati sobre los tags comienza con:

What’s a tag?

Think of a tag as a simple category name. People can categorize their posts, photos, and links with any tag that makes sense.

Asumo que la definición intenta simplificar el problema, pero me parece esencialmente incorrecta. Tags y categorías no son lo mismo.

El uso de tags en un rango amplio de sitios es un fenómeno reciente e interesante, pero me sorprende que la diferencia entre ambos no sea suficientemente clara para muchos. Hay sitios que utilizan tags, otros que utilizan categorías y otros que hacen uso de ambos. A continuación trataré de anotar algunos aspectos importantes de ambos esquemas para comentar sus beneficios y algunos casos en que uno sea más apropiado que otro.

Categorías

Las categorías son un sistema de asociación de contenido con uno o más temas. Permitendefinir y agrupar la información estableciendo relaciones. Las categorías tienen estructuras planas (un nivel) o jerárquicas (múltiples niveles). Establecen una relación de dependencia del tipo pertenece a.

Por ejemplo:

• Recetas
  • Postres
    • Fruta
      • Manzanas
      • Peras
      • Naranjas
      • Sandías

Tags

Los tags, o keywords, son términos simples que hablan de una propiedad o característica de la información, pero no la define ni la agrupa jerárquicamente. Es información sobre la información, o un metadato. Un nodo o unidad de información puede tener uno o más tags, relacionados o no, cada uno de los cuales se refiere a una característica específica del objeto, pero que no lo clasifica o categoriza. Por ejemplo:

Manzanas

fruta, vegetales, postre, verde, roja, dulce

En este caso, cada uno de los tags habla sobre una propiedad del objeto Manzana, pero no son categorías a la que éste pertenezca. Se trata de una estructura plana de términos que lo caracterizan, en un esquema de es o tiene.

Dado que ambos esquemas son diferentes, pero no son opuestos, es posible utilizarlos simultáneamente para obtener una mayor riqueza en la organización de la información. Una estructura de clasificación es útil, por ejemplo, para establecer un esquema de navegación jerárquico. Los directorios son un muy buen ejemplo de esto.

Los tags, en cambio, permiten alimentar muy precisamente un buscador, porque identifican los términos más relevantes de un contenido. Esto es particularmente importante para contenido no textual, como fotografías, videos y audio, casos en los que no es fácil extraerlos automáticamente.

Existen casos en que es posible beneficiarse del uso de ambos esquemas por su complementariedad. Por ejemplo, Spurl.net, un organizador de bookmarks, permite organizar los bookmarks en categorías y asignarles tags. Esto facilita el encontrar la información mediante el uso de un buscador o explorando directamente las categorías o los tags.

Un factor adicional de los tags es el uso en esquemas colectivos, conocidos como folksonomía, en que cada usuario puede agregar tags a diferentes contenidos, de modo que se complementan entre ellos y ayudan a describir de modo más completo al contenido.

En el rediseño de una intranet que realicé hace poco, se definieron dos esquemas de categorización diferentes: uno centrado en los contenidos y otro en la estructura de la institución. Por ejemplo, un formulario de solicitud de vacaciones correspondería a la categoría Formularios, según su tipo de contenido y a Recursos Humanos desde la perspectiva de la organización. El primer esquema se utilizó para navegar el sitio y el segundo para aportar un esquema complementario. Adicionalmente, se sugirió el uso de tags para que los propios usuarios pudieran ayudar a definir los contenidos de un modo más eficiente y con una perspectiva centrada en los usuarios, desde abajo hacia arriba (orgánica), antes que desde arriba hacia abajo, como es el caso con los esquemas de clasificación predefinidos.

En este caso, los tags deberían contribuir a alimentar las descripciones
de contenidos mediante los metadatos, y de este modo se pueden mejorar o precisar los resultados de búsqueda.

En suma, hemos visto que:

• las categorías ordenan y agrupan contenido
• los tags hablan de características del contenido, pero no lo agrupan
• las categorías pueden ser jerárquicas
• los tags son planos, sin jerarquías
• las categorías determinan a qué pertenece el contenido
• los tags hablan de qué es o que tiene el contenido

Es cierto que se pueden realizar evaluaciones de usabilidad en las fases finales de un proyecto, pero los riesgos aumentan mucho respecto a incorporar prácticas y pautas de usabilidad desde la etapa de diseño. Si los errores o problemas se detectan de modo temprano, el costo de corregirlos es bajo. Por el contrario, si se detectan problemas al concluir un proyecto, el costo de las correcciones será mucho mayor.

Por esto es importante considerar la usabilidad como una más de las prácticas del diseño de un producto, realizando pruebas desde los prototipos más tempranos y estableciendométricas y objetivos precisos. Así, las revisiones finales y el control de calidad sólo considerará factores menores y se enfocará en comprobar que las pautas se hayan cumplido.