As part of the alpha looking at how we can better manage panel hearings, we created a basic prototype to test and assess whether it’s worth taking forward.
It aims to meet some of the user needs identified in discovery and GDS design principles.
Issues with the existing panellist portal
Usability
Users think the panellist portal is slow, unreliable, inaccessible and unclear.
They’ve said:
- it takes a long time to save their availability
- updating their availability sometimes crashes the system, meaning they must enter it again
- they're not always informed whether the hearing is remote or in-person, or who the chair is
- it's hard to use on a mobile device
- there is a lot of information and it’s not intuitive to navigate
“I find it fairly clunky and it times out very quickly.”
“I don't find it very intuitive. It's not very easy to navigate. I think there are easier systems that could be put in. For instance, all of your cases are listed, the ones that you've sat on, instead of being cleared.”
Accessibility
We identified the following issues from a basic accessibility check of the service:
- There are no skip links when tabbing through content.
- The target size for modal close buttons is too small.
- In mobile view, the touch area for the calendar is too small, the full content does not display, and the user cannot select a date using the keyboard only.
- There are tables with no data within them.
- There are multiple tables for different purposes on single pages which increases cognitive load
Designing the prototype
The 3 areas we focused on were:
- the homepage
- allowing users to view and respond to hearing requests
- allowing users to enter their unavailability for hearings
These are currently the only functional parts of the prototype.
The homepage
We’ve used the card component to organise content on the homepage.
It’s separated into 3 sections, where users can:
- respond to hearing requests and view upcoming and past hearings
- manage their availability for hearings
- contact the Teacher Misconduct Unit and view relevant resources
The notification banner component at the top of the page lets users know they have a new hearing request.
Viewing and responding to hearings
Clicking ‘View hearing requests’ on the homepage takes the user to the Respond to requests to attend hearings page. Here, they can see details of the request and respond to it.
The basic details we display are:
- the teacher’s name
- the date of the hearing
- whether the hearing is in-person or online
- the panellist’s role in the hearing
Entering unavailability
Like the existing service, we ask users to enter their unavailability for hearings. Our assumption is that most users will be available most of the time, so it would be easier for them to select the few dates that they cannot attend hearings.
Instead of a calendar, we propose using the date input component to enter unavailability.
After entering a date, we ask the user if it will be a recurring event. If they select ‘Yes’, they can select the frequency of their unavailability and enter the number of times it will repeat.
Naming the service
We also needed to give the service a meaningful and descriptive name, so the team held a workshop where we:
- discussed GDS guidelines around naming services
- came up with as many names as possible on post-its on a Lucid board
- dot-voted for our preferred options
The 2 with the most votes were ‘View and manage panel hearings’ and ‘Manage misconduct hearings’.
For now, we’re using ‘View and manage panel hearings’ in the prototype, but we plan to test the 2 options in February to see what users prefer.
Next steps
We aim to carry out research on the prototype and service name by the end of March.