Why we’re doing this work
Contracts and agreements was one of the first areas to go live in MYESF, in 2016. It was innovative in a number of ways - we think it was one of the first government services to allow digital signing of contracts - but users have told us that some of the features are now difficult to use.
In 2021, a research team confirmed this, by gathering evidence that users struggled to find the contracts requiring action, and the filters that should have helped with this task were not understood and widely avoided. Unfortunately, there was no capacity for the team to pick up a redesign at that time.
Although users appreciate the service, they have learned to work with its flaws, because it’s much more efficient than sending paper contracts back and forth in the post.
More recently, we’ve also become aware that internal service users, including the Contracts and Payments team in Operational Excellence (OpEx) in ESFA had needs that weren’t being met; a number of their requests had been on the product backlog for some time.
So, in mid-2024, we carried out a design review of this area. Each journey was put through a heuristic evaluation and Web Content Accessibility Guidelines (WCAG ) compliance analysis. These told us there were a significant number of usability and accessibility issues.
Fixing the latter was particularly important; not doing so would mean we were breaking the law.
The problems we’re trying to solve
Here’s a list of the usability issues we knew we needed to tackle:
- users are overloaded when they're presented with a single list of current and old contracts
- navigation is clumsy; users report difficulty in locating specific contracts and their updated versions in the list view, because the display logic often means the contract publication dates are jumbled up, instead of being displayed in reverse date order, i.e. most recent first
- the box alerts that appear when there is a new contract or variation to sign or review don't tell the user which specific contract(s) require action
- users often also leave one of the box alerts on for a long time, because they don’t realise it can be switched off
- the UI doesn’t tell a user when a contract is being terminated or sanctioned (i.e. having conditions applied to it), which can be confusing for both external and internal users
Plus, a number of design features in the existing service do not meet the latest accessibility requirements:
- screen reader and keyboard users are not being provided with important page content such as the H1 heading
- screen readers are missing some buttons
- the filter blocks do not render properly when orientation is changed on mobile screens
- there are legibility issues when screens are zoomed to 200% and 400%
- the use of breadcrumbs is inconsistent
- there are issues with error messaging on some pages when CSS is disabled
Early thoughts on how to fix these issues
Our experience of designing other parts of the service suggested we could make things better by:
- separating current contracts and variations from older versions. As users still need access to the latter, we would move them into an archive, which we’re calling a contract history
- doing away with the existing filters and box alerts, which would no longer be needed if there was a much shorter list of current contracts on display
- giving users better status information, using a mix of tags and messaging
Our approach
After agreeing the usability and accessibility changes with MYESF’s product manager, we worked with OpEx colleagues to:
- better understand what varying a contract means, and how this changes the status of the contract in the service
- agree a definition for a ‘current’ or ‘live’ contract – they suggested this should be ‘one that has funding or data attached to it’. As a result, it could include contracts published in previous academic or financial years
One of the Business Analysts in the team also helped us to understand what status information is available in the Funding and Contracting Service (FCS). This helped us to work out ways to give users more information when they need it.
Next, we ideated and built a prototype that brought our design thinking to life. As we did so, we found there were still gaps in our understanding, which made it difficult to get the messaging right for the ‘sanctioned’ and ‘terminated’ statuses. So we did a walkthrough of the prototype with OpEx colleagues, and asked them for feedback on the draft messaging.
As well as answering our questions, OpEx colleagues were impressed with the prototype. One of them said:
“you’ve gone above and beyond. We just need a simpler version of what we have now, but you’ve supplied something that’s much better.”
After making the content changes, we were ready to put the prototype into user research. We lined up five participants in round 1.
What we found in round 1
We used this round to check the following:
- does the separation of new and older contracts work in practice?
- do users need a filter or other means to search through contracts?
- are the new status tags helpful and understood?
- do users want to manually confirm that they’ve reviewed a contract?
- can users locate the link to a data download and is it useful?
Our most significant finding is that users’ and the business definition of a current contract are different. For users, a current contract is one that delivers funding in the current academic or financial year only.
As we had designed the prototype to reflect the business definition, our participants struggled to understand the contract list we showed.
For example, we put contracts that needed action at the top of the list, but users want to see them in date order. And as we had removed the filter from the design, they couldn’t work out how to search by contract type and/or year. They’re not yet familiar enough with a contract history doing this work for them.
Our participants in this round had no previous experience of sanctioned and terminated contracts, so they struggled to fully understand what these statuses mean. This told us that we need to explain that they’re related to offline processes, which may involve colleagues who submit data or receive business communications at their end.
However, the prototype did help us to understand a number of important user needs more clearly. We now have evidence that they:
- would welcome the separation of older contracts into a contract history
- do want to manually confirm they’ve reviewed a contract
- would use the data download option – but we need to make this easier to find
- would welcome links to guidance, on topics such as how to access ESFA systems
- would welcome the summary of changes provided with each contract variation (this is in the pdf)
We need to fix some navigation issues too, and make it easier for users to:
- gain access to contract histories
- submit a contract query
- go back to the contracts list page after signing a contract
On the whole participants were positive about the prototype. One of them told us:
“I like it. It’s more compact. The navigation is comfortable.”
And on seeing the new contract history, another said:
“Oh! You’ve got to give me this. It’s brilliant!”
With this feedback, we’ll be iterating the prototype and getting it ready for the next round of user research. We’ll report on what we find soon.