An architecture or interior design website needs to help a prospective client understand the work, the studio’s role and how to start a suitable conversation. Large photographs matter, but so do clear project descriptions, a usable phone layout and an enquiry process the team can maintain.
This guide is written by No Brainer Creative, an Auckland web design and digital agency. Use it to prepare a website brief and compare proposals for a NZ design practice. The right build depends on the content, workflow and constraints of the studio.
Start with the clients and projects you want to discuss
Describe the type of work the practice takes on, the areas it serves and the questions a prospective client needs answered. A residential renovation client may need different information from a commercial property team or a homeowner seeking interior design support.
Decide what a useful enquiry contains. Project type, approximate location, current stage and the help being sought can give the studio context before a conversation. A website cannot establish whether a project is suitable on its own; agree who reviews enquiries and how they are followed up.
Give each selected project a useful story
A gallery should explain what the visitor is looking at. Identify the project type and status, the design problem and the practice’s actual role. Distinguish a concept, visualisation or work in progress from a completed building. Credit collaborators and photography where appropriate and agreed.
Choose the level of location detail that is suitable for publication. A region or general setting may be enough; do not assume that a client wants a private home address, floor plan or personal details displayed. Confirm which images, drawings and descriptions are approved for the website before preparing the pages.
| Content field | What to prepare | What to check |
|---|---|---|
| Project identity | A meaningful title, project type and suitable location description | Visitors can distinguish it from other work without exposing private details |
| Status and role | Concept, in progress or completed; the studio’s contribution | Images and wording do not imply a different stage or scope |
| Design brief | The challenge, important constraints and decisions | Claims are supported and approved for publication |
| Image set | Selected photographs, drawings or renders, with captions and credits | Use is approved and the phone crop preserves the important detail |
| Related information | The relevant service, team member or project category | Links help a visitor continue exploring the practice |
| Next step | A project-enquiry route appropriate to the studio | It works on phone and reaches the person responsible for responding |
This is a planning example, not a record of a particular client project. Agree a repeatable set of fields so future projects can be added without rebuilding the layout each time.
Make imagery work on phone and desktop
Ask how image variants, crops and gallery layouts will be handled. A panoramic exterior, a portrait interior and a detailed plan need different treatment. Review real supplied images in the proposed layout rather than approving a gallery with convenient placeholder pictures.
Google’s responsive image guidance explains how image alternatives and display-size information help browsers choose suitable files. The build should balance useful detail with efficient delivery, rather than sending the largest original to every visitor.
Measure representative pages with their real content. Include a project gallery, the homepage and the enquiry route. Record the device, test conditions and any field data available, then prioritise demonstrated problems. A fixed file-size rule or a claim that every visitor leaves at three seconds is not a diagnosis of your website.
Keep the portfolio understandable and accessible
Use headings and written project information alongside images. A drawing containing important labels may also need an accessible explanation; a photograph does not need a list of search keywords in its alternative text. The W3C image decision tree distinguishes informative, functional and decorative images by their purpose in the page.
Check navigation and galleries with a keyboard. Visitors should be able to identify focus, move through project links and close an enlarged image without getting trapped. On a phone, check text size, image crops, tap targets and whether essential project information is hidden inside an awkward interaction.
If animation is part of the visual direction, agree how it behaves for people who prefer reduced motion. The work should remain understandable while assets load and when a visitor does not watch a full animation or video.
Explain services and the working relationship
A portfolio shows work; service pages explain what the practice can be engaged to do. Use language a prospective client can understand, identify the actual scope and show where different services fit together. The studio should review professional descriptions and claims before they go live.
Introduce the people and their roles using approved information. If the site includes testimonials, awards or publication coverage, confirm the wording, source and permission to use them. A logo or project photograph alone does not prove a partnership, an award or a measured business result.
Give visitors a practical next step. Explain what information to bring to an initial conversation and which contact route to use. Do not promise immediate replies or a particular project outcome unless the business can support that promise.
Review the current platform before deciding to migrate
WordPress, a hosted website builder or a more tailored build can each support a portfolio when the implementation and editing workflow fit the brief. A project count does not automatically establish that a platform has been outgrown.
List the actual limitations: perhaps the team cannot add captions, categories are difficult to manage, image crops are inconsistent, or enquiry routing is unreliable. Ask a provider to demonstrate whether those issues can be repaired within the current site before comparing a rebuild.
If a migration is justified, inventory existing project and service URLs, useful content and enquiry routes. Agree which pages remain, where changed URLs lead, and how the launch will be checked. Keep a rollback route and assign responsibility for the domain, hosting, editing access and continuing maintenance.
Connect project discovery with useful search information
Write project titles and descriptions for people looking at the work. Link between relevant projects, services and team information so visitors can explore the practice. Accurate location and service information should reflect where the business actually works; a separate thin page for every suburb is not a substitute for useful evidence.
Google’s image SEO guidance recommends discoverable images, relevant surrounding information and useful descriptions. Ask how the finished site will make its photographs and project pages available to search engines. An attractive gallery or completed sitemap does not guarantee indexing or a particular Google position.
For ongoing search work, separate the website build from the investigation, content and measurement needed afterwards. No Brainer’s website design service explains build and handover scope; our SEO service describes the separate search-marketing work.
Agree a manageable enquiry and publishing workflow
Keep the initial enquiry form proportionate. Decide whether attachments are necessary at the first contact, who receives the information and how the team notices a delivery problem. A success message on screen is not proof that an email arrived or that someone followed up.
Before launch, agree a controlled test of the form and the recipient’s confirmation process. If a CRM or booking system is included, define the connected steps and exception handling. Identify who maintains the integration after launch rather than assuming that an automation will run indefinitely without review.
For project publishing, ask the provider to demonstrate adding a project, changing its category, editing a caption and replacing an image. Use that demonstration to agree the training, documentation and support the studio needs.
Bring a clear brief to a website discussion
- Who are the intended clients, and which services should they understand?
- Which approved projects best demonstrate the relevant work?
- What project descriptions, images, credits and permissions are ready?
- Which existing URLs and useful content need preserving?
- What does a suitable initial enquiry contain, and who handles it?
- Who will add projects and maintain the site after launch?
- Which performance, accessibility and enquiry journeys will be checked?
- What budget, approval steps, dependencies and support requirements should shape the quote?
These answers make proposals easier to compare. Ask for named deliverables, exclusions, responsibilities and review points rather than choosing a build from an unsupported “best platform” verdict. Talk to No Brainer if you would like help turning the brief into a practical website scope.
Questions architecture and interior design studios ask
Does a portfolio website need a custom build?
It depends on the required layout, editing workflow, integrations and current limitations. Ask for a demonstration using the studio’s real content before deciding whether repair, redesign or migration is appropriate.
How many projects should the website show?
Choose work that helps prospective clients understand the studio’s relevant experience. Explain each project clearly and organise a larger portfolio sensibly. There is no universal project count that determines the platform or design.
How long will a new studio website take?
Agree a schedule from the actual content, design, development, approval and launch tasks. Photography permissions, project descriptions and stakeholder reviews can affect readiness; a generic timetable is not a scoped commitment.
Can a website rebuild guarantee more architecture enquiries?
No. The offer, audience, project fit, search visibility and response process all matter. Establish what can be measured, verify the enquiry journey and review evidence after launch without treating a design change as proof of growth.