Architecture portfolio website: how to write a useful brief

By Alexandros Dikastopoulos · Brand Designer & Consultant, Hello Design

Thinking about a new website for your architecture practice? Start with the work you want to show and the people you’d like to reach. A useful brief helps you explain what feels true to your practice and what visitors should understand through each project.

The website is also a content system that your team will maintain. Project photographs, descriptions, credits, languages and future updates need as much attention as the homepage. Agreeing them early makes the design scope easier to assess.

Start with the practice and its audiences

Describe the practice’s focus and the types of commissions it wants to discuss. Identify the main visitors: prospective clients, collaborators, journalists or people considering joining the team. Each audience may need a different route through the same work.

Then decide the primary action. Visitors might need to understand your approach, explore relevant projects or contact the practice about a commission. Let those needs guide the navigation and the order of information.

Choose projects and define a repeatable project record

Select a representative group of projects before building page templates. Include the range of disciplines, scales and project types that matter to your positioning. A long archive and a tightly selected portfolio need different structures.

For every chosen project, prepare the same basic information so the design can accommodate real content. Define which details are public and who approves them. This also helps the team add future work consistently.

• Project name, location, year and relevant status.
• The practice’s role, scope and collaborating disciplines.
• A concise description of the design question and approach.
• Approved photographs, drawings and visualisations with captions and credits.

Organise images and credits before layout

Group images by project and identify the preferred sequence. Keep original files and agree useful crops for wide and narrow screens. Distinguish photographs of completed work from renders, proposals and other visualisations in the captions.

Record the photographer and collaborator credits alongside the files. The project team should confirm that the selected material can be published. For informative images, write descriptions that explain the relevant content; the W3C image tutorial is a useful accessibility reference.

Decide what Greek and English each need

List the pages and projects that will exist in both languages. Agree who supplies and approves each version. A translation may need editing to suit its audience, especially for the practice’s approach, project descriptions and professional terminology.

Plan language switching between matching pages. Check names, project details and credits for consistency. If one version is still incomplete, identify it in the content plan before launch rather than leaving the migration team to guess.

Define templates, responsibilities and the handover

A practical scope identifies the page types: homepage, project listing, project detail, practice information, people and contact. Add filters, news, downloads or recruitment content only when they serve a defined need. Specify who enters existing projects and prepares future updates.

Agree website development, content migration, licences, training, hosting arrangements and ongoing support as explicit responsibilities. Confirm how the team will add a project, replace a photograph and update credits after delivery.

Labarch and ASPA Design are relevant portfolio examples. Our Architecture Branding service explains how identity, project presentations and the website can form a shared system.

Review a real project on mobile before launch

Use a complete project entry to assess the templates. Check whether the introduction is readable, the image order makes sense, captions remain clear and contact details are easy to find. Test menus, filters and language links using both keyboard and touch.

The launch checklist should cover approved content and credits, image delivery, form handling, page titles, redirects from an older site and access for the person maintaining the website. Define who signs off each area and which support follows launch.

• Representative project selection and a complete sample project.
• Approved images, descriptions and credit information.
• Greek and English page list with named content owners.
• Required templates, filters and download formats.
• Target milestones, an optional budget range and maintenance responsibilities.

Use the worksheet below to collect the essentials with your team. Then tell us about your practice, current website and the projects you want to present.

A few thoughts for our first conversation.

A short brief to help you talk with your team about what you want to achieve, who you want to reach and what you need. Note what you know. You don’t need to have everything worked out, and the budget range is optional.

Download the project brief (PDF, 1 page, 73 KB) ↓

Our proposal will explain the work, fees and schedule in detail.