Improving waste and recycling services with design and prototyping

Defining and setting out objectives is an important step, missing it can lead to a meandering path where lots of “stuff” gets done but you lose track of what you are trying to achieve.

But we wanted to keep it simple. So, our alpha was defined as “Reduce unnecessary orders from residents”. It sounds simple, but making sure everyone is clear on what we were trying to do was a good anchor to keep each task focussed. We then set our sprint goals across the time we’d allocated to alpha. These were:

• Conclude user research and present back to the team
• Explore what processes we could affect
• Look at tools and platforms we could build on
• Prototype and build some tangible products
• Iterate those products and test with users

So where did we start?

First of all we had to whittle down the options by prioritising which opportunities would deliver the most value and be the simplest to do, whilst keeping in mind the timelines of the project. We had to be ambitious, but realistic.

We decided that we could deliver 4 key products to meet the alpha objective. They were:

• Explore functionality already built in to the council’s system to help identify repeat orders using an alert system based on geography.

• Make it easier for residents to order the right equipment by redesigning the form

• Build a reporting tool that aggregates business data over time and presents it back in a way that could be used to identify trends

• Provide a report on how to improve reporting capability in the future using tools such as PowerApps and PowerBI.

We quickly discovered that our first objective would be more difficult than originally thought. It wasn’t working as it should have and the council had already built a number of workarounds with the product, and as a fix was already being investigated this made it difficult to make any changes. So we focussed our time on developing a new prototype of the web ordering service and reporting tools which we’ll explore more in this blog.

Designing a new equipment ordering form

The first thing we did was to run some usability testing of the existing ordering form to test some of our assumptions about difficulties using it, mistakes that might get made on orders and potential for people to submit duplicate orders. We then used this info about the problems we identified to design the new screens / flows. We started sketching this out using screenshots of the existing service and working out where it started to cause issues for users. Once we’d done this we took a blank page approach and started redesigning. Rather than asking the user what they thought they needed, we took the approach to ask about their circumstances. Why they needed new equipment, what type of property they had and what type of waste they wanted to recycle. That led to a set of options that were all in one place, and easier to understand.

It seems funny to write about, but one of the main points of confusion in the existing process was around the term ‘swap’ – where a user was asked if the wanted to swap old broken equipment for new. It seems simple, but in that context just didn’t make sense.

So, we simply added a check box at the end of the process that said “collect my old equipment’ instead. Simple, but very effective and one of those things that would have just been missed if we’d not listened to users.

We also improved the email notifications as we found that if not kept up to date users would order again – so better communication would assure them that things were on track.

Creating a prototype and testing it with users

We spoke about using several tools to build this prototype. Sketch, Figma, Adobe XD – but as we were building in some lookups and a few other little tricks to improve the user experience, our tech lead Ben decided that it would be quicker for him to spin it up on a development server using the Angular web platform – it was his comfort zone and he knew he could get up to speed with delivering a first draft quickly.

After a great collaboration session with the council, we agreed the approach and added in the Gov.uk style guide to adopt good practice before testing with real users.

Again, we learned a lot. It was certainly much better but we’d made some assumptions that just didn’t work. Some of the emails we shared were “too nice” and not authoritative enough, and the way we structured the questions weren’t as logical to users as we’d thought they would be. Always interesting to watch.

So, we redesigned again.

Adopting the changes highlighted by our users. This is where we’d hit a bit of a snag. Ben our tech lead had coded this in JavaScript (very different to ‘Java’, despite the similarity in name!). And by now he was busy developing our BI tool and so we had limited resource to make the changes. But in the true spirit of collaboration, we gave it a go, and subsequently made it worse than it was. Thank goodness for Git and its rollback feature! But it was fun nonetheless.

Eventually we concluded our prototype of the new service and played this back to the team at Blaenau Gwent. The feedback on the process was really useful. We already knew that we’d prototyped based on user need rather than what was wholly technically possible on their live environment, so naturally there was some discussion around how some of it could be implemented. But overall, the approach, the testing, iterating and design was seen having more ability to satisfy users and reduce the duplicate orders.

Next week, we’ll be writing our final blog on what we learned, how we’ve used open-source code, and how we’re going to make sure that all the work we’ve done over the last 6 months can be used to create sustainable value into the future development of services at Blaenau Gwent.