Content consultation for HM Land Registry

About the project

My team was tasked with assessing one of the client's existing services and providing an extensive options document. The document provided a range of recommendations for a combination of different budgets and timeframes.

 

We were also encouraged to make any improvements that could be delivered by the end of the project. And the client wanted to know how they could add SMS alerts to the service.

 

An NDA prevents me from naming the service, but I can say it is very outdated. It does not align with Government Digital Services (GDS) standards and it's nowhere near to meeting current accessibility standards. It's also not available in Welsh. 

 

The service issues users with jargon-heavy email notifications. These increase call levels because many users do not understand the content. So improving the service will not only improve the user experience, but will benefit HM Land Registry too.
 

About the users

The service was designed for members of the public, rather than businesses or organisations. It surfaces publicly available information, so essentially anyone can access the service.

​

About the team

The team comprised:

• me, the design lead

• a user researcher

• a business analyst

• 2 developers

• a tester

• a technical architect

• a product owner

• a project manager

​

​How I approached the task

I began the task with a content audit of the service, flagging any jargon and highlighting areas where I could improve the content. I then worked closely with the user researcher and the business analyst to identify pain points in the current journey, based on our own analysis, previous user research, and user feedback recorded by customer service agents.

​

Using this information, I set up a workshop with subject-matter experts (SMEs) to clarify the pain points and agree user-friendly content for testing. 

​

I first created a guidance page to address the issues discovered in the content audit and pain-point analysis. I then simplified and shortened the email notifications, linking through to the new guidance page.

​

I then created 5 Figma versions of the service's user journey, as defined by the team's research. Each version corresponded to different combinations of timeframe and budget as laid out in the options document.

​

The challenges​​

It normally takes more than 6 weeks for team members to familiarise themselves with a service, a client, and each other. However, we were not afforded the luxury of time, so we had to quickly learn how to collaborate as effectively and efficiently as possible.

​

The platform the service is built on was another significant problem. Onboarding issues, combined with the obscurity of the ancient technical platform meant the developers were continually descoping potential improvements they'd initially thought possible. This minimised the deliverable improvements.

​

The results

Despite the challenges, we delivered a new guidance page, updated email alerts, and content updates. 

​

Alongside my contribution to the team's options document, I left the client with:

• a report on my content audit

• a Figma prototype of an accessible, GDS-compliant version of their 'as-is' service, based on the technical restrictions of their existing technical platform

• a detailed design decision log linking to specific screens in the Mural diagram of the improved 'as-is' service

• Jira backlog items for each change of the improved 'as-is' version, linked to from the decision log

• a report on the content challenges of adding SMS alerts to the service, plus example SMSs