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:

• UML con Rational Unified Process
• Feature Driven Development
• Xtreme Programming

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:

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.

Por mucho que intentemos establecer un ambiente familiar y apropiado para los tests de usuarios, es fundamental tener claro que es imposible reproducir en condiciones de laboratorio la forma en que un usuario se comporta cuando utiliza libremente y sin presiones una aplicación. Desde la perspectiva de usabilidad, es importante observar directamente a los usuarios, pero es necesario compensar y tener claro que, por mucho esfuerzo que pongamos:

• Los usuarios no están en su ambiente natural, ni realizando las tareas de un modo real, sino siguiendo las instrucciones de los evaluadores
• En laboratorio el usuario no es interrumpido por sus compañeros de trabajo, ni recibe mensajes instantáneos, ni revisa el email con la misma frecuencia, por lo tanto no tiene que dejar y retomar la tarea como haría en el mundo real
• El usuario se sentirá evaluado, sin importar cuánto insistas en que no es una evaluación de su desempeño, sino del software
• El nivel de tolerancia a los problemas es mayor, y la tarea será abandonada mucho después de lo que lo haría en su entorno natural
• Muchos usuarios se culparán a ellos mismos por lo errores, antes que al software
• La motivación para finalizar una tarea es diferente en el laboratorio, en el que sedesafía tácitamente al usuario a finalizarla

No estoy tratando de descartar el test de usuarios sino simplemente apuntando ciertos factores que deben ser considerados. Aproveché de comentar sobre esto porque coincidentemente me topé hoy, mientras revisaba mis feeds en Bloglines, con dos artículos relacionados de algún modo: When Do Users Really Give Up? , de Heidi Adkisson y Usability Stockholm Syndrome de Jensen Harris.

Después de todo, cualquiera que haya realizado un test de usabilidad sabe lo importante que es, pese a todo, observar a los usuarios de primera mano.

Aunque con unos días de retraso, no puedo dejar de comentar un par de cosas que me parecieron relevantes del fin de semana recién pasado. En Chile las transmisiones de mando de un presidente saliente al recién electo se realizan tradicionalmente los 11 de marzo. Sí, extraña coincidencia con el 11M español. Pero este 11 de marzo fue especial: asumió laprimera mujer electa Presidenta de la República. Esto por sí mismo ya es digno de comentario, aunque en realidad lo que quiero destacar es un detalle: la ceremonia de traspaso fue transmitida por cadena nacional con closed caption y lenguaje de señas.

Hace un tiempo atrás había comentado la iniciativa de algunos canales locales de implementar closed caption en sus transmisiones, inicialmente en los noticiarios centrales y ahora en varios de sus programas. Pero una cadena nacional de televisión ya es otra cosa.

Esto me pareció una señal muy positiva de políticas de accesibilidad y ciertamente una promisoria forma de comenzar un gobierno. Los dejo con algunas fotos de la transmisión, incluyendo el closed caption y la traducción a lenguaje de señas.

Hay problemas que frecuentemente retornan cuando estás diseñando una interfaz, básicamente porque no terminas de darles una solución aceptable. En este momento estoy pensando en particular en un problema muy común: la ejecución de un pago en línea. ¿Cómo etiquetar la acción pagar? Fácil, Pagar. Perfecto, eso lo entiende claramente cualquier hispanohablante. Pero ahora viene el problema: ¿cómo llamas a la acción deabortar una tarea, en este caso un pago? Siempre he creído que abortar tiene más implicaciones que las que quisieras para una interfaz, por lo tanto la omito y busco una alternativa. Cancelar suena razonable. Pero hay un problema: la segunda acepción de cancelar es Acabar de pagar una deuda, según la RAE. No sé realmente qué ocurre en otros lugares, pero en Chile esta acepción es de uso común. No es raro escuchar a alguien decir que ha cancelado una cuenta, refiriéndose a que la ha pagado. En una ronda reciente de testeos de usabilidad observé a varios usuarios dudar ante la presencia de dos botones etiquetados Cancelar y Pagar.

Entonces, la pregunta es obvia: ¿cómo etiquetar la acción Cancelar para evitar la confusión? ¿Alguien ha tenido mejores resultados?

Hace unos días atrás les mostré el equipo que utilicé para realizar y registrar algunas evaluaciones de usabilidad. La ventaja del registro en video es que se puede repasar la sesión de evaluación para observar con más detalle ciertos aspectos o incluso discutirla en grupo con otros evaluadores.

Pues bien, la configuración que les comenté antes estaba compuesta por una cámara de video digital para registrar la actividad del usuario y un software para el registro de pantalla, o captura de pantalla a video. En esa oportunidad utilicé Camstudio, una aplicación open source (al menos hasta la versión 2.0) que permite capturar la pantalla sin afectar la actividad del usuario, aunque obviamente éste debe estar enterado del registro que se realiza y lo debe autorizar. El problema es que posteriormente hay que montar el video y editarlo, y eso puede ser un gran problema.

Finalmente, me decidí a probar una configuración mucho más simple y compacta: Camtasia Studio 3. Camtasia permite capturar la pantalla en video, pero junto con eso, es posible utilizar una webcam para registrar la actividad del usuario e insertarla directamente en el registro de pantalla en un formato picture in picture. Esto, naturalmente, ocurre sin que el usuario esté viendo su imagen en la pantalla, ambos videos se combinan directamente en el software y el usuario no lo percibe. Con una webcam de buena calidad, con micrófono integrado, y un notebook de capacidad razonable (el mío es un Toshiba Satellite, Pentium 4 de 3.2GHz y 512 RAM) se puede conseguir un desempeño impecable y un registro de calidad. La grabación producida por Camstudio se puede exportar a una serie de formatos para distribución o revisión posterior (Flash, avi, QuickTime, etc.), con opciones excepcionales como la posibilidad de generar un menú de navegación basado en marcadores insertados manualmente en el proyecto.

Este tipo de laboratorio resulta altamente portátil y mucho más cómodo que una cámara de video con el correspondiente trípode, más el micrófono y cables extra. Más importante aún, resulta mucho menos intimidatorio y, por lo tanto, permite obtener una reacción más natural de los participantes.

Bien, los dejo con algunas fotos de la disposición de los elementos en esta ocasión.

Durante sesiones de pruebas de usabilidad con usuarios, user testing, he observado que es común que se presenten problemas al momento de ingresar la arroba (@) que forma parte de la estructura de una casilla de correo electrónico. Recordemos que la estructura de una casilla es básicamente usuario X en el servidor Y, donde la parte del en está representada por @ (at en inglés). Pues bien, si la estructura básica de un email es reconocible, y esperamos siempre encontrar el caracter @, ¿por qué exigirle a los usuarios que lo escriban? Lo planteo basándome en lo siguiente:

• el caracter @ siempre deberá formar parte de una casilla de correo electrónico
• el resto de la estructura, usuario y servidor, es variable
• las configuraciones de teclado e idioma hacen que para los usuarios sea un problema encontrar la forma de obtener el caracter @ en un teclado al que no están habituados

Por lo tanto, ¿no sería mucho más razonable utilizar una estructura como la siguiente?

El HTML básico para esto sería:

<form action=”#” name=”test” method=”get”>
<fieldset>
<legend>Patrón de ingreso de email</legend>
<label>Email: <input type=”text” name=”email-name” id=”email-name” /> @ <input type=”text” name=”email-server” id=”email-server” /></label>
</fieldset>
</form>

Para todos los efectos prácticos (validación, almacenamiento, etc.), el email estaría compuesto por la unión de los dos campos, con una @ entre los dos: email-name@email-server. ¿Alguien ve algún inconveniente razonable para no usar esto?

Cada vez que realizo pruebas de usabilidad con usuarios, o user testing, me sorprende la cantidad de información útil que puedes obtener con el sólo hecho de observar cómo personas reales utilizan un prototipo, un sitio o una aplicación. Sobre la metodología de las pruebas de usuarios podemos hablar después, ahora sólo quería compartir unas fotografías del laboratorio improvisado (en el sentido de no establecido o fijo, porque en esto no te puedes dar el lujo de dejar nada sin planificar) en el que he estado sumergido los dos últimos días.

No había tenido tiempo de escribir al respecto, esperaba que alguien más tocara el tema antes, pero me sorprende que nadie haya hablado de esto.

Pues bien, hace unos días (el 9 de diciembre) escuché que un operador de la bolsa de Tokio accidentalmente realizó una transacción que bien podría ser el error más caro de esta naturaleza. El empleado activó una orden de venta de 610.000 acciones de J-Com por ¥1 (yen) cada una, en lugar de poner a la venta 1 acción por ¥610.000.

Aparentemente el sistema habría advertido al usuario que la orden era poco usual, pero élignoró el mensaje. El error fue notado posteriormente por una llamada telefónica para confirmar la veracidad de la orden, pero el empleado no pudo inactivar la orden de venta.

El error generó un caos financiero que causó pérdidas inconcebibles a la compañía que administraba las acciones y al mercado en general.

Probablemente en este punto ya tendrán muy claro que tras el error hay una serie de problemas de diseño que permitieron que eso ocurriera:

• Un corredor de bolsa es un usuario muy particular: permanentemente estresado y operando contra el tiempo, por lo que el manejo de situaciones como las confirmaciones de acciones y los mensajes debe ser cuidadosamente considerado;
• El sistema permitió que el corredor ejecutara una acción poco frecuente, sin reforzar de modo apropiado la importancia de ésta, esto es una falla del manejo de la confirmación de las tareas y de la comunicación con el usuario, que permite elacostumbramiento ante los mensajes de alerta, probablemente por el uso de un formato estándar de respuesta: seguramente el usuario hizo clic en OK o Aceptar sin leer el mensaje;
• El sistema no permitió la anulación de la orden de venta, desconozco los detalles del flujo de venta de acciones, pero esto es algo que podría preverse;

Por la importancia de un sistema que maneja las acciones y la economía de todo un país, es vital que todos estos detalles se tomen en cuenta, si no las consecuencias pueden ser muy graves. En el caso que les comento, el error principal es del sistema, antes que del usuario: el sistema permitió y facilitó que el error ocurriera.

Este es un caso extremo, en el que las consecuencias de un error son muy caras. Normalmente la situación no es tan dramática, pero nos permite reflexionar sobre la relevancia de un diseño que considere a los usuarios, sus características y necesidades.

Más información sobre el incidente:

• Resultados en Google News
• The unthinkable at the TSE
• Stock Fiasco Damages Exchange’s Reputation
• J-Com’s Tokyo Debut Marred by $2.8 Bln Trading Error
• Too fat, too fast. The £1.6bn finger
• Typing Error Triggers Loss of 240 Billion Won

Desde hace un tiempo vengo observando un problema común que sorprendentemente parece no haber llamado mucho la atención. Me refiero al manejo de claves en los formularios, tanto en sistemas de autenticación y acceso, como en registro de usuarios nuevos.

Como medida de seguridad razonable HTML define un tipo de input, o campo de ingreso de texto especial, definido por el atributo type como password. La propia definición indica que a diferencia del input de texto y los de tipo password es que estps últimos deben enmascarar su contenido mediante caracteres como asteriscos:

Like “text”, but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks).

Si bien esto es razonable y provee una aparente seguridad (sólo aparente, porque el texto de la clave es siempre accesible), es común que los usuarios se equivoquen al ingresar una clave y que la única manera para corregirla sea borrar todo y escrirla nuevamente. El problema es más severo en situaciones como el registro de un nuevo usuario, en que es común solicitar la creación de una clave y el uso de un segundo campo para confirmar la clave original. En estos casos, ante cualquier duda, el usuario debería borrar ambos campos, el de clave y el de confirmación, y escribirlo todo nuevamente.

Pero también es común que ocurra otra situación, que personalmente he hecho y que además he observado en otros repetidas veces: cuando se solicita la confirmación de una clave, el usuario copia la clave escrita originalmente y la pega en el nuevo campo. Si la clave estaba mal escrita, terminará sin poder acceder al sistema porque la clave registrada no era la que pensó que había escrito. Este es un problema severo.

Soluciones

La lógica de ocultar la clave tiene sentido cuando el usuario no está solo, pero si se encuentra en una situación de confianza es perfectamente razonable que pueda ver el texto que está ingresando como clave. Para esto se podría implementar un mecanismo que permita alternar entre un campo de clave convencional, presentado por defecto, y otro que revela el contenido de la clave, para confirmar que se ha escrito correctamente.

El modelo base es simple:

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede revelar el contenido del campo presionando el botón mostrar.
3. El campo muestra el contenido de la clave en texto legible y cambia la etiqueta del botón a ocultar.

En términos de interacción todo va bien hasta acá, pero dependiendo de la técnica utilizada para cambiar las características del campo de clave, tendríamos que realizar un paso extra antes de enviarlo al servidor para procesarlo: si se utilizó JavaScript para alternar entre dosinputs, uno tipo password y otro tipo text, es necesario sincronizar el contenido de ambos antes de ejecutar el submit, e incluso, entre cada cambio de estado entre los dos campos porque el usuario pudo haber editado el texto. Por lo tanto, el flujo completo debería quedar del siguiente modo.

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede alternar el estado del campo entre enmascarado o descubierto
   1. El usuario hace visible el texto (desenmascara)
   2. Edita el contenido de la clave
   3. Se sincroniza el texto de los dos campos, el enmascarado y el descubierto
   4. Se repite el proceso tantas veces el usuario cambie de estado
3. Usuario presiona el botón submit.
4. Nos aseguramos de sincronizar el contenido de los campos.
5. Se ejecuta el envío de los datos al servidor.

La verdad es que estoy considerando la implementación más compleja que implica usar dos campos y alternarlos mediante JavaScript, pero teóricamente debería ser posible alternar los estados simplemente cambiando el atributo type del elemento, con lo que se conservaría el valor y el ID del input, sin que sea necesario realizar ninguna sincronización. No lo he problado, pero lo haré pronto.

Por ahora, pueden probar el ejemplo que creé para esto. La implementación es sencilla y estándar y requiere de JavaScript y CSS. El ejemplo no separa el comportamiento del HTML, eso es el siguiente paso y lo haré en cuanto tenga un tiempo.

Si hay interés, puedo explicar en detalle la implementación del script del ejemplo. Espero sus comentarios.

Me llegó la semana pasada una parte de los libros que compré en Amazon y entre ellos se encuentra Ambient Findability, de Peter Morville, coautor junto a Luis Rosenfeld de Information Architecture for the World Wide Web, más conocido como el libro del oso polar. Ya desde el principio lo estoy disfrutando, y con sólo unas pocas páginas avanzadas puedo recomendarlo con confianza.

Por ahora quería dejarlos con una cita que me pareció muy relevante, en que Morville enfatiza la atención en los aspectos relevantes de la interacción de los usuarios con la información:

[…] Though our attention is drawn to the fast layers of hi-tech, the map to this maze is buried in the slow layers of human behavior and psychology. It’s not enough to focus on the I in IT. We must also lose the C in HCI. Becauseambient findability is less about the computer than the complex interactions between humans and information.

[…] Pese a que nuestra atención está dirigida a las rápidas capas de la alta tecnología, el mapa de este laberinto está enterrado en las lentas capas del comportamiento humano y la psicología. No es suficiente enfocarse en la I deTI. También debemos soltar la C de IHC. Porque la encontrabilidad ambientales menos acerca del computador que de las complejas interacciones entre los humanos y la información.

Incluyo la traducción de la cita porque me lo han mencionado algunos lectores, pero no termino de convencerme de cómo suena, particularmente el término ambient findability, que en inglés es también un neologismo. Si tienes alguna sugerencia de traducción más apropiada y que suene menos espantoso que encontrabilidad ambiental, pues bienvenido a comentarlo.

En suma, todo el argumento de Morville se refiere a la usabilidad del contenido y la facilidad de encontrar lo que uno necesita en una fuente incontrolable de información, no siempre relevante. Comentaré más adelante si hay otra cosa que me llame particularmente la atención.