Client onboarding checklist for web designers

Why onboarding is a design deliverable

Onboarding is not admin busywork—it is the phase where scope, narrative, and constraints become shared reality. Weak onboarding shows up later as scope creep, surprise stakeholders, brand files that arrive after launch, or analytics tags that nobody owns. Strong onboarding compresses uncertainty early, when changes are cheap. For freelance designers and agencies alike, the kickoff is also where you train clients how to work with you: structured communication, clear approvals, and respect for boundaries. Treat onboarding as product design for the relationship, not as paperwork you rush through between sales and pixels.

The checklist mindset is simple: every item should map to a decision you must make before visual design locks, or to risk you cannot afford to carry silently. If an item does not change how you design, research, or sequence work, cut it. If skipping an item creates a predictable failure mode—like building a marketing site without agreed primary conversion—keep it mandatory. This discipline keeps your process lean without becoming naive about real-world messiness.

Phase 1 — Pre-kickoff: align commercial reality

Before you schedule a discovery workshop, confirm the commercial frame. Signed contract or statement of work, payment schedule, and change-order rules should be explicit. Capture the roster: who pays invoices, who approves creative, who owns technical DNS, and who provides legal review if applicable. For web designers, ambiguity here surfaces late as "my partner needs to see this" approvals that stall development. You are not being difficult—you are preventing invisible approvers from appearing after you have already presented final UI.

List the exact deliverables in language a non-designer understands: number of templates, responsive breakpoints you support, illustration or photography scope, motion level, and content population responsibilities. If copywriting or SEO is out of scope, say so now. If the client believes those are included, fix the mismatch before you translate brand strategy into layout. This phase is also when you set communication channels: where feedback lives, expected response windows, and how rush requests are handled. Email-only workflows fail at scale; decide whether you will use a portal, a project tool, or structured documents—then stick to it.

Pre-kickoff mini-checklist

• Contract signed; deposit received if that is your policy.
• Written scope: pages, integrations, analytics, SEO depth, and launch support.
• Named approvers and a single primary point of contact.
• Change-order process for new pages, new integrations, or new brand directions.

Phase 2 — Discovery and strategy inputs

Discovery is where you convert anecdotes into brief clarity. Start with business goals and user goals separately. A business goal might be lead generation; a user goal might be booking a call in under sixty seconds. Map audiences with enough nuance that navigation and copy can diverge where needed—especially for sites serving both consumers and partners. Ask for competitors the client respects and ones they dislike; both teach visual territory without copying. Capture brand personality on a spectrum—formal versus playful, premium versus accessible—not only adjectives but tradeoffs they refuse to make.

For web designers, information architecture belongs in discovery, not as an afterthought. Even a simple sitemap workshop prevents you from designing hero layouts before you know whether "Resources" is a hub, a blog, or both. Discuss SEO intent at the page level: which URLs must rank, which pages are support, and whether localization exists. If the client runs paid campaigns, align landing page strategy with ad groups so you are not retrofitting dedicated landers later. Summarize discovery outcomes in a short memo your client approves in writing—verbal alignment is where beautiful mockups meet surprised stakeholders.

Add one practical artifact most studios skip: a decision log. When the client chooses a navigation model, a hero emphasis, or a conversion path, record the date, the decision, and who signed off. Later, when memory diverges, you trade arguments for references. Pair that log with a simple risk register: known dependencies like legal review, procurement of stock imagery, or third-party API rate limits. Web projects rarely fail because someone forgot a shade of blue—they fail because invisible dependencies met visible deadlines. Your onboarding checklist should surface those dependencies before design hours burn.

Collaboration rituals that keep momentum

Checklists are static; projects are not. Build lightweight rituals so onboarding does not stall between heroic meetings. A weekly fifteen-minute client sync beats a monthly three-hour workshop when files and decisions need steady movement. Use async updates: what shipped, what is blocked, what you need by Friday. For web designers, blockers are often binary—no logo vector, no finalized homepage copy, no DNS access—and naming them plainly keeps emotional debates out of Figma comments. When stakeholders multiply, assign a "workflow referee" on the client side who resolves conflicting feedback before it reaches your team. That single habit can cut revision time more than any new plugin.

Internally, mirror the same clarity. Designers, developers, and strategists should share one source of truth for scope and timeline. If your studio still passes critical context through DMs, you will pay for it at QA. A portal-based onboarding flow gives everyone the same ordered tasks, the same uploads, and the same history—so account managers do not become human routers. The outcome is not bureaucracy; it is throughput. Clients feel momentum, your team protects margin, and the work stays creative because the chaos moved to a system instead of your evenings.

Phase 3 — Brand, content, and asset collection

Asset chaos is the silent budget killer. Define acceptable formats for logos—vector source files, not exported PNGs from a slide deck—and specify naming conventions if multiple sub-brands exist. Collect color values, type families, and licensing proof for web fonts. If photography is part of the brand system, clarify usage rights for web versus print and whether model releases cover digital advertising. For icon sets or illustration libraries, note edition versions so developers do not inherit mismatched glyphs.

Content responsibility must be explicit. If the client provides copy, set deadlines relative to design milestones so you are not blocking development on late paragraphs. If you provide copy support, define rounds and word counts per template. For dynamic content—team bios, case studies, product data—decide who enters it in the CMS and who validates accuracy. Designers often inherit spreadsheets that nobody validated; push for a content owner who signs off before you bind real data into components. When you centralize uploads and approvals in one client portal, you replace "I thought Jen sent the logo" with a visible checklist the whole client team shares.

Phase 4 — Technical access, hosting, and analytics

Technical onboarding separates brochure sites from serious web products. Confirm domain registrar access, DNS expectations, SSL approach, CDN usage, and whether email lives on the same DNS zone. If you are not the launch engineer, identify who merges code, who runs staging, and who performs smoke tests after deploy. Capture CMS choice and constraints: headless versus monolith, component library expectations, and whether marketing needs no-code editing at the block level. For forms, document spam protection, CRM destinations, and data residency requirements if EU or healthcare rules apply.

Analytics and privacy belong here—not after launch. Decide on GA4, Tag Manager, consent banners, and event naming so you do not rip out tracking pixels two weeks post-release. Accessibility targets should be explicit: WCAG level, keyboard expectations, and whether an audit is in scope. When clients delay access to Search Console or ad accounts, design can proceed but SEO and measurement cannot—surface that dependency early so timelines stay honest. If you want fewer access ping-pong threads, consolidate requests into a single onboarding flow clients complete step by step.

Phase 5 — UX, approvals, and design ops

Before high-fidelity design, approve wireframes or low-fidelity prototypes that map to the sitemap. Tie each major template to measurable outcomes: this landing page exists to drive demo requests; this pricing page exists to reduce sales calls. Define feedback formats: timestamped comments, Loom videos, or live workshops. Limit open-ended "make it pop" feedback by asking for problems, not solutions, and by referencing agreed strategy notes when debates drift. Version your files and freeze rounds; otherwise you will merge contradictory comments from parallel stakeholders.

Design ops for web designers also means export discipline: naming layers, documenting component states, and specifying responsive behaviors at breakpoints you actually intend to build. Developers should not guess whether the third navigation variant is exploratory or required. When you pair crisp Figma libraries with a written interaction model, engineering estimates stabilize and QA has a reference. This is where onboarding pays off in fewer build-phase surprises—because the brief, IA, and component strategy were settled before visual polish seduced everyone.

Phase 6 — Launch readiness and handoff

Launch is a product moment, not a FTP upload. Define pre-launch QA: forms, responsive checks, performance budgets, 404 behavior, redirects from legacy URLs, and search indexation plans. Post-launch, specify support windows, training for editors, and how bugs versus enhancements are classified. Handoff documents should include CMS map, component glossary, analytics verification steps, and who to call when DNS blinks at 9 PM on a Friday—because it will. A thoughtful onboarding process makes this handoff boring, which is the compliment you want.

Finally, schedule a retrospective with your internal team: what questions should become default next time? That is how checklists evolve into competitive advantage. The best web design studios do not win only on taste—they win on repeatable operations that make clients feel guided, not chaotic.

Put the checklist on rails with Fentyr

You can run this checklist in spreadsheets and email, or you can turn it into a branded client portal with structured steps, file uploads, reminders, and AI-assisted summaries that keep everyone aligned. Fentyr is built for agencies and freelancers who want onboarding to feel as polished as the sites they ship. Start your free trial and publish your first flow in minutes—then iterate as your studio matures.

For profession-specific playbooks, explore our guides like client onboarding for web designers and compare tools when you evaluate suites—see our Dubsado alternative page if you are outgrowing all-in-one CRMs but still need onboarding clarity.