Background
As part of our work to improve the TRS console, we looked at how support tasks are displayed and accessed.
This came out of user research into interaction transaction records (ITRs), which showed that some support tasks don’t relate directly to individual teaching records and need to be accessed in other ways.
Instead, they need to be accessed independently of the 'records' area of the console.
Previous design teams displayed support tasks in a single list, but this was:
- difficult to scan and find tasks the user needed to complete
- not scalable as more tasks were added
This piece of work focused on refining these designs.
Design kick-off
We held a design kick-off to explore challenges and opportunities around navigation.
The aim was to ensure users can easily find and complete their tasks, especially as more support tasks are added over time.
What we were trying to solve
The main problem we identified was that users need to know:
- where a task begins
- where to go next
- how to find specific pieces of information
What we needed to consider in the design
Themes that emerged included:
- basic usability - we needed to provide clear start and end points and highlight high-priority tasks
- access permissions - different roles have different levels of access, which dictates what they can see or do
- MVP or post-MVP - the service needs to scale as more support tasks are added, but the MVP shouldn't overload users
- non-linear journeys - users might stop mid-task or follow an unexpected route, so they needed to be able to find their way around easily
- consistency and clarity - navigation had to be consistent and as simple as possible
What we already knew
We knew that users:
- already understand what each task means
- broadly understand their roles and responsibilities
- are used to using filters and shortcuts to find information quickly
- rely on the search function to find what they need rather than navigating to it
Risks
We also considered risks to the success of the navigation design, such as:
- taking on too much for an MVP
- overcomplicating the navigation
- not accommodating role-based differences
- overdesigning for a relatively small group of users who will receive training
Design ideation
Mapping the TRS console as it is
As part of our design kick-off, we reviewed the existing layout of the TRS console to help us understand how the current system organises tasks.
We used this to inform the creation of a to-be map: a clearer, scalable structure for navigation that supports different user needs and aligns with the growing set of support tasks.
User needs are shaped by roles and permissions. Some users can only view data, while others can create and edit records or manage alerts. This meant we couldn’t design a single linear journey through the service.
We considered the following to make sure the new map worked for different users:
User groups and responsibilities
We identified key user groups and mapped out their responsibilities. The new navigation needed to make it easy for each group to access the tasks they use most often.
Permissions and access levels
Permissions vary across roles. Some users have read-only access, while others can edit specific types of information or manage system-level tasks. The to-be map needed to reflect what each user can do without showing tasks they can’t carry out.
Support tasks
We reviewed and grouped support tasks into MVP and post-MVP phases. This helped us keep the initial journey focused while allowing for scaling (for example, bulk data uploads or managing third-party alerts).
Shared tasks
Some tasks are shared between teams, while others are owned by specific groups. The to-be map needed to accommodate these shared tasks without confusing users.
Creating a to-be map
We created a first-pass map of the revised console structure, starting with users who have the most common permission type: record managers.
This group performs a wide range of tasks, so we used them as a starting point. We focused on the main tasks they carry out such as:
- viewing teaching records
- creating new records
- handling TRN requests
- updating personal details
- managing ITRs
- resolving potential duplicate records
We also made a structural change by moving support tasks from its own tab to the homepage,
Previously, these tasks were in a separate tab, which made them harder to find. Moving them to the homepage makes them easier to find and access.
This was a first iteration of navigation tailored to a specific role. It forms the basis for a role-based structure that can scale across other user types.
What’s next
We’re testing these designs with internal teams in early June and will iterate based on what we learn.