In round one of our user research into redesigning the contracts and agreements area in MYESF, we realised some of our design decisions were stopping us from fully testing whether it works to separate current and older contracts.
When users interacted with the prototype in round 1, they clearly struggled with:
- the way we’d defined a ‘current’ contract, which was based on information provided by the business. This didn’t match their understanding, and they were thrown by the presence of what they regarded as ‘old’ contracts
- our inclusion of 10 contracts in the list; in reality, the majority of providers have only 2 to 4 in a current funded year
- finding the new contract history feature, because the access link had been pushed too far down the page by the long contracts list
- two new ‘edge case’ contract statuses, for modified or terminating contracts. They were distracted by these, and found the content being tested too jarring , as it had negative connotations without providing explanatory information
Our approach for round 2
Many of the content and design changes could be made fairly quickly, by iterating the lo-fi page designs in Figma, and then seeing how they looked in the prototype.
One or two changes needed to be checked with the business before they could be made in the prototype. For example, we wanted to find out whether content such as contract reference numbers were seen by users in other communications. This would make it easier to work out whether it was worth including them in this part of the service.
We tested with 6 users in this round.
What we did, and what we found
We first looked at the contract list view, as this needed more work than the other pages. Our changes included:
- showing only currently funded contracts and agreements, and reflecting this change in the page heading
- reducing the number of contracts in the list to 4
- putting them in reverse publication date order, to match users’ expectations
- maintaining this order, even when the user has completed a task that changes a contract’s status
- removing status tags such as ‘Signed’ and ‘Read’; these appear in the live service, but users told us they didn’t add much value once the list had been simplified
- simplifying the secondary messaging in each list item, by removing any contract reference information, while keeping the version number
- making the heading for the contract history link more descriptive, so users understood it was their access point for all their earlier contracts and agreements
The result is a cleaner user interface, that users could scan easily to find what they need.
We tested a list view with a realistic number of contracts in this round. Two contracts were tagged to show users where action was needed.
The page tested much better in this round. All users correctly interpreted the premise of current contracts, the list logic and content for each list item. They could see which list items required an action, and which ones had already been dealt with.
The shorter list also meant all users spotted the contract history link easily, even though it was hidden just below the fold in desktop view.
Links to the new contract history and existing data download page, both anchored by sub-headings to make them easier to find, appear at the bottom of the contracts list page.
Once they’d clicked through to the history page for a contract type, all the users responded positively, and thought it looked clear and logical. They also thought the amount of information provided for each contract version was about right. One or two users thought it might be useful to show contract values for each one, but one user summed up the majority view when they said:
“It’s more concise and easier to look at.”
Earlier versions of a contract are grouped, usually by year, in the new contract history. All users said this would make it much easier to find older contracts.
Another remarked:
“It’s quite problematic to locate old contracts in the service currently. This is much easier.”
Users also located the link to the CSV download at the bottom of the list page more easily, but it was new to all of them – even though the feature is available in the live service.
And while they understood the reason why we were continuing to offer it in the service, they weren’t sure that it would be useful. As one user said:
“It’s not a format we need. Just the PDF is fine.”
Refining the ‘Ready to sign’ and ‘Ready to review’ journeys
When round 1 users were asked how they would submit a contract query, some struggled to find the link to the form, perhaps because it sat below a number of other links.
For this round, we made the access point clearer, by changing it from a link to a button, and locating it next to the ‘Continue to sign’ button. We thought this would make more sense to users, as they’re typically going to do one thing or the other.
To make the 'Submit a contract query' action easier to find, we changed it from a link to a button.
Now, all users found the button easily. One of them said:
“I don’t normally know where to raise queries. I like this display – it’s simple.”
The content of the query form was also considered to contain everything they would need to complete the task.
We got confirmation from users that the contract history link is most useful at the start of each journey, on the same page as the contract PDF. This is when they’re most likely to refer to an earlier version of the contract. As one user said:
“I'd always look at the previous version of a contract before I sign the new one. It's very useful to have them together.”
Users in round 1 had completed the ‘Ready to sign’ journey easily, but they did find it difficult to spot the link back to the contracts list page on the confirmation page. So, we made this more prominent by giving it a sub-heading for round 2. This worked much better, and they all used the link to navigate back without prompting.
To make the link back to the contracts list easier to find on the confirmation screen, we added a sub-heading above it. This makes it easier to spot when you're scanning the page.
We knew the alert for ‘Ready to review’ contracts in the existing design was difficult to manage. Users in both rounds of research told us they had instances of old alerts that they couldn’t switch off. As one user said:
"They can stay on for months. I don’t feel confident that I have actioned everything and feel like I need to come back and check.”
After some discussion in the team, we decided to get rid of the checkbox that’s supposed to offer this functionality in the current service. Instead, we proposed a set of Yes/No radio buttons with more explanatory messaging, which reflect our understanding of users’ needs more clearly. We also make direct reference to the ‘Ready to review’ alert in the content, so users understand which option will turn the alert off.
Removing the checkbox also meant users were no longer presented with an error message if they deliberately decided not to check the box. Instead of telling them ‘you’re doing something wrong’, we wanted to empower them by using messaging and functionality that better reflects the way they actually work.
We tested whether a set of "Yes/No' radio buttons would make it easier for users to manage their 'Ready to review' alerts.
Four out of the five users in this round welcomed the radio buttons and understood how to turn the alert off when they were ready. One of them said:
“This makes it obvious. It’ll be great if it gets rid of our alerts.”
Testing new content
To avoid confusion, we decided not to re-test messaging for the new ‘Modified’ and ‘Terminating’ statuses on the redesigned list page. Instead, we mocked up a separate page, so users could focus on the messaging alone.
To test the new status tags and messaging, we mocked up a separate list page, so users weren't distracted by other content.
This time, we wanted to soften the tone in the new status alerts and explanatory messages. After discussing our drafts with the business, we also decided to make the messages a bit more general, to make them easier to implement in the service.
Our messaging needed to bridge the gap between digital and non-digital parts of the contracting process. Users are notified that contracts are being modified or terminated by letter, not in MYESF. We can’t provide them with specific reasons for the changes in MYESF, so our messaging needed to be clear where more details had been provided.
Although the users in this round were also unfamiliar with the scenarios, they understood the new messaging, found it much less alarming and knew where to look for more details. As one user said:
"It’s self-explanatory.”
Finally, we used this round to check messaging for a new variant of the contract list page – one where the provider has no currently funded contracts.
It occasionally happens that we don't have contracts to display to a provider - usually when they're new. We tested messaging for them too.
All users understood the messaging, although they questioned why a provider with previous contracts wouldn’t have any. This scenario didn’t seem logical to them; they thought it more likely that this would apply to a brand new provider with no contracts, and therefore no history either.
Questions that still need answers
We haven’t yet established whether users need links to supporting guidance in this area of MYESF, but we’re working with the business and comms teams to see if there’s anything we can offer.
And more work needs to be done (perhaps outside MYESF) to explain the circumstances when a contract or variation needs to be signed, and when it only needs to be reviewed. It’s very clear from both rounds of research that users are unaware of the funding rules that govern these scenarios.
In conclusion
We think the work to improve users’ experience of the contracts and agreements is now complete. Feedback from users in this round was overwhelmingly positive. One of them summed it up perfectly when they told us:
“Well, it’s all very straightforward and user-friendly. You don’t need an instruction manual to use it, that’s for sure.”
After making some content tweaks we’ll get the prototype ready for handoff to developers and testers.