By the Templateez Team · Licensed Attorney · June 2026

Web Design Intake Forms: What to Capture Before the First Wireframe

A web design project that starts with "just build us something modern" is a project heading for scope creep, revision spirals, and a client who is unhappy with the result despite never articulating what they wanted. The problem is not that the designer lacks talent. The problem is that no one pinned down the requirements before the work started. And by the time the client sees a homepage mockup they do not like, everyone has already invested weeks of effort that cannot be recovered.

The difference between a project that launches on time and one that drags through months of revisions almost always traces back to intake. A thorough web design intake form captures what the client actually needs, what their business is trying to accomplish, what technical constraints exist, and who has the authority to approve the final product. Here is what that form should include.

Project type: defining what you are actually building

Web design is not a single service. A new brochure site for a law firm and an e-commerce migration from Shopify to WooCommerce are entirely different engagements with different timelines, budgets, technical requirements, and risk profiles. Your intake should identify the project type immediately because it shapes every question that follows:

• New website — the client has no existing site or is starting from scratch. This is a clean-slate engagement, which sounds easier but actually requires more discovery because there is nothing to reference. You are building the information architecture, visual identity, and content strategy from the ground up. If the client also needs a logo and brand identity system, the graphic design intake guide covers those discovery questions.
• Redesign — the client has an existing site that is not working for them. The critical question here is why. Is it outdated visually? Is it not converting? Is it slow? Is it not mobile-friendly? "We need a redesign" tells you nothing about the actual problem to solve.
• Migration — moving from one platform to another. Shopify to WordPress, Squarespace to a custom build, an old PHP site to a modern framework. Migrations carry unique risks around URL structure, SEO equity, content transfer, and integration compatibility that new builds do not.
• Landing page — a focused, single-purpose page tied to a campaign, product launch, or ad spend. The scope is narrow, but the expectations for conversion performance are usually high.
• E-commerce — any project with a transactional component. Product catalog, cart, checkout, payment processing, inventory management, shipping logic. This is a fundamentally different technical scope than a content site, and your intake must branch into e-commerce-specific questions.
• Web application — a functional tool, not just a website. Client portals, dashboards, booking systems, SaaS products. These projects require technical discovery that goes far beyond design and into software engineering territory.

Business goals: what the website is supposed to accomplish

A website without a defined business goal is a digital brochure that exists because the client felt they should have one. That is not enough to design against. Your intake form needs to surface what the client expects the website to do for their business, because every design decision, page structure, and call-to-action should serve that goal:

• Lead generation — the site exists to capture contact information and drive inquiries. This changes how you design forms, CTAs, landing pages, and the overall conversion funnel.
• E-commerce sales — the site needs to sell products or services directly. Product photography, trust signals, checkout friction, and payment processing become primary concerns.
• Brand awareness — the client wants to establish credibility and presence. The emphasis shifts toward visual storytelling, content, and social proof.
• Information / resource hub — the site serves as a reference or knowledge base. Navigation, search functionality, and content organization are the design priorities.
• Portfolio / showcase — the client needs to display their work. High-impact visuals, case studies, and project galleries drive the layout.

Most clients will identify with more than one goal. That is fine. What matters is the priority ranking. A site that tries to optimize equally for lead generation, e-commerce, and brand storytelling will do none of them well.

Current web presence: understanding what already exists

If the client has an existing website, you need to understand its current state before you can plan the transition. Skipping this step leads to broken redirects, lost SEO rankings, and integrations that stop working on launch day:

• Existing domain — what domain or domains does the client own? Is the primary domain the one they want to use, or are they rebranding? Are there secondary domains that redirect?
• Current hosting provider — where is the site hosted now? Will you be migrating hosting, or does the client want to stay with their current provider? Are there contractual obligations with the current host?
• Current CMS or platform — WordPress, Squarespace, Wix, Shopify, a custom-built system, or a static HTML site from 2014? Knowing the current platform tells you what content export options exist and what migration complexity you are facing.
• Analytics and tracking — is Google Analytics installed? Google Search Console? Any other tracking tools (Hotjar, Mixpanel, Facebook Pixel)? You need access to historical data to establish baselines and preserve tracking continuity through the transition.
• Current traffic — approximate monthly visitors, top-performing pages, primary traffic sources. A site getting 50,000 monthly organic visits requires a much more careful migration plan than a site getting 200.

Design preferences: visual direction without guesswork

Asking a client "what do you want it to look like?" produces answers that are impossible to act on. "Clean and modern" means something different to every person who says it. Your intake form should structure this conversation so the design team gets actionable direction:

• Style references — ask the client to provide 3-5 websites they like and, critically, what specifically they like about each one. "I like Apple's site" is not useful. "I like how Apple uses large product photography with minimal text and lots of whitespace" gives the designer something to work with.
• Brand guidelines — does the client have an existing brand guide, style guide, or visual identity document? Logo files, brand colors, approved typography, tone of voice? If yes, request these files at intake. If no, note that brand development may need to be part of the project scope.
• Color palette — existing brand colors or color preferences. If the client does not have established colors, capture their preferences (warm vs. cool, bold vs. muted, industry-appropriate expectations).
• Typography — does the client have brand fonts, or is font selection part of the design scope? Are there accessibility requirements that influence type size and weight?
• Competitors — which competitors does the client admire visually, and which do they want to differentiate from? This dual question is valuable because "we want to look nothing like CompetitorX" is as informative as "we love what CompetitorY did."

This kind of structured creative intake is what separates professional discovery from ad hoc guesswork. Photography and videography studios face a similar challenge — translating a client's visual taste into actionable creative direction.

Content: who provides what, and when

Content is the single most common bottleneck in web design projects. The design is done, the development is done, and the site sits unfinished because no one has written the About page. Your intake form must address content ownership and timeline explicitly:

• Copywriting — is the client providing all written content, or is copywriting part of the project scope? If the client is writing their own copy, when will it be delivered? Many projects stall for months waiting on client-provided content that was never given a deadline.
• Photography and video — does the client have professional imagery, or does it need to be created? Will stock photography be acceptable? Is a professional photo or video shoot part of the project, and if so, who is coordinating it?
• Content management — who will be updating the site after launch? Does the client need a CMS they can manage themselves, or will they rely on you for all updates? This fundamentally affects platform selection and how the site is built.
• Blog or news section — does the client want a blog? How frequently do they plan to publish? Is there existing content that needs to be migrated? A blog that the client intends to update weekly requires a different CMS configuration than one that will be updated twice a year.

Technical requirements: platform, integrations, and compliance

This is where intake separates web designers from web developers, and where many creative-focused agencies leave money on the table by not asking the right questions early enough:

• CMS preference — WordPress, Shopify, Squarespace, Webflow, a headless CMS, or a fully custom build. Each has different cost, maintenance, and flexibility profiles. Some clients have a strong preference based on past experience. Others need guidance, which is itself a scoping conversation.
• Integrations — CRM (Salesforce, HubSpot), email marketing (Mailchimp, Klaviyo), payment processing (Stripe, PayPal, Square), appointment booking (Calendly, Acuity), live chat, social media feeds. Every integration adds scope, testing, and potential failure points.
• Third-party APIs — does the site need to pull data from or push data to external systems? Inventory management, shipping calculators, property listings (MLS/IDX), job boards, membership databases. API integrations require documentation, credentials, and often coordination with the third-party vendor.
• SSL certificate — required for any site processing sensitive data and expected by browsers for all sites. Is there an existing SSL, or does one need to be provisioned?
• Mobile responsiveness — this should be the default, but the intake should confirm whether the client has specific mobile requirements. Is their audience primarily mobile? Do they need a progressive web app (PWA)? Are there specific mobile interactions (click-to-call, mobile maps, app-like navigation)?
• ADA / WCAG accessibility — does the client require WCAG 2.1 AA compliance? Are they in an industry (government, education, healthcare, finance) where accessibility compliance is legally mandated? This affects design decisions, development approach, and testing scope.

Technical discovery at intake is similar to what IT support companies capture when onboarding a new client — you need the full picture of the existing infrastructure before you can responsibly plan what to build on top of it.

SEO requirements: protecting and building search visibility

A beautiful website that no one can find is a failure. SEO should be part of the intake conversation, not an afterthought bolted on after the site is built:

• Keyword targets — does the client have specific keywords or phrases they want to rank for? Have they done keyword research, or is that part of the project scope?
• Current rankings — if the client has an existing site, what are they ranking for now? Which pages drive organic traffic? A migration or redesign that ignores existing rankings can destroy years of SEO equity in a single launch.
• Google Search Console and Analytics access — request access to both at intake, not two weeks into the project. You need baseline data to measure the impact of the new site and to plan URL redirects if the site structure is changing.
• Local SEO — does the client serve a specific geographic area? Is Google Business Profile optimized? Do they need location pages? Local SEO requirements influence site structure and content strategy.
• Content strategy — is ongoing SEO content creation (blog posts, landing pages, resource guides) part of the engagement, or is the project limited to the initial site build?

Timeline, budget, and maintenance

Timeline and budget are where client expectations most often diverge from reality. A client who wants a custom e-commerce site with 500 products, three integrations, and a blog — launched in four weeks for $3,000 — needs to hear about that gap at intake, not after the contract is signed:

• Launch deadline — is there a hard date (product launch, event, seasonal campaign) or is the timeline flexible? Hard deadlines constrain scope. If the date cannot move, the feature list must.
• Phased approach — is the client open to launching a minimum viable site and adding features in phases? This is often the most practical approach for complex projects, but some clients want everything at once.
• Budget range — even a broad range ("$5K-$10K" vs. "$25K-$50K") helps you scope the project appropriately. A client who will not discuss budget at intake will not discuss it later either, and you will end up building a proposal against unknown constraints.
• Ongoing maintenance — does the client want a maintenance contract after launch? Plugin updates, security patches, hosting management, content updates, performance monitoring. Some clients expect this to be included in the project price. Establish the boundary at intake.

Domain and hosting logistics

These are the operational details that seem mundane until they block a launch. A site that is ready to go live but cannot because no one has DNS credentials has happened to every agency at least once:

• Domain registrar — where is the domain registered? GoDaddy, Namecheap, Google Domains, Cloudflare? Does the client have login credentials? Is the domain set to auto-renew?
• DNS management — who controls DNS? The client, their previous developer, their IT department? Can they update A records and CNAMEs, or will you need access?
• Email hosting — does the domain have email accounts tied to it (name@company.com)? Changing DNS without accounting for email MX records will break the client's email. This is a launch-day disaster that is entirely preventable with one intake question.
• Hosting requirements — shared hosting, VPS, dedicated server, managed WordPress hosting, static hosting (Netlify, Vercel)? Traffic expectations, storage needs, geographic requirements (server location for performance), and any compliance requirements (HIPAA, SOC 2) that constrain hosting options.

Stakeholders and the approval process

This is the section of the intake form that prevents the single most frustrating pattern in client work: building to one person's vision, only to discover at the review stage that three other people have veto power and different opinions.

• Primary point of contact — who is the day-to-day contact for questions, content requests, and feedback?
• Decision-makers — who has final approval authority? Is it the person you are talking to, or does a CEO, board, or marketing director need to sign off? If the approval authority is not in the room during intake, you are already at risk of revision loops.
• Review process — how many rounds of revisions are included? Who participates in each review? Is feedback consolidated through one person, or will you receive conflicting notes from multiple stakeholders?
• Sign-off authority — who approves the final design, the final development build, and the launch itself? Get this in writing at intake. A project that is "done" but cannot launch because the CEO has not looked at it yet is a project that is costing you money every day it sits.

Setting the engagement up for success

A web design project that begins with a comprehensive intake process is a project where the client feels heard, the scope is defined, the technical requirements are documented, and the approval chain is clear. That is the foundation for a smooth engagement — not a guarantee of one, but the closest thing to it.

The alternative is the project that starts with a handshake and a vague brief, where the designer discovers halfway through development that the client needs Salesforce integration, the CEO hates blue, and no one has written a single line of copy. That project is going to cost more, take longer, and leave everyone dissatisfied.

If you are building intake documentation across a professional services operation, the Professional Services Bundle includes web design alongside 34 other professional service categories, each with industry-specific intake fields.