“How long will planning permission take?” is a common question, but a single figure is misleading without the project’s location, scope and approval route. A useful FAQ explains what affects the timetable, what the client needs to provide and when the team can offer a firmer estimate. The point is to help someone make a decision, not make a complex process sound simple.
FAQs are most useful as a reference for recurring questions about a particular service, building or project stage. They cannot replace a project brief, statutory advice or a detailed service page. Their narrower job is to clear up predictable uncertainties and direct readers to the right next step.
Start with a specific audience and purpose
A developer assessing a site needs different answers from a tenant preparing to occupy a completed building. The developer may ask about surveys, design stages, cost estimates and approvals. The tenant may need to know the opening hours, access arrangements, delivery procedures and whom to contact about a defect. Mix those questions on one undifferentiated page and both readers have more work to do.
Before choosing questions, define the page in one sentence: “This FAQ helps prospective healthcare clients understand what we need before a feasibility study.” That gives the page a clear boundary. Families using a new public facility might need a separate FAQ; neighbours affected by site access and working hours might need information specific to the construction phase.
State the location or project wherever the answer depends on it. You can give a definite answer about the accessible entrances at one completed library. You cannot give one answer about accessibility requirements for every future library project: the brief and local requirements will differ.
Collect questions people actually ask
Start with the words people use before they know your internal terminology. Review enquiry emails, meeting notes, reception logs, handover queries and questions raised during public consultation. Ask the colleagues who handle them which questions recur and which were one-offs. Frequency is not the only test, though: a visitor needs to know about step-free access before travelling, even if few people ask.
Sort questions by audience and task, then look for duplicates. “Can the building remain open during refurbishment?” and “Will we have to close?” express the same concern. “What does the architect do?” is broader and may be better suited to a service page. The FAQ could answer a more precise question: “Who coordinates the structural engineer?”
A small selection table makes those decisions easier to check:
| Candidate question | Best treatment | Reason |
|---|---|---|
| What information is needed for an initial site review? | Answer in the FAQ | A short checklist can help most prospective clients. |
| What will my exact project cost? | Explain the estimating process | A reliable figure needs a defined scope and project-specific information. |
| How are all project costs controlled? | Use a dedicated guide or service page | The topic needs more detail than a short answer allows. |
| Is the west entrance open this week? | Use a current building notice | The answer may change too quickly for a general FAQ. |
Do not include a question just because it matches a search phrase. If the team cannot give a useful, supportable answer, gather the missing facts or leave it out.
Organise the page around decisions, not departments
Teams may file information under design, finance and operations. Readers are more likely to look for what they need to do next. A project enquiry FAQ could group questions under “Before the first meeting,” “Scope and fees,” “Approvals” and “During construction.” For a completed building, “Getting here,” “Using the building” and “Reporting a problem” may be more helpful.
Lead each group with the questions that have the greatest practical consequences. At a public venue, step-free access matters more urgently than the history of the design. Someone considering a commission may need to know what to bring to an initial discussion before learning the names of every design stage.
Move substantial explanations to the pages where they belong. An FAQ can give a general answer to “When is a planning application needed?” and explain that the proposal and local rules determine the result. It should not try to reproduce an approvals manual. If several answers become long and overlap, give that topic its own clearly structured page.
Write question headings in the reader’s words
“Can we use the building while work is underway?” is easier to recognise than “Phasing and operational continuity.” Use technical terms where they add precision, but define them on first use. Keep separate issues in separate headings: cost, completion dates and permission each depend on different evidence and may change at different times.
Separate the client’s responsibilities from the design team’s, too. “Who submits the application?” is not the same as “Who decides whether permission is granted?” Submission arrangements can be agreed within the project team; the decision belongs to the relevant authority.
Build each answer around a useful first sentence
A reader scanning the page should find the answer before the background. Give a direct response, then the condition, reason or next step. For example:
Can you give us a construction cost before design starts? “We can discuss an indicative budget, but a dependable estimate needs an agreed scope, site information and assumptions about specification and procurement. At the first review, we identify which inputs are available and record the main uncertainties.”
That answers the question without presenting an early budget as a fixed price. For an occupied refurbishment, use the same approach: say whether continued use is being considered, identify what is needed to assess phasing, and make clear that safe access and construction methods must be resolved before anyone promises uninterrupted operation.
If an answer depends on a rule, contract or building-specific procedure, name the source in plain language. “The approved access plan identifies the temporary entrance” tells the reader more than “access may vary.” If the plan has not been approved, say so; a proposed arrangement is not yet an operational fact.
Keep exceptions visible without burying the answer
Qualifications matter, but a run of “may,” “usually” and “subject to” can leave readers none the wiser. Name what changes the answer. Rather than saying only that additional surveys may be needed, explain that an existing building may require a measured survey, while ground conditions or suspected contamination may call for specialist investigation. Confirm the scope for the particular site.
For fees, distinguish what the quoted service includes from costs that may sit outside it, such as statutory charges, specialist surveys or changes to the agreed brief. For programme questions, distinguish the design team’s working time from external review periods, procurement and construction. Readers can then compare proposals without mistaking a preliminary allowance for a guarantee.
Check technical claims and protect sensitive information
An FAQ is published guidance, however conversational it sounds. Ask the responsible specialist to check answers about approvals, fire strategy, accessibility, energy performance, construction sequencing and building operation. Check the current project record or applicable requirements rather than relying on an answer remembered from another scheme. If rules vary by location, say so.
Before turning a client’s question into a public answer, remove identifying details and check that the situation applies more widely. Do not publish security arrangements, personal contact details, confidential budgets or unresolved contractual positions. Where an answer requires a case-specific assessment, tell the reader what information the team needs and where to send the enquiry.
Be wary of absolute claims. “All our buildings meet every accessibility need” is too broad to verify or use. For a particular building, identify confirmed facilities—step-free entrances, lifts and accessible toilets—and any known limitations. Readers can then ask about a specific requirement if they need to.
Make answers easy to find and use
Give the page a clear title and descriptive section headings. Keep questions as scannable text rather than placing essential information in a decorative graphic. If answers use expandable panels, the question should remain readable when the panel is closed; the control should work with a keyboard and indicate whether it is open. Do not make important access or safety information depend on someone finding a collapsed section.
Use short paragraphs, lists and specific labels for procedural answers. To help someone prepare for an initial design meeting, list the site address, available ownership or lease information, intended use, approximate area, budget range and desired dates. An incomplete set need not prevent an initial conversation; it shows what still needs to be established.
Put the FAQ where its audience will look. Building-user questions belong near practical visitor information; prospective client questions belong near the relevant service description. Avoid placing the same generic FAQ across pages when its answers apply only to one building type or project phase. Readers should not have to guess whether advice about a school, clinic or office applies to them.
Assign ownership before the page goes live
An answer can become wrong without looking old. The planning route may change, a construction phase may end, an entrance may move or a named contact may leave. Record an owner for each answer, the source used to check it and a trigger for review. Fixed review dates help, but project events matter too: check public access information before a phase change and approval guidance when the applicable process changes.
Use follow-up enquiries as evidence, not just page-view counts. Repeated questions about what a fee includes suggest that its scope boundary is unclear. If visitors keep asking where to enter, the site may need clearer wayfinding as well as a better online answer. Editing the FAQ alone will not always fix the problem.
Before publication, ask a colleague who has not worked on the draft to complete three tasks: find out what to bring to a first meeting, check whether an approval timeline is guaranteed, and locate the contact for a building-access problem. Note where they hesitate. If they must read five other answers to understand the approval timetable, rewrite its first sentence and put the deciding condition directly below it.