Bromford LAB

Online Repairs Reporting

Description: Visual prototypes had been used in the development of the customer portal interface, data collection requirements and data architecture required to support key business processes such as collecting online payments and issuing rent statements as part of Bromford’s transformation programme ‘milestone two’. These prototypes were designed externally and after the user stories had been generated by our colleague design team (known as subject matter experts, or SMEs), with the intention of helping our developer partner understand more about the solution they were building. 

We saw an opportunity for prototyping not only to enhance the aesthetics and usability of the solution, but also as a mechanic for drawing out key technical requirements, functions and integrations if used before user stories were sent for development. Leading this concept, Tom set about designing a number of ‘working wire-frames’ for what reporting a repair on the portal might look like and how it might operate. This included propositions for how we might support customer self-repair across a range of minor repairs tasks and use data to justify and inform the development and targeting of a range of bespoke service offers - such as a local handyman service or providing tool-kits. 

As a result a cohort of data architects, service leads, designers, system developers and SMEs have been drawn in to tackle crucial problems relating to how the portal will work. We’ve worked closely with Microsoft field operatives and discussed how to allocate priority to jobs - with a prototype ‘banding’ system starting discussions about our obligations and expectations responding to specific repair use cases. The team have applied a greater degree of attention to how functionality and interaction/usability play out in the design of our new repairs diagnostic. 

Actions: 

• Defined and iterated (with service leads) a viable service offer for repairs;

• Documented a potential process based around service and customer needs;

• Designed and built a visual prototype to demonstrate some of the requirements using Invision and Paint.net, and underwent several iterations as we uncovered many new constraints and opportunities in both the technology and our organisational capacity/appetite to support each proposition; 

• Guided key stakeholders in their approach to meeting these build requirements.

Outcomes:

• SMEs and the concept team have a clear appreciation for the ‘how’ we implement, communicate and design the solution being as important as the ‘what’; 

• A tighter product specification for repairs diagnostic, leaving our developer partners less need to infer/assume elements of the solution. By raising to the fore a number of technical and design challenges for early consideration we’ve saved considerable delay/cost/risk at identifying these post-build. Some of this happened in milestone two, however the real world impact of this was never costed by the programme team. 

Next Steps: The team are currently working through their ‘incident types’, rationalising them down from a list of thousands to as few as possible while still delivering enough data to get the right trades-person, with the right tools at the right appointment, first time. We’ll be on hand to interrogate this final list to ensure we can hit our pre-defined objectives and understand how it directs the choice of solution (independent software vendor integration or develop bespoke in-house).