Architect portfolio structure, projects versus process

Lead with projects. A prospective client comes to an architecture website to answer one question first: has this studio built something like what I need? Finished projects answer that. Process belongs inside each project page, as the story of how that building came to be, rather than as a separate section that has to earn a second click.

Why do architects end up choosing between projects and process?

Because both describe what a studio does, and most sites give each one its own menu item. The Projects page turns into a grid of photographs. The Approach page turns into a block of text about listening, collaboration and context. Neither works on its own.

The grid shows outcomes without reasoning, so any studio with a good photographer looks much like the next. The approach page shows reasoning without evidence, so it reads like every other approach page. A prospective client needs the two joined up: this is the building, and this is how the studio got there.

So the real question is not which one to show. It is where each one goes, and which one a visitor sees first.

What does a prospective client look for first?

Relevance. Someone commissioning a house extension, a school or a mixed-use block wants to know whether the studio has done that kind of work, at that scale, somewhere similar.

That makes finished projects the way in. Photographs of built work prove things that diagrams and sketches cannot, especially for private clients hiring an architect for the first time. They may not read plans. They can read a photograph of a kitchen full of light.

Commercial and institutional clients look for the same thing through different filters: sector, budget band, procurement route, delivery record. They also start with projects, then go looking for the people who led them.

So the homepage and the main navigation should put projects first. I cover homepage order in more detail in what makes an architecture website win awards. The principle is the same there: evidence before explanation.

Where does process belong, if not on its own page?

Inside each project. Process persuades best when it is tied to a specific building, because then it stops being a claim and becomes a record of what happened.

A line such as 'we respond to site and context' says nothing. A project page that shows the constraint (a narrow plot, a conservation area, a tight budget), the options tested and the decision taken makes the same point with proof.

The project page structure I use

This is the order I build architecture project pages in. It is short on purpose.

1. Hero image and a one-line summary. The strongest photograph, then type, location, size and year on a single line.
2. The brief in two or three sentences. What the client needed and what made it difficult.
3. The key decision. The one idea that shaped the building, shown as a sketch, model photo or diagram next to the finished result.
4. The built work. A gallery in a set order that moves from the approach to the interior to the details, with a caption on each image.
5. Facts and credits. Status, stage reached, team, collaborators, photographer, awards.
6. A relevant next step. An enquiry prompt that fits the project type, plus links to two similar projects.

Process lives in sections 2 and 3. For most visitors, that is enough to see how the studio thinks without clicking anywhere else.

What to leave out of a project page

Long essays on design philosophy, full drawing sets and every render made during the job. A project page is a sales document for the next client, not an archive. If the studio wants an archive, it can link to one from the bottom of the portfolio, where it will not water down the main selection.

Image weight matters here too. A page carrying 40 full-resolution photographs will load slowly on a phone over mobile data, and that is where many first visits happen. Core Web Vitals for image-heavy portfolio sites covers how much image weight a page can carry.

How many projects should the portfolio show?

As a rule of thumb, not a measured figure: eight to twelve featured projects is enough for a small or mid-sized studio. Fewer than six can make a practice look new. More than fifteen in the main grid starts to bury the best work among the merely good.

Pick them based on the work the studio wants next, not the work it has done most. If the practice wants more cultural commissions and fewer loft conversions, the grid should show that. A portfolio looks forward.

Unbuilt work is fine if it is labelled honestly. Competition entries and projects under construction can sit in the grid with a clear status. Renders passed off as photographs lose a client's trust the moment they notice.

Should projects be filtered by type, stage or location?

Filter by type, and only when there are enough projects to need it. Sector filters such as residential, cultural, workplace and education match how clients think about their own commission.

Stage and status filters help larger practices with many projects in design or under construction. For a studio with ten projects, filters add clicks and make nothing clearer. One well-ordered grid is better.

Location filters rarely help, unless the studio works in several countries and the client's question really is whether it works in theirs.

When does a standalone process page make sense?

When it answers a practical question rather than a philosophical one. Private clients hiring an architect for the first time often do not know what happens after the first meeting, how long each part takes or what they pay for at each stage.

A page that explains the stages in plain terms is genuinely useful. In the UK, many practices already describe their work using the RIBA Plan of Work, which divides a project into eight stages numbered 0 to 7. Mapping the studio's own services onto a framework clients recognise gives both sides the same terms, and makes clear when fees fall due.

The page should be named for what it does, for example How we work with private clients, and it should link to projects at each stage as evidence. It should not be an Approach page full of abstract nouns. Those pages are where portfolios lose visitors.

Which structure turns a portfolio visit into an enquiry?

The one that cuts out steps between seeing a relevant building and asking about it. In practice, that comes down to three things.

An enquiry prompt on every project page

Most architecture sites put the contact link in the footer and on a separate Contact page. But a visitor is most interested at the end of a project that looks like their own brief. A short prompt at that point, written for that project type, catches them while the interest is there. On a house project it might read 'Planning a house on a difficult site? Tell us about it.'

Related projects that keep visitors on relevant work

Two or three links to similar projects at the bottom of each page keep a residential client looking at residential work. A generic next-project arrow can send them to a hospital they have no interest in.

An enquiry form that asks about the project, not just the person

Project type, location, rough stage and a budget range tell the studio whether a lead is a good fit. A form that asks only for a name and email tends to bring in vague messages that need a round of questions before anyone can reply properly. Five or six fields is usually enough. What that form and the project template cost to build is part of the scope I break down in what an architecture firm should pay for a website in 2026.

How should project pages be built for search?

Every project should have its own URL, title and description, because clients search for specific things, such as an architect for a barn conversion in a particular county or a practice that has designed a primary school. A portfolio that puts every project on one scrolling page or in a lightbox gives search engines one page to rank instead of twelve.

Give image files descriptive names and write alt text that says what each photograph shows. Google's image SEO guidance states that both help it understand images. Captions do two jobs at once: they help a client follow the gallery, and they help a crawler understand the page.

The wider case for building a studio site this way is on the web design for architects page.

How can a studio check whether its current structure works?

Open the site on a phone and try to answer three questions within a minute. What kind of buildings does this studio design? Which one is most like my project? How do I ask about it?

If getting those answers means opening the menu, making two clicks and scrolling to the footer, the structure is working against the work. If the process page is second in the navigation and projects are fourth, the order is the wrong way round.

I apply a similar test when I assess a site's content and structure, as set out in how we score a website. It always comes back to one thing: does the site help the right client find the right evidence and then get in touch?