For the password to access the prototype pages linked to in this post, email: rob.dale@education.gov.uk.
You can read about some previous design thinking we did around this need in a post about hiding services.
The need: removing services from the directory
Through discussions and usability testing carried out with local authorities (LAs) we identified a need for account managers to remove services from the directory. The two main reasons for this were that the service:
- listing is incorrect, it is a duplicate or it no longer exists
- no longer wants to appear on the directory, either temporarily or permanently, for example due to a change in their working relationship with the LA or being overwhelmed by demand
Initial solution: deleting and hiding services
Initially, we explored the options for:
- deleting services from the directory
- temporarily hiding them from the directory
The original plan was to first implement the ability to hide services first, followed by the ability to delete them. However, we decided to postpone work on hiding services, as we now want to address this as part of wider changes related to quality assurance.
You can read more about allowing account managers to hide services.
We continued working on the delete functionality since this could be done separately to these other changes. Implementing this would still allow users to remove services from the directory, and at least partially meet the user need.
Backend considerations for deleting services
We worked together with the development team to evaluate the options for deleting services.
Option 1 - hard deleting services (rejected)
This option involved deleting all data on the front and back end. We decided there were too many risks involved with this option. These included the impact of deletion on analytics data and the loss of information related to connection requests.
Option 2 – soft deleting services (adopted)
This option would mean that when a service is deleted on Manage it will no longer be visible to users on the front end, but the data will be kept in the backend. We chose to adopt this approach as:
- it avoids the risks associated with hard deleting
- the digital team did not anticipate the retention of this data will cause any technical issues
In the Open Referral UK standard database we use, the status of deleted services will be changed to ‘Defunct’. This hides them from users whilst still retaining them for auditing purposes.
We will also need to ensure this data is still managed in line with the principles of our privacy statement.
Designing the delete services journey
We discussed the idea of giving users the option to still view deleted services on Manage, as this would be possible as part of going with ‘soft deletion’. However, we rejected this idea, as it could cause confusion, especially once the 'hide services' functionality is introduced. If a need to view deleted services arises in the future, we could introduce this feature, as the data will still be stored in the back end.
Deleting services pattern
We already have a deletion pattern in place for removing users. To ensure design consistency and familiarity for users, we decided to use the same pattern for deleting services.
In the initial design, we considered including a checkbox page to gather insights into why users were deleting services. This would help inform our future work on hiding services. However, due to complexities around how we would store this data, we decided to leave this feature out of the current design.
User research on deleting services
Although we thought the risk of implementing our design was low because of its consistency with an existing pattern, we still wanted to check this with users. We used a fortnightly call we have with LAs and monthly call with voluntary and charity sector organisations to gather feedback.
We showed the Figma designs for the deletion pattern and received good feedback. We decided to go ahead with implementation.
You can view how deleting services now works on the prototype.
Next steps: further testing and quality assurance
We will test this feature with users to ensure it meets their needs and is easy to use. As part of this we may explore adding the ability to collect insights about why users are deleting services. This information would help refine the feature and support future improvements.
Our development team will monitor any potential impact related to retaining deleted data and if this will pose any long-term difficulties.
As part of our ongoing work on quality assurance, we also plan to explore introducing the ability to hide services. This would complement the delete functionality and further address this user need.