Drivers first provisional licence
Design an internal system to support the public-facing ‘Apply for your first provisional driving licence’ service.
The system allows staff to manage applications, track progress, and contact applicants if there are any issues, updates, or requests for more information
The details
I was one of three interaction designers responsible for streamlining the service, focusing on user needs while balancing business requirements.
With the most experience in designing internal systems, I took on the role of lead designer for this project.
My role -
Sketch
Confluence
Visual Studio Code
MS Teams
Tools -
User testing
Iterating
Collaborating
Wire framing
Prototyping - Sketch/code
Methods -
Replace a legacy system that is used for approving and rejecting applicants uploaded photos
During the discovery and planning phase, there were two key business requirements that needed to be considered as well as user needs.
Speed - There are a certain amount of images that needed to be reviewed within a set time
Accuracy - The decisions the staff were making needed to be accurate and concise to prevent errors
Overview and requirements -
The focus
This is a large internal service with different sections, user roles and tasks. For the sake of this case study I will focus on just one of these.
Photo standards
When an applicant uploads a photo for their licence, it must meet specific criteria, similar to a passport photo. Each image is manually reviewed by a staff member, who manages several parts of the application process, with the ‘photo standards check’ being one of the most important.
An incorrect decision at this stage could delay the application and potentially impact the applicant.
The process
“Slow is smooth, smooth is fast”
When users rush, they can make mistakes. When users are thorough, it can take time.
When speed and accuracy are your requirements, you need to find a balance.
1
We began by reviewing the current system, capturing screenshots of every step and laying them out to map the user journey.
It quickly became clear that the process was overly complicated and that gave us our starting point.
2
From there, we stripped out unnecessary steps, removed repetition, and replaced outdated screens and patterns. The user journey was streamlined, directing users only to the screens relevant to their situation. After reviewing it with the rest of the project team and refining it through feedback and discussion, we finalised a clear, efficient journey.
3
When looking at an applicants uploaded photo, the user has three options: approve, reject or refer.
Approve - Everything is fine with the photo
Reject - There’s something wrong. If the reject option is chosen, the user then needs to tell the applicant what is wrong and how to fix it
Refer - The user isn’t sure and would like a second option. For example “Is that a shadow?” or “Are their eyes fully open?”
Sitting alongside user researchers and watching people navigate the legacy system gave us valuable insight into their thought process. The pain points were clear, though many users had simply become “used to them.” With a better understanding of both user needs and business requirements, we were ready to continue.
4
With new insight, we started to create wireframes on paper, including some new patterns we believe will work.
We built a new user journey and explored it from every angle, looking for pain points and opportunities to improve. Once we felt confident, we moved on to prototyping.
5
Using Sketch, we took our low-fidelity wireframes and create high-fidelity versions.
We can then put together a click through prototype that is robust and realistic enough for the first round of user testing.
6
The users we tested with were subject matter experts, this was their job and they knew the old system inside out. How would they react to a completely new version?
At first, they were fine. A little slow to begin with, but they understood the new patterns and made accurate selections.
Then they realised they were taking longer than usual.
As they sped up, mistakes crept in, frustration grew, and they started longing for the familiar legacy system.
It didn’t work but that was valuable insight.
“Fail fast, succeed sooner”
Back to the drawing board, time to iterate.
7
Observations
Users did not read the heading question
Users tried to zoom in to make the photo bigger
Users frequently referred back to the criteria list
Users did not see the ‘Refer to supervisor’ link
Users selected the wrong button in error
Users spent a lot of time deliberating if a shadow on the face should be rejected
“I didn’t mean to click that”
“It’s too small to tell, can I zoom?”
8
After a few rounds of user testing and iteration, we ended up with a version of the screen that was being successfully used by new members of staff (with no previous training) as well as the existing ones who were used to the old system.
“I feel confident using this”
“That was really easy to use”
Key changes
The biggest improvement: Radio buttons
Changing the option buttons to radio buttons gave users time to double check they have made the right decision before continuing. By having more space and clearly defining the options, users were also able to select quickly and accurately
Print preview toggle: This came from users being unsure about shadows. The toggle shows the user what the image will look like after the printing process. We matched the contrast and saturation levels with the printing department. This change made it clearer to see if the shadow would be acceptable or too prominent for the licence
Enlarged photo: At our suggestion, the photo is now cropped backend, before it gets to the user
Question heading next to the options: Added context and clarity
Application type heading: Since developing this service, there are now a few different applications users will deal with that involve viewing images. Users felt more confident seeing the application type on the screen, so they knew what the image was for
The conclusion
This specific user group had years of experience using the legacy system. Change was daunting to them and we had to be mindful of that. Every change we made had to be for the right reason, to benefit the user.
Summary -
1. Journey mapped the service, removed complexity and identified possible pain points
2. Created new patterns and solved problems based on previous experience and evolving information
3. Gathered those patterns in to a user journey that is simple to use and achieves the business needs
4. Made a click through prototype from static screens to be tested with users
What I did
5. Collaborated with user researchers and interpreted their reports to iterate designs based on user behaviour
6. Repeated steps 2, 4 and 5 until a level of confidence in the screens and journey is reached
7. Created a more complex and dynamic prototype to understand user behaviour when it comes to more complex patterns and interactions
8. Debriefed with project team
For this project, understanding user behaviour was more important than ever.
These users knew the processes inside out — they could do them in their sleep. Spending time with them and observing how they used the legacy system gave us invaluable insight.
Why did they do things a certain way? Were there workarounds or tips they shared with each other? Where were the pain points or moments of uncertainty? Answering these questions was crucial to designing a service that truly supported them in their work.
We combined our own observations with findings from user research sessions, which helped build a clearer, more rounded picture. Having access to a dedicated UX research lab gave us even more valuable insight, helping us make well-informed, user-centred decisions.