Architecture first: why we design structure before aesthetics on every project

What architecture means in the context of a website

When we talk about architecture in web development, we mean the underlying structure that determines how a site is organised, how content is grouped, and how users move through it. It's distinct from - and prior to - the visual design of individual pages.

Architecture includes: the set of page types (what kinds of pages does this site need to exist?), the navigation structure (how do those pages relate to each other, and how do users get between them?), the content model (what information does each page type need to contain?), and the URL structure (how are pages addressed, and what does that address communicate?).

None of these questions are visual. They don't have anything to do with whether the hero image should be full-width or contained, or whether the colour palette should be warm or cool. They're structural questions, and they have consequences that last the entire lifetime of the site.

What happens when aesthetics come first

The most common alternative approach - starting with a visual design in Figma or similar - produces beautiful mockups quickly. This is one reason it's popular. A polished visual design feels like progress and gives clients something concrete to react to early in the process.

The problem is that visual mockups make implicit structural decisions that often don't survive contact with real content. A homepage design might assume a single headline and a two-sentence subheadline. When the client sends their actual copy, it's four paragraphs. The design breaks.

A services page design might assume five services in a three-column grid. The client has eleven services in four categories. The grid doesn't work. A new layout has to be designed, which may conflict with the visual language of the rest of the site.

These conflicts are not rare edge cases. They're the predictable result of designing visual layouts before understanding what content they need to accommodate. Every design revision that happens because real content doesn't fit the assumed structure is a cost that architecture-first avoids.

Information architecture: the first deliverable

At Linekern, the first deliverable on every project is an information architecture document. It lists every page the site needs, describes what each page contains, defines the navigation hierarchy, and specifies the URL structure.

This sounds like bureaucratic overhead. In practice, it takes two to four hours to produce and saves much more than that in revision cycles. It forces two things to happen simultaneously: the client has to articulate what their site actually needs to say, and we have to understand the business well enough to know whether the proposed structure will serve it.

Common discoveries at this stage: the client thinks they need a page for each service, but actually has three service lines that should each be a page, not fifteen individual services as separate pages. Or the site needs a resources section that wasn't in the original brief. Or the navigation structure the client proposed would bury the most commercially important pages two levels deep.

These are structural problems. Finding them in a document is cheap. Finding them in a finished design - or worse, after launch - is expensive.

Content zones and page types

Once the page list is defined, we design the content model: what information does each page type need, and in what form? A service page might need a headline, a short description, a list of features, a case study reference, and a CTA. An about page needs a narrative section, a team section with individual profiles, and a values statement. A contact page needs a form, location information, and a FAQ section.

These are the content zones - the named regions that every page of a given type will contain. They define what the Kernset CMS fields will be. They also constrain the visual design: the design has to work for whatever content a page of that type will contain, not just for the specific example used in the mockup.

This is the direct connection between information architecture and the CMS structure. If we define the content zones correctly at the architecture stage, the CMS fields that emerge from them will be coherent and usable. If we skip the architecture stage and design the CMS fields from the visual mockup, we often end up with fields that are either too restrictive or too flexible for what editors actually need to do.

Navigation hierarchy and user journeys

The navigation structure is a separate architectural decision from the page list. A site can have fifty pages organised into a clear three-level hierarchy, or it can have fifteen pages with navigation that forces users to make four clicks to reach any destination. The number of pages matters less than the structural logic connecting them.

We map user journeys explicitly at the architecture stage: how does a prospective customer move from landing page to conversion point? Where are the decision moments? Which pages do most users see, and which ones are accessed only by users who are already committed? This determines which pages should be in the primary navigation, which should be accessible through contextual links from other pages, and which should be findable only through search.

URL structure follows from this hierarchy. Clean, descriptive URLs - /services/website-design/ rather than /?p=234 - serve both navigation clarity and SEO. They should be designed deliberately, with the understanding that changing URLs after a site launches requires 301 redirects and carries SEO risk.

Why this leads to better outcomes

The architecture-first approach produces better outcomes for two converging reasons. The first is avoidance of downstream costs: structural problems found early are cheap to fix; structural problems found after visual design or development are expensive. The second is that understanding the structure of a site deeply before designing it produces visual designs that actually work with the content they'll contain.

A design for a service page that was conceived with the knowledge that it needs to accommodate between three and twelve features, in categories with user-defined names, looks different from a design that assumed a specific number of features with specific names. It's more robust. It accommodates the real range of content rather than just the example used in the mockup.

The architecture phase typically adds a week to the start of a project. It removes far more than a week of revision time from the middle and end. More importantly, it means the site that gets built is the right site for the business, rather than a site that looked right in the mockup and turned out to have structural problems once real content was added.