Sistema de Seguimiento de la consulta: estudio de caso
Estrictamente hablando, el QTS (Query Tracking System, Sistema de seguimiento de la consulta) fue un proyecto relacionado con los viajes que se desarrolló mientras que Visionär se formaba pero los trabajos en la interfaz del usuario y la ruta de acceso del usuario para acceder a la aplicación fueron solucionados en su mayoría por un miembro del equipo Visionär. Creemos que es provechoso mencionar la variedad de aplicaciones en las que hemos trabajado, así como contar historias sobre ellas que reflejen la importancia de ver los proyectos digitales a través de los ojos del usuario. En el caso del QTS, el proyecto afectó decenas de miles de transacciones y una cantidad considerable de ingresos de cada año.
Efectivamente el QTS fue un sistema concebido para abordar el difícil problema de manejar la administración de los viajes del back office a través de operaciones europeas de una compañía.
Diariamente, las compañías especializadas en la gestión de viajes de empresa (TMCs, por sus siglas en inglés) y los administradores de los servicios de viajes en las compañías reciben numerosas consultas sobre: viajes no pagados, códigos incorrectos en la nota de gastos de los itinerarios, tarifas especiales en los hoteles no recibidas, reembolso de pasaje, y la lista continúa.
Efectivamente el QTS fue un sistema concebido para abordar el difícil problema de manejar la administración de los viajes del back office a través de operaciones europeas de una compañía, donde este tipo de consultas se acumulaban y alcanzaron el valor de medio millón de libras esterlinas en transacciones.
Aparentemente, el QTS fue un proyecto difícil de colaborar. Por ejemplo, dos desarrolladores del proyecto trataron de resolver los requisitos antes que nuestro trabajador interviniera. También hubo una verdadera preocupación pues no se sabía si el proyecto podría ser completado.
No se dudó de la capacidad de los desarrolladores. De hecho, no se cuestionó su experiencia. Sin embargo, el contexto era que los desarrolladores estaban codificando de acuerdo a su percepción de lo que la aplicación necesitaba en lugar de ver lo que los usuarios necesitaban para acceder a la aplicación. Esto es muy común – enfatizar los requisitos funcionales en la medida de lo posible, de modo que el usuario se vuelve un actor secundario en el diseño del producto. Naturalmente, si el usuario está “en segundo plano” tendrá que interpretar lo que la aplicación está tratando de hacer, lo cual reduce el deseo de usarla e impide su posibilidad de convertirla en una herramienta eficaz. Todo esto se debe a que el proyecto no fue diseñado considerando al cliente. Los planes del proyecto pueden sacar el valor de la investigación y los procesos de la Experiencia de Usuario (UX) que pueden aclarar de manera exacta cómo los sistemas de Diseño de Interfaces (UI) y la Experiencia de Usuario (UX) deberían desempeñarse de acuerdo a las necesidades de los usuarios. A menudo, estos procesos son vitales para permitir que los usuarios lo consigan, alcanzando así, sus objetivos comerciales.
Una vez que nos involucramos, el énfasis cambió a ¿qué es lo que el usuario debe ver para poder alcanzar sus propósitos?
Una vez que nos involucramos, el énfasis cambió a ¿qué es lo que el usuario debe ver para poder alcanzar sus propósitos? Se llevó a cabo un análisis de las funciones – observando los procesos y trayectos que los diferentes usuarios de la aplicación necesitaban para viajar. Además, nuestro arquitecto realizó un boceto del sitemap – una visión general de la aplicación – y luego lo perfeccionó en combinación con entrevistas a las partes interesadas con personal back office quienes iban a ser los principales usuarios de la aplicación. Se utilizó estas entrevistas para elaborar un resumen de lo que el típico usuario quiere y necesita.
Finalmente, se dispuso a adaptar el Diseño de Interfaces (UI) – estableciendo una guía de estilo muy básica enfocada en la claridad, simplicidad y utilidad. Se utilizó la información recolectada para influenciar la navegación y cómo los usuarios inician sesión, lo que nos permitió ayudar a otros usuarios y determinar dónde aterrizaron los usuarios una vez que sus credenciales ingresaron al sistema. Esto ayudó a minimizar el número de páginas que el usuario necesitaba para profundizar e identificar información contextual que debía ser mostrada en la parte superior de la arquitectura del sistema para ahorrarle tiempo valioso al cliente. Además, el tiempo pasado con los usuarios fue imprescindible para comprender su apreciación de los componentes del Diseño de Interfaces (UI) y qué componentes (no necesariamente los más sofisticados disponibles en ese entonces) le permitían a los usuarios cumplir sus tareas rápidamente, ya que para ellos estaba claro que los componentes trabajan tan rápido como fuera posible. Nosotros hicimos esto cuando el servicio de acogida no tenía la afirmación que tiene ahora.
Por último, se enfocó la mayor parte de la aplicación en la mensajería. Era como un Whatsapp o BBM con archivos adjuntos muy específicos y designación de mensajes basados en el tipo de consulta y un sistema de lista de espera para las acciones fueran llevadas en los archivos. Los diferentes actores que intervinieron en el proceso de tratar con las consultas debían conocer el estado de la consulta y su valor para determinar qué acciones debían tomar. Junto con esto, el tiempo que la consulta permaneció en la aplicación fue necesario para enviar alertas sobre cuándo es que la consulta debía ser resuelta. Todo esto se resolvió mediante la visión general en un tablero donde la administración y el personal podían ver sus consultas procesables y aquellas con credenciales que les permitían editarlas para cambiar su prioridad y resultado.
Este fue un gran proyecto para trabajar. Logramos compensar el tiempo perdido al inicio al desmitificar el Diseño de Interfaces (UI) y al satisfacer las necesidades de los desarrolladores; así como las necesidades empresariales para brindar un producto eficaz y exitoso.