What Information Does a Web Designer Need from Me?
A web designer needs clear business context, customer priorities, accurate content, useful evidence and access to the systems affected by the project.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
A web designer needs to understand your business goals, customers, services, current website, content, evidence, technical requirements and decision process. You do not need to design the solution yourself, but accurate, organised information makes discovery faster and the result more useful.
The best brief explains the problem and context without prescribing every visual detail. It gives the designer enough evidence to ask better questions.
Explain why the project is happening
Describe what has changed in the business and what the current website fails to support. Use examples: customers cannot find a service, staff cannot update prices, the site performs poorly on phones or enquiries lack essential information.
Separate required outcomes from preferences. “Customers must be able to compare three services” is a requirement. “Use three cards” is one possible design response.
Share how success will be evaluated. Choose measures the project can influence, such as task completion, qualified enquiries, form delivery or publishing time, rather than guaranteed rankings.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Describe the business accurately
Provide the official name, ownership, locations, service areas, team structure and relevant history. Explain what the business offers now and what may change soon.
Identify genuine differences from alternatives. Avoid unsupported adjectives. A named qualification, transparent process or specialist audience is more useful than “industry-leading quality”.
Mention legal, regulatory or professional requirements that affect content and approval. Name the person responsible for verifying them.
Define priority audiences
Describe the people or organisations the website should help. Include their situation, questions, constraints and level of subject knowledge. Avoid fictional personas built from assumptions when real customer evidence is available.
Explain which audiences are highest priority and which are not a fit. A site cannot give every group equal prominence without becoming vague.
Share recurring enquiry questions, objections, support needs and customer language. These are valuable inputs for navigation and content.
List services and boundaries
Provide a current service list with scope, typical process, locations, exclusions and next steps. Highlight services that need separate pages or a different enquiry route.
Explain relationships between offers. Customers may need to compare, choose a sequence or understand when one service is unsuitable.
The guide to information a business website should include can help identify missing practical facts.
Share existing content and evidence
Collect page copy, brochures, proposals, FAQs, policies, team biographies, project records, approved testimonials and photographs. Mark what is current and who owns it.
Do not expect the designer to infer accurate service detail from the old website. Identify known problems, contradictions and material that must not be reused.
The article on reusing existing website content explains how to evaluate rather than copy it automatically.
Provide brand assets and rules
Supply logos in suitable original formats, colour references, typeface licences, photography, icon systems and current brand guidance. State what is approved and what can change.
Share the practical origin of assets and usage permissions. A downloaded logo or image may not be suitable for web publication. Identify third-party marks with restrictions.
If no formal identity exists, say so. The project can then include a proportionate visual direction rather than pretending incomplete files form a complete system.
Explain desired tone with examples
Describe how the business should sound using meaningful contrasts, such as direct rather than playful or expert without unexplained jargon. Provide examples of existing copy that feels right and explain why.
Avoid asking to copy another company’s voice. Competitor and inspiration links can communicate preferences, but the final content and design must be original.
Identify terms the business uses consistently and claims it avoids. Include capitalisation for product and service names.
Share website examples thoughtfully
Provide a small number of websites and name the specific feature you find useful: clear service comparison, calm typography, accessible navigation or strong project evidence.
Also explain what does not work. A designer cannot reliably infer whether you like the colour, layout, tone or animation from a link alone.
Examples are discussion evidence, not instructions to copy. Your content, audience and technical constraints may require a different solution.
Give access information securely
List domain registrar, DNS, hosting, content system, analytics, Search Console, business profiles, email services and integrations. State who owns each account.
Do not send passwords in an ordinary brief or email. Use approved secure sharing and create named, limited accounts where possible. Keep ownership with the business.
Provide access early enough for discovery. Missing domain or analytics control can become a launch blocker.
Describe technical functions
List forms, bookings, payments, search, user accounts, downloads, maps, multilingual content and data feeds. Explain the business process after each action.
A form requirement includes recipients, required information, confirmation, response time, spam handling and privacy, not merely visible fields.
Name third-party suppliers and contract owners. Share documentation and test accounts securely when available.
Explain content management needs
Identify who will edit the site, how often and what they need to change. A team publishing weekly articles needs different controls from a business that updates hours twice a year.
Ask editors about their confidence, review workflow and accessibility responsibilities. Provide sample content so fields and constraints can be tested.
Do not demand unrestricted editing if it would let routine changes break layout or metadata. Good systems make common work safe and clear.
Clarify SEO and migration priorities
Share important pages, queries, backlinks, indexed content and previous SEO work. Provide Search Console and analytics access where appropriate.
Do not supply only a keyword list. Explain services, customer questions and valuable existing routes. Identify URL changes already planned.
The website replacement guide shows how content, redirects and technical checks fit together.
State privacy and compliance needs
Describe personal data collected through forms, accounts, analytics and third parties. Provide approved privacy and legal text or the responsible adviser.
Identify retention, consent and access requirements. Do not ask the designer to invent legal policy. They can implement approved decisions and flag technical questions.
Mention accessibility standards or procurement requirements that apply. Inclusive design should be planned, not added after visual approval.
Provide project constraints
State the budget range, target window, fixed deadlines and internal availability. Explain whether hosting, writing, photography, migration and maintenance are included in the expected scope.
Name constraints such as an expiring contract, campaign date or integration dependency. Distinguish a desired date from an immovable obligation.
Transparency lets the provider propose appropriate priorities rather than designing a solution that cannot be delivered.
Name decision-makers and reviewers
Identify one project owner and the people who approve content, design, compliance and launch. Explain whose decision is final when feedback conflicts.
Agree how comments will be consolidated and when they are due. Late feedback affects the timeline and may require a scope decision.
Include delivery staff early when they hold important service knowledge. Avoid inviting a new senior stakeholder only at final approval.
Prepare a concise page and content inventory
List current URLs, their purpose and the proposed action: keep, improve, merge, redirect or remove. Add important documents and media.
This inventory does not need to solve the final navigation. It reveals scale and prevents valuable material from disappearing unnoticed.
The guide to how much content a business website needs helps separate necessary coverage from avoidable volume.
What the designer should help discover
You are not expected to arrive with a finished specification. A good designer should test assumptions, identify gaps and translate business and customer needs into structure and interaction.
They should explain trade-offs and work with you to clarify requirements during discovery, asking for evidence where needed.
Be honest about uncertainty. A known question is easier to resolve than a confident but inaccurate answer.
A practical handover checklist
- Business goals and evidence of current problems.
- Priority audiences, services and customer questions.
- Existing copy, images, policies and approved proof.
- Brand assets, licences and tone guidance.
- Website examples with reasons.
- Domain, hosting and integration ownership.
- Editing, privacy and accessibility requirements.
- Budget, timetable, reviewers and approvals.
- Existing URL and content inventory.
- Known future business changes.
Provide what exists and mark gaps. Do not delay the first conversation while trying to produce a perfect brief alone.
Frequently asked questions
Do I need all the website copy before hiring a designer?
No, but content responsibilities and source information should be clear. Real content needs to enter the process before layouts are finalised.
Should I give the designer my passwords?
Use secure sharing or named accounts with appropriate access. Never place passwords in an ordinary brief.
Do I need to know how many pages I want?
An initial inventory helps, but discovery should test the final structure against services and customer tasks.
Should I provide competitor websites?
They can show market expectations and preferences, but explain what you observed and do not ask for copying.
Who should approve the website?
Name a final project owner, with specialist reviewers responsible for factual, legal or technical areas.
Prepare the information for your designer
Turn the collected information into a business website brief with scope, exclusions, responsibilities and acceptance checks.
The most useful information explains the business, customer and constraints. Organise the evidence, identify decision-makers and let the design process turn those inputs into a coherent website.
Afterworks begins website rebuilds with the existing site and business context, helping clients gather what matters without expecting them to write a complete technical specification.
