Web Design
The Discovery Checklist: What I Ask Before Building Anyone a Website
Part 1 of the thread Building a site for someone
- My checklist has eight groups, from the business basics to the awkward constraints nobody mentions until week three.
- Most of it is context. A handful of answers decide the build: the one job the site has, who updates it, and who owns the domain.
- It's a conversation, not a form to fill out before you're allowed to talk to me.
- Anything you can't answer yet is fine. Knowing it's unknown is the useful part.
When I plan a site for someone else, I start from the same list. It lives in my notes as a plain checklist, eight groups of questions that cover everything from the business basics to the constraints nobody thinks to mention.
I don't send it as a questionnaire. Nobody wants homework before they've even decided whether they like you. It's what I work through with someone over a conversation or two, filling in what I can and flagging what we don't know yet.
The whole list, grouped
| Group | What I'm asking about |
|---|---|
| The business | Name, who I'm talking to, who signs off, how long it's been going, where it is |
| What you offer | Main products or services, what actually brings in money, what makes you different, three to five competitors |
| Goals | What the site should do, in order of importance, and how we'd know it's working |
| Audience | Who visits, what they're trying to get done, what devices they use, how comfortable they are online |
| Content and design | The current site, what content exists, sites you like and dislike, photos, brand guidelines, anything to avoid |
| Technical | CMS preference, shop, logins, forms, blog, search, calendar, newsletter, analytics, accessibility target, hosting |
| Project | Budget range, timing, a hard launch date, who gives feedback, who's writing the words, upkeep after launch |
| Constraints | Legal or industry rules, privacy, seasonal rushes, changes coming to the business, what went wrong last time |
That's a lot of rows. Most of them are context. They help me write in the right voice and avoid a design that fights the business. But a few answers change what I build, and those are worth pulling out.
The questions that change the build
What's the one job this site has? "Get people to call," "take bookings," and "show the portfolio" are three different sites. The checklist asks for primary and secondary goals with a priority each, and the primary one decides what goes right under the headline. It's also the thing that decides whether a one-page layout will do.
Who's going to update it? Someone who'll change the menu every week needs an editor they're comfortable with. Someone who'll touch it twice a year might be happiest with a simple static siteA website made of plain, prebuilt HTML files, with no database or server code running behind it. and an email to me. This one answer decides more of the tech than anything in the technical section.
Who's writing the words? "Final content received from the client" is a milestone in my project plan for a reason. If the answer is "we'll figure it out," that's fine, but it goes on the schedule as its own job.
Who owns the domain and the hosting login? It should be the business, in the business's name. If an old developer or a nephew registered it years ago, that's the first thing to sort out, well before launch day.
What went wrong last time? The "previous website issues" line is near the bottom of my list, and it can be the most useful answer in the whole conversation.
Tip
The inspiration question works better as "show me two sites you like and one you hate." People are much better at reacting than at describing.
What I don't need on day one
The list has a revenue range marked optional, and I leave it that way. Budget matters, but I'd rather hear "about this much" than a bracket. Number of employees, years in business and growth plans are nice to know and rarely change the design.
It's also fine to leave a lot of it blank. "We don't know who our competitors are" or "we haven't decided about a shop" are real answers. They tell me which parts of the build should stay easy to change.
Note
A few technical items look optional and aren't: an accessibility target (WCAGWeb Content Accessibility Guidelines. The standard for accessible web pages, including the contrast ratios text has to meet.More: Borrowing a Palette from a Reading App AA is a sensible default), a privacy policy if there's a form, and a note of any third-party tool the site has to talk to. Those are cheap to plan and expensive to bolt on.
What happens with the answers
The answers turn into a short plan: the pages, the one or two main CTACall to action. The one thing a page wants you to do next, usually a button: book, call, buy.More: Laying Out a One-Page Website: The Section Order and Why, the tech, and the milestones. That's the next post in this thread, from kickoff to launch, which walks through the phases and the points where I stop and ask for a yes before going further.
And if you'd rather skip straight to "here's what I've got," the Work With Me page takes a few lines and I'll write back myself.