Is Time On My Side? Análisis de una interfaz de registro de horas

Recientemente he sido asignado como responsable de mantenimiento de una aplicación web que gestiona los pedidos que se le hacen a una Software Factory. Esta aplicación fue desarrollada por un proveedor externo y quedo bajo mi responsabilidad.

Una de las primeras impresiones que tuve fue de desconcierto. Digo desconcierto porque me costo muchísimo entender como se realizaban las acciones en la aplicación. Creo que cometieron todos los errores de usabilidad y diseño existentes.

Esta aplicación posee, además, la funcionalidad de carga de horas a dichas solicitudes. Es decir, permite registrar cuantas horas una persona le dedico a una solicitud en particular.

En este articulo analizaremos en profundidad esta función de carga de horas.

Cuando un usuario desea registrar las horas de su trabajo, ingresa a la siguiente pantalla:

Ilustración 1- Interfaz de Carga de Horas

¿Qué tiene de malo esta interfaz?

Si de un único intento, logra entender como registrar horas de su actividad, entonces forma parte un selecto grupo de iluminados.

Hemos realizado pseudo pruebas de usabilidad con gente interna del equipo y hubo quienes no pudieron ingresar sus horas correctamente. Veamos que tiene de malo esta imagen y que acciones podríamos tomar para mejorarla.

1. ¿Cómo está pensada la interfaz?

Primero, antes que nada, analicemos más detalladamente en que consiste la interfaz.

En el caso de que no lo hayan notado, hay una cierta lógica en la interfaz. La misma se encuentra dividida en 5 zonas, a saber:

• Zona 1: Encabezado de la Aplicación
  Contiene el nombre de la aplicación (Qué ocultamos en la imagen) y el nombre de la funcionalidad que estamos ejecutando, en nuestro caso, la “Carga de Horas”
• Zona 2 : Filtro de Solicitudes
  Aunque este confuso, en esta zona se pueden filtrar las solicitudes que se listan en la zona 3. Hay 2 filtros, uno por palabras clave y otro por área de la Software Factory. Cabe destacar que hay dos comportamientos diferentes. Si se busca por palabra clave, se debe presionar el botón filtrar. Si se busca por área, solamente se selecciona una opción del combo box.

  De más esta decir que al utilizar cualquiera de los 2 filtros el sistema no muestra ningún mensaje acerca de si se aplicaron los filtros o no, violando una de las reglas de oro de Schneiderman, la de ofrecer feedback al usuario.

• Zona 3: Carga de Horas
  Está es la sección que más le importa a un usuario. Aquí se registran las horas de su actividad. Todo en una línea. Las solicitudes seleccionables son las que resultan de aplicar el filtro de la zona 2.

  Por defecto, se encuentran en el combo todas las solicitudes activas. Un problema de esta decisión de diseño es que cuando hay más de 200 solicitudes activas, el combo no es la mejor opción para buscar algo ya que la lista se torna muy larga. Creo que es por ello que se decidió implementar el filtro de la zona 2.

  Para guardar el registro, en el extremo derecho están las clásicas acciones de todo formulario: Aceptar o Cancelar

• Zona 4: Listado de horas previamente registradas
  Quizás, al ver la pantalla por primera vez, se preguntaron porque había botones de “Duplicar” o “Eliminar”. Bien, es porque al final de la pantalla, si hubieran, se listan todos los registros de carga de horas del usuario. Ese listado lo veremos más adelante.

  Las acciones de los botones actúan únicamente sobre los elementos de ese listado.

• Zona 5: Menú de Navegación de la aplicación
  Por último, un botón de volver. Este nos permite ir al menú principal de la aplicación y así poder acceder al resto de las funcionalidades. En cierta forma, es un history.back() del navegador. No nos permite saltar directamente a otra funcionalidad, tenemos que pasar siempre por el menú principal.

2. Problemas que existen en esta Interfaz

Bien, ya dimos una vista rápida a que es lo que se puede hacer en la interfaz. Ahora veamos que puntos débiles tiene. Antes de seguir, recordemos que el objetivo es registrar las horas de nuestro trabajo
Interfaz Visual y Separación de Conceptos

El primer problema que podemos encontrar es que, a simple vista, no se puede definir dónde tengo que trabajar. Todas las acciones están en el mismo bloque. Alta, consulta, edición y el filtrado.

Parte de la causa es que la interfaz no resalta los diferentes elementos que la componen. Todo incluido en lo que parece ser un único bloque. Se utilizan colores muy suaves que hacen que la pantalla sea “plana”. Otro problema que hay es que tanto los combos seleccionables como los botones de acción tienen el mismo estilo. Esto dificulta el reconocimiento de que elementos se utilizan para accionar y que elementos se utilizan para completar información.

¿Qué sucede entonces? El usuario debe primero ver la interfaz, leer toda la información que hay en ella, pensar y recién después de realizar todo ese trabajo, encontrará la sección en donde debe cargar las horas. En los usuarios menos experimentado, este punto fue el más débil. La pregunta más común termino siendo:

¿Y donde registro las horas?

Veamos un ejemplo de la pantalla con toda la funcionalidad expuesta.

En esta imagen aparece el listado de horas ya registradas por el usuario. Sobre ese listado, se selecciono un elemento. La selección de este elemento dio error. ¿Pueden verlo? (Si no lo ven, sigan leyendo)

Otro problema que se divisa aquí es que, con el listado de horas ya registradas, la edición no se realiza sobre el registro seleccionado, sino que se realiza sobre los campos para dar el alta del registro. O sea, una misma zona cumple dos funciones diferentes.

Los engañe, ¿Creían que la zona 3 era solo para dar de alta registros?. Se equivocaron. Sirve también para modificarlos. Ahora bien, ¿Qué sucede con los botones de aceptar/cancelar? ¿Qué estoy aceptando o cancelando ahora? ¿Creación o edición?

No lo sabemos con certeza, tenemos que pensar que estábamos haciendo para poder deducir que significan el aceptar y el cancelar.

Estos son algunos de los problemas que surgen cuando reutilizamos mal los componentes que tenemos. Noten además, que el registro seleccionado, si bien está “resaltado”, no tiene el checkbox seleccionado, generando la duda: “¿Estoy trabajando con este registro o no?”. Esto es una inconsistencia en la interfaz.

Modelo conceptual de acciones

Otro punto, es la forma conceptual que se definió para realizar la acción. En principio, el modelo seleccionado es el de: filtrar -> completar registro -> guardar

¿Qué significa esto?, que para poder realizar la acción de cargar horas, primero tenemos que filtrar la información existente. Una vez que filtramos, podemos completar el registro con nuestra información y de ahí guardamos. Es decir, al clásico ABM (Alta-Baja-Modificación), para poder hacer el alta, anteponemos el Filtrado, convirtiéndose en un FABM (Filtro-Alta-Baja-Modificación).

Esto tiene como problema que el usuario no esta acostumbrado a filtrar para poder dar de alta un registro. La tarea que quiere hacer es dar el alta y es por ello que busca dónde dar el alta. No imagina que primero tiene que filtrar, aún cuando el filtro es el primer elemento de la interfaz. Filtrar no forma parte en su modelo mental de la acción que quiere hacer, qué es guardar.

Mensajes de Error

Algo que no se pudo mostrar en la primer pantalla es la presentación de errores. La aplicación no diferencia cuando una acción se realizó correctamente y cuando no y utiliza la misma zona de la pantalla para mostrar mensajes de resultado correcto e incorrecto.

A continuación una imagen que muestra el mensaje de error asociado a la selección incorrecta de una fecha:

¿Fácil de notar, no?

El texto nos indica que hay un error en el formato decimal de horas, cuando lo que hicimos fue registrar una fecha incorrecta (35/35/2009). El primer problema es el mensaje en sí ¿Formato decimal para horas? ¿El error no es que deberíamos ingresar una fecha en formato dd/mm/aaaa y que sea válida?. En esta aplicación, los mensajes de error no condicen con el error en sí mismo.

El segundo problema, es que el sistema no destaca el error ni nos posiciona donde ocurrió, queda a criterio del usuario determinar cual fue la causa del error y dónde se produjo.

Y por último, todos los errores de las diferentes zonas se muestran en el sector remarcado en la imagen, por lo que resulta muy difícil determinar de que zona proviene el error. ¿De un alta de registro?¿Al filtrar?¿Al consultar?

Este problema con los errores es quizás el más crítico, ya que lo que deseamos es que se registre correctamente las horas. Ante esta liviandad en el tratamiento de errores, un usuario pudo haber pasado por alto un error y no haber registrado las horas, creyendo que si lo había hecho.

3. ¿Qué mejorar?

Tenemos ahora una lista de temas que podríamos mejorar. Veamos como podemos solucionar estos puntos encontrados.

No hacer pensar al usuario
El primer problema que nos encontramos es que el usuario tiene que pensar como tiene que hacer lo que quiere hacer.

Steve Krug, en su libro “Don’t Make Me Think! A Common Sense Approach to Web Usability” plantea una serie de principios para el diseño de sitios web que bien podrían trasladarse a esta aplicación. Dentro de los conceptos introducidos en el libro plantea que el usuario no debe tener dudas acerca de donde se encuentra lo que quiere hacer.

En esta aplicación, cuando el usuario ingresa por primera vez, intenta identificar donde tiene que registrar horas y queda mareado con la interfaz. Hay muchas cosas todas juntas, y demora un tiempo en determinar donde debe registrar las horas. Obviamente, luego de un tiempo, se acostumbra y ese tiempo inicial perdido disminuye.

Centralizar el foco en la tarea que quiere hacer el usuario

Alineado con la idea anterior, se debe lograr focalizar al usuario en la tarea que debe hacer. En este caso, el principal caso de uso es el registro de horas. El resto (consultar, editar registros) son secundarios.

La interfaz lo debe posicionar donde tiene que trabajar y el resto acompañar a la tarea. Aquí sería la zona de carga de horas. Esa es la zona más importante de esta interfaz. Deberíamos reposicionarla para que sea lo primero que el usuario vea en la pantalla.

El filtrado es otro punto que debería desaparecer. El filtrado solo debería usarse para realizar consultas sobre registros existentes. En este caso, se lo utilizo como mecanismo para acotar las solicitudes en las que el usuario puede registrar horas. Lo recomendable es que el mismo sistema sepa en que solicitudes está trabajando el usuario y por defecto en los combos de carga sólo aparezcan esas solicitudes (En el caso real, se muestran en el combo todas las solicitudes activas).

Dividir conceptos

Cerrando el punto anterior, si queremos agregar los casos de uso secundarios, como ser la edición y la consulta de registros, estos deberían aparecer como conceptos separados y como una funcionalidad aparte.

Se tienen que separar lo que es alta de consultas y separaciones, aún cuando esto no implica que no puedan compartir la misma pantalla. Una opción sería el uso de menús de acciones, aunque no es la única opción.

Lo importante aquí es las diferentes funcionalidades no mezclen componentes de otras zonas. Si hay que editar, se debe utilizar elementos diferentes que los de alta. O bien, si queremos reutilizar el alta, tenemos que dejar en claro que esos elementos ya no se utilizan como alta sino como edición. Esto implicará, seguramente, cambiar las etiquetas de los botones de acciones o resaltar en algún lugar que se esta editando y no.

La mejora del “Look And Feel” también puede ayudar en la división de conceptos. Utilizando estilos bien definidos y diferentes para cada acción se logrará el efecto de separación de acciones.

Una propuesta de Mejora

La siguiente imagen muestra una opción de mejora aplicando los conceptos mencionados anteriormente. Es una opción, puede haber otras, pero la idea es mostrar como reordenando conceptos y aprovechando tecnologías existentes (Estilo Web 2.0) se puede mejorar una interfaz existente, con el fin de facilitar la tarea del usuario.

En esta interfaz, se modifica drásticamente los estilos de la aplicación. Se aprovecha al máximo el uso de AJAX para recuperar la información asociada al usuario y se divide la interfaz en 4 zonas bien definidas, a saber:

• Zona 1: Registro de Horas
  Al ingresar, se posiciona al usuario en esta zona. Registra la información completando el formulario y el sistema le presenta únicamente las tareas y proyectos en los que participa y puede registrar horas. No es necesario filtrar, el sistema se encarga de ello.
• Zona 2: Consulta de registros existentes
  En esta zona, se listan, separados por día, los registros de horas que el usuario ya creo. La edición se realiza sobre el mismo registro.

  La idea es utilizar el concepto de vistas planteado por diversas aplicaciones, principalmente las de correo electrónico como por ejemplo Outlook o Gmail.

• Zona 3 : Acciones disponibles sobre el registro
  Al igual que en Outlook, al seleccionar un registro de la zona 2 se habilitan las acciones existentes para ese registro. Cualquier funcionalidad extra que se puede realizar sobre los registros, se lista en esta zona. Un ejemplo es la eliminación de registros o la repetición de registros.

  Zona 4: Navegación
  La última zona contiene el menú de navegación de la aplicación. Este menú permite navegar las diferentes funcionalidades que brinda la aplicación.
  En este caso, se puede saltar a diferentes funciones sin necesidad de ir al menú principal.

  Además, se muestra información de soporte al usuario (Cuanto le falta registrar en el día, exportación de registros, información del usuario, etc).

Si bien esta interfaz también puede mejorarse, plantea un salto muy grande respecto del punto inicial.

4. Conclusión

Hemos visto como una aplicación resolvió una problemática de registro de horas. Vimos también que puntos débiles tenia y como mejorarlos.

Siempre durante el mantenimiento se plantea si es necesario realizar mejoras de interfaz. La realidad indica que depende mucho del contexto en que se use la funcionalidad.

En este caso planteado, la funcionalidad es critica y utilizada por varios usuarios. La interfaz original no fue “diseñada” con una visión de usabilidad ni se intento disminuir el tiempo que tardan los usuarios en registrar su esfuerzo, por lo cual un cambio en la interfaz sería significativo e importante para los usuarios. Con lo cual, si sería necesario el cambio.

Como idea final, desde mi punto de vista, a veces es muy importante analizar el uso que se le dará a una interfaz y diseñarla para que sea los más simple de utilizar como sea posible, ya que cualquier cambio en la etapa de mantenimiento puede inducir a un esfuerzo demasiado grande para poder realizar el cambio deseado.

En otras palabras, hacer bien las cosas desde el principio.

Agregar a diferentes marcadores sociales