A “modern” approach to back-office planning
Manifold is a project aimed at replacing DEF’s current software offering of MasterGov (a suite of tools covering the entire planning industry). Converting desktop software to the web is always a challenge but even more so for the highly demanding and constantly changing requirements, the planning industry demands. Officers at local councils need to move quickly but at the same time have enough flexibility within the system to adapt to applications when requirements change.
- Timeline: 2020-Ongoing
- Process: Agile
- Roles: UX/UI design, design systems, service design, UX research, focus group, consultant for Telford and Wrekin Council.
Designing a UX for flexibility
A big challenge of this project was MasterGov was a product customised to each individual authority and was built in a way to handle the ever-changing requirements of a planning application; as such the users expected and wanted to feel like they had control over the product. This led to many problems for the company such as:
- Inconsistent builds between customers.
- Security and bugs were commonplace.
- A very condensed and busy UI.
- Problems launching the software over VPN connections from home.
- A bad developer experience and process for dealing with bugs.
Manifold presented an opportunity to fix many of these problems but it wasn’t going to be easy. When I first started on the project many customers echoed complaints about moving to a web app:
I’m worried about my data being easily accessible, MasterGov doesn’t shy away from allowing users to feel in control and I feel moving to Manifold we may miss that.
We’ve spent a lot of time customising MasterGov and we acknowledge that things will change with Manifold but I hope we don’t lose what we’ve built.
Most of the research I did at the start was trying to understand our customers, competitors and the overall planning process but somewhere along the way, I realised that Manifold was more than a product for users.
Goal: To design an adaptable, accessible, user-friendly product that replaces the MasterGov suite of tools but goes further to improve the agile process for support, developers and user feedback iteration.
Early user personas
Figure by PlanX describing the Planning Process
Manifold as a service design
Quickly I realised this project involved more than the user. This product represented a chance to change the business practises, developer processes and the agile process to be more efficient. I began by outlining a sprint process I think best suited the project.
Outline of my sprint process
The sprint process had a timeline of about 1 month (with being the sole UX designer I figured this was realistic). I presented my research and my conclusions to the project lead and developers and they were more than happy for me to take the lead on implementing this myself.
Eventually, Telford and Wrekin Council joined the project as stakeholders/project partners and started taking a more direct interest in my designs, with this we took the reins and collaborated on the sprints. Teaching them about the design process so they could comment more on the designs.
Sketch of some designs provided by stakeholder collaboration
Picture of a whiteboard session around a sprint
A product for multiple jobs
One of the biggest hurdles to jump over initially was understanding that when designing a prototype with Telford and Wrekin for “Planning” required a different approach than designing a prototype for “Building Regulations”. The reason for this is because even though they belong to the same industry they each have different workflows, legislation and structured differently.
I noticed we were much more productive with our output of prototypes when we adopted different thinking strategies for each tool within Manifold. For example, we’d think more logically and impose more restrictions within “Building Regulations” and for “Planning” we’d adopt more of a “what if” approach - optimising more for edge cases.
Pushing boundaries in the right areas
When I begin working on a feature for a sprint, I always ask myself what could be improved, I’d question not just myself but our stakeholders, developers, current users and project leads on what they think about this specific area.
A recent sprint we finished up was around “Planning Consultations”. A big area of planning that was in need of some overhauls.
Another whiteboard example covering a different sprint with sketches
After interviewing and surveying a bunch of our users myself and Telford and Wrekin deducted that consultations was not organised and we hypothesised that better organisation of data was key to our success. Many users sometimes complained it was hard to find neighbour responses to planning applications under the same address and that the data was hard to copy/paste into the reports that they write.
To fix this we organised the responses into a collapsible tree view which grouped neighbours by address but at the same time grouped responses by the same person in a table.
High-fidelity design example of the consultations sprint
We also heard from users at Telford and Wrekin that they tend to use the register to view comments as the structure in their current system was disorganised, again to fix this we came up with a few ideas.
High-fidelity design example of the consultations sprint summary screen
Upon demoing to the users, many loved the simple interface and how it brings the data to the front and organises by who sent the response. They also expressed a happy response to the fact they can now get map data within the consultations area to view responses by address.
One area they didn’t feel to comfortable with was that neighbours choose why they’re objecting/supporting. Officers confessed that this is a job they like to do themselves as they write it in a report. They also pointed out how busy the response totals area could get and expressed an interest in having objections per address.
Improvement sketch provided by feedback from users
The team and I went back to the drawing board and analysed the prototype to find areas to improve upon. The new direction seemed promising.
A recent example of an area where Manifold aims to push boundaries but at the same time realises when pushing boundaries goes too far and reels it back, and the majority of the time makes the design even simpler to use.
The design system
Upon building numerous prototypes, I realised that Manifold’s development process could benefit from a design system. A system of components and rules the developers could use to develop features and build the product faster.
Picture of the design system so far
The result
Overtime this project saw increasing interest from all of our current customers which cover 41% of the UK and most of Northern Ireland, this was done by the increasing number of user interviews/workshops I held for our customers as well as the focus group I setup for customers to take an active role in the agile process.
We were also seeing some interest in the project from other councils that weren’t on MasterGov.
The project has also been well received by the developers on our team (that work on MasterGov) and users within Telford and Wrekin Council have expressed excitement in the prototypes demoed to them that myself and the team have collaborated on.
This project is still ongoing…