One of the ambitions of the Register with a GP surgery service is to reduce the barriers of entry to healthcare for everyone.

It is important to pause and consider what we mean by everyone. Some of us – myself included – will not face inherent barriers to accessing basic healthcare. This is not the case for everyone.

Today, there are nearly 56 million people living in England. Within this population we know that:

People in these groups may need additional support to complete certain tasks. Or, they may have a lived experience which affects their ability to engage with and trust health services.

What this means is that when you design something for people with additional needs, it almost always improves the experience for everyone at the same time. If we can give people what they need, when they need it and in a way that works for them, then we can help to reduce barriers for people accessing healthcare. 

Before launching the Register with a GP surgery service, we had already done a lot of user research to understand some of the barriers people face. For example, not being able to register because they didn’t have ID or proof of address. 

After our beta service assessment earlier this year, we dedicated more research time to better understand the needs of people who:

• come from historically marginalised groups 
• have low digital confidence 
• face healthcare inequalities 

We wanted to be able to hear from everyone who needs our service and that our designs reflected our diverse audiences. My colleagues Imran Akhtar and Lucy Johnson worked hard to learn how these user groups are affected by healthcare inequalities as well as digital exclusion.

We found that some of these users:

• have difficulty concentrating for lengthy periods 
• can get overwhelmed by a lot of text
• may need extra time to complete tasks 

We also found that some users with English as a second language would often mistake words like ‘options’ with ‘optional’. 

40% of households have at least one person with additional needs. 6 million people register with a GP every year, so it’s a reasonable assumption that there are thousands of people struggling to register.

This is why the work Imran and Lucy led on was so important in helping to bring some of the seldom heard voices into the design space.

We wanted to do something with what we had learned. We started back at the beginning and considered how we could improve our service start page (the first page of the service). We could see from our data that this was the largest drop-off point for our users – why was this?

While some of those opting to not continue at this stage would have been for good reasons, our assumption was that for some users our start page presented barriers which were blocking them from getting what they needed. 

Over time, as we had added more features to the service and discovered more requirements, the start page had grown quite big. 

Our hypothesis was that if we made the start page simpler that it would not just improve the experience of users from low confidence backgrounds and marginalised groups but improve the experience for all users. 

We revisited the basics of good user-centred design and the service standard when looking at our start page. 

After reviewing the page our research and design team felt that we were:

• asking for too much information too early 
• referencing niche jargon where it wasn’t needed

David Evans, one of our content designers, analysed the page in what we call a ‘heuristic review’ and saw that while what we asked people for was technically necessary for some users – much of it could be asked later on in the service at the point of need. 

Our performance framework includes things like the top-level service purpose, goals, user needs, key performance indicators and design hypotheses. Because the framework considers user-needs, it keeps tech, design and data hypotheses focussed on improving things for the people using it.

We spent several weeks workshopping and refining our framework and used these start page changes to test the effectiveness of:

• our design decisions
• the framework we had created

As well as being a useful tool to help us to optimise the service, it was also a reminder of what we are all working toward.

When delivering something at pace and to scale, it can be easy to lose sight of why you started the work in the first place. Building the framework helped us all to course correct. 

When we moved the content from the start page we wondered if it would simply move the problem to somewhere else in our service.

For our initial test we wanted to start small so that we could better measure a few things at a time. We felt that the most useful leading indicators we identified from our framework for telling us this were:

• drop off rates
• time spent on the page

After a month of making the change, we observed a significant decrease of 11% in drop-offs on the start page without any increase in drop-offs on the pages we moved the content to. 

Similarly, we found that the average time users spent on the start page decreased significantly by 18.5% – with no significant change to how long they spent on other pages.

Using our performance framework to improve our start page was a useful first step. It provided us with some re-assuring data and gave us confidence that we have built a tool which works for our service.

There is more work to do on the start page – now we have improved it, there are new challenges emerging that would benefit from this approach.

With that said – a performance framework is something which should always be evolving. It does not stop at one test. As a team we will continue to iterate upon and use our performance framework to help monitor our design decisions and to put our users first.