3 tips to avoid a Post Office scandal- a user research perspective
Over the past few weeks, I think we have all been horrified to see the extend of the UK Post Office miscarriages of justice depicted in the Mr Bates vs The Post Office tv drama.
The accounting software program (Horizon) for post office was rolled out across the UK despite known bugs and it not being fit for purpose. As a result over 900 subpostmasters were prosecuted for false accounting and fraud.
Here are 3 things user research could help you with in avoiding the same mistakes:
1. Incorporate user research in agile sprints
It is clear that waterfall development with a big list of requirements at the start didn’t work in this incase. Instead, look at how you can move to a fortnightly sprint cycle where you decide on high-value features to research, test and develop.
At least 1 day of the 10-day sprint should be dedicated to user research. It is not a hard thing to do, many product companies are successfully doing this now. I’ve shared how the sprint cycle looks like with user research activities.
My framework on user research activities in an agile sprint:
2. Do contextual research to understand how post office works
The role of a post office is actually complex depending on the needs of the customers in front of them- from postage, to paying bills, to supporting the welfare system. These complex tasks and processes need to be well understood.
- How do post masters actually work? How do they switch between these tasks?
- How do post masters keep track of book keeping currently? What challenges do they face?
- How can your software solve their problems? (not create complex workarounds)
3. Run a pilot with feedback mechanisms
Of course, having a prototype and running pilots are great ideas. But make sure you set parameters on what you want to learn this exercise.
- What does success look like for the pilot? Perhaps it’s the ability for postmaters to accurately do their books, and less about looking for fraudulent behaviours? (Also, if that really is your aim, define what’s your tolerance level for malignant behaviours)
- How should users give feedback throughout the process? Will you have 1–1 feedback sessions with the pilot users? Is there a pre-launch briefing? How often will you be speaking to your pilot users?
- What is your feedback loop? Once you’ve received the feedback from users, how will the issues be investigated and prioritised so they are fed back to the development cycle? There is no point collecting feedback and then do nothing about it!
