What have we done so far?
In Sprint 2 we have worked across four streams of activity - business analysis, user research, technical architecture and development. I’ll briefly summarise each one before digging into what we’ve learned in a bit more detail.
In Sprint 1 we went broad and gathered as much material as possible across all of the Waste Services each council provides digitally. Moving into Sprint 2 we focused on three priority services:
Find my bin day
Request an Assisted Collection/Pullout
Subscribe to Garden Waste Collections
Our BA Martin spent time fleshing out the steps in each service to identify variations in the process , and gathered further details on the integrations with Waste Management Systems.
User Research Review
Our User Researcher Bal spent time gathering and reviewing existing user research , and the user experience for the three services in focus.
For each service she has reviewed the councils’ website & flows documented by Martin, overlayed any UR/Discovery work available and summarised her findings .
Our Technical Architect, Dave, is leading the work to define our low code enhancements. During Sprint 2 he continued work on defining the new Integrations Manager module , adding technical details to user stories ready for the dev team in a future sprint. He also completed definition of user stories for the Case Management configuration GUI which the team are currently working on.
During the sprint our development team completed work on the new Case Management case type creation GUI framework , and started implementation of the GUI for configuring Case Type settings. They also picked up stories that enhance the new Form Summary component so that it displays map locations.
The Case Management cube could be used for any service that requires council officers or suppliers to do tasks that can’t be integrated with a system. Our original UI involved a lot of editing of Groovy script and JSON arrays, and you had to create the form and workflow in different areas of Digital Place’s admin menus. We have now developed an integrated view of the workflow process that automatically generates the Groovy script which connects the workflow to the case type. You can edit stages from a listing, and pick the actions you want in that stage visually. Configuring the case dashboard and case type settings is next on the list – our devs are working on stories that turn these into visual layouts now. Finally we’ve made it easier to visually select the actions you want to be available for use in a case type.
What have we learned?
Common core: at its heart this is a simple service, request a postcode, lookup the address, validate that it’s in the council’s area, pass the address to the waste management system and request the next bin dates for that property, and display them on screen.
Variations: the variations between councils mainly arise in what and how results are displayed, and whether additional information is provided. Some councils provide a simple at a glance “your next collection dates are” listing with the type of collection identified. Other partners provide a longer page of information about all the possible collection types for that property, plus information notices about collection issues, changes to timetables, and calculate how many days it is to the next collection of each type. Some also offer downloadable calendars or display the dates visually in mini-calendar formats.
Common core: all of the partners start by asking the user to identify themselves and select their address, or to login to pre-populate those details, and of course every process includes some kind of step that asks the user to confirm they want an assisted collection, but beyond that there is a fair amount of variation
Variations: Some councils ask for a declaration up front, others at the end of the process. One council asks whether the assisted collection is short or long term before splitting the form into different short and long term reasons, another asks the duration question after the reasons, another asks a series of questions about reasons, one of which leads to a sub-question about whether the reason is permanent, and a third has a standard period for the collection to be in place. As far as we can see the wording used to describe reasons is quite varied too. Several councils ask where the bins are located, and one has a detailed set of questions about any hazards or barriers to deal with. Some councils integrate directly with a back office system, others create case records in a generic case management system, others send emails to the outsourced waste provider.
Common core: all of the partners start by asking the user to identify themselves and select their address, or to login to pre-populate those details. They all involve a check for an existing subscription and payment for the service, but there are a number of variations across the councils.
Variations: Some councils offer more than one type of container - bins or bags, some limit subscribers to a single container, others allow multiple containers to be ordered. The way that subscription costs are calculated varies too, two councils have a fixed cost, others are dependent on the period of the subscription, number of containers, or both. Most councils require payment online, one offers Direct Debit as well as card payments, and one still allows offline payments.
As a reminder - we aren’t identifying these variations because we want to rationalise the partner councils’ services to one customer journey, or because we are planning user testing to establish which is better… our interest in the variations is to help us identify what level of configuration we need to provide, so that we are confident that we are identifying the low code components required in the platform. As an example - it would be easy for us to provide a payment component for services that have a single fixed price no matter when you sign up. But for those councils that have set their Garden Waste service policy to support variable pricing dependent on the length of your subscription, we need to provide calculation capabilities.
What are we doing next in Sprint 3?
We have a sense of the broad themes we will be working on:
Completing the review of process maps, integration capabilities and user experience of first three services with partners to agree a common core and points of variation
Continuing design of enhancements to low-code Integration Management capabilities
Detailed investigation of APIs and integration methods for each partner Waste System in preparation for designing Digital Place integration connectors
Our Sprint 2 Show & Tell session will be held online at 2pm on 15 March, so please do get in touch if you'd like to attend this.
This project has been funded by the DLUHC Local Digital Fund.