Prototyping in Discovery
Client
This write up is a summary of prototyping process used while working on a complex project in HMRC.
Context
We’d been approached by a policy team to help unpick a proposed solution to see if it could work and would solve user problems. The project was short, we only had 3 months to get our heads around the policy area, the as-is, and to start testing the new service idea. The solution was also partly defined, so we weren’t necessarily starting with a blank piece of paper. With all of that in mind, we decided to take a slightly different approach and dive straight in to prototyping.
Why did we decide to prototype early on?
-
Prototyping during discovery enabled us to identify process gaps early on and devise workarounds for them. We found it beneficial to write the content in the prototype as close to the final version as possible. For us, the prototype highlighted some critical customer questions, such as:
What are the questions we need to ask the customer?
How would customers be aware of the answers?
Are there any edge case scenarios and customer groups we need to be aware of?
Do we need to give customers extra guidance at any stage?
Would any question result in increase HMRC call volumes for support?
How would the backend work?
Highlighting and discussing these questions with our stakeholders allowed us to continuously iterate our prototype.
-
We used our prototype during the research session for our participants to be able to visualise the new solution. Since our target audience were customers who didn’t hav interact with HMRC apart from this instance. In our research endeavours, prototypes served as powerful tools for user testing and feedback collection. It allowed us to observe user interactions, preferences, and pain points in a realistic context, facilitating data-driven decision-making. It helped our stakeholders ensure that the final service aligns closely with user needs and expectations.
-
Clear communication with stakeholders became crucial, especially since the project timeline were tight. Early prototyping acted as a common language, enabling effective communication among team members and policy teams. It facilitated a more accurate conveyance of design concepts, reducing the risk of misunderstandings and ensuring everyone is on the same page. Seeing a tangible representation of the change early on fostered confidence among the policy team, encouraged constructive feedbacks, and ensured that the expectations aligned with the policy intent.
Along with the prototype we used provacative statements to test the stakeholders assumptions of the new service. For eg.
The new service will create less admin for the customer
The new service will improve non-compliance
The new service will improve awareness of the tax charge
All of these statements challenged the stakeholders ideas and thoughts and helped improve the service for customers before it reached the delivery team.
-
The prototype was shared with the policy and the delivery team to help continue the project after we exited. Along with the wireframes, we shared our learning for the next steps and how we would change the prototype in a separate deck. This helped them to understand the service better and avoid any duplication in terms of testing that that already been done.
“The prototype was a useful tool for the core team (ahead of exposure to stakeholders) to centre our thinking, it meant that we had a ‘thing’ that removed any risk of us each having a slightly different idea of the service when coming away from discussions and reduce the risk of any misunderstanding.
The prototype also allowed the team to create empathy by putting ourselves in the customers shoes ahead of actually running any testing, however we had to be careful that we did not fall into the trap of using our experiences in place of understanding user needs.”
- Product Manager leading the project
Having taken the step to prototype before the ‘define’ stage, we realised it’s not something to be afraid of. We learned a lot from getting ideas down into a more tangible output. It meant we could identify gaps early on and resolve them before the delivery team stepped in, highlighting potential challenges within the service. Creating a prototype created a focal point for our user research activities and brought the idea to life, making it easier for customers to understand. It was also invaluable when talking through challenges with stakeholders, and getting them to see issues from a user perspective. And finally, it gave us a clear deliverable to hand over to the delivery team that they could pick up and run with.