Prototyping in Discovery
This write up is a summary of prototyping process used while working on a complex project in HMRC.
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.
Be clear, be confident and don’t overthink it. The beauty of your story is that it’s going to continue to evolve and your site can evolve with it. Your goal should be to make it feel right for right now. Later will take care of itself. It always does.
Why did we decide to prototype early on?
To Identify gaps early on the discovery
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.
Use it as an artefact for research
We used our prototype during the research session for our participants to be able to visualize the new solution. Since our target audience were customers who didn’t interact with HMRC apart from this instance. In our research endeavors, 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.
Enhanced communication
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.
Prototype as a deliverable
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.
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.
