User testing and training

Even with the most carefully considered content and structure, your code will benefit from testing with end users. This will help you to spot issues and refine passages for maximum useability. For some Pathfinders, the process led to substantial changes, saving them time and unanticipated expense later in the project.

Pathfinders used a range of methods to ‘road test’ their codes during the drafting process. These included in-depth workshops, training and briefing sessions with planning committee members, engaging with existing developer and stakeholder forums, and working directly with architects and agents to see how comfortable they were with using the code.

Typically, Pathfinders tested their codes once an initial draft was available. It is worth noting that these drafts were informed by inputs from earlier engagements with users, and so the project leads could be confident that their drafts, while far from perfect, were at least on the right track.

The testing phase had extra benefits. It updated user groups about how the code would work so that they could be better prepared once it was adopted. It also promoted the code more generally so that its adoption would not come as a surprise.

Some Pathfinders planned to maintain the ‘feedback loop’ of testing and refining their codes beyond adoption in a process of continuous improvement. As the team from East Riding of Yorkshire Council put it, “As things become more standard practice, we can add extra things and keep raising the bar.”

The East Riding Pathfinder team ran ten immersive three-hour workshops with their development management officers over two weeks to test their code’s useability.

Comprising of colleagues at all levels of seniority, the group was broken into smaller teams, each of which was asked to apply the code to a ‘guinea pig’ live application. About a third of the time was used to test the code on the application, with the remainder used for wider discussion about participants’ experience.

Clearly, the lead team learnt from participants, which helped them refine the code in several ways. They improved the imagery to better illustrate the code requirements, refined overly prescriptive codes and the compliance checklist to enhance useability, and combined placetype codes with authority-wide requirements to reduce the page count. It was also an opportunity to tell the participants how their previous inputs had been incorporated, which built confidence that participants’ needs were being addressed.

Digitisation

Digitisation offers a key tool for councils when considering the useability of design codes. The ability to navigate directly to the sections of code that apply to a specific site or application, combined with tabs of additional information for those that need it means that a web-based format can be well-suited to clear communication of design code information.

Trafford Council worked with their consultants to produce a digital platform for their design code that was easy to use. They worked with their team and framework consultants to prioritise the key diagrams and visual material that would help to communicate the code without becoming overwhelming. As a result, Trafford have received positive feedback from code users:

“We’re proud of how easy it is [to use]. We hope that somebody who doesn’t even know what a design code is could go on to this website and to the platform and look at the codes. They’re straightforward and clear.”

Best-practice principles for user-friendly codes

Feedback on how easy or difficult design codes were to use often came down to general best-practice principles. The checklist below summarises the most commonly received feedback.

Do

Think about your intended audiences. Consider separating your final code into different versions for user groups with distinct needs. Making these decisions early will avoid abortive work.

Be concise. Even 50-page documents have received feedback saying, ‘This is too long’!

Tailor your language. Codes for homeowners should be simple and avoid jargon. People making larger applications are likely to be more knowledgeable and familiar with the planning and design process and so versions for them can be more technical.

People are put off by lots of text so, wherever appropriate, communicate visually through good illustrations and accessible graphic design. The NMDC includes examples of useful illustrations that are free to download. See also ‘Presenting Codes’.

Consider using compliance checklists. These have generally been well-received as a simple way to navigate code requirements by applicants and development management teams. Checklists can be included at the end of relevant chapters, or collated together in one place. See also ‘Laying the groundwork’.

DON’T

Don’t swamp users in information. As the team at City of Bradford Metropolitan District Council pointed out, “Developers and development management officers just find it overwhelming, the amount of stuff to factor in. The key for codes is to stand out amongst this, to be a clear and easy tool to use so people can see why we are doing this”.

Don’t include non-essential additional information, such as background analysis, that can be consigned to separate documents. The main code can afford to be quite sparse.

The relationship between the main code and supporting documents must be clear and well-mapped. This does not mean that other documents need to be referenced in the code itself, but rather that the team managing the code should clearly understand how all documents integrate. Keeping certain information separate is a great tactic for avoiding duplication, possible contradiction or misalignment between documents.

Don’t feel compelled to digitise until you have a good draft in place. It will be important, however, to have a good data schema which can allow you to process and present information in different ways, including with future digitisation. If you do intend to release your code in a digital format, structuring your drafts accordingly is strongly advised.

This piece was written in collaboration with Holly Lewis, a registered architect and co-founding partner at We Made That. Holly has extensive experience in urban projects, including industrial intensification and high street regeneration. Holly Lewis – Design Council