El otro día me enviaron una carta por una infracción vehicular que cometí y me informaron que debía obligatoriamente sacar un turno para hablar con un Agente de Faltas en una sede comunal específica. Para sacar un turno viví un proceso de usabilidad muy dudosa y me llevé una experiencia de usuario mala.

Al ingresar a la URL de turnos, me pedían primero un dato que no tiene mucho sentido para mí: el Dominio. ¿Qué es el Dominio? ¿El código de la infracción, la patente, mi DNI, algún otro dato que no sé de dónde sacar?

Debajo describo los pasos que aparecen en la captura de pantalla.

Paso 1

Citando algo que aprendí en el curso de UX de Gonzalo Auza en el ITBA, este es un ejemplo típico de Folksnomía versus Taxonomía. Dentro de la jerga técnica, todos los que trabajan en la Dirección General de Tránsito saben qué es un dominio (Taxonomía). No obstante, los usuarios del sistema – personas como yo – no asocian nada a la palabra ‘dominio’ (Folksonomía).

Una de las reglas heurísticas de usabilidad de Jakob Nielsen menciona que debe haber una correlación entre el sistema y el mundo real: El sistema debe hablar el lenguaje del usuario, con idioma, palabras, frases y conceptos que le sean familiares, en lugar de términos orientados al sistema.

Paso 2

En la misma pantalla debía tomar otra decisión, que no tenía sentido para mí en esta primera instancia del proceso: Elegir por Fecha, Lugar o Disponibilidad.

Ni siquiera sabía cuál era mi dominio, pero al mismo tiempo me pedían que elija por Fecha, Lugar o Disponibilidad ¡Qué complicado! Con muchísimo esfuerzo, pensé lo siguiente:

• Dado que sólo podía sacar turno para una oficina determinada, elegir por Lugar no tenía sentido alguno. No iba a presionar esta opción.
• Elegir por Disponibilidad: No entendía realmente qué quería decir esto… ¿Cuál era la diferencia con la elección por Lugar, o por Fecha?
• Decidí entonces presionar el botón asociado a la Fecha.

Tras un par de intentos fallidos originados por no conocer mi Dominio, llegué a la siguiente pantalla del proceso, que se puede observar debajo.

En esta pantalla intenté elegir una fecha, pero simplemente el sistema pasó de ser interactivo a estático. ¡Por más que presionara cualquiera de las opciones, no pasaba nada! Ya frustrado con esta usabilidad, volví a comenzar desde cero pero llegué a esta pantalla estática nuevamente…

Citando uno de los principios heurísticos de Donald Norman, se debe asumir que todo error que pueda ser cometido será cometido. La pregunta en este caso es si realmente yo había cometido un error o no… ¡No había forma de saberlo porque no había ningún mensaje de error! Era imposible conocer el estado del sistema.

Gonzalo Auza menciona que “Cada acción del usuario es parte de un diálogo con el sistema, que debe fluir naturalmente. Se deben acompañar y no combatir las respuestas del usuario; informarle qué hizo y qué ocurrió como consecuencia y ayudarlo a recuperarse del error.” Claramente aquí no pasaba nada de eso…

Finalmente, decidí llamar por teléfono para sacar el turno…

El Desenlace

Al llegar a la sede comunal me informaron que no funcionaba el sistema de turnos. ¡Genial!

Notar qué importante sería que el sistema de turnos online posea una funcionalidad en donde se le informe al usuario que el sistema de turnos está caído. Esta pantalla debería:

• Reemplazar a la primer pantalla que hay ahora.
• Ser estática, para que el usuario ni siquiera pueda interactuar con el sistema.
• Poseer un mensaje indicando al usuario que no reserve por teléfono tampoco, sino que se acerque a la sede comunal – sin turno.

En resumen, este es un caso de experiencia de usuario con muchas áreas de mejora. ¿Qué opciones se te ocurren para mejorar la usabilidad web de este proceso? ¿Diseñarías las pantallas de otra forma?