Web design project intake form: Sort fields by deadline
Sort a web design project intake form by the date each field blocks work — kickoff, build, launch — then the A/B/C answerability test and a stall log.
Kristian Hoffmann
SaaS founder and operator
A web design project intake form is the structured request you send before kickoff to collect scope, content ownership, technical access and approval authority in one submission — and the version that gets returned sorts its fields by when each one blocks work, not by whether it carries a red asterisk.
Most intake forms carry one required flag and one deadline: Now. That is why they stall. A client who has a logo, a domain login and a rough page list can answer two thirds of a good form in ten minutes. The last third asks for things that do not exist yet — final copy, a signed-off sitemap, the analytics property the previous agency still controls. Mark those required and the whole submission waits on them.
The three windows a field can belong to
Kickoff-blocking fields are the ones you cannot draw a wireframe without: What the site is for, who it sells to, roughly how many top-level pages, the date that actually matters (a trade show, a funding round, a lease that ends), which brand assets exist today, and the name of the person who signs off. If these are missing, there is nothing to design against.
Build-blocking fields arrive later without stopping the start: Final copy per page and who writes it, where photography comes from, the CMS, the integrations (booking, payments, newsletter), languages, migration scope. You can design a homepage with placeholder text. You cannot ship one.
Launch-blocking fields are access and legal plumbing: Registrar and DNS control, hosting, the analytics account, the redirect list from old URLs, consent and cookie text. Clients rarely have these at hand on day one, and chasing them at intake is what turns a five-minute form into an unanswered email thread.
A field belongs in the window where its absence stops you — not in the window where you would like to have it.
| Window | Fields | Examples | If it is still empty |
|---|---|---|---|
| Kickoff-blocking | 9 | Goal, audience, page count, hard date, existing assets, approver, budget band, reference sites, current URL | Do not schedule the kickoff call |
| Build-blocking | 7 | Copy owner, photo source, CMS, integrations, languages, legal-page owner, migration scope | Start design, flag it in the week-one status |
| Launch-blocking | 6 | Registrar, hosting, DNS, analytics, redirect list, consent text | Ask at design sign-off, not at intake |
The 9 / 7 / 6 split is an allocation model for a standard small-business site, not a benchmark — a shop with 400 SKUs shifts weight into the build column. What holds across project types is the rule: Make only the kickoff column required at submission. Ask for the other thirteen in the same form, let the client submit without them, and give the form a re-open link so the rest can land in the window where it matters.
The answerability test: A, B and C questions
Before you count fields, classify each question by what the client has to do to answer it.
- A — from memory. Goal, audience, approver, the date that matters, what they dislike about the current site.
- B — findable in under five minutes, alone. Registrar name, current CMS, whether analytics is installed, the URL of a competitor they admire.
- C — needs a decision or a third party. Budget sign-off, assets held by a former agency, legal text from an adviser, a sitemap nobody has agreed on.
Count the C-questions. Keep at most three in one form and put every one of them on the final screen. A C-question at position four is where an intake form becomes a saved draft — the client hits something they cannot resolve, closes the tab, and the whole submission dies behind a question you did not need on day one.
Each C-question also needs a one-line note next to it: We can start without this. Without that note, a conscientious client reads a blank field as a blocker and waits.
One form, three respondents
Intake forms are usually written as if one person will fill them in. Real projects have three, and the person who opens the link guesses on the two sections that are not theirs.
| Section | Who actually knows | What you get from the wrong person | Fix |
|---|---|---|---|
| Goals and audience | Decision-maker | Plausible answers paraphrased from the current site | Ask for the approver by name in field one |
| Content and assets | Content owner | "We'll send that over later" | Upload slots per asset, with accepted formats named |
| Technical access | Technical contact | Wrong logins, expired invites, a reseller nobody can reach | Ask who controls the domain, not what is the login |
| Approval and timeline | Decision-maker | A date nobody committed to | Ask what happens if the date slips |
If your form cannot be forwarded section by section, you are relying on one person to chase two colleagues on your behalf. That is the same delegation problem project intake software for agencies solves with request routing, one level down: Routing inside a single project rather than across a queue of them. For the wording of the individual questions, the web design template for client intake covers the field list itself.
Four ways the form fails
It asks for a decision and files it as a fact. Budget and sitemap are the usual offenders. The client types something to get past the field, you quote against it, and the correction arrives in week three.
It collects sentences, not artifacts. A text box that says "we have a logo somewhere" is not a logo. Every asset question needs an upload slot attached to it, or the files come back through email anyway — which is the failure mode a client file sharing portal exists to close.
It assumes one respondent. Covered above, and it is the quiet reason half-empty submissions look like disengaged clients when they are actually forwarding problems.
It submits once. A one-shot form has no place to put the logo that turns up nine days later, so that logo arrives as an attachment with the subject line "Re: Re: Fwd: website".
A stall autopsy you can run on your last ten intakes
Open your last ten projects and build a five-column log: Date sent, date submitted, the last field answered before the gap, which window that field belonged to, and who you ended up chasing. It takes about twenty minutes for ten projects if the forms are in one place.
Two readings come out of it. If the same field is the last-answered field in two or more of ten, it is misclassified — usually a C-question sitting in a B position, or a launch-blocking field marked required. Move it, do not rewrite it. And if the median gap between send and submit is longer than the week you allocated for kickoff, the form is not documenting your schedule; it is setting it.
Stop using free text for anything you will later count
If an answer ends up in a quote, a spec or a checklist as a number or a named option, a sentence is the wrong input type.
- Countables — pages, languages, products, revision rounds, locations: Number inputs, so you can total them without reading.
- Enumerables — CMS, e-commerce platform, hosting, payment provider, email tool: A select list with an "other" escape, so your answers stay comparable across clients.
- Artifacts — logo, fonts, photography, brand guide: Upload fields with accepted formats stated; a URL field for the live site and social profiles.
Free text still belongs in exactly the places where you want the client's own words: What they dislike about the current site, what a successful launch looks like to them, and anything a competitor does that they envy. Those three answers are worth more than the rest of the form.
How long should it be, and does it go before or after the kickoff call?
Length is measured in C-questions and screens, not in fields. Twenty-two fields where nineteen are A or B answers is a shorter form, in practice, than twelve fields where five need an internal meeting first.
On sequencing: Send the form first and run the call on the answers, when the client's first email already names a deadline and an approximate page count — that combination signals they have a project, not an idea. If the enquiry is exploratory ("we know we need something new"), the call comes first and the form captures what you agreed, because an intake form is poor at extracting a decision that has not been made yet.
What to check in whatever tool you send it through
- A re-open link, so build-blocking answers can land after submission without a new form.
- Section-level forwarding, so the technical contact answers four fields and nothing else.
- Upload slots bound to the field that asks for them, not a general drop zone.
- An export you can read without the tool still being open: A structured brief plus the files.
cluein.me — the product behind this blog — is built around that last pair: One portal link for the brief and the uploads, and an export of the result as a structured brief with the files. It suits designers and small studios running intake per project. A team triaging dozens of inbound requests a week wants ticket-style routing instead, which is a different category of tool.
The field you cannot classify
Budget resists all three windows. It is a decision, not a fact, so it behaves like a C-question — but leave it out and you design against an imagined number. Offer three bands drawn from your own last ten quotes, plus a fourth option reading "not decided yet", and treat that fourth answer as a kickoff-blocking gap you resolve on the call. It is the one item on the form that email will not settle.