Designing Public Records, Agendas and Minutes Pages That Actually Get Used

Every public body publishes agendas, minutes, notices and budgets, and almost every one of them does it the same way: a page listing PDFs in reverse chronological order, growing forever. It satisfies the letter of the posting obligation and fails nearly everyone who tries to use it — the resident looking for the decision about their street, the reporter checking what was approved, the staff member trying to find last year's budget line.

This is a design problem with a well-understood solution, and getting it right also resolves two obligations at once, because the same structure that makes records findable is the structure that makes them accessible.

Start from the question, not the document

Nobody wants a meeting packet. They want to know what was decided about a specific thing. The list-of-PDFs pattern forces every user to translate their actual question — "did the council approve the rezoning on Oak Street?" — into a guess about which meeting date might contain the answer, then download a 200-page file and search it.

The design fix is to make the meeting a page rather than a link. A page per meeting, with the date, body, status, agenda items as text, and the documents attached to it. Suddenly the meeting is searchable, linkable, and quotable — by your own site search, by Google, and by the AI assistants residents increasingly ask first.

Make agenda items first-class content

The single highest-value change is publishing agenda items as structured text on the meeting page rather than only inside the packet PDF. For a California special district, this is also the cheapest way to satisfy the SB 929 posting duty and the accessibility standard with one piece of work. Each item gets a title, a description, and where applicable an outcome.

This does more work than it appears to. It makes items individually linkable, so a resident can share the exact item rather than "page 47 of the packet." It makes them searchable, which is how most people actually arrive. And it means an item can be tracked across meetings — introduced in March, deferred in April, approved in May — which is the question people most often have and current systems most often cannot answer.

Give records real metadata

Date, meeting body, document type, and status are the four fields that let people filter. Most records pages have none of them, which is why the only navigation available is scrolling.

With those four, you can offer filtering by year and by body, a search that returns meetings rather than files, and a stable URL pattern that survives redesigns. That last point matters more than it sounds: records URLs get cited in legal documents, news articles and grant applications, and breaking them is both a records problem and a credibility problem. Our migration checklist covers preserving them.

Deal with the PDFs honestly

The formal record is often legitimately a PDF — a signed document, a certified minute, an attachment from a third party. The mistake is treating the PDF as the only publication.

The workable pattern is both: the content residents need published as an accessible web page, with the PDF attached as the formal copy. That satisfies the records obligation while making the substance readable to someone using a screen reader, someone on a phone, and any search engine or assistant trying to answer a question from it.

Where a PDF must stand alone, it needs to be a real document rather than a scan, with text, tags, headings and a document title. A scanned image of a minute is unreadable to assistive technology, and under the Title II rule that is a compliance problem as well as a usability one.

Publish the schedule, not just the history

Records pages are almost always retrospective. Residents also want to know what is coming: when the next meeting is, what is on the agenda, how to submit a comment, and by when.

An upcoming-meetings view with the agenda posted as soon as it is available — and the comment deadline stated in plain language — turns a records archive into a participation tool. It is also the content most likely to be quoted correctly by an assistant if you mark it up properly, which is covered in GEO for government websites.

Handle video like a record

If meetings are streamed or recorded, the recording is part of the record for most practical purposes. Two things make it usable: captions, which are an accessibility requirement rather than a nice-to-have, and time-stamped links to agenda items, so someone can jump to the discussion they care about instead of scrubbing through three hours.

Where a transcript exists, publishing it as text makes the entire meeting searchable — frequently the single most useful thing you can do with a recording.

What to specify if you are procuring this

If a redesign or an agenda-management procurement is coming, put these in the requirements rather than hoping: a page per meeting with agenda items as structured text; filtering by date, body, type and status; stable, permanent URLs for meetings and documents; accessible web publication of substantive content with PDFs attached as formal copies; captions on recordings; and an upcoming-meetings view with comment deadlines.

Ask specifically how any third-party agenda system will meet the accessibility standard, because that system is content your entity provides even when someone else operates it — and it is one of the most common places conformance quietly fails.

We build this as part of municipal and government website projects. If you are writing the specification now, the public sector requirements checklist covers the surrounding obligations.