What to prepare before hiring a web designer

Start with the job

Most businesses prepare for a website project by collecting a logo, a few competitor links, and a rough page list.

Those items help later.

The first thing a designer needs is context around the job the website must do.

A useful starting sentence sounds like this:

We need the website to help qualified SaaS teams understand our product and request a demo.

Or:

We need local customers to find the right service, trust the company, and request a quote without calling first for basic information.

Those statements give the project a direction.

Compare them with:

We need a modern website.

Modern describes taste. The business goal explains the work.

Before I start a serious website project, I want clear answers to five questions.

• Who should visit?
• What do those visitors need to understand?
• What action matters most?
• What feels weak in the current experience?
• What would make the project useful six months after launch?

The answers do not need to arrive in polished marketing language. A rough founder explanation is often more useful than a long brief filled with vague brand phrases.

The designer should help shape the structure, page plan, hierarchy, messaging direction, and visual system. The client should bring the business knowledge which only the client owns.

Gather the useful inputs

Start with the offer.

List the main services or product areas. Mark the one which matters most. Explain what buyers usually ask before moving forward. Explain where deals slow down. Explain which objections appear in sales conversations.

Next, describe the audience.

Job title alone is not enough. A founder, marketing lead, procurement manager, and local homeowner read pages in different ways because each person brings a different level of knowledge and risk.

Write down what the best buyer already knows, what still feels unclear, and what proof helps the decision.

Then gather proof.

Useful proof includes real testimonials, case studies, product screenshots, client logos with permission, certifications, process evidence, before and after examples, or real project outcomes with context.

Do not wait until the design review to mention proof. Proof changes section order and page structure.

Content also needs an owner.

Decide who writes the first draft, who supplies subject matter, who approves claims, and who signs off on the final version. Many website projects slow down because design work starts while nobody owns the words.

Gather the files and access next.

• Brand files.
• Existing copy.
• Photography.
• Product screenshots.
• Domain access.
• Current CMS access.
• Analytics access.
• Search Console access.
• Any CRM, booking tool, form destination, or tracking setup which touches the website.

Do not send passwords inside a random document. Use the proper access or invitation system for each platform.

The last preparation item is decision ownership.

One person needs final approval authority.

A project with five reviewers and no final owner turns small feedback into long revision loops. Input from several people still has value. Final responsibility needs one home.

Prepare the project inputs

A client does not need a finished sitemap before hiring a designer.

A client does not need final copy before the first conversation either.

The useful preparation sits one level above design.

• Bring the business problem.
• Bring the audience.
• Bring the offer.
• Bring the proof.
• Bring the current data where available.
• Bring the constraints.
• Bring one decision owner.

Then leave room for the designer to diagnose the website problem before prescribing pages.

I would also save a simple baseline before the project starts.

• Current qualified form submissions.
• Booked calls.
• Important page traffic.
• Search clicks.
• Top landing pages.
• Main conversion path.
• Known mobile problems.

The baseline does not need a giant dashboard. The baseline gives the new site something real to improve against.

A strong project starts when both sides bring different expertise to the same problem.

You know the business. The designer should know how to turn the business goal into structure, messaging, interface decisions, build quality, and a clear path after launch.

A good brief gives enough context for those decisions without designing the website before the designer arrives.