Our users work for voluntary and community sector (VCS) organisations and receive requests to support families from professionals through our service. They must then decide whether to accept the request and contact the family to offer support, or to decline.
Our design questions were:
- how might we show users a list of requests they have received?
- how might we help users to find a request they are looking for?
Original design for a dashboard with search
We designed a ‘dashboard’ page which used the table component from the GOV.UK design system to summarise the requests the VCS organisation has received.
The fields shown in the table on the dashboard, in order from left to right, are:
- request number
- date received
- family contact - shortened from ‘Person in family to contact’ to fit the table
- requester - shortened from ‘the professional who requested support’ to fit the table
- status
The statuses are:
- ‘New’ for a request a VCS organisation has just received
- ‘Viewed’ for a request a VCS organisation has opened but not accepted or declined
- ‘Accepted’ for a request a VCS organisation has accepted
- ‘Declined’ for a request a VCS organisation has declined
Declined requests are not shown on the dashboard because when a VCS organisation declines a request, they are no longer able to view it. We will test if this is what users expect.
We’ve used the tag component from the GOV.UK Design System to indicate status.
We added functionality for a user to search by name of contact because this is the primary way users would identify and look for requests.
We used the sortable table and it tested well in user research. We considered using filters, however only one option has categories - the status - meaning a filter is not very useful.
We will test further with users to find out how they would find a specific request.
It’s fine to have repeated links if we use visually hidden text to make them accessible
The table includes an ‘Action’ column at the right end. This column includes a ‘View’ link to open each request.
We thought there was an accessibility issue with these repeated ‘view’ links because they linked to different places. We considered combining the view link with the request number for example ‘View request 0001’ to create unique links- which would also save space in the table.
When we discussed this with the interaction design community, we learned that it’s fine to have repeated links if we use visually hidden text to make them accessible - just like the ‘change’ links on the GOV.UK check answers pattern.
Ordering requests on the dashboard to make sense to users
We assumed users would want to address ‘new’ requests first, then ‘opened’ requests and then ‘accepted’ requests. We made this the default sorting order in the table. Within the status, requests are ordered new at the top to oldest at the bottom.
In user research, when users received an email informing them they had a new request, and followed the link to the dashboard, they identified the oldest ‘new’ request and opened this first. This showed that the ordering made sense to users.
Iterating the requester information
From user research, we learned that the team that the professional who made the request belongs to is important to the VCS organisation. They are more likely to recognise the name of the team than the individual who made the request. Knowing the team who have made the request also helps them to prioritise the request. For example, they may have agreements with certain teams whereby they automatically accept any requests they make.
We swapped out the ‘requester’ column for a ‘team’ column. We will be retesting with users to see if this meets their needs. We also need to investigate how to collect this data when we onboard professional users to the service.
Iterating the pagination
We have used the pagination component from the GOV.UK design system and placed this on the lower left hand corner underneath the table. We have included 10 results per page.
We will be testing further with users to see whether this is the right number of results they expect to see on the page, and whether they are easily able to navigate through the dashboard pages.
Iterating sortable columns
We have made the ‘date’, ‘status’ and 'team' columns sortable - as we assumed that these are the ways users would want to sort the data. We have used the sortable table component from the MoJ design system.
Iterating the dashboard to deprioritise the request number
During the usability testing, several users said they would not use the request number. They said they would copy the information into their own customer relationship management system, which has its own reference numbers.
From exploring how we notify VCS organisations they have received a new connection request and how we update professional users on their connection requests. We know we cannot include personal identifiable information in email notifications. We need an anonymised way to refer to specific connection requests, which is the reference number.
Users testing dashboard told us the request number is not important to them, so we have deprioritised it in the table and moved it the last but one column. The usefulness of the reference number is something we will continue to review during private beta, when users have the added context of the email notifications.
Iterating the column heading for ‘Family contact’ to ‘Contact in family’
We shortened ‘Person in family to contact’ to ‘Family contact’ to fit the table. However, from user research we learned that users were confused about who the person was, especially as it was shown next to the name of the team. Some users wrongly assumed it was the name of the person who worked in that team and had made the request.
We’ve iterated the column name to ‘Contact in family’. We also considered moving it away from the team name, however we want to test just the name change first to see if this resolves the problem.
Iterating to descope search and add sort to contact in family
The original designs we built included functionality to search by ‘contact in family’. We initially agreed this would be part of our minimum viable product (MVP).
When we tested how users would find a specific request, we saw some use this search, and others navigate through the pages using the pagination component.
We investigated how the design for search would function and found that there was no component or pattern in the GOV.UK Design System. We looked at different options and spoke to colleagues in different services and departments who have used search in similar scenarios. We also discussed with our developers that it would be tricky for them to implement in time for the proposed MVP launch.
As a result, we have removed the search functionality from the scope of the MVP. Instead, to help users find connection requests by name, we’ve added sort to the ‘contact in family’ column. We are not expecting VCS organisations to receive large number of requests, so navigating through the pages and using the sortable columns should be enough. After delivering our MVP, we will learn from research and if we discover there is a need for a search then we can add this to the service.