Query Tracking System: A Case Study
Strictly speaking, Query Tracking System, or QTS as it was abbreviated, was a Travel-related project that took place as Visionär was forming but the workings of the user interface and user journeys for the application were solution-led in the majority by one of the Visionär team. We think it’s valuable to refer to the breadth of applications we’ve worked on and tell stories about them that reflect how important it is to look at digital projects through the eyes of the user. In QTS’s case, the project affected tens of thousands of transactions and a significant amount of revenue every year.
QTS was effectively a system envisaged to tackle the problem of the unwieldy back-office travel administration across a Company’s European operations
On a daily basis, Travel Management Companies (TMCs) and Travel Managers in companies receive numerous queries about, for example, unpaid travel, incorrect cost codes against itineraries, un-received special rates at hotels and ticket refunds. The list of reasons goes on.
QTS was effectively a system envisaged to tackle the problem of the unwieldy back-office travel administration across a Company’s European operations where these types of enquiries were in a backlog to the value of about half-a-million GBP in transactions.
QTS was, on the face of it, a difficult project to engage with. For example, there were two developers on the project and both had tried to solution the requirements before our operative was engaged. There was also a genuine concern as to whether the project could be completed at all.
There was no question of the developers’ ability. In fact, their experience was beyond question. However, the background was that the developers were coding according to their perception of what the application needed to do rather than what the application’s users needed access to. This is all too common – the emphasis being placed on the functional requirements to the extent that the user becomes a secondary actor in the scheme of the product. Naturally, playing “second fiddle” for the user typically means that users then have to interpret what an application is trying to do, leading to a reduced inclination to use it and frustrating what could have been an effective tool. All because a project isn’t designed with the user in mind. Project plans can squeeze out the value of the research and UX processes that can clarify exactly how a system’s UI and UX should perform according to the needs of its users. These processes are often vital to allow users to achieve their own, and therefore ultimately their business’s, goals.
Once we became involved, the emphasis changed to what does the user need to see to achieve their aims?
Once we became involved, the emphasis changed to what does the user need to see to achieve their aims? Task analysis was carried out – looking at the process and journeys the different application users needed to travel. In addition, our architect mapped out a draft sitemap – an overview of the application – and then refined it in conjunction with carrying out stakeholder interviews with back-office staff who were going to be the main users of the application, using the interviews to then build up an overview of the typical user wants and needs.
Finally, the work set out on adapting the UI – establishing a very basic style-guide focused on clarity, simplicity and utility. The research gathered was used to influence the navigation and how users logged in, what help was on offer to help users, and determine where users landed once their credentials had cleared the system. It was able to help minimise the number of pages the user needed to drill down and identify contextual information that needed to be displayed higher in the system architecture to save the user valuable time. Moreover, the time spent with the users was invaluable for understanding their appreciation of UI components and which components, not necessarily the most sophisticated ones available at the time, allowed users to achieve their tasks quickly because how the components worked was clear to them as quickly as possible. We did this at a time when onboarding didn’t have the affirmation that it currently enjoys.
Ultimately, the major part of the application was focussed on messaging. It was like a Whatsapp or BBM with very specific file attachments and message designations based on the query type and a queuing system for actions to be carried on the files. Different actors in the process of dealing with queries needed to know the status of a query and it’s worth to determine what action to take on it. Together with this, the time the query had been sitting within the application was needed to drive alerts about when the query should be resolved. All of this was resolved for easy overview into a dashboard where management and staff could see their actionable queries and those with credentials that allowed could edit them to change their priority and outcome.
It was a great project to work on. We managed to make up the initial time lost in demystifying the UI and satisfy the developer’s needs as well as the business’s requirements to deliver a successful and effective product.