When you are designing a consumer app, the metrics that you track are very clear:
- Time spent on page
- Average session time
- Number of pages visited
- Drop-off or conversion statistics from one page to another
- Abandoned cart percentage (for ecommerce pages)
- Returning users percentage
- Anywhere to anywhere navigation
But the same metrics for a core backend transaction system will not apply as most of these metrics will remain the same, as these are functional necessities. Returning users will be 100%, number of pages visited will usually remain the same as per the role, and there will not be any drop-off on any page as the pages are critical in a workflow or transaction, and cannot be skipped.
So how do you measure the effectiveness of a backend system? What are the metrics you should track?
What are the UI/UX Metrics for backend platforms?
Based on our design work for large banking clients, ecommerce warehousing and logistics companies, and pharma companies, here are a few metrics that we think are the most relevant.
- Time spent on task
You don’t measure the time spent on a page but instead look at the time spent on a task. How much time does it take to create a new credit proposal? How much time to create a new borrower? How much time to compute RAROC? Some of these are not just design aspects but relate to how the technology stack has been architected. Also, a key difference: time spent on task is not equal to number of steps. It may be counterintuitive but many times more steps may mean less time. So don’t fall into the trap of measuring number of clicks.
- Navigate from one task to another:
Because most backend platforms have some sort of RBAC, it’s not possible to create an anywhere to anywhere navigation. For example, if a particular master is not available for say a business user, then they can’t just create the master because the rights to create master will be with someone else. Therefore, what’s critical is how clearly the modules are defined, and how easy is it to find out where a particular functionality resides. These can be enhanced by: second/third tier of navigation, searchable navigation, FAQs that explain the same and are searchable.
- How fast can you understand the workflow/status indicators:
This becomes one of the most important metric in any transaction system. How easy is to know the status of a particular task or workflow and also know whose bucket is it in. This inevitably means that every task or workflow has a TAT associated with it and a clear branch that shows the flow from one person to another and the time it took.
- Time taken for Internal communication: Given that different users will have different roles and permissions, and there can be multi-layer workflows, time taken to raise a query, communicate to an internal user and check responses becomes an important metric to track. Does the user have to open a separate email client and write an email, or do they have an integrated inbox or one specific to the platform? These become important design and platform architecture considerations.
- Tracking Notifications (in the right place at the right time):
Related to the above, and the status indicators is the role of notifications. This becomes critical as a task could be stuck in a queue or with another person. When is the user intimated about the success or failure of a particular task? If there are multiple tasks running, how does the user understand how and where to check the updates in a notification tray. Visually coded notifications with clear badges of important or critical ones can speed up the time spent on going through the multiple notifications.
- Ability to understand changes and audit trails:
Since multiple users can work on a particular case or workflow, it is important to understand who has done what changes. Design considerations here include an easy to understand audit trail (and not a tech log), which clearly highlights at a field level changes that were made, including original value, changed value, who made the change and when (and a history if multiple changes were made).
- AI Prompts usage and refinements:
If free text AI chat is allowed, you can measure the number of prompts required to reach the relevant result. The same can be used to refine the system prompts
Many of the metrics are offshoot of the first one, time to perform a task. So, when an effective tracking mechanism is being designed to measure the success of any redesign, please ensure that functional tasks as well as other tasks like notifications, audit trails, and internal communication are also considered.
One of the right methods would be to test a cohort of users across roles and functions, and then create a cluster graph of the time taken. And compare it to the time a developer working on the platform takes for the same task (given that the developer knows the platform in and out).