Metering Officer Scheduling System: Native App and Desktop Scheduler
Full Product Design life cycle incorporating a mobile application that allows Meter Officers to efficiently read water meters and a desktop site to allow Schedulers to manage and organise the Meter Officers.
Overview
Team of ten including Frontend and Backend Developers, Product Owner, Scrum Master and myself as the sole UX/UI Designer
End to end product design in Agile of a native android mobile application and a complementary website scheduler encompassing business analysis, generative and explorative research such as contextual interviews and usability testing, information architecture and low to high fidelity prototypes.
The release of the application and website resulted in the company saving an average of £236 per Meter Technician through decreased specialist device costs and a decrease in downtime for device issues.
The Opportunity
Anglian Water are leaders in the Utilities industry for customer service and serve 2.6 million properties in the UK. As part of a large scale digital transformation across the company, Anglian Water recognised the need to overhaul the current meter reading system. Meter Reading is a fundamental department within Anglian Water, calculating water usage and rates for their customers, bringing just shy of £1 billion pounds of revenue annually in 2018.
The current meter reading devices had come to the end of the product life cycle. With the need to update the hardware being used out in the field, came a need to review a programme that had lain untouched for over a decade. With this update, we could provide a system that was intuitive, easy to use and most importantly designed with the users in mind.
Project Kickoff and Stakeholder Engagement
Earlier in the year, Anglian Water trialled a small project in Agile and was keen to establish this methodology with the MOSS project.
Led by the Lead UX designer and an agile coach, we began with a project kickoff workshop, that gathered the team, including the developers, the product owner, the business analyst and the project manager. We sat down as a team in a kickoff meeting to outline Agile and understand the minimum viable product for the handheld units based on earlier discussions with the stakeholders and users.
After identification of the minimum viable product features, the Lead UX and I conducted a feature prioritisation with the team. We were able to compile this into four releases, a more manageable plan for the team.
However, the euphoria around the successful kickoff was short lived. Before the kickoff meeting ended, the revised budget proposal was refused. The project was at risk of not going ahead the next week.
The project was salvaged in the next 24 hours, but with significant changes. The Lead UX had 3 days over the next 3 weeks; I became the sole UX designer, down to only 3 days a week and the dedicated project manager and the agile coach were removed from the team.
Ideation and Iteration
With a newly restricted budget, we were keen to maximise the efficiency of my time and the limited time that I had with the Lead UX designer. In just a few weeks, I would be working by myself on a mammoth project and joining on the initial discovery for a second Agile project.
For each release, high-level user flows were sketched out in rough. For the first release user flows, I wanted to build high fidelity diagrams. However, with such limited time on the project, I soon found that high fidelity sketches or even paper prototypes would be a luxury I could not afford. As there had been a UI designer who had put together an Anglian Water pattern library on a previous Anglian Water project, the idea was that I would use the pattern library to guide the wireframe components and make the hand over to the developers easier.
For each story on Azure DevOps, I created tasks from backlog stories to formulate wireframes. I sketched out paper wireframes and whiteboard wireframes with detailed annotations. This was supplemented by walking the product owner and developers through the wire flow to ensure that it was usable by Meter Technicians and that the designs were technically possible.
I soon found that using sketches in conjunction with referencing the pattern library was not enough. What was being produced in development did not match what the product owner or I visualised. After a build, we spent a lot of extra time negotiating what the developers could accomplish there and then, and what would have to go into the backlog.
I was able to convince the senior project managers that I needed to spend some extra time to develop high fidelity wireframes. This helped solve a lot of our initial issues but came with its own challenges.
As we did not receive any additional budget, I moved from using low fidelity wireframes to get feedback, to only using high fidelity wireframes. This led to discussions fixated on the visuals with little focus on key functionality. To counteract this, I had members of the team sketch out bigger ideas with me to involve them earlier in stylistic choices.
Usability Testing
I was fortunate enough to be able to start testing the product early on. The product owner and the wider department were extremely keen on getting the releases in front of users to get feedback. Through this, I was able to conduct some research on user needs in the guise of mini field studies while gathering useful product feedback.
Using Optimal Workshop, I could make notes while testing and then add tags to the observations. I was also able to capture participants' screen interactions, journey and audio using screen capture software.
During testing in the field with the Meter Technicians, I discovered that having the route and meter location visible without the need to scroll on the handheld unit, was more important than having the address prominently displayed. I relayed these findings to the team and we decided to reorder the screen.
The biggest issue I found with testing was that there was not enough time for it. I started off on the project with 3 days a week, which meant I had 6 days in every sprint. Testing and analysis at a minimum required two days of work. This meant there was regularly a risk of there not being enough wireframes for stories being completed. I highlighted this issue early on and eventually, the company had to ask for more budgeting resources.
Commercial Outcomes
When we presented the first three releases to the lead business sponsor, the Director of Metering, we received extremely positive feedback with the business sponsor saying, “Both the scheduling system and the handhelds themselves looked really easy to use, very intuitive, responsive and designed with the end users in mind. The overall solution should ensure we remain leaders in meter reading services and continue to improve the customer experience.”
After the live release of the product, we saved the company an average of £236 per Meter Technician through decreased specialist device costs and a decrease in downtime for device issues.
