Spending time struggling to renovate my own house has perhaps unsurprisingly got me reflecting on the Adur Homes Repairs app that we successfully launched at the end of last year.

It was an ambitious project, consisting of five major components:

  • a customer portal for requesting repairs
  • a mobile app for Repairs Operatives on site
  • a Contact Centre portal
  • invoicing and finance integration
  • an admin and scheduling interface for the back office.

I have given several demos to various Local Authorities and it’s fair to say the focus is usually on the customer portal – diagnosing the repair and booking an Operative of the right trade. We believe we’ve achieved a simple and effective design with the help of a UX Consultancy and much research and iteration.

What can sometimes be missed, with all the focus on the public interface, is the approach taken to design the back office side of the system (which has around 60 users from a variety of departments). How do you achieve a balance between functionality and simplicity? What principles should be applied?

At the beginning of the build I had a brief conversation with another dev about the world-wide adoption of Microsoft Office in the 90s and why it had been so successful. It struck us that apart from the new-at-the-time notion of applications in ‘windows’ the most user friendly aspect was that a task could be performed in many ways – for example saving a file had an icon, it’s own menu item and also a keyboard shortcut.

Although it’s perhaps unfashionable to look back to that time given how far operating system and application design has come, we agreed that intuitive layouts and ‘many paths to an action’ should always be key.

It occurred to us that the equivalent in a browser based application could be to make as many displayed fields as possible ‘clickable links’. That is to say, if an address is displayed for a repair, it should be clickable to view the repair history, a location map, and perhaps further link to other apps that use address such as the Asbestos Register, Stock Condition Survey, Compliance, etc.

However, rather than same-tab links that would require a mashing of the ‘back’ and ‘forward’ browser buttons, the links should be served as ‘overlay pop ups’ so the user doesn’t lose their place or worry about form resubmission as they navigate. They can simply click outside of the pop-up to return to their starting point.

In this way, we can view a repair, click on the booked operative’s name and see their status, trade, contact details, current job list, etc. Then clicking on their trade could show a list of all other operatives of that trade. We could then click on one of those operatives to see their details and job list, etc. At each step, we can click out of the pop up to close it or keep drilling down. We’ve not navigated away from our original repair so we are not ‘lost’ in the system.

Users have reported that they find this intuitive; it prevents cluttered screens and gives many ways to access the same information without having to memorise the layout of every interface page.

Finally, key to this interlinking approach are strategically developed data models and application architecture so that linking between apps sharing common core data is seamless and instant. Our low-code cloud platform, Matssoft, has allowed us to achieve this - although that is probably a story for another blog!