What Should You Give Your Web Designer Before Kickoff?

The worst kickoff folder is not an empty one. It is a crowded folder where three logos are labeled “final,” two price sheets disagree, the best testimonial has no customer permission, and nobody knows who may approve the home page. Readiness means the team can tell a fact from an idea, a current asset from an old one, and an approved decision from an open question. You are building a reliable starting point, not doing the designer's entire job before the meeting.

Give the project a business job

Start with the decision the website should improve. “We need a modern site” describes a preference, not a business job. A more useful statement might be: help commercial property managers understand which emergency services are available before they call; reduce unqualified requests for a specialized consulting service; let returning patients find preparation instructions; or recruit technicians in two new markets. Choose one primary job and up to two supporting jobs. If every goal is equally important, the design has no basis for prioritizing content.

Share the baseline even when it is incomplete. Existing analytics, call logs, booking reports, sales notes, search queries, customer emails, and staff observations can all provide context if their limits are clear. Do not manufacture a precise target because a project form asks for one. State what is currently measured, what is not, and who will decide whether the launch helped.

Describe audiences through decisions, not demographics alone

A persona that says “Jordan is 38 and likes coffee” rarely helps a service page. Tell the designer what brings a person to the site, what they already know, what they fear getting wrong, what proof they trust, what prevents action, and who else influences the purchase. Separate a buyer, end user, referrer, job applicant, existing customer, and partner when they need different information. If accessibility research or user testing is planned, include people with disabilities from the intended audience rather than treating accessibility as an automated check at the end. W3C recommends involving users early because it helps teams understand real-world accessibility issues and design more effective solutions.

• The top two or three audience groups, in priority order, with a reason for the order.
• The event or question that sends each group to the website.
• The service, location, product, resource, or task each group is trying to find.
• The objections and risks staff hear before a customer says yes.
• The proof each group accepts: credentials, process, examples, reviews, data, policies, people, or demonstration.
• The next step that is reasonable for this group, including what happens after they take it.
• Known language, device, disability, technology, or assistance needs that should inform research and delivery.

Build a service and offer source of truth

For every service or product that may appear, provide its approved name, plain-English description, suitable customer, exclusions, delivery area, process, timing range, pricing information the business is willing to publish, and required qualifications or disclaimers. Include discontinued names so the designer does not revive them from an old brochure. If departments disagree, mark the field unresolved and name the decision owner. Clear gaps are safer than confident contradictions.

Local business facts need special care because they often appear across the site, maps, directories, schema, and campaigns. Google's Business Profile guidance asks businesses to represent themselves accurately and consistently and includes specific rules for names, addresses, service areas, hours, categories, and virtual offices. Give the designer the current authoritative profile and identify who can approve changes. Do not hand over a spreadsheet of target cities as though each were a staffed office.

Bring customer language and proof

Provide real sales questions, support emails with personal information removed, estimate objections, lost-deal reasons, search terms from tools you already use, and phrases customers use to describe the problem. Then collect proof that answers those concerns: named project examples, process records, current credentials, staff expertise, original photos, customer reviews, policies, and results with a clear baseline and period. Do not rewrite everything into polished marketing language first. The designer or writer needs the raw truth behind the message.

Inventory content by status

List the current URLs and mark each one keep, rewrite, combine, redirect, archive, or undecided. For new pages, name the question or task each page should handle. Attach the content owner, reviewer, source material, status, and due date. Separate approved facts from draft copy. A designer can work with rough content when its purpose is clear, but designing around a one-line temporary stand-in and receiving 1,500 words later usually causes avoidable layout and schedule changes.

If you need a structured project narrative, pair this inventory with how to write a website design brief. The brief explains the project and its decisions; the kickoff inventory supplies the evidence and access needed to do the work. The wider hiring and project planning library keeps both connected to timelines, contracts, and approvals.

Supply brand files with names a stranger can understand

• Current logo files in suitable vector and raster formats, plus one document that identifies the approved versions.
• Brand colors with actual values, typeface names and license information, spacing or usage rules, and known accessibility concerns.
• Original photo and video files rather than compressed images copied from the existing website or social media.
• A short explanation of what must remain recognizable and what may change; “keep the brand” means different things to different people.
• Examples the team likes with a note about the specific quality—navigation, tone, photography, density, motion, or content—not a request to copy another site.
• Deprecated logos, slogans, templates, and imagery moved to an archive and labeled with the date they stopped being current.

List systems and access without sending secrets

Give the designer an account inventory: domain registrar, DNS, current platform, host, repository, analytics, tag manager, business listings, email marketing, forms, CRM, scheduling, payments, chat, maps, media, and any API or automation that touches the site. For each system, name its purpose, business owner, current administrator, plan, renewal, integration, and approved access method. Invite the provider through an official user role when possible. Share necessary credentials through an approved password manager or secure process, use multi-factor authentication, and avoid reusing a personal password.

Name accessibility, privacy, and regulated-content responsibilities

Tell the designer which laws, regulations, contracts, policies, professional rules, accessibility commitments, languages, data types, or internal reviews may affect the site. Do not ask the designer to guess whether your intake form may collect health, financial, student, employment, or other sensitive information. Identify the qualified person who approves privacy notices, terms, disclaimers, claims, record retention, consent language, and regulated content. W3C's planning guidance recommends assigning responsibilities and planning budgets, resources, reviews, testing, training, and monitoring for accessibility; those decisions belong in project planning rather than a final-day checkbox.

Set the approval map and working rhythm

Name who can approve scope, design direction, content facts, brand use, legal language, budget changes, integrations, and launch. Set one place for feedback and one person who consolidates conflicting comments. Agree on meeting cadence, response windows, time zones, planned absences, and escalation. Ten stakeholders may contribute; they should not send ten competing final answers directly to the production team.

Bring an honest gap list

Missing inputs are normal. List them by impact: launch blocker, design dependency, content dependency, later enhancement, or optional. Examples include unavailable team photography, a service name under review, a contract awaiting counsel, an integration without API access, an unconfirmed office move, or a testimonial awaiting permission. For every gap, assign an owner, next action, decision date, and fallback. This lets the project sequence around uncertainty instead of discovering it during final review.

Your final kickoff packet

• One-page project summary with primary job, supporting goals, scope, target timing, and known constraints.
• Audience decision notes, real customer questions, objections, and preferred next actions.
• Approved business, service, location, pricing, credential, team, and contact facts with owners.
• Current URL and content inventory with keep, rewrite, combine, redirect, archive, and undecided status.
• Proof register for testimonials, projects, outcomes, reviews, credentials, and permissions.
• Brand and media index showing current files, usage rules, creators, licenses, and missing assets.
• System and integration inventory with business owner, access role, plan, dependency, and renewal.
• Accessibility, privacy, legal, language, and regulated-content requirements with qualified approvers.
• Stakeholder and approval map with one final decision owner for each subject.
• Gap and risk list with impact, owner, due date, fallback, and effect on launch.
• Communication plan naming the project workspace, meeting rhythm, feedback route, and escalation contact.

Send the index before the meeting and ask the designer which sections deserve attention live. A useful kickoff should confirm goals and roles, resolve high-impact ambiguity, test assumptions, and assign the next decisions. It should not spend an hour watching someone open unlabeled files. Strong website design work begins faster when the facts are organized, but it also includes discovery that challenges those facts and turns them into a customer-centered structure.