Projects can go wrong in the gap between disciplines. A designer draws a beautiful service page template with a hero image, three feature cards and a testimonial strip. The content team then discovers their services need eligibility rules, fees and a list of documents, none of which fit the cards. The developer builds fields for the design, not the content, and writers paste everything into one large text box. Over time, service pages can drift apart in layout. Content structures for UX close that gap before it opens.

What the service covers

Content types. The distinct kinds of page or item your site needs: service, guide, location, event, person, news item, form. We aim for as few types as the content allows, because each extra type adds design, build and training work.

Content models. For each type, the fields it holds, which are required, and rules such as "summary under 160 characters" or "at least one contact method". Models also record which taxonomy terms each type uses.

Template outlines. For each type, a structural outline of the page: the order of content blocks, which are fixed and which are optional, and where navigation elements such as breadcrumbs and local menus sit. The outline is a brief for the designer, not a finished design.

Sitemap alignment. Every page in the sitemap is assigned a content type, so the sitemap shows not only where pages sit but what they are made of.

Consistent wayfinding. WCAG 2.2 asks that repeated navigation keeps "the same relative order" across pages (3.2.3) and that help mechanisms such as contact details also stay in a consistent place (3.2.6). Defining these positions in the template outlines makes consistency the default rather than something to check after launch.

Why structure belongs inside templates

A page's structure is part of how people find their way through it. The Australian Government Style Manual recommends hierarchies with no more than four heading levels and stresses descriptive section headings. When templates fix the heading order for each content type, every page of that type is scannable in the same way. Readers who have used one service page know where to look on the next.

How the work runs

Review content. We sample existing pages, or draft examples if the site is new, to see what each type must hold.
Draft types and models. A first set of content types with fields and rules.
Outline templates. Structural outlines for each type, reviewed with your designer.
Write test pages. We fill each model with real content to prove it works. Gaps show up quickly when a writer tries to fit a real service into the fields.
Align the sitemap. Assign a type to every page and adjust where a page does not fit any type.
Hand over. Models, outlines and notes for developers and writers.

What you receive

A content type list with a purpose statement for each type.
Content model specifications in a spreadsheet, one tab per type.
Template outlines showing block order, required and optional blocks, and navigation placement.
An updated sitemap with a content type for every page.
A writer's guide for each type: what goes in each field and how long it should be.

How this helps accessibility

Templates built from content models give every page of a type the same heading order, the same landmark structure and the same position for help and contact details. That consistency is what WCAG 2.2 success criteria 3.2.3 and 3.2.6 ask for. It also means accessibility checks done on one page of a type apply to every other page of that type, which makes testing a large site practical. Writers benefit too: when the template asks for a summary, a list of eligibility rules and a contact block, the result reads clearly without each writer inventing a structure.

Who this suits

Teams about to start design on a new site or a rebuild, especially where several writers will publish into the same templates. It also suits teams whose current pages have drifted, with each one formatted differently, and who want to bring them back into line during a migration.

Getting your inputs together

The information architecture worksheet asks for your audiences, tasks and content types and turns them into a brief. Bring that to a first conversation and we can talk specifics straight away.

Questions about this topic

What is a content model?

A content model describes a type of page or item: the fields it has, which are required, how long they may be and how the type connects to other types and to the taxonomy. A service page model, for example, might require a summary, eligibility, cost and a contact block.

Do you create wireframes?

We produce structural outlines of each template showing the order and purpose of each content block. Detailed wireframes and visual design are done by your designer, working from that outline.

Which content systems do you support?

The models are written in plain language and spreadsheets, so they work with any system. Your developer translates them into fields in WordPress, Drupal, a headless system or whatever you use.

Content structures for UX