London Borough of Southwark just completed an alpha project with DXW Digital Ltd, Greenwich, Lincoln and South Kesteven councils exploring approaches for the design of a common pattern for reporting, diagnosing and scheduling of housing repairs. The project is part of MHCLG’s local digital collaboration fund which aims to address common local service challenges in common, reusable ways.
Following a short inception period in December, we’ve spent the last 6 weeks (3 sprints) researching, designing, prototyping and testing. DXW digital engaged with a small core team of Debs (interaction designer), Vita (user researcher), Daria (service designer) and Alex (transformation manager) working with the support of experts across the four councils.
We’ve been writing weeknotes to update stakeholders about the progress of the work. You can read our previous weeknotes here. If you are coming fresh to this work, you might find it more useful to watch our show and tells here, and get the background of the project from the earlier discovery phase here.
Why is this work important?
There are over 160 local authorities with more than 1000 homes in England for which they are responsible for providing repairs. With some notable exceptions, the services available to report a problem and book a repair appointment have evolved in a pre-internet era. They are predominately phone based, with organisational needs prioritised over resident needs, and with gaps in communication that lead to significant failure demand (for example where residents call because of uncertainty about what is happening).
While the local context is different in each authority or area, the general pattern of needs for reporting and booking a repair is the same. This makes this challenge well suited to developing a common service pattern. A service pattern is a best practice guide for providing services that meet user needs.
It does not not require uniformity across all service providers and does not mean that there should be a single system that multiple councils will use. Councils should be able to adopt all or part of a pattern. By designing the pattern once, based on what is common, councils can quickly pick up the pattern and build a service for their own residents.
A service pattern can be seen as a recipe to design and build a service. A successful service pattern can be picked up by a service designer, service owner, or digital development team in a council who can then use the pattern to build the service itself (the meal). Each council (kitchen) is different and has different tools that work in different ways, and different ways of working – but the recipe gives them enough that they can create that meal. The recipe can be adapted and changed, but the meal is fundamentally the same. If one kitchen finds a better way of cooking the meal, they can update the recipe for other kitchens to benefit.
What did we do in alpha?
The discovery identified a pattern for housing repairs based on a current state, organisational view. We evolved this pattern into a user centred pattern, based on what our research found that a resident wants to achieve.
To get there, we designed activities in order to understand the user needs, the organisational needs and the constraints that the service exists within. By the end of the third sprint, we had completed:
- Service mapping workshops with the four authorities
- Observation sessions with contact centre staff
- A prototype of what the digital service could look like
- Design crit sessions with council staff to get feedback on the prototype
- Two rounds of prototype testing with residents
We used the approach of prototyping what an online journey could look like in order to test ideas and concepts that inform the overall service pattern. This means we recorded our design decisions as we went (why are we asking this thing? why do we display this content to the user? why do we send this notification?), with this rationale becoming the basis of the service pattern.
In the final sprint, we’ve brought together all of our learnings to design the high level pattern for a repair reporting and booking journey. We also have a prototype of what a digital repair reporting service could look like that has been built with council staff and tested with residents.
We produced a final report, summarising all of our research. Together with the prototype itself, this allows a team (or teams) to enter a next phase with confidence (see ‘what’s next’ below.)
We also developed a benefits case to validate the case for investing further in this work. Taking just the financial benefits, across the four partner authorities, benefits are estimated at £2.26m – £5.97m over ten years (depending on the level of channel shift achieved). Extrapolating this nationally, across a 50% of the remaining authorities in England with more than 1,000 units of accommodation, could realise £19.4m – £81m (high case) over ten years.
What did we learn?
The main learning is that a common service pattern for housing repairs is both possible and valuable., and that we know what it looks like. Because of the context and local service delivery differences between councils, a single system for housing repairs would likely be impossible, but the service pattern approach accommodates these differences.
An online service is only likely to succeed if it works seamlessly with the rest of the service. We learnt that a big barrier to the success of a digital service is trust. Rebuilding trust in the service is critical. This can be achieved by setting clear expectations, clearly and regularly communicating, and meeting commitments when they are made.
We also learnt that managing the scope of a project like this is crucial in order to deliver value in a short time scale. Housing repairs services are complex and there is no shortage of ideas on how to improve the experience for all involved. We focussed on a straight forward path for a council resident reporting a problem for the first time. Because of this, there are other areas we’d have liked to have tested and designed for (e.g. leaseholders, communal repairs, emergencies), but we simply didn’t have time and needed to be ruthless on scope to achieve what we did in our timescales.
Collaboration is both valuable and essential to create something common and re-usable. We’ve really enjoyed working with four authorities on a single project. A learning to take forward is the need for strong engagement with all involved, while ensuring the right governance – in essence that product leadership exists and decisions can be taken quickly and with the minimum of friction.
The four councils, led by Greenwich, have submitted an application to the MHCLG local digital fund for further funding to complete a beta phase of this work.
A successful beta involves building a real service for users. Therefore, the focus will need to switch from prototyping and pattern development to taking the learnings from discovery and alpha and building a working service. Prioritising what to build for a minimum viable product will be a critical first part of the next phase.
The recommended approach is that a service is built in the lead authority according to a common standard. All code and product artefacts will be shared for use by the other authorities in the partnership (and any others) who can undertake their own implementations and integrations into their own particular technology stacks. As beta progresses, new patterns will be discovered, and existing assumptions will be challenged. These should continue to inform the overall pattern for the benefit of all.
If you’re interested in learning more about this work or to understand how your council could benefit from the housing repairs common service pattern, then get in touch:
London Borough of Southwark –Jyde.Omotajo@Southwark.gov.uk
City of Lincoln Council – Fraser.trickett@Lincoln.gov.uk
Royal Borough of Greenwich –Kit.Collingwood@royalgreenwich.gov.uk
South Kesteven District Council – G.Andrew@southkesteven.gov.uk
DXW digital Ltd – email@example.com