Research

Before you design anything for anyone, find out whether the project is real.

You spend a week on a homepage for a business that has already moved on. Or you pitch someone who can't sign anything. Both start on day one, when you say yes to a project you never checked. Qualifying is the short check that prevents it: a few questions, each answered with evidence, written down before you start.

I use four questions. First, is the business alive: trading now, at this address, answering its phone. Second, is there something to fix: a real problem the website causes or could solve, beyond 'it looks old'. Third, who is the client: the person who decides and pays, which is often not the person who emailed you. Fourth, the money test: can they pay for this, and is what you'd fix worth more to them than it costs? A no on any one of them is worth knowing now.

Sign of life is where people get fooled, because the internet keeps a business looking open long after it has stopped. Take a fictional upholsterer, Fenwick and Daughters. Their social page posted last week, but it's a chair from four years ago, the kind of repost a scheduler sends out by itself. The map listing says open now, because nobody told it otherwise. Sort the reviews by newest and the top one says the owner retired and the workshop is shut. So read what the evidence describes, and check the date on the thing itself, never the date the platform shows you.

Who the client is sounds obvious until you're three drafts in and someone new appears with opinions. Ask early and plainly: who decides, who pays, and who else has to like it. A manager who loves your idea may not be able to approve the spend. A partner who never answered your email can still veto everything. If you can't get a name for the person who decides, write 'unknown' and treat it as a risk.

The money test is really two questions. A business that could easily afford a new site but loses nothing from the current one will stall on every invoice. One that loses bookings every week to a broken inquiry form may find the money quickly. You don't need their accounts. You need a rough idea, in their own words, of what the problem costs them.

For each question, write four things. The question. Your answer, and unsure is allowed. The evidence, as a link or a file path, with the date the evidence is from. Then what would change your mind. That last line does the most work. It turns a vague worry into a task: if the phone goes unanswered twice this week, this is a no.

Here's the sheet for the upholsterer. Alive is a no, and the two lines underneath say why, with dates. Who is unknown, because the inquiry came from a relative. Fix and money were never assessed, because there was no point. The call is no-go, and it says exactly what would reopen it. If you wrote this on Monday and a colleague read it on Friday, they could check every line without asking you a thing.

Do all this before you ask the AI, for the same reason you decide first on anything else. Asked whether this is a good lead, it will happily help you talk yourself into a yes. Then let it look for evidence you missed. Keep the sheet in the project folder. When something goes wrong in month two, it's the first thing you'll want to reread.

If you can't point to the evidence, you haven't qualified the project. You've hoped.

A harvest is only useful once you can trust what's in it.

After a harvest you have a pile. Downloads, screenshots, PDFs, pasted text, and the client's own folder of things. A pile feels like research, but you can't build on it, because you can't tell which version of the opening hours is current or where a photo came from. An inventory is the same material with one row per item, saying what it is, where it came from and how old it is. My test for a source field: could a stranger open it and find the same thing? If not, it isn't recorded yet.

Each row has five fields. What it is, in plain words, and who made it: the client, a customer, a directory, you. Where it came from, as a full web address or file path, so anyone can open it. The content date, and how you know that date. Reliability: high, medium or low. And what would raise it. This is the part that saves you when the client asks where a claim on their own homepage came from.

The field that catches people is the content date. When you download a PDF price list, your computer stamps it with today. The server may say it was uploaded last March. Neither is when the prices were set. Open the file. The fictional Harbour Lane clinic's price list says 'from January 2023' in the footer, and that's the date that counts. If nothing in the content gives a date, write 'undated' and lower the reliability. Don't fill the box with the file's date because it looks empty.

Here's that row. The source is precise enough to reopen. The date comes from the content, with a note so nobody, person or agent, swaps it for the download date later. Reliability is low, and the reason is written down: another source shows different prices. And the last field is already a question for the client.

Low reliability is a note about how far you can lean on a source. A source drops when it has no date or an old one, when you can't say who made it, when it disagrees with something more direct, or when it's a copy of an original you haven't seen. A directory that copied the clinic's hours years ago is all four. It still goes in the inventory. You just don't put its hours on the new site.

Then say what would raise it. Find the original the copy came from. Find a second source that didn't copy the first. Ask the client to confirm in writing, so the confirmation becomes a dated source of its own. If none of that is possible, the item stays in the inventory marked low, and stays off the page. Filling in this field gives you a short list of questions for the client, which is exactly what the harvest was for.

Your coding agent is useful for the first pass. It can walk the harvest folder and draft a row per file. It's weakest on the two fields that matter: it can easily take a file's date for a content date, or call a confident-sounding page reliable. So tell it to leave the date blank when the content gives none, rather than guessing. Then check every date and every grade yourself. Keep the inventory as a file next to the harvest, so the next session starts from it.

Every item gets a source and a real date, or it doesn't go on the site.

A harvest leaves you with hundreds of images, spread over pages and folders. Before you design with any of them, put every one on one sheet, where you can see it, count it and decide about it. Here's AllWeb's, made on the fifth of October. The photos are blurred in this video, because they show real people.

It has two parts. Everything the live site shows: 128 images, and 113 of them have no text alternative. Then the whole media library: 430 images, and most of them never reach a page. Each image carries what you'll need to decide about it: its file name, its size, how many pages use it, and whether it has a text alternative. Click one, and the original opens on the live site.

Then give each image you might use a row of your own, with a number that never changes. Where it came from, and where it's used. Who made it, and whether you may use it. For this event photo the photographer isn't stated, so that's a question to ask, not a yes. Keep or cut, and the slot it would fill, you settle in Design. The sheet stays in the project folder as a page of links to the originals, with a PDF copy, and your worksheet records its path. Keep both. You'll use them again on the next site.

Put every image on one sheet with its source, size, pages and alt text. Then give each one you might use a numbered row: who made it, whether you may use it, and where it would go.

Every image on a client's site is a decision about rights and about truth. Make both on purpose.

Images are where small sites get into trouble quietly. The client sends a folder, the old site has a gallery, the agent finds a perfect photo online, and three months later nobody knows which is which. Before an image goes into a design, it needs two answers: who made it, and who gave permission to use it here. If you can't answer both, you don't know whether you can use it.

Add images to your source inventory with their own fields. Where it came from: the client's folder, the old site, a stock library, a generator. Who made it: a photographer, a member of staff, a customer. What permission exists, and where it's written: a license, an invoice, an email. And who's in it, because a recognizable person raises questions only the client can answer. 'The client sent it' tells you where it came from, not who owns it. Paid stock counts too: keep the license or receipt with the image, because its terms are your permission.

When rights are unclear, you have three moves: find out, replace it, or leave it out. An image found through search is out unless you can trace it to a license. A photo from the old site goes on the client's question list: who took it, and on what terms? A customer's photo of their order is lovely, and it's theirs. Ask them, or don't use it. Unclear doesn't turn into yes because the deadline is close. If the client insists an image is theirs to use, get that in writing and keep the email with the image.

Licenses have an official teacher, and it isn't me. Creative Commons explains its six licenses, and every one of the six requires credit to the creator. If a license includes NC, non-commercial, check whether a business website fits before you rely on it. The link is with this lesson. I'm not a lawyer, and when money or a dispute is involved, the client should ask one.

Now generated images. They have a place: texture, atmosphere, a concept for a client to react to. But a generated image is never evidence. It doesn't show the real shop, the real team, the real product or a real result. A generated 'our workshop' picture is a false claim, made with pixels instead of words. The same goes for editing a real photo until it shows something that didn't happen: a fuller room, a product that doesn't exist yet.

Write it down as a short policy in the project, and agree it with the client. Allowed uses. Never-uses, named concretely for this business: the shop, the staff, the bread, the customers. And a provenance record for each generated image: which tool, when, the prompt, and who approved it. Check the generator's own terms as well, since they govern what you may do with its output. Months later, when a client asks where a picture came from, the record is your answer.

The two halves meet in one test. For every image in the design, ask what a visitor will believe it shows. If they'll believe it's the business, it has to be the business, photographed with permission. If it's decoration, the context has to make that obvious. And if you can't tell where an image came from, it doesn't go on the page. Write the answer next to each image in the inventory before you send anything.

If an image presents something as real, it has to be real.

Before anyone reads a site, they meet it somewhere else: a search result, a map pin, an AI's answer. So check what those say about the business, and write down where each one comes from. This is common, and it's quick to fix. Here's the conference site, checked today.

The search snippet comes from the page's description. Fetch it, and it names Mavrovo, Macedonia. This year, the event is in Albania. That's the first sentence a searcher reads. The page title says it's all about digital, with no year and no city. Search engines and AI answers read structured data. Count the event descriptions in this page: zero. So an AI asked when AllWeb is has one line of body text to quote: next event, the sixth of November 2026.

Write each one down: what it says, whether it's right, and the fix, all under the date you checked. The map pin names a mosque, and the venue isn't stated anywhere, so that one is a question for AllWeb. Search results and AI answers change, so date every check, and check again after launch. Plan turns these fixes into the search plan.

Check what search, maps and AI say about the business. Write each with its source and the date, list the fix, and check again after launch.

Two people run the business. They've each got a different website in their head, and each of them is right about something.

Take a fictional architecture studio with two partners. One says the studio does house extensions and the site should show them. The other says extensions pay the bills but the future is small commercial work, and the site should be for that. Both are telling the truth as they see it. Put them in one room and you'll get a polite version of the louder one's view.

So interview each person on their own, with the same core questions, so the answers line up when you compare them. Ask if you can record. If you use an AI tool to transcribe it or pull out quotes, check every quote against the recording, because a paraphrase can sneak in looking like someone's words. Keep the exact phrasing for anything that matters. And tell each person the other is being interviewed too, with the same questions, so nobody feels ambushed later.

Ask what someone wants and you get a wish. Ask what happened, and you get how the business actually works. 'Walk me through your last job, from the first message to the final invoice.' 'Where did your last three clients come from?' Past behavior is harder to dress up than plans. The partner who talks about commercial work may tell you the last three jobs were all extensions, and you'll both learn something.

Ask one more question in every interview: 'If I asked your partner the same thing, what would they say?' It tells you whether they know a disagreement exists, and how they'd describe the other side. Sometimes they describe it more fairly than the other person does. Sometimes they've no idea there's a disagreement at all, and that's worth knowing too.

You'll hear contradictions, sometimes inside a single interview. When you do, ask one neutral follow-up: 'Earlier you said most work comes from referrals. Where did this one come from?' Then stop. You need to know that the disagreement exists, how big it is, and what each person's evidence is. Deciding who's right comes later, and it may never be your call. Write down the exact words of both versions while they're fresh.

It's tempting to reassure people: 'Don't worry, we'll definitely show the commercial work.' Don't say it. A promise to one partner is a decision you've made for both of them, and the other partner will hear about it. Say 'that's useful, I'm writing it down', and write it down.

This is what comes out. Each person's position in their own words. The facts they both agree on, kept apart from the positions. Then the open question, phrased so it can be answered, and who has to answer it. Notice what's missing: any opinion of mine about which partner is right. That might come later, as a recommendation with reasons. It doesn't belong in the record. Keep the record as its own file next to the interview notes, so the brief can point to it.

The record feeds the brief. List every open disagreement near the top, because a brief that hides one falls apart at the first design review. Name who decides each one. Say what it blocks: you can wireframe the contact page while the partners argue about the homepage. And when they decide, get it in writing, with a date, so the decision becomes a source like anything else in the project.

Write the disagreement down. Settling it isn't your job.

Your client's customers have already written some of the site's best lines. They're in the reviews, in their own words, waiting to be copied out.

A business describes itself in the vocabulary of its trade. Its customers use their own. A fictional children's swimming school says 'aquatic confidence programs'. Its reviews say 'they didn't rush him', 'she finally put her face in', and 'the teacher's in the water'. The second set is what a nervous parent types into a search box.

Collect reviews from wherever customers post them: listings, booking sites, the replies under social posts, and messages the client is willing to share. Read the three-star reviews, which are often the most specific. Check a platform's terms before you automate collecting. And ask the client what people ask on the phone, because that's customer language that never made it into a review.

Pull four kinds of phrase. The problem they had, in their words. What worried them before they booked. What surprised them, good or bad. And whatever they call the service. 'Five stars, lovely staff' gives you nothing. 'I was worried he'd cry the whole lesson' gives you a headline and an objection to answer.

The trap is summarizing. Ask an AI to read two hundred reviews and tell you what customers think, and you get 'parents value the patient approach'. True, and useless, because nobody talks like that. You want exact phrases in quotation marks, each with the review it came from. Then check a sample against the originals, because a paraphrase can slip in looking like a quote. A quote you can't trace is a quote you can't check.

Here's the prompt, run on a file of reviews you've already collected. It asks for the four kinds of phrase, word for word, each with a line number so you can check it in seconds. It also says not to fix spelling, because the customer's odd word is sometimes exactly the one you want.

The glossary keeps two lists. Words to reuse, with a count of how often they come up. Words to avoid: ones customers use when they're complaining, and the company's own terms that no customer ever says. Every phrase points back to the file of collected reviews, so you can show the client where it came from. The counts are for your choices, never a statistic to publish. Keep it short enough to read in a minute. Twenty good phrases beat two hundred.

One boundary. Borrowing the way customers put things, in your own copy, is fine; you're learning their vocabulary. Putting a review on the site as a testimonial, with a name next to it, is a claim and a use of someone's words. It needs a source and, where it's needed, permission. Keep the two in separate files so one doesn't drift into the other.

Then use it. Read the glossary before you write a line of the site. When the draft says 'program', ask what parents call it. When you brief an agent to write copy, give it the glossary file by path and make the avoid list a hard rule. Then read the headlines aloud against the 'use' list. If none of the customers' words survived, the copy has slipped back into the company's voice. The customers' worries are also your questions page.

Write in the customer's words, not the company's.

Every site makes claims, and nobody reads them as claims until something goes wrong. Before this one goes live, you'll know which of them are true.

'Family-run since 1998.' 'Every loaf is baked every morning.' 'We deliver across the neighborhood.' Each of those is a fact someone could check and find false. On a client's site, you're the one publishing it. So before copy is final, every claim gets mapped: what it says, whether it's true, and how you know.

Go through the draft copy, the old site and anything the client wrote, and pull out every claim. They cluster. Any number, any year. Awards, accreditations and memberships. Superlatives, especially 'only' and 'first', which are claims about every competitor too. Quotes and testimonials. Prices and guarantees. Your coding agent can do a decent first sweep if you ask it to list every checkable statement word for word. Then read it yourself, because the quiet ones slip through.

For each claim, the routine is the same. Copy it exactly as written, because rewording it is how a false claim gets softened into one nobody checks. Find its row in your source inventory, which already has a source and a date, or note that there isn't one. Give it a status. Then decide what happens to it: keep it, reword it to what the source supports, replace it with a placeholder, or cut it.

Four statuses do the job. Verified means you have a source you could hand to someone else. Client says means the client confirmed it in writing and you couldn't check it independently, which is often fine for things only they know. Conflicting means sources disagree, and the rule is to leave it out until it's resolved. Don't pick the version you like. No source means a placeholder, or cut it. Put the status next to the claim in the copy file itself, so whoever edits the copy next can see it.

Two rows for a fictional butcher's. 'Family-run since 1998' is conflicting. The company register says the business was formed in 2004. The owner says her mother started selling at markets in 1998. Both can be true, so the fix is wording both sources support, agreed with the owner. 'Award-winning sausages' has no source, so it becomes a visible placeholder asking for the award, the year and who gave it. From there it follows the placeholder route from the lesson on never inventing a fact: onto the client checklist, and searched for before anything is sent.

Rewording is the move people forget. 'The best butcher in town' can't be proven by anyone. 'Trading in the town since 2004' can, and it's more interesting. A customer count with no records behind it goes, and something you can check takes its place. Narrower wording almost always reads as more confident, because it's specific.

No source, no claim. A visible placeholder until there is one.

Your first reaction to a client's site is a starting point, and nothing more.

Open a client's current site and you'll have an opinion in seconds: dated, cluttered, dark photos. Note it, but it's your taste, and it skips whatever didn't jump out at you. An audit looks at the same site several times, each time through one lens, so the things you'd never notice on your own get their turn.

I use eight lenses, in four pairs. UX and information architecture: can a visitor find what they came for, and do it? Copy and conversion: what does the site say, and what does it ask people to do, honestly or not? Accessibility and performance: can everyone use it, and how long does it make them wait? Technical SEO and legal awareness: can search engines read it, and is there anything that could land the client in trouble? Legal awareness means noticing, never advising: a cookie banner that does nothing, a missing privacy page. You flag it for someone qualified.

Each pass has the same shape. Pick one lens. Then do the thing a visitor comes to do, such as ordering bread for Saturday, on a phone as well as a laptop, since a small screen exposes problems a desktop hides. Note every finding with its evidence: a screenshot, a URL, a measurement. And don't fix anything yet. The moment you start fixing, you stop seeing.

Severity is about consequence. How much something annoys you doesn't count. Four blocks the site's main job: someone who wants to order bread can't. Three costs visitors or trust. Two is friction people work around. One is cosmetic. A dated font is usually a one, however strongly you feel about it. A booking button some people can't read is a four, even if nobody has complained.

Here's part of an audit of the fictional Harbour Lane clinic. Each finding has its lens, what was seen, and a grade. The contrast failure on the booking button is the only four, because it blocks the one thing the site exists to do. The dated footer font, which was the first thing I noticed, is a one. That's the point of grading: it overrules your first impression with consequences.

Lenses will disagree, and that's useful. The copy pass says the hero photo of the real team builds trust and should stay. The performance pass says it's four megabytes and leaves the first screen blank on a phone. Don't let the louder lens win. Name the conflict, then look for the move that satisfies both: keep the photo, and make the file a fraction of the size. When no such move exists, the site's main job decides.

An agent is good at the gathering part of some lenses. It can list every image over a size you choose, every page without a title, every heading out of order, and save them to the audit file with URLs. What it can't do is grade them for this business. It doesn't know the site's main job unless you tell it, and it will tend to report everything as important. Grading stays with you.

Then turn the list into a decision. Sort by grade. Group findings that share a cause, because five contrast failures from one color are one fix. Pick the few that matter most for the site's main job, and write why, pointing at the evidence. That short list is what the client reads. The full list stays in the project file. For accessibility and performance, specialists go much deeper than this, and the related skills point to their official resources.

Every finding gets a lens, a grade and evidence. Then decide.

Most businesses already have more proof than their site shows. Before you write a word of copy, find it, count it, and note where it is now. Here's AllWeb's, checked today on the live site and against the audit from October.

Start with the numbers the business publishes about itself. Its homepage shows all four. They're its claims, so they're credited to it, never restated as yours. Then the talks. Eight videos on the homepage today, and an archive going back to 2017. Put each one in the list as you find it, with its source. Then the photos: 304 images in the library aren't on any live page, most of them from the 2022 to 2024 events. That's proof sitting in a folder, usable once its rights are checked. Speaker bios are strong on their own pages, and never reach the homepage. And the four testimonials, names only, are in the page's code twice. Keep each once.

For each piece, note where it is now, its source and date, whether it can be shown, and where it should go. Structure uses this list when it plans the homepage.

Find the proof the business already has: its numbers, its archive, its photos and its people. Note where each is now, its source, and where it should go.

Before you change a site, write down how the old one performs. Once the redesign replaces it, nobody can measure the old one again. Here's the baseline for AllWeb's current site, measured on the fifth of October.

Speed first. This report comes from a free speed test, run on a simulated mid-range phone over a slow mobile connection. Performance, 76. The largest thing on the page took 4.7 seconds to appear. Layout shift, how much the page jumps while it loads, was 0.052, which is low. Write the settings down with the numbers: the date, the device, the connection and the tool's version. A number without its settings can't be compared with anything later.

Copy each number into one baseline file, with the capture it came from: speed on the phone and on the desktop. The page weight from the audit. And the accessibility scan's three counts. Each of these is one run, and these tests vary from run to run. So in the Test phase you'll run each three times with the same settings, and keep the middle result. It's a starting line, not a grade.

Before you change anything, record the old site's numbers with their date, settings and capture, so the Test phase can compare like with like.

Research ends with a folder of good files: an audit, a brief, dated screenshots, a manuscript. Nobody can plan from a folder. So the last research step is one page that says what's known, what disagrees and what's still unknown, with every line pointing to where it came from.

Start with what you know, and name the source on every line. The event: one day, the sixth of November, in Tirana, read on their site. The 2026 speakers: six, with bios and no talk titles yet. The past events, in AllWeb's own published numbers, credited to them. And the starting line for speed, measured on the fifth of October, so the Test phase has something to compare with. Then what disagrees. The plan's manuscript says AllWeb was founded in 2012. Their site never says it, so it stays off the page until someone confirms it. Two documents proposed two different headlines, so the decision, and where it's recorded, goes here too. Then what you don't know, and who could answer it. The ticket prices after the early bird. The 2026 program. The venue's name: the map pin is all there is. On a speculative project, those questions stay open. On a commissioned one, they go to the client.

Last, check what an AI told you. I had an AI audit the old site, then checked each of its findings against the site itself. Some held up, like the video archive being worth more in search. Some were wrong. It said a hundred and twenty speakers and panels, and the site says a hundred and twenty partner brands. And some were invented, like a ticket price and a sold percentage that appear nowhere on the site. A finding isn't true because an AI said it, or because two of them did. It's done when someone could start planning from this page without opening the others. That's where the Plan phase begins.

End research with one page: what's known, what disagrees and what's unknown, every line with its source. Check every AI finding against the real thing before it goes in.

Research gives you facts. A SWOT turns them into a few calls the site has to act on: what to lead with, what to fix, what to use, and what to watch. Do one on every project, and make every line point at where it came from.

Start with the other events, at the level of the business. This research is from October, and it says so: it isn't presented as how their sites look today. Web Summit makes the ticket path obvious and uses its scale for urgency. The next one sells the experience of being there. OFFF lets art direction carry the event. SXSW shows its long history. Then the line that matters: where AllWeb can win. A focused one-day event for the region, not a smaller Web Summit. Strengths and weaknesses are about AllWeb itself. Its history is real, in AllWeb's own published numbers. Its talks are on video back to 2017. The weakness: that proof is spread across the site, social channels and video. And on the fifth of October, no talk titles were out yet. Opportunities and threats come from outside. Gather the talks and photos into one archive, and answer when and where first, for search and for AI answers. The threat: bigger events with clear ticket paths compete for the same attention. That one is an inference from the research, and the line says so.

Every line ends with what the site will do about it. Those lines are where Plan starts.

Do a SWOT on every project. Build it from your research, cite a file or a dated source on every line, and end each line with what the site will do.