How I’ve used the universal barriers framework to audit a live service
When I moved onto a new service team, I inherited a service in the live phase of the delivery lifecycle. I wanted to use my new found learning and get to know my service, so I used the universal barriers framework to create a checklist for auditing the service.
One user journey at a time
My service is quite big, with multiple different user journeys. I audited 1 user journey at a time. I’d recommend the same if you have a big service as:
- different user journeys will have different barriers
- it helps you to focus on that one bit of the service
- it’s a good way to chunk up the task
The audit
I phrased the questions in the audit as “does the service require users to do the thing that might be a barrier?” and took the “things” straight from the framework.
For example for the ‘time’ barrier, the questions are:
· does the service require users to gather information?
· does the service require users to fill out forms?
· does the service require users to travel?
· does the service require users to spend time on the phone?
· does the service require users to wait for a response?
I worded them in this way rather than “do any of our users have a barrier with this?” because universal barriers is a shift in thinking from “what is wrong with our users?” to “what is wrong with my product or service and where does it put up barriers for people?” (Schauberger 2023).
I could do the audit without the need for user research, as I was auditing the service itself, rather than the users and their experience of their service.
Where the service presented a barrier
Where the answer to a question was “yes”, the service does require the user to do this thing that might be a barrier, I then looked at:
- why do we make users do that?
- how have we helped users with this barrier?
- is there anything more we could do to help users?
- can we design the barrier out completely?
Barriers are obvious once you look for them
Through doing this exercise, I identified a really obvious barrier, which we’re now working to reduce. We were not letting users know they needed to do the thing. And so, they were not doing it.
It made me realise that a lot of the barriers are quite obvious, once you go looking for them. The universal barriers framework provides you with the structure to do that looking.
Reflecting on how I’d use the barriers
Obviously it would be better to design services without barriers in the first place, rather than to identify and fix barriers in a live service. Other teams in Department for Education and across government are currently experimenting with how to use the universal barriers framework during the discovery, alpha and beta phases of the service delivery lifecycle.
I reflected that if I was changing or adding a user journey, I’d want to run this audit as part of the design process to check we weren’t unintentionally introducing a barrier. Potentially I’d want to do it every time we consider an iteration to a design but, definitely before we progress to the build. I’d want to work with my team at that point to figure out how to incorporate it into our process.
I also realised that there may be certain triggers that would prompt me to do this audit to check for universal barriers.
For example if users were:
- not doing the thing
- doing the thing late
- taking longer to do the thing
- reaching out for help a lot
- not using the service to do the thing and finding another way
- giving negative feedback
I also began thinking about how I could measure the impact of removing a barrier, which is something I’d like to explore more in the future.
References
Schauberger, U. (2023) Universal barriers to access.
