The brief

Whoever builds a site makes hundreds of small decisions: what goes at the top of the page, how big the photos are, what a phone shows first. A brief is the short document that lets them make those decisions the way you would, without asking you each time. The same brief works for a designer, an agency or an AI agent.

It starts with the people the site is for and what they come to do. Take your own portfolio. Its main visitor is a recruiter or an engineering manager with forty applications for one internship. They give each portfolio about thirty seconds before deciding whether to call. This tells a designer more than "a modern, clean site in React".

Next comes what those visitors must be able to do, in order. First, they understand in one line what you do and what you're looking for. Then they see two or three projects, with your role and the result. Last, they find your CV or your email. Anything else is optional. Name a technology in the brief only when there's a reason for it, such as a company whose other sites all run on WordPress.

Designers and AI design tools fill an empty layout with placeholder text and stock photos (generic photos from a photo library). The placeholder text is often fake Latin, called "lorem ipsum". Everything fits, because the placeholders were chosen to fit. Then the real content arrives. A project title is 80 characters long and takes three lines on a phone. Your best project has no picture, or only a blurry photo of a circuit board. The "About" text is three times longer than its box. The layout has to be redone, and the first one was wasted work.

So the brief says what content exists and who provides it: who writes each text, which photos and videos exist, and how long each text really is. For your portfolio, write the real text of each project before anyone makes a mockup (a first picture of the design). Each project needs a title, the context, your role, what you did and the result. Add a number when you have one, such as "inference time cut by 40%". Gather the photos and screenshots you actually have, and list the projects that have none. A designer can plan a good layout for a project without a picture, if they know about it in advance.

The limits are the things a builder can't decide for you. Each one changes what gets built.

Give the budget and the deadline as numbers. If you only write "not too expensive", you will receive price quotes that you can't compare. Say which devices come first. Most visitors arrive on a phone, and a recruiter may open your link on one between two meetings. Say which languages the site needs. An English version doubles the texts to write and check. For accessibility, many French organisations must follow the RGAA, the official French accessibility standard. Any site that follows it is easier to use. On the legal side, most French sites must show a legal notice, the "mentions légales". It says who publishes the site and who hosts it. A contact form also collects personal data, so the GDPR, the European law on personal data, applies.

People often forget one limit: who will update the site once it's online. If it's you, with an AI agent on a free account, the site must stay simple enough for you to do that. If it's someone else, adding a project means waiting for the person who built the site, or paying them.

Words that describe a look are vague. "Modern", "clean" and "impactful" mean something different to each person. An AI design tool turns them into the same generic page that it gives everyone. Showing real sites makes your meaning clear much faster.

Pick two or three sites and write down exactly what you take from each one: the typeface, the calm feeling, the size of the photos, or the way one project follows another. "Like Apple" doesn't help, because nobody knows which part of Apple's site you mean. "Large photos, one project per screen, very little text, like this architect's portfolio" is something a designer can build. A reference can come from another field. For example, a restaurant's menu page may have exactly the calm feeling you want for your list of projects.

Add what to avoid, with the reason, such as "no dark page with neon gradients, because it looks like a video game studio". This helps as much as the sites you like. Keep a folder of sites you notice while browsing, with one line on why each one works. Then your next brief will take only minutes to write.

Two short lists end the brief. The first says what this version won't do: no blog, no dark mode, no project filters in this first version. Once it's written down, this list stops the work from growing in every direction. It also gives you a ready answer when someone suggests one more feature.

The second list says how you'll know the work is finished. It's often called the "done when" list, and it uses criteria anyone can check. For example: "it works on a phone screen 375 pixels wide", "messages from the contact form reach my inbox", "Lighthouse gives accessibility a score above 90 out of 100", "the home page loads in under 3 seconds on a 4G mobile connection". Lighthouse is the free audit tool built into Chrome. Each line is a test you can run yourself on delivery day.

One person should make the decisions and answer the builder's questions quickly. When three people are in charge of a brief and disagree, the builder waits, or guesses. If you change the brief during the work, say so clearly, and first ask what the change costs. Moving a section takes a minute in a mockup, and much longer once the site is built.

Ask these questions when you give a brief to anyone: an agency, a freelancer, a colleague or an AI agent.

First, ask them to tell you the brief in their own words, and to list what's missing or unclear. Misunderstandings appear when they retell it. At that point, fixing them still costs nothing. Ask what they need from you, and by when: texts, photos, access to accounts, decisions. Content that arrives late is one of the most common reasons a site goes online late.

An AI agent gets the same brief, plus what it can't guess: who you are, the tone you want, and the files that already exist. Keep the brief in a file in the project. The agent reads this file again before it works, so it doesn't forget the brief during a long session. The lesson on working with an agent explains this in more detail. Before the agent builds anything, ask it the same first question: can it tell you the brief in its own words?

During the work, each time you change your mind, ask what the change costs before you say yes. On delivery day, check the "done when" list yourself, one line at a time.