Renderings may be ready while the article still needs work. A caption that calls a proposed clinic “completed,” or copy that names a client before disclosure is approved, can create a factual or contractual problem. Give each draft an editorial owner, keep a record of the checks, and make publication a deliberate decision.
Start with a publishable brief
Before writing, set down who the article is for, the question it will answer, the project or technical evidence available, and the target publication date. Treat the date as a planning tool, not permission to skip checks. An article about a new school, for instance, could explain how the circulation plan separates deliveries from pupil arrival. That gives readers something more useful than a broad claim that the design “improves learning.”
State what kind of article it is: general guidance, an account of a proposed design, a completed-project case study or an update on a building in use. That choice affects verb tense, captions and which claims can be supported. If project approval is pending, say so in the working file; do not expect an editor to work it out from the drawings.
Name one editorial owner to coordinate the draft, then assign reviewers according to what they know. A designer can verify intent and drawings; a project manager can check programme, scope and cost references; a client representative can approve names and disclosures. The owner resolves conflicting comments and keeps the final version. Without someone responsible for that decision, drafts can sit in several inboxes despite a shared deadline.
Build a source record as the draft develops
Facts in an architecture article may come from documents updated on different schedules: site area from a survey, floor area from a drawing schedule, opening date from the client’s programme. Keep a claim log beside the draft for figures, regulatory statements, project status and attributed quotations. For each claim, record the source, document date, responsible reviewer and publication approval status.
Keep design targets separate from measured results. “Designed to reduce summer overheating” states an intention; “reduced indoor temperatures” calls for evidence from the occupied building. A planning submission is not an approval, and an estimated budget is not the final construction cost. When performance data or permission status cannot be verified, narrow the wording or leave the claim out.
Regulatory guidance needs a location and a project stage. Accessibility, fire safety and permit requirements vary with jurisdiction and building use, so one project’s approval route should not be presented as a rule for every project. Ask a technical reviewer to check the statement and the qualification that makes it accurate.
Use review stages with distinct purposes
Sending an unfinished draft to everyone at once often brings back conflicting edits. Give each reviewer a defined task:
- Editorial review: Check that the article answers the brief, explains terms for non-specialists and distinguishes facts from design rationale. Remove repetition and unsupported superlatives.
- Technical review: Check dimensions, building type, drawing references, project phase, construction methods, and performance or compliance claims against current records.
- Permissions review: Confirm that client and consultant names, quotations, photography, plans and visualisations may be published with the proposed credits and captions.
- Production review: After approved edits are entered, check the page layout, images, headings, links, mobile display and publication settings.
In a small team, one person may handle several stages, but the checks should still be distinct. Keep comments in one tracked document and set a cut-off for substantive changes. If a late edit changes a figure, caption or statement subject to approval, return that passage to the relevant reviewer. The earlier sign-off no longer covers it.
Define what sign-off covers
Record approval against a specific draft and its accompanying images: who signed off, when, and under what conditions—for example, “publish after public announcement.” Approval of the copy does not cover a replacement photograph or a new headline that makes a stronger claim. For confidential projects, also check whether maps, filenames or image metadata reveal identifying details.
Prepare the page, not just the prose
Once the words are approved, build the article in the publishing system and inspect the page itself. Write descriptive alternative text for images based on what they show, label proposed views as visualisations, and put captions where readers will see them. Check that plans remain legible at the displayed size. If the labels cannot be read, a cropped detail or a plain-language explanation may serve readers better.
Use a clear title and descriptive subheadings. A contextual link to an existing explanation on the blog can help readers without breaking the argument. For teams scheduling several pieces, planning an editorial calendar for an architecture practice covers topic choice and publication timing. The check at this stage is simpler: make sure the link opens the intended page and its anchor describes that destination accurately.
Preview on a phone as well as a larger screen. Look for clipped tables, oversized files, broken captions and headings stranded from the paragraphs they introduce. Compare the page title and short search description with the approved copy; neither should promise an outcome the article cannot support. Before scheduling, confirm the author, category and publication date.
Publish with a record and a correction route
End the release checklist with a clear decision: publish, hold or return for revision. Store the approved draft, image permissions, claim log and final page address together so a later editor can trace a disputed detail. For time-sensitive articles, flag facts to revisit, such as permit status, expected completion date or whether a proposed facility has opened.
After release, inspect the live page rather than relying on the preview. Make sure images load, captions match the displayed files and the scheduled date is correct. If something is wrong, assign one person to fix it and record the change; make a material correction visible to readers where appropriate. A useful note in the publishing record might be: “Opening date checked against client update on 12 June; revisit after handover.”