Our users are professionals who use ‘Connect families to support’ to complete a form to request a voluntary and community sector (VCS) service contacts a family. They may want to look back at the request they have made, and they will want to know if the request has been accepted or declined.
The information shown in the request is populated by the information entered on the request form.
Our design questions were:
- how might we show users a list of connection requests they have sent?
- how might we help users to find a connection request they are looking for?
- how might we show users updates to connection requests they have sent?
We have also explored how we should keep professional users updated on their requests.
Original design for dashboard and search
When we started these designs, we had already designed and tested the dashboard for VCS users. We used some of the learning from that to inform the design of this dashboard. The design is very similar, but with different fields shown in the table, to account for the different user needs.
The fields shown in the table on the dashboard, in order from left to right, are:
- contact in family, on the request for support form this field is called ‘Person in family to contact’ however this is too long a heading for the table
- service, the service the connection request was sent to
- date updated, allows users to sort requests and we assume they will want to do this
- date sent, we’ll be researching whether this is important to users
- status
- request number
The statuses are:
- ‘sent’ for a request a professional has sent, but has not been accepted or declined yet
- ‘accepted’ for a request a VCS organisation has accepted
- ‘declined’ for a request a VCS organisation has declined
We’ve used the tag component from the GOV.UK design system to indicate status.
We’ve added sorting to:
- date updated
- service
- status
- date sent
We’ve added functionality for a user to search by name of contact because we assume this is the primary way they would identify and look for requests. We will test this assumption.
We will test further with users to find out how they expect the dashboard to be ordered, and how they would find a specific request.
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). We have not yet been able to test this functionality with users, but we have tested how VCS users would find connection requests on the VCS dashboard.
June 2024 update: updated the table based on an accessibility audit error
The accessibility error
The accessibility audit report highlighted problems on the Connect request lists page v12 with the Web Content Accessibility Guidelines (WCAG) - WCAG 2.4.4 and WCAG 2.4.9.
The report said: ‘The links within the sortable table on this page do not sufficiently describe their purpose to screen reader users browsing in context. These links lead to unique request pages but are labelled by the contact name for the request. As a result, it could be extremely difficult for screen reader users to discern the destination of the link based on the person's name, as the link text does not name the request.’
Reviewing past user research
Looking back through user research it appears there may have been some misunderstanding due to testing in isolation.
Voluntary and community sector (VCS) users had said they will not use a request number in their own internal systems and was therefore unimportant. Research also showed the name would be useful when searching for a request, which is something we will consider when we add the search functionality.
This led to us making the contact name the link, rather than the unique request number. However, the header 1 for the request page itself was the request number. This in turn led to the accessibility error.
The solution – making the request number the link
Looking at the full user journeys we refer to the request throughout, so it is good practice to keep this consistent. We have updated Connect request lists page v13.
The request number is now the first link in the column. This will avoid people with the same name appearing as a link in the table. The WCAG guidance says, ‘having the link and the title agree, or be very similar, is good practice and provides continuity between the link 'clicked on' and the web page that the user lands on.’
Other options considered
We considered adding a ‘View’ link to the end of the table as we did in early request list designs for VCS users. Although this would be accessible, it would make the usability worse on mobile devices. We are already using a horizontal scroll on the mobile view, and we want to avoid adding any unnecessary additional columns. The MoJ case list page states ‘You should display the link in the first column and use meaningful content such as the case number or name. Avoid using words like View’.