3. Our approach
This project is based on a few key principles:
From documents to data
Instead of asking users to provide information by uploading documents (forms, reports, statements and drawings) that can only be read by humans, wherever possible, planning services should ask for information in the form of structured data that can be read by humans or machines.
Don’t check for mistakes, prevent them
This means that, instead of checking applications for errors after they have been submitted, we can prevent most errors occuring in the first place, before the user hits submit. If an application is not valid, users will not be able to submit it.
Don’t expect users to know what is required
Create a single point-of-access that guides the user through what information is required, based on their previous answers. Don’t expect them to research through multiple other websites and documents.
Only ask for what is required
Use dynamic forms to ensure that users are only asked for information that is relevant to their project, based on their previous answers.
Don’t ask something that is already known
Do not ask the user to tell us something they have already told us before, that planning officers already know, or can be worked out based on the information already provided (for example, the correct fee, or whether the property is in a conservation area).
APIs as a service
Allow the service to be used by third party software applications as well as humans, by receiving data via an API as well as via the main user interface. This will allow others to build complementary software applications on top the service. (Note need for appropriate security measures).
Modular, extendable and updateable
Break down the service pattern into modules, such that it can be edited using ‘low-code’ dynamic form editors, allowing it to be easily understood, maintained, improved and extended by domain experts (eg planning officers, internal consultees, service designers and content designers) without them knowing how to code. Also, separate national, regional and local policies and requirements, where suitable.
Pass on the planning application data as structured data, in such a way that back-office systems can use it, and the data can be passed on to registers automatically, without planners needing to do data entry.
Key design questions for this project:
1. How many planning documents can be replaced with planning data?
2. What are the data schemas that can capture most required information for planning applications?
3. Can we design a service pattern that captures the complex dependencies of required information involved in planning applications?
4. What dynamic form components are needed to cover most types of planning information?
5. How can we ensure that such a long, content-heavy digital service is legible and navigable for users?