Architecture practice websites: how to present a project

On an architecture practice’s website, a project is told as a story, not shown as a set of beautiful photographs. The story has six parts: project data that identifies it, context that sets out the problem, an approach that explains the decisions, process images from sketch to site, notes on materials and detail, and the outcome. Photographs stop the visitor. The words answer the question “will this practice understand my problem?”

Below we go through each part — with an eye on keeping the page fast, and on letting you add new projects yourself.

Who is a project page written for?

Three kinds of visitor read an architecture practice’s site: a family hoping to build a home, a business planning to refit its office or shop, and someone from within the profession — an architect, an editor, a prospective colleague.

For the first two, photographs are not enough. A family cannot look at a finished house and see their own plot, their own timetable, their own daily life in it. But they may recognise themselves in a sentence such as “a house on a sloping plot that does not feel too big for two on a weekday, yet takes a crowded weekend in its stride”.

For readers from the profession, the reasoning behind the decisions matters. Why this material, this orientation, this plan? A project page can speak to both audiences at once, provided its structure is set up from the start.

The six parts of a project page

1. Project data: the project at a glance

The project data is the project’s identity card. The moment visitors arrive, they should know what they are looking at.

Field	Example
Location	Town or district, region
Year	Year of completion or design
Area	Floor area, m²
Category	Housing, office, restoration, interiors
Scope	Architectural design, interiors, site consultancy
Status	Completed, under construction, in design
Team	Project team and collaborating disciplines

Marking up the project data as a table keeps the information orderly for screen-reader users too. Crediting collaborators — the photographer, engineering consultants, the contractor — is part of professional ethics and of trust, provided you have their permission.

2. Context: what was the problem?

Every project has a starting point: a site, a building, its users and its constraints. The context section sets this out in two or three sentences.

A good context paragraph covers what kind of place it was, what the client wanted and what stood in the way. A steep slope, a prevailing wind, a listed building, a narrow shop unit, a team that had to keep working throughout. Naming the constraints plainly gives the decisions in the next section their meaning.

3. Approach: decisions and their reasons

The approach is the heart of the page. Short points, each holding one decision and one reason, work well: “We set the house into the slope and split it over two levels; from the street it reads as a single storey, whilst on the garden side it opens into two floors of living space.”

Three or four numbered decisions are easier to read than a long design statement. Visitors can match each decision to a constraint in the context. Architectural terms are fine, but explain each one plainly the first time it appears. A client who has never heard of a “restitution study” will follow “a study showing how the building changed, period by period”.

4. Process images: from sketch to site

Photographs of the finished building show the end of the project. Process images show how you think: first sketches, model photographs, sun-angle studies, measured survey drawings, shots from the site.

They are especially valuable to a client working with an architect for the first time. They show that the process is not a black box — that each step involves a conversation. A short caption under each image (“First sketch: testing eaves depth against sun angles”) turns the image into a document.

5. Notes on materials and detail

Materials are amongst the subjects clients ask about most. On a project page, gathering materials, light and detail into separate short notes works well:

• Materials: the main materials used, and why they were chosen
• Light: decisions about daylight and artificial lighting
• Detail: a junction, a window frame, a piece of built-in joinery

These notes are at their strongest beside close-up detail photographs. A single frame of two materials meeting at a corner says more than a long paragraph.

6. Outcome: what did the project change?

Keep the outcome short. What happened once the building was in use? Did the heating load fall, how does the team use its floor, did the old mansion become a guesthouse?

Restraint matters here. If a result has been measured, say so. If not, describe it as an observation, in measured language. Client comments should be used only with permission, and only if they are genuine.

Links to the previous and next projects at the end of the page keep visitors moving through the portfolio. Then a short invitation — “Thinking about a similar project?” — with a link to get in touch.

An example: Bağlık Evi

You can see these six parts working together on the Bağlık Evi project page, part of a Turkish-language example site we built for a fictional architecture studio. It opens with a large cover image and a one-sentence summary. The project data table sits in a side column, with the context paragraph and numbered design decisions in the main column. Materials, light and landscape appear as short notes, and the images, each with its caption, can be enlarged for a closer look. The page ends with links to the previous and next projects and an invitation to discuss a project.

For documentation-heavy work such as restoration, the same template works with a different emphasis. On the example site’s Taş Konak restoration page, the approach section walks through the measured survey, the restitution study and the conservation-board approval process in turn.

Large photographs, fast pages

Architecture sites are image-heavy, and rightly so. But if large photographs slow the page down, visitors may leave before they see them — particularly on a phone, over a slow connection.

These are the methods we use to keep image quality high and pages fast:

1. Sized for the screen. Each image is produced in several widths; a phone gets the small file, a wide screen the large one.
2. Modern formats. Photographs are served as WebP or AVIF, which give smaller files.
3. Deferred loading. Images further down the page load as the visitor approaches them. The cover image, seen first, loads with priority.
4. Fixed aspect ratios. Space for each image is reserved in advance, so text does not jump about as the page loads.
5. Meaningful alternative text. Every image carries a description of what it shows, for people using screen readers.

In mobile Lighthouse tests, our example sites score 96–100 for performance and 100 for accessibility, with layout shift (CLS) below 0.05. We share this to show that an image-led portfolio can load quickly too. For more on what slows sites down, see why is my website slow?

Adding projects yourself

An architecture practice’s portfolio keeps growing. Waiting for a developer every time a new project is ready is the most common reason portfolios fall out of date.

That is why we build every project page on a single template. To add a project, you fill in the data fields, the context, the approach points, the notes and the images. Depending on what suits you, this can be done through content files or a simple editing flow. Because the template stays fixed, every new project appears in the same order, and at the same standard, as the rest of the site.

The arrangement has two further benefits:

• Consistency. Visitors find the same information in the same place on every project, and can compare projects with one another.
• Search visibility. Each project lives at its own address, with its own title and description, so the relevant work can be found for searches such as “restoration”, “office interiors” or “house on a sloping site”.

A project list that can be filtered by category, and a short archive list that includes smaller or unbuilt work, show the breadth of the portfolio on a single page. Not every job needs a detailed page of its own.

For our general approach, see our web design and development service.

What to avoid

• Photographs alone. A gallery without words looks lovely but answers no questions — and is not found in search.
• Heavy images. Uncompressed, single-size files lock up the page on a phone.
• Content without permission. A client’s name, address or interior photographs should not be published without their consent.
• Inflated language. Instead of words such as “award-winning”, “unique” or “the best”, let the decisions speak.
• A stale portfolio. A site whose latest project was added years ago raises the question of whether the practice is still working.

Frequently asked questions

How much text should an architecture project page have?

Enough to answer three questions: what the problem was, what you decided, and why. A context paragraph of two or three sentences, three or four numbered decisions and a few short notes on materials are usually plenty. More text does not help if it buries the reasoning.

Should we include unbuilt or competition projects?

They can show how you think, and that is valuable. Mark their status clearly — “in design” or “competition entry” — so they are not read as completed buildings. Smaller or unbuilt work can also sit in a short archive list rather than having full pages.

Can we add new projects without a developer?

Yes, if the site is built that way. With a fixed project template, adding a project means filling in fields and uploading images, through content files or a simple editing flow.

If you are thinking about a site that presents your projects this way, have a look at our web design and development service or write to us with a little about your practice. We reply within two working days.