First decide what kind of consultation the website actually supports.
A public consultation website is not a property sales landing page with the enquiry button renamed. Its job is to let affected people understand a proposal, inspect relevant information and respond through a clearly defined process. Visitors may be neighbours, local organisations, future users or people who disagree with the design. The page must work for all of them, not only people already enthusiastic about the project.
Distinguish informal project engagement run by a design team from a formal planning consultation administered under local rules. A project microsite should never claim to replace an authority's statutory submission or comment channel unless the responsible authority has explicitly confirmed that arrangement. Where a planning register exists, link to the official record and explain which channel counts for formal representations.
“This website explains the current proposal and collects design-team feedback. To submit a formal planning representation, use the relevant authority's official planning portal.” Adapt that distinction to the actual jurisdiction and process; do not copy it as a universal legal notice.
For an example of how formal planning comments are handled separately, see Barnet Council's public planning guidance. It illustrates a local process, not a rule for every project.
Build the content around questions people are likely to bring.
Before designing the page, list the concerns that different readers may have. A resident may want to understand height and overlooking; a parent may care about the route past a school; a business may ask about deliveries and construction access. A visitor who does not know architectural terminology still needs to find the answer.
Write the top-level navigation in ordinary language: The proposal, Site and surroundings, Plans and images, What may change, Have your say, Updates. If the scheme is small, these can be anchored sections rather than six separate pages. Give each section a clear purpose and avoid burying key facts in a presentation video.
On the first screen, identify the project and location, who is running the engagement, the current design stage, the opening and closing dates if confirmed, and the next useful action. If dates are not approved, do not invent a countdown. State that the timetable is to be confirmed.
Give the proposal a date, a revision and a responsible owner.
“Proposed design” is not a stable reference if drawings change during the engagement period. Create a small, public-facing record with a proposal revision, issue date, status and a named organisational contact. Match that record to the drawing set and image package. Readers should know whether they are looking at the current option or an earlier concept.
| Field | What to publish | Why it matters |
|---|---|---|
| Proposal status | Concept, consultation draft or submitted scheme, as applicable | Stops an early option being mistaken for approval |
| Revision and date | Version label and date of the published set | Connects comments to the correct drawings |
| Scope of feedback | Topics open for input and any fixed constraints | Sets expectations without pre-judging responses |
| Responsible team | Project contact and moderation owner | Makes follow-up accountable |
| Formal process | Official planning link, when relevant and verified | Prevents confusion over statutory channels |
When a new revision is published, keep a short change summary and the earlier version's identity. Do not silently overwrite a drawing while comments about it are still being collected. Archive access and retention should follow the actual engagement and records policy, not an invented one-size-fits-all rule.
Use drawings and renderings to explain the design, not to win an argument.
A polished sunset rendering can be an effective introduction. It cannot, by itself, answer how a proposal meets the pavement, what it replaces or how tall it is relative to neighbouring buildings. Build a sequence that moves from location to measured design to illustrative experience.
Start with a legible site plan and a clear boundary. Add elevations, sections or massing diagrams where they help explain height, distance and public space. Use views from identifiable locations rather than only idealised aerial angles. State whether a visual is a design-stage architectural visualisation, a measured photomontage or an existing-site photograph. Do not suggest that a rendering proves daylight, noise, traffic or planning compliance.
When the design is provisional, label important uncertainties close to the relevant image: planting maturity, facade materials, public-realm details or buildings shown for context. For more on controlling camera assumptions in context images, see our photomontage camera-matching guide.
Let visitors compare changes without changing the camera or the claim.
Consultation often involves alternatives: two entrance locations, a revised massing envelope or a changed public-space layout. A slider can help, but only if both views share a viewpoint, framing and comparable lighting. If the camera moves between options, a visual difference may be mistaken for a design improvement.
For each alternative, state what differs and what remains constant. Pair the visual comparison with a text summary and the relevant plan or section. A person who cannot use a slider must still be able to access both images and their descriptions. Avoid labels such as “community preferred” unless a real, documented process supports them.
Do not publish a “before” photograph and an “after” rendering as if they were equivalent evidence. Name the media accurately and keep the date and revision visible. When a proposal has changed substantially, publish an update rather than quietly replacing the old hero image.
Make technical information readable on a phone and without a mouse.
Consultation is weakened when the only readable plan is a large PDF that requires a desktop monitor. Offer a simple HTML summary of the main proposal, an appropriately sized preview of each drawing and a downloadable full-resolution document when publication rights permit. Identify drawings by meaningful titles and revisions, not filenames like final2_revised.pdf.
Provide a text description of the site boundary and the important design relationships so the map is not the sole source of information. Ensure that interactive maps, before-and-after controls and navigation can be used by keyboard. Test zoom, focus, contrast, touch targets, labels and error messages. A static accessible alternative is preferable to a beautiful interaction that traps visitors.
The W3C Web Content Accessibility Guidelines 2.2 provide a reference for testing accessibility. They do not replace hands-on checks with the actual drawings and forms.
Ask questions that can lead to a design decision.
“Do you like the project?” is easy to ask and hard to act on. A more useful form separates the topic from the comment: site access, public space, height and massing, landscape, servicing, other. Let people describe a concern in their own words, and avoid leading language that makes support appear to be the only reasonable response.
State who receives the response, whether individual replies are possible, what happens after the closing date and whether comments may be summarised or published. Do not require an account merely to view project information. Collect only personal information needed for the stated process, and agree the legal basis, retention period and privacy notice with the responsible organisation before launch.
Never automatically publish raw responses. Free-text comments can contain addresses, personal allegations or other sensitive information. The UK Information Commissioner's consultation privacy notice is one concrete example of explaining collection, use and publication; a project's own notice must reflect its actual controller, jurisdiction and processing.
Design moderation and response handling before opening the form.
Assign an owner to submissions and decide how to handle duplicates, abusive content, accessibility requests and technical failures. Acknowledge successful submission on screen. If a confirmation email is promised, test delivery. Preserve the version of the proposal that the respondent saw and a timestamp for the response, without collecting unnecessary identifiers.
Decide whether feedback will be analysed by topic, location, stakeholder group or design option. Keep raw responses separate from a public summary, and define a review process that prevents a single staff member from rewriting criticism into a favourable quote. Do not display a real-time approval percentage unless the methodology, sample and limitations are genuinely defensible.
Submit a test response on a phone, interrupt the connection, submit again, and verify what appears in the back office. A visually convincing form that silently drops responses is not a consultation tool.
Explain what was heard, what changed and what did not.
People are more likely to understand the process when there is a visible conclusion. Publish a dated summary of themes, the team's response and the design decisions that followed. Separate feedback received, design response and remaining questions. Do not promise that every suggestion will be adopted.
If a design remains unchanged, explain why in plain language. If the proposal is revised, identify the affected drawings and images and link the new version from the old update. A consultation site should remain intelligible after the feedback window closes, with the status clearly marked as closed rather than leaving a dead form in place.
For subsequent changes to public renderings, our rendering change-control checklist covers how to identify, approve and replace outdated visual assets across channels.
A fictional example: one courtyard entrance, two revisions.
The following record is fictional. It demonstrates a useful public change log; it is not a real project, consultation outcome or testimonial.
Notice what is absent: fabricated vote counts, a claimed preferred option and a promised design change. The record describes the question, the evidence and the next responsible action without pretending that engagement has already produced a result.
A real project would need verified dates, actual approved drawings and a genuine record of comments before this example could be replaced with project-specific information.
Test the published consultation journey, not just the page design.
- The project owner, design stage, scope and consultation dates are accurate.
- The site distinguishes informal engagement from formal planning representations.
- Each drawing and rendering has a clear status, revision and publication permission.
- Location, height and access can be understood without watching a video.
- Visual alternatives use comparable viewpoints and have text explanations.
- Plans, maps and controls remain usable with keyboard, zoom and touch.
- Forms explain the purpose of data collection and link to a project-specific privacy notice.
- Successful, invalid and interrupted submissions have been tested end to end.
- The moderation, response, retention and publication responsibilities are assigned.
- A plan exists for a dated response summary and closing the feedback window.
- The production URL, linked documents, canonical, sitemap and mobile layout are checked after deployment.
A website can help a design team listen, but it cannot make a consultation legitimate by itself. The governing process, accurate information and a traceable response to feedback matter more than the animation budget.