Sprint and Workshop w/e 20 Nov ‘20
Our latest partner workshop (number 13) kicked off with a discussion around the new prototype for Lawful Development Certificate (LDC) applications for proposed use. This had been presented in our 12th Show and Tell. The partners felt that the use of drawings was incredibly valuable when communicating with individuals who perhaps have less technical knowledge of the planning system.
We recognized there was a need to bridge the gap in conversations; for example we use the term “data” a lot — but what does that actually mean? Using drawings is one way of bridging that gap in language and helping others to understand what we’re talking about. A user can more easily decide between two drawings when answering, for example, if their extension will be to the side or to the rear. Additionally, by allowing users to select different images which relate to their proposed development, we can also create a shortcut around users having to read lengthy policy documents to work out and understand what information is required for an LDC application — making our product more accessible.
The level of specificity of images was discussed — and how much this should be developed in the future. The downside to these images is that they show users an abstraction, so the image won’t necessarily look like their own property. The challenge is getting users to buy into just enough abstraction that they think: “OK this doesn’t exactly look like my house, but I get the idea”. It will be interesting to test and draw results from that conundrum in future user testing.
One partner proposed the use of audio descriptions under images to further help engage users with the tool. Without doubt — the addition of drawings has made a significant improvement to the prototype.
Get the Inside right. The outside will fall into place… — Eckhart Tolle
When Tolle wrote these famous words, he may not have been thinking about Lawful Development Certificates… Nonetheless, these words are arguably relevant to Workshop 13.
First up was reviewing the Checklist that had been drafted over the last sprint. The checklist provides the tasks/items that must be in place in order for the LDC private Beta to work.
The items were listed by priority —
High being ‘must haves’ without which the private Beta won’t work
Medium — would be nice to have but we can find work arounds if not in place; and Low — absolute bonus if available.
The partners started by reviewing the items marked as High Priority for the MVP (Minimum Viable Product) for the December 2020 Golive — see below for discussion.
GIS (geographic information system) Layers: Trial and Error
One key focus of the project has been “Don’t ask users for any information we already have”. The hope is, as a result, the process will be much easier for applicants and will lead to higher quality submissions.
For those who have been regularly following our progress, you will know that a lot of work has gone into programming our online tool with GIS layers. These layers inform, for example, which local planning constraints (e.g. if a property is in a conservation area) and other factors affect users’ applications.
One partner highlighted that completing this exercise for December will be challenging due to the variation in data held by local authorities. This is particularly relevant to the mapping of Article 4’s — a condition set by local planning authorities to restrict permitted development rights. Whilst the programming of this data was identified as ‘high priority’ in advance of the launch of our private Beta, a number of partners expressed the need to test the service further with users and stakeholders. Information about Article 4’s tends to be recorded differently among councils, with some holding digital records and others paper documents.
The mapping of GIS layers is also linked with the varying spatial requirements of local planning authorities involved in the RIPA project. For example, 75% of the land area in Buckinghamshire is classified as within an Area of Outstanding Natural Beauty (AONB) and requires further attention as the project progresses.
Partners were asked to review and tick off where they had completed the required items for their councils, as well as to raise any potentially missing tasks/items that may need to be added to the High Priority list.
Finding Exceptions
Another high priority item identified by the partners consisted of testing the Beta product with stakeholder planners — getting them to run historic cases through the system. Whilst a phenomenal amount of work has gone into programming our tool with rules from planning policy, it was agreed that:
“Only by using the service will we find weird exceptions in the rules.”
As an example of a more technical aspect previously addressed by the design team, one partner raised the question of “which side is the front of my house?”. This could be particularly relevant to users who live on the corner of their street or users who tend to access their house more frequently from a side door. Whilst this question has been clarified in our online tool, we are expecting similar small-scale questions to arise once we go live.
Gov.Pay.UK
We touched on the payment system that the private Beta will be using. In a previous sprint we provided ideal field templates, however, these ‘ideals’ included fields such as postcode. The question posed: ‘is it really necessary for the finance team to have a postcode provided or are they just used to having that field in their existing system and replicating it through habit?’. Is a postcode really necessary for payment information? There is currently a standard field output template from Gov.Pay.UK that can be used by finance teams and if we can encourage finance teams to use this template, this could reduce a lot of additional work. You never know, finance teams may find they don’t need or even use all of the additional fields that are currently requested.
The question for MVP needs to be — can we make the file work? We need to establish whether it is a firm constraint that the council systems will not accept an import unless a certain field is within that file. If this is the case, for now, perhaps as a workaround we simply fill that field with “n/a” for the short period of time whilst we test the MVP of the private Beta.
Timeline Discussion
The partners ended Workshop 13 by discussing the overall timeline of the RIPA project’s Beta Phase. Over the last sprint, partner councils have been busy drafting proposals of what the Beta product will look like in their local authority. This spreadsheet incorporates a range of areas — including Key Goals, overall Parameters and Feedback Mechanisms (to test the success of our service).
Te partners agreed that the period from January — March 2021 should consist of end-to-end user testing. This is where alignment with our sister project, the Back-office Planning System or ‘BoPs’, is particularly important.
Once users submit their applications through the RIPA system, this information will then be passed through the BoPs process to be assessed by planning officers. We therefore need to ensure that both RIPA and BoPs are streamlined as much as possible so that the two projects can work efficiently together.
We recognized that we don’t need to wait for GoLive to start testing — and could do with building a rough plan of phases — so the first phase would be 5 or 10 dummy cases that represent the most common type of application. Planning officers can also help us with scenario gathering.
We also want to start testing ‘dummy’ scenarios to find out more about the exceptions and issues for those who are not so familiar with planning — but may have submitted a planning application in the past. An obvious place to find such volunteers would be internally within partner councils. Housing, Regeneration — and other officers — may well have experience of submitting their own planning applications, as well as planning officers who may have experience working as private agents. Also — Councillors who are interested in the tool could be willing to use it to try submitting an application. For some forms of testing, it will always be most beneficial to use complete lay users — again we can reach out internally across council departments pending the GoLive. For now, we need to start reaching out internally for volunteers to help us with this pre-Golive testing.
Finally, we considered what we are testing and how best to test our services. We plan to have two main groups involved in this research:
Stakeholders: ensuring that the service is viable and not problematic for planners
Users: testing the overall accessibility of the system
Over the next sprint, one of the tasks teh partners will continue with will be mapping out the high priority areas for our LDC tool and working alongside the BoPs team to develop the end-to-end service.
