Write a Useful Brief Before Building a Personal Website

Photo: Domenico Loia / Unsplash. Stock photograph for illustration.

In this guide

1. Name the visitor and the reason for arriving
2. Choose a small first version
3. Inventory the content before choosing a layout
4. Describe navigation in ordinary language
5. Specify the few interactions you need
6. Set visual direction with specific references
7. Make ownership and maintenance explicit
8. Define a review that proves the site works

A personal website becomes easier to build when you can explain what it should help a visitor do. Without that explanation, it is tempting to choose colors, collect impressive examples, and add pages until the project feels too large to finish. A short website brief turns those possibilities into a manageable set of decisions. It describes the audience, the content, the necessary features, and the work involved in keeping the site useful.

You can write a brief whether you plan to use a website builder, work with a designer, or create the site yourself. It does not need formal language or a technical specification for every component. It should be clear enough that another person could read it and understand what a successful first version would contain.

Name the visitor and the reason for arriving

Start with a particular visitor rather than everyone who might use the internet. A potential client reviewing your work needs different information from friends looking for details about a community project. Describe what the visitor probably knows already, what they need to learn, and how they might reach the site. This helps you choose both the language and the order of information.

Then write the main task in one sentence. For a portfolio, it might be to understand your work and send a relevant inquiry. For a personal archive, it might be to find a project by subject and read its background. Keep secondary audiences in the brief, but identify the primary one so later decisions do not have to satisfy every possible visitor equally.

Choose a small first version

List the pages you actually have material to fill. A clear home page, a few substantial examples, an about page, and a contact route may be enough for an initial portfolio. Do not add a blog merely because other sites have one. A section that requires regular writing should have an owner, a purpose, and a realistic plan before it becomes part of the build.

Separate essential items from future possibilities. A searchable archive may matter once you have many projects, while a simple list can serve a small collection. This distinction is not an argument against ambition. It prevents useful work from waiting on features whose value has not yet been established. Write down what would justify adding them later, such as a larger content collection or repeated visitor requests.

Inventory the content before choosing a layout

Gather the text, photographs, project descriptions, and documents you already own or have permission to publish. Note what is finished, what needs editing, and what is missing. A beautiful sample layout may rely on large photographs you do not have. Discovering that during the brief stage saves you from designing around placeholders that never become real content.

For each project, identify the question its page should answer. Explain your role, the context, the work, and the outcome without claiming results you cannot support. Remove confidential information and confirm permission for collaborative work. If a photograph is illustrative rather than evidence of the project, make that distinction clear. A trustworthy portfolio is more useful than one that looks impressive through ambiguity.

Describe navigation in ordinary language

Sketch the route a visitor should take. They might arrive on a project page, read the example, learn about your role, and then contact you. Check that each stage has an obvious next step and that the visitor can return to the main collection. Use labels that describe the destination instead of clever names that require explanation.

Include the mobile experience in the brief from the beginning. State which information must remain easy to find on a small screen: project titles, contact details, readable text, or navigation. You do not need to draw every breakpoint. You do need to avoid assuming that a wide desktop composition is the only experience that matters. A simple paper sketch can reveal a confusing structure before any code exists.

Specify the few interactions you need

Write down what each interactive feature should do. A contact form needs fields, a delivery destination, useful error messages, and an honest confirmation. A download link needs the correct file and a label explaining what opens. A gallery needs readable captions and a way to move through images without trapping the visitor. Naming the behavior is more valuable than asking vaguely for a modern site.

Consider whether a simpler alternative serves the same purpose. An email link may be enough for occasional inquiries, while a maintained form may suit a more structured process. If you collect personal information, identify why you need it and how you will manage it. Do not add fields merely because they appear in someone else's template. Every field creates work for the visitor and responsibility for the site owner.

Set visual direction with specific references

Choose a few references and explain what you like about each. Perhaps one has comfortable reading width, another has restrained colors, and another makes project categories easy to scan. Distinguish those qualities from the reference's entire identity. Asking for a site that feels calm and readable is more actionable when accompanied by examples of spacing, typography, and image treatment.

Record existing brand assets and their permitted uses. If you do not have a logo, state whether a simple name treatment is sufficient for the first version. Avoid letting an undecided brand project delay basic content. Also identify visual requirements such as clear contrast, legible text, and usable focus states. These should be part of the design brief rather than decorations added after the layout is complete.

Make ownership and maintenance explicit

Decide who controls the domain, hosting account, source files, and publishing access. Write down who updates content and who handles problems. If another person builds the site, ask for a handover that covers ordinary tasks such as changing a project image or correcting contact information. You should not need to reconstruct the entire setup to make a small edit.

Include recurring costs and maintenance responsibilities in the planning conversation. Verify current prices and terms directly with the providers before committing. A feature that depends on an external service may introduce future work even when it is easy to install. The brief should make those dependencies visible, particularly if you expect to maintain the site alone or only revisit it a few times a year.

Define a review that proves the site works

End the brief with a short acceptance check. Can a first-time visitor understand the purpose? Can they find the main examples and contact route? Do links, forms, and downloads work? Is text readable on a phone? Are permissions and credits correct? These are observable questions, unlike whether the site feels sufficiently impressive.

Ask one or two people from the intended audience to try a realistic task without coaching. Use their difficulties to revise the site, not to add every feature they mention. Keep the brief with the project and update it when the purpose changes. A good brief remains a practical decision tool: it tells you what belongs in the site, what can wait, and what evidence will show that the first version is ready.