Bocetos en Papel

General

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.

bocetos-ilustracion-buscador

Bocetos para ilustraciones sobre el funcionamiento de un buscador.

bocetos-ilustracion-folksonomy

Boceto para presentar el funcionamiento de la clasificación colectiva.

bocetos-ui-buscador

Ideas iniciales para la interfaz de un buscador avanzado.

bocetos-ui-cards

Boceto para la interfaz de una aplicación propia.

bocetos-ui-mayuda

Ideas para varias páginas y elementos.

bocetos-ui-noticias

Wireframes iniciales para la sección de noticias de un sitio.

bocetos-ui-varios

Más wireframes para páginas y fragmentos.

bocetos-ui-elfactorhumano

Finalmente, unos bocetos para el rediseño de El Factor Humano que algún día terminaré…

Es el Usuario, Estúpido!

General

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.

Evaluaciones de Usabilidad de Sitios de Gobierno

General

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.

evaluaciones-vista-evaluacion

Los evaluadores pueden utilizar un ordenamiento de ventanas que permite evaluar al mismo tiempo que se ve el sitio o trámite que se está revisando.

evaluaciones-vista-multiple

Todas las evaluaciones de un trámite se disponen simultáneamente para poder compararlas y consolidar un informe final.

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.

Diseño de Interacción y Diseño de Interfaces

General

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.

Storyboards y Narrativa para Wireframes Guiados

General

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:

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

No Es…

General

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.

Análisis de Uso de Espacio

General

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:

screen-01

El área de trabajo está preparada para analizar capturas de pantallas grandes, de hasta 1280×1024 píxeles. En la zona inferior, las funciones principales y la selección de criterios.

screen-02

Al crear un nuevo proyecto se importa una captura de pantalla para analizarla.

screen-03

Una vez importada la captura de pantalla se puede comenzar a definir las áreas. En la imagen, una captura de una ventana a 1024×768 píxeles.

screen-04

Se puede agregar las áreas necesarias y seleccionar los colores para los criterios deseados. Las áreas se pueden modificar o eliminar.

screen-05

Una vez definidas las áreas, se puede exportar un gráfico de torta con el uso de los espacios en diversos formatos.

exportar-final

Finalmente así es como se ve una captura analizada y exportada.

Tags y Categorías

General

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.

categoriasdmoz

Dmoz.org utiliza un esquema de categorías para organizar la información de su Directorio.

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.

tagsflickr

Flickr.com permite asociar tags a las fotografías de sus usuarios, esto facilita la descripción de las imágenes.

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.

categoriasspurl

Spurl.net permite el uso de categorías para organizar los bookmarks.

tagsspurl

De un modo complementario, Spurl.net da la posibilidad de asociar tags a los bookmarks.

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

Usabilidad No es Control de Calidad

General

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.

Proceso de Diseño Centrado en Usuario

General

Este es un artículo que tenía guardado como borrador desde hace mucho tiempo, pero finalmente lo he revisado, editado y se los presento. Se trata más bien de una serie de ideas sobre los procesos de desarrollo web, desde la perspectiva del Diseño Centrado en el Usuario. Por lo mismo, no son ideas definitivas ni absolutas, pero tratan de darle forma al modo en que procuro enfrentar el problema. Sin duda continuaré editándolo y extendiéndolo, pero no quiero dejar pasar más tiempo. Sin más, aquí va.

Desde hace bastante tiempo me interesan las metodologías y procesos de desarrollo de proyectos, particularmente las relacionadas con el web, donde la rapidez y flexibilidad es un requisito. Es un hecho que resulta vital contar con un proceso definido y adaptable, que permita resolver los problemas del desarrollo de proyectos de un modo eficaz. Factores como la optimización de procesos, reproductibilidad de las actividades, modularización e incluso manejo de riesgos justifican de sobra la adopción o creación de un proceso de desarrollo. Sin embargo, las metodologías existentes se enfocan al desarrollo de proyectos de software, en los que la funcionalidad es el eje del desarrollo y el factor humano es un dato más dentro de esta perspectiva, pero normalmente bastante disminuído:

Un factor común en la mayoría de los enfoques de la gestión de proyectos es el considerar cuatro etapas o fases principales, en una simplificación extrema esto es aproximadamente como lo siguiente:

Análisis
Como factor común la primera etapa consiste necesariamente en asimilar el problema, conocerlo y dimensionarlo para poder tener una visión completa de él. Normalmente esto significa establecer descripciones simples del problema, para luego ir progresivamente profundizando en sus detalles mediante la definición de requerimientos, identificación de la audiencia, etc.
Diseño o Planificación
Luego de la primera etapa, teniendo una definición completa del problema, se comienza a planificar la solución, tanto desde la perspectiva del manejo de proyecto, considerando la definición de roles, actividades, plazos, costos, etc., así como desde el diseño lógico, la planificación concreta de la solución.
Desarrollo
Con la planificación y diseño conceptual resueltos, se procede a desarrollar las piezas necesarias que compondrán la solución.
Distribución, Transición o Implantación
Finalmente, luego del desarrollo de las piezas que constituyen la solución, se procede a realizar las pruebas finales y se distribuiye el producto al entorno del cliente.

¿Y qué Ocurre con el Factor Humano?

Ninguno de los procesos y metodologías que he conocido considera de modo central el enfoque de diseño centrado en el usuario. RUP incluye algunos roles y actividades relacionadas, pero en rigor sólo se trata de componentes menores del proceso de desarrollo, todo el problema se enfoca básicamente desde la perspectiva de desarrollo, de ingeniería de software.

Por otro lado, el Diseño Centrado en el Usuario o User Centered Design (UCD) es más bien una disciplina, o un conjunto de ellas, que define una filosofía, antes que un proceso concreto de desarrollo. Naturalmente, las herramientas permiten establecer un proceso que se complemente con los procesos de ingeniería de software y permita crear productos más completos, funcionales y fáciles de usar. Ése es el desafío de quienes trabajamos en esta área: hacer notar que el desarrollo de software es importante en la medida que el propósito esté claro, y que no es un objetivo en sí mismo. Hablo de software porque inevitablemente nuestro medio, el web, es en mayor o menor medida un problema de software, pero antes que todo, es un problema de comunicación.

Personalmente procuro sistematizar mis propios mecanismos de trabajo y establecer una metodología lo más clara posible, con un proceso predefinido y adaptable, que contribuya a facilitar el desarrollo de los proyectos actuales y futuros. Esto es un proceso dinámico que permanentemente va evolucionando en la medida que se refinan los procedimientos y se agregan nuevas herramientas.

En concreto, las principales disciplinas relacionadas al diseño centrado en el usuario, al menos en lo que concierne al web, son la Arquitectura de Información, la Usabilidad, elDiseño de Interacción, Diseño de Interfaces y el Diseño Gráfico. En particular, soy de aquéllos que consideran la Accesibilidad como una subdisciplina de la Usabilidad, fundamentalmente porque se trata de usabilidad aplicada a tipos de usuarios con requerimientos concretos comunes.

La relación entre todas estas disciplinas es estrecha y los límites en muchos casos son difusos, pero finalmente contribuyen a generar lo que conocemos como Experiencia de Usuario. Los siguientes gráficos ilustran cómo cada una de estas disciplinas participa dentro del proceso de desarrollo y cómo se relacionan en términos de dependencias y temporalmente:

diagucdfull

El diagrama muestra la incidencia de cada una de las disciplinas durante el desarrollo de un proyecto o una iteración de éste en los modelos de desarrollo iterativos.

Este diagrama muestra las curvas de participación de las diferentes disciplinas durante el desarrollo de un proyecto, o de una iteración de un proyecto mayor. Las displinas se extienden en las etapas que identificamos representando el tiempo o el momento en que participan. Así, una de las primeras en intervenir es la arquitectura de información, capturando requerimientos, identificando grupos de usuarios, contenidos, etc. Del mismo modo, su protagonismo declina finalizando la etapa de diseño. El diseño de interacción tiene un rol relevante que en algunos caso puede reemplazar a la AI cuando el foco está más en la funcionalidad que en el contenido. Un muy buen punto sobre esto lo plantea Garrett en el clásico diagrama de Experiencia de Usuario, expandido en su libro The Elements of User Experience: User-Centered Design for the Web. Luego continúa el diseño de interfaces, concretando las definiciones del diseño de interacción. A éste le sigue el diseño gráfico, que debe entregar la experiencia estética junto con potenciar el contenido mediante códigos visuales. Casi transversalmente, la usabilidad participa durante todo el proyecto, cautelando que el resultado sea usable.

diagucdia

La arquitectura de información interviene tempranamente en el proyecto y define una serie de aspectos fundmentales como los requerimientos de contenido, los perfiles de grupos de usuarios, taxonomías o sistemas de clasificación, entre otros.

diagucdusab

La usabilidad es transversal al desarrollo de los proyectos, debe estar presente desde el inicio y hasta el final. No es conveniente conformarse con testeos al finalizar un proyecto, los costos de modificar los problemas encontrados, y los factores de riesgos son muy grandes de este modo.

diagucdixd

El diseño de interación define los aspectos globales de la interacción con el usuario: flujos, navegación, esquemas de interacciñon, metáforas, etc.

diagucdid

El diseño de interfaces concreta los detalles de los criterios globales planteados por el diseño de interacción.

diagucddsg

El diseño grafico tiene una mayor responsabilidad hacia el fin de la etapa de diseño y durante el desarrollo, una vez que el producto se ha diseñado. Su rol es fundamental, un buen diseño visual fortalece un diseño de producto bien ejecutado, pero no podrá salvar un producto mal diseñado.