Overview
We discovered a user need that followed:
As a someone trying to contact the TRM or SFSO lead associated with a trust
I need to know that the details held in FIAT are up to date
So that I don’t waste time chasing the wrong person
What we did
Individual cards and structured headings
We've chosen to move away from earlier designs which were based on findings from FIAT's early discovery.
We split contact roles into separate cards, grouped by semantic headings.
For example, rather than placing TRM and SFSO roles inside one “DfE Contacts” card, each now has its own.
This means that an edit journey can be made specific to one contact, as each card has a single “Change” action link. As well as being a general UX improvement, this is also consistent with the approach taken by “Complete conversions and transfers”.
Finally, we added another row to each card for the email address. Previously the label and the address itself were on the same row. This meant that people using screen readers would be given no warning before it gets read out.
The new design means that “Email address” is announced before the address itself is read back.
What we might do in the future
In the future, we’d like to work towards following the standard GOV.UK pattern for “Show missing information” when using summary cards.
This would make it clear to users when we do not have a piece of data, but also allow them to add it via a call to action if they do.
Sources and updates
We’ve made some changes to the ‘Sources and updates’ area to show who last made a change to DfE contact information. This is so that they can be contacted if the user thinks there has been a mistake.
We:
- reused content from this section as much as possible
- spaced the copy out to make it more readable
- added ‘last updated by’ grouping for the sections
So far, the team are unaware of a need for a more detailed audit trail, but we’re mindful that this may be something we need to consider in the future.
What we might do in the future
Problems with the ‘Sources and updates’ section were highlighted in user research and peer review sessions.
This includes users not:
- noticing the information inside the component
- understanding what me mean by “updates”
We have a ticket in our backlog (as of Sept 2024) to review 'Sources and updates’ feature as a bigger piece of work.
This may include removing the details component and moving each piece of meta data closer to the card it refers to.
Doing this would put a contact detail’s last date of change, and who made it, closer to where the user might need it.
Edit journey
We follow the RSD pattern for contact details pages where users can edit multiple fields where applicable.
Hint text lets the user know that they can only add a DfE email address. Although limited, this will help to prevent incorrect addresses from being entered.
Backend validation checks that the address ends in “@education.gov.uk” and is in the correct format.
If it is, the user sees a success banner letting them know that the information has been updated.
In the backend, the record is changed and saved back to the database.
Meta data about the change is also saved, including:
- the email address of the person making the change – taken from account details of the logged in user
- the date the change was made
- the time it was made
- what the what the data changed from and to
What we might do in the future
If we discover a user need for a more detailed change history, we may look to introduce the MoJ timeline component.
Each timeline entry would represent a “Change” to the contact details.
The data for this is already stored in our back end, but it could be made visible to the user through this component.
This might help in cases where an error has occurred, for example if the wrong email address had been added.