Plan

This is a speculative redesign I made of the AllWeb conference site. AllWeb didn't commission it, and its ticket button is a demo. A bakery mostly serves regulars. A conference has at least five kinds of visitor, and each one arrives with different questions. So before you decide what the site asks anyone to do, write down who comes and what they need to know.

Start from your research notes, not a blank page. My strategy draft names five audiences: people who might buy a ticket, partners and sponsors, speakers, the media, and people searching past years for a talk. A list like that is still a draft. Check each audience against what research found. If nothing shows them arriving, they don't get a row yet.

Now take one audience at a time and write its questions in its own words. The attendee's list runs twelve lines. It opens with what is this, and is it for me. Price comes near the end, and how do I buy a ticket is last. That order is information. Nobody asks how to buy before they know what the thing is. Keep the order here, because the page structure will follow it later. Under each list, write the one step that audience should take. Attendees get tickets. Partners become a partner. The media send an inquiry.

Then put it in the brief, short enough to read in one look: who they are, their first questions, and their next step. One block per audience. Watch for a step that promises something the business hasn't offered. The draft says it outright: don't promise an open speaker application unless one exists. So the speaker's next step is contact, and the question goes to AllWeb as a confirm marker.

Last, choose who leads the homepage. Partners matter, and they pay. But this site's one job is selling tickets for the sixth of November, so attendees lead, and the brief says why in a line. Here's that decision on the built page. The first screen answers the attendee first: what it is, when, where, and the ticket button. Partners get their own section further down, with their own button.

Write down who comes, what each one asks, in the order they ask it, and the one step you want them to take next.

Ask a client what their website is for and you'll get a list. Book a class, buy a mug, join the newsletter, follow us. All reasonable. A page can only lead with one of them, though, and if you don't choose, the homepage chooses for you. Usually badly.

So the first decision is the primary action: the one thing a visitor does that makes the site worth having. Everything else can stay on the site. It just doesn't lead.

When it isn't obvious, I ask four things of each candidate. Does it earn or save the business money? Can the business actually deliver what happens after it? Can a visitor finish it in one visit? And would the owner notice if it stopped happening? The candidate with the most yeses usually wins. If two tie, ask the owner which one they'd miss first.

Here's a fictional ceramics studio. Priya runs evening classes and sells a few of her pieces. List what a visitor could do, and next to each, write why it matters to the business. Classes are most of her income, and every course has a fixed number of wheels to fill. Her pieces mostly sell at craft fairs. The newsletter matters, but nobody pays for it. So the primary action is booking a class. The others stay, further down, as secondary actions that don't compete for the first screen.

Next, how much to build. Don't scope in pages. 'A twelve-page site' tells nobody anything, and the term she adds a thirteenth class, it starts an argument. Scope in page types instead. A class page is one type. You design and build it once, and every course she runs is another instance of it, with the same slots filled differently. Then the real questions are which types exist, and how many instances you're writing content for. That's what the work actually costs.

Then give the client options, instead of one proposal they can only accept or reject. Three is enough. Each has to be a site you'd be happy to build and they'd be well served by. No decoy that exists only to make the middle one look sensible. That's a sales trick, and clients can smell it.

Here are Priya's. Option A is a homepage and one classes page, with booking through the tool she already uses. Option B adds a page for each class, a page about the studio, and an FAQ. Option C adds shop pages for her pieces and a newsletter sign-up. Every option leads with the same primary action. What changes is coverage, and the line underneath each one changes with it.

That line is who keeps it up to date. A site is only as accurate as the last time somebody edited it. Option C looks generous, but it means Priya updates stock on the website whenever something sells at a fair. If she won't, the shop pages are wrong within a month, and a visitor tries to buy a bowl that's gone. Write the upkeep into every option, in plain words, so she chooses the work along with the pages. Who edits, and how often, then decides the stack. That's the next skill.

Use a model as a second reader once you've drafted the options. Ask it what each option leaves out that someone booking a class would need to know. Ask what upkeep each one creates for an owner who teaches four nights a week. It's quick at that. Don't ask it to pick the primary action. It doesn't know where Priya's money comes from. You do, because you asked her.

Choose the one action the site exists for, then scope it in page types, with the upkeep written beside every option.

Every bike shop says it's friendly, expert and passionate about cycling. A visitor reads those words and learns nothing, because the shop down the road says them too. A position is what you can say that they can't. And you only get to say it if you can prove it.

Here's the working definition I use. A position says who the business is for and what it does differently, and every word of it points at evidence. Adjectives don't count. Anyone can type them.

Take a fictional repair shop. Dee runs it from a railway arch. Her current site says friendly, expert, all makes and models. Then look at the evidence you gathered. Her reviews keep coming back to the same thing: old three-speeds and steel frames, bikes another shop said weren't worth fixing. Her inventory has a photo of a cabinet of discontinued parts she's collected for years. There's the position. She fixes the bikes other shops turn away. None of that was on her old homepage.

Order matters. Start from what you've collected: the claims map, the customer language, the inventory. Don't start from what the owner thinks makes them special, because that's usually an adjective too. Draft one sentence: who it's for, what the business does, and why that's different. Read it out loud. It should sound like something Dee would say to a customer at the counter.

First, the swap test. Put a competitor's name on the sentence. If it's still true, it isn't a position. 'Friendly, expert repairs for all bikes' survives any name you give it, so it goes. 'Repairs for the old and unusual bikes other shops turn away' stops being true the moment you put a chain store's name on it. That one stays. If the sentence sounds like the category default, the line every competitor already uses, you've written the default again.

Second test: point every phrase at a source. 'Other shops turn away': the reviews say it, in customers' own words. 'Parts nobody stocks': the photo of the cabinet, plus Dee confirming it. Now say she also wants 'the fastest turnaround in the city'. Nobody has measured that. You don't soften it into 'fast'. You drop it. When the proof runs out, the position gets narrower. It never gets padded with a guess.

One more check. A position can be true, provable and unique, and still be useless, because nobody chooses a shop on it. Dee's is also the only shop on her street with a blue door. Provable, and nobody cares. The customer language tells you what people care about. Dee's reviews bring up the old bikes again and again. That's how you know this is the right position, and not merely a defensible one.

Then write it down where the brief can use it. Who it's for, what they're choosing between, what the business does, and the proof, each with its source. Add a line for what you're deliberately not claiming. That line stops the next person, or the next AI draft, from putting 'fastest in the city' back in.

An AI can spot the phrases your sentence shares with competitor copy, and find what customers keep saying in the reviews. Ask it what makes Dee different, though, and you'll get adjectives back. And it can never supply the proof. Proof comes from the business.

Find the claim a rival couldn't make, then narrow it until every word has proof behind it.

When a page doesn't get inquiries, people redesign the button. The visitor usually left three questions earlier, wanting to know something the page never said. Design the path first. The button is the last step on it. Here's the bakery's path in this course, walked on a phone. Home, then Today's bread, then Order ahead. Place order is the last step, and the page after it says exactly when to collect.

Every visitor arrives from somewhere, with something already in their head. Someone who searched has a problem and no trust in you yet. Someone a friend sent already trusts you and mostly wants to know how to book, so their path is short: a line of reassurance, then the booking. Write down who arrives, and from where, before you plan a single section.

Here's a fictional moving company: two brothers, three vans. Take one visitor. She's renting, moving in three weeks, and found them through a search. Write her questions in the order she'll ask them. Do you cover my area, on my date? Roughly what will this cost? Will my things be safe? And then, how do I go ahead? The order matters. A page that answers the last question first is asking her to commit before she knows they can even do the job.

Next, mark where she hesitates. Price is one: she's worried the quote will grow on the day. Safety is the other. Proof belongs at exactly those points. Next to the price question goes how the brothers quote, a fixed price after a video survey, and what that price includes. Next to safety goes their actual insurance coverage, in their policy's words, once they've supplied it. A row of logos at the bottom of the page answers neither question.

Now the action itself. The legitimate next step is the one the business can actually deliver, described as what really happens. The brothers can't price a move from a form, because every house is different. So 'Get an instant quote' would be a lie with a button on it. What they can do is a fifteen-minute video call: they look at the rooms, then send a fixed price. That's the next step, and the button says so: Book a free video survey.

This is where persuasion tips into manipulation, and the line is clearer than people like to admit. A false 'only two slots left'. A countdown on an offer that isn't really ending. Fees that turn up only at the final step. The US Federal Trade Commission's 2022 report on dark patterns describes all three. Honest persuasion uses the same moments with true content. The bakery's pages in this course do it. Show real availability or none at all. Show a deadline only when there is one. Put what's included up front. Usually that's also what removes the hesitation you marked.

When the page is drafted, walk the path as her, on a phone. Can she tell whether they cover her area and date without scrolling? Is the proof still next to each doubt, or did it drift to the bottom during layout? Did the brothers give a source for every claim they supplied? And when she presses the button, does what happens match what it said? If 'book a free video survey' opens a long form asking for her whole inventory, the button lied. More politely, but it lied. You're done when the button's words say exactly what happens next.

Then have the AI read the draft as a visitor. Give it the persona, ask for her questions in order, and put its list next to yours. It has never met a real renter, so anything it raises is a prompt to check with the client, never research.

Answer the visitor's questions in the order they have them, put proof where they doubt, and offer only a next step the business can keep.

Search engines and AI answers describe a business from what its pages say plainly. Ask one when this conference is, and it looks for a sentence that says so. So before anyone writes the pages, plan the answers: one description, the questions worth answering, and the facts you can prove.

Start with one sentence that says what the business is, and use it on every page. My strategy draft had one, and it says the conference was founded in 2012. When I checked AllWeb's own site, that year wasn't on it. An answer engine would repeat it as fact, so it stays out. The plan's sentence keeps only what was checked: a one-day conference in Tirana, for people in marketing, business, innovation and creativity.

Next, the questions people actually ask. When is it, where, who's speaking, how much, and can I watch a talk. Each gets a place on the page, written so the answer comes first. Then decide what gets nothing. The draft allows a page per talk only where a video exists. An empty page doesn't answer anyone.

Structured data is a block in the page's code that states facts for machines: the event's name, date, place and speakers. The draft's rule is short. Include only verified. So list each fact, where it came from, and whether you checked it. The founding year gets a no, and stays out. The venue's name gets a confirm marker, because the source is only a map pin.

Here's the built page's source. The organization block has no founding date. The event block carries the same sentence, the date and the place. Two things in the plan aren't built yet: the FAQ data and the video data. The plan says so, so nobody assumes they shipped.

Search engines and AI repeat what your pages say. Give them one true sentence, plain answers to real questions, and only the facts you've checked.

After the interviews you've got a pile of requests: facts you need, features, moods. You have to decide what to ask the client for, and what you can safely leave out. Get it wrong and the launch slips, usually waiting on something nobody needed.

That's the requirements list. Every request gets a tag, and every tag gets a reason in a few words. If there's no reason, it gets no tag.

BLOCKS START means you can't plan the site without it. Which services the business really offers, where it works, who the site is for. Get those wrong and every page after them is wrong. BLOCKS LAUNCH means you can build with a visible placeholder, but the site can't go live until the real thing arrives. Prices, real photos, the legal business name. LATER means it's a real request, worth doing, and outside this launch. It's written down with its reason, so the client knows they were heard.

Here's one for a fictional mobile dog groomer. Tomasz drives a van and books everything by text. Areas and services block the start, because the whole site hangs on them, including what he won't do. He doesn't take very large breeds, and the site has to say so. Prices, photos and his insurance wording block launch. Each sits in the build as a placeholder, marked so nobody could mistake it for the real thing. And the online booking calendar is LATER. Here's why.

In the interview his partner said, more than once, that they must have online booking. Said that firmly, it's tempting to tag it BLOCKS LAUNCH. That's the classic mistake: a wish tagged as a requirement because somebody said 'must'. Look at what actually happens. Tomasz books by text between appointments. A calendar he doesn't keep up to date shows slots that don't exist, which is worse than no calendar. So it's LATER, with the reason next to it, and with what would change it: the day he moves his diary into a booking tool.

Ask it of every item. If the answer is that the site can't do its one job, or that it says something untrue, the item blocks. If the answer is that someone's disappointed, it's LATER.

Then turn every BLOCKS item into a request list. That's what you actually send. Each line asks for one thing, in the form you need it. 'Your prices, exactly as you quote them by text' gets you real prices. 'Send pricing info' gets you a brochure from four years ago. 'Photos of dogs you've groomed, with the owners' OK' settles the rights question before it becomes a problem. Short list, specific asks, and a date.

An AI is useful here as an opponent. Once you've tagged the list, ask it to make the strongest case that the site could launch without each BLOCKS item. The ones it can't move are your real requirements. You still decide, and you write the reason.

The BLOCKS LAUNCH lines are your before-launch list. Copy them into the Go live checklist, so the site can't go out while any of them is still a placeholder. Every line is either real, or the site waits. How to search the built pages for a stray placeholder comes later, in the lessons on checking a build before it goes out.

Tag every request by what breaks without it, give each tag a reason, and send the client a list of specific asks.

A brief that can't be checked after launch is a wish list. Three months in, someone will ask whether the site worked. Decide now what you'll look at to answer, while the plan is still on paper.

Start from the site's one job, and turn it into a question you can answer with a yes or a number. Here the job is selling tickets, so the question is: do visitors reach a ticket button? Then name the step that answers it, something a page can count. The build already names it. All five ticket buttons carry the same event name, and each says where it sits. Here's the honest part. On this concept the buttons are demos, so a click stops there and nothing is counted. Real counting waits for an analytics tool and the visitor's consent.

Next, the starting number. For speed there is one. On the fifth of October, the old site's largest element took 4.7 seconds to appear, on a simulated phone over a slow connection. For tickets there isn't one I can show, so the brief asks, and says not known yet. And no target. A target with nothing behind it is a guess with a deadline.

Last, who reads it, and when. On a speculative build that's the client's call, so it's a confirm marker too. In Improve, this list becomes the measurement plan, and that's where the tool gets set up.

Before launch, write each question you'll check, the step it counts, the number you start from, and who reads it. Where there's no number yet, say so.

Scope is the line around the work: what's in, what's out, roughly when, and who can move the line. Write it before you build, so a request that turns up later has somewhere to go.

This redesign is speculative, so its scope is small. One homepage concept, at desktop and phone width. AllWeb's own photos and published facts. And a review link, kept out of search.

Out of scope matters more. Name everything someone might assume is included. Ticket sales aren't: the ticket buttons are demos. One search counts eighteen demo links on the page, and the sign-up form says nothing was sent. Analytics, the other fifteen planned pages, a new logo and an Albanian version are out too. The brief already said what it wouldn't do, so the scope just carries it over.

Then rough milestones, with dates you can show. The audit and the brief are dated the fifth of October. An outside audit ran on the seventh. The event is on the sixth of November, and after that the concept's dates go stale. Last, who decides. On a speculative project, you do. For a real launch it's the client, and nothing moves from out to in without their yes.

Write what's in, name everything that's out, give the milestones you can show, and say who can move the line.

Most site projects go wrong before the first sketch. The client describes a feeling, the designer hears a feature list, and nobody writes down what the site is for. A one-page brief fixes that. It's the first thing I write after the interviews.

A brief names what has to change for this business once the site exists. It doesn't pick colors or fonts or a template. If you catch yourself writing about how the site looks, you've jumped ahead, and later you'll be defending a style nobody agreed to.

Take a fictional framing workshop. Ines runs it on her own. She asked for a modern look, her social feed on the homepage, and a gallery of every frame she's ever made. Those are wishes: none of them says what should happen. Underneath, she loses evenings answering calls about opening hours, people walk out when they hear the price, and she wants commissions to start online so she can quote from a photo. Each of those is a change you could check. My test: three months after launch, could I tell whether it happened? If yes, it's a goal. If not, it's a wish, and it waits until a goal asks for it.

Before the full brief, write one sentence: the site's one job. For Ines it's this. Get people with something to frame to send a photo and a size, so she can quote before they visit. One line forces a choice. If you need two sentences, you've got two sites, and one of them will lose.

Then the page itself, in five parts. Purpose is the one job and why it matters now. Sources lists what the brief rests on: the interview notes, the inventory of what's already online, anything the client sent you. Do-not is what the site must never do. Outcomes are the goals, written so you could check them. And the last part says who signs the site off, and against what. Keep it to one page. If it runs longer, you've started designing inside the brief.

Here's hers, a line per part. Look at the do-not list, because that's where a brief earns its keep. No testimonials until Ines gives us real ones. No same-day turnaround, because some jobs take her a week. No stock photos of frames she didn't make. An AI will write every one of those if you don't forbid it. Ask for a framing site and it reaches for 'trusted by hundreds of happy customers', because that's what framing sites say. The do-not block stops it before it starts.

You can use AI here, after you've written your own draft. Ask it to tag each line goal or wish, and say how you'd check each goal after launch. It's good at catching a feeling dressed up as an outcome, and it wasn't in the room, so you make every call.

The part people skip is how the site will be judged. Write the checks now, while nobody's attached to a design, and write each one so a stranger could run it and get the same answer. Does the first screen make the one job obvious? Can someone send a photo and a size from their phone in under a minute? Did Ines supply every claim on the page? Here's a check like that being run, on the bakery's site from this course. Is ordering ahead on the first screen of a phone? At three-seventy-five wide, it's there in the header, so anyone who looks gets the same answer: yes. At the end you review the build against these lines, and so does Ines. That's what a brief is for. It can say no.

Write down what has to change, and how you'll know it did, before anyone opens a design tool.