What to prepare before hiring a web designer

The one paragraph everything else hangs on

Before anything else, write one paragraph: what you do, who you do it for, and what makes somebody choose you over the obvious alternative. Plain language, no marketing register.

This paragraph becomes the homepage headline, the meta description, the social preview, and the opening of every service page. Written badly, it makes all of those weak at once. Written well, most of the rest of the site follows from it.

Decide the pages before you look at designs

The page list is the highest-leverage decision in the project and the one most often made by default. Choose it from the questions people actually ask you, not from a template.

For each page, write the single sentence describing what it exists to do. If you cannot write that sentence, the page probably should not exist — and if two pages produce the same sentence, they are one page.

Gather assets in the state they are actually in

Perfect assets are not required. Present ones are. Collect what exists now rather than waiting for a photoshoot that keeps slipping.

• Logo files, ideally vector, but a large PNG will do
• Brand colours, or an existing thing you want colours pulled from
• Photos of real work, premises, or people — imperfect real beats polished stock
• Any existing copy: brochures, proposals, even long emails you have sent prospects
• Testimonials with permission to publish them and a real name attached
• Logins for your domain registrar and any existing hosting

The credentials conversation, held early

Find out now who controls your domain. Not who set it up — who can log in today. Surprisingly often the answer is a former contractor, a nephew, or nobody at all, and discovering that on launch day turns a one-hour task into a multi-week recovery.

If the domain is registered to someone else, fix that before the build rather than after. A domain in your own name in your own account is the one asset that makes everything else recoverable.

Two or three examples, and why they help

Send two or three websites you like, with a sentence each on what specifically you like about them. "This one, because the pricing is clear without scrolling" is worth more than a page of adjectives.

Examples of sites you dislike are equally useful, for the same reason. Both narrow the space faster than any amount of describing a feeling, and they prevent the expensive version of this conversation, which happens after a design already exists.

Agree how feedback will work

Revision rounds exist to protect the timeline for both sides. The failure mode is not too much feedback — it is feedback arriving in a trickle, one thought at a time over a week, with each note restarting work that had just been finished.

Batch it. Look at the whole preview, collect every change into one list, send it once. Most projects that include two revision rounds finish comfortably within them when feedback is batched, and blow through them when it is not.

What you do not need to prepare

The list above is short on purpose, and it is worth naming what is not on it — because waiting on these is how projects lose weeks for no benefit.

You do not need finished copy. A structure with prompts per section is far easier to write into than a blank document, and that structure only exists once the build has started. You do not need a professional photoshoot; real photographs of real work outperform stock, and better ones can be swapped in after launch without touching the layout.

You do not need to have chosen a colour palette, picked fonts, or decided anything about the design. Those are decisions the build is for. And you do not need to know what your competitors are doing — a couple of examples you like says more about what will suit you than any competitive survey.