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.