What to Expect When Working with a Web Designer

By Kootenay Made Digital · Updated May 8, 2026

Process map

A good website project has a trail, not a fog bank with invoices.

First conversation

A plain talk session about the business, customers, location, pressure points, current website problems, goals, and whether a new site is actually the right move.

Scope and proposal

The designer turns the conversation into pages, deliverables, timeline, price, responsibilities, exclusions, revision rules, and the decision needed to start.

Content gathering

Logo files, photos, service details, proof, contact details, hours, FAQs, team notes, policies, and local details get collected before the build starves.

Design direction

The visual system takes shape: homepage direction, typography, layout, tone, call-to-action placement, proof, mobile rhythm, and the trust signals that matter.

Build and test

Approved design becomes the real site. Forms, responsive layouts, links, metadata, accessibility basics, page speed, images, and launch details get checked.

Launch and support

The site goes live with a handoff, ownership clarity, update path, support boundaries, and a plan for seasonal changes or business updates after launch.

The short version

A website project should move through discovery, scope, content, design, build, revisions, launch, and support without mystery.
Your job is not to know code. Your job is to provide business facts, customer insight, proof, priorities, and clear feedback.
The biggest delays usually come from missing content, unclear approval, vague feedback, hidden scope, or public business details that do not match.
Good designers explain technical decisions in plain language and protect mobile, accessibility, search basics, forms, and launch hygiene.
For Kootenay businesses, local context matters: towns served, seasonal hours, photos, road and weather realities, service area, and how people actually choose.

Hiring a web designer should not feel like handing your business to someone behind a curtain. A good project is structured, practical, and surprisingly calm. You should know what is happening, what decision is needed, what is waiting on you, and what will be true when the site goes live.

The designer is not there to make you speak technical. The designer is there to translate your business into a website that customers can understand, trust, and use. That means design, yes. It also means content structure, mobile behaviour, search foundations, accessibility basics, calls, forms, Google profile alignment, and the dull launch details that keep the machine from coughing blood in public.

The real partnership: you know the business, the customers, the objections, and the work. The designer knows how to turn that into a digital path people can follow without getting lost.

Client prep checklist

You do not need everything perfect. You do need the raw material.

Business name, tagline, phone, email, address, service area, hours, and any seasonal or appointment rules.

A short explanation of what the business does, who it helps, and which work or products matter most.

Main services, packages, menus, treatments, rooms, product categories, or booking types with enough detail to explain value.

Current logo files, brand colours if they exist, social links, Google Business Profile link, and any printed materials still in use.

Real photos: storefront, team, work, products, rooms, food, vehicles, views, job sites, clinic rooms, or customer experience.

Proof: reviews, testimonials, before and after examples, certifications, associations, media mentions, guarantees, or local partnerships.

Competitors or peers you admire, plus what you do not want the site to feel like.

The top customer questions you answer before someone buys, books, calls, visits, or asks for a quote.

The main action visitors should take: call, book, reserve, request a quote, visit, order, join a list, or ask a question.

Any tools the site must connect to: booking, payment, newsletter, forms, maps, analytics, calendars, reviews, Shopify, or a CRM.

Known constraints: budget, launch deadline, staff availability, photo gaps, old domain access, hosting access, or approval requirements.

After-launch needs: who updates hours, seasonal notices, products, menus, staff, events, policies, photos, and support requests.

You do not need every sentence written before the first call. You do need enough raw material to stop the project from becoming guesswork. If the designer has to invent your services, your proof, your hours, your service area, and your customer questions, the site will sound like a mannequin wearing your jacket.

For a local business, good prep is rarely fancy. It is often a folder of photos, a notes document with services, a list of customer questions, screenshots of sites you like, a Google profile link, and honest answers about what the current site fails to do.

Discovery to support

Discovery, design, build, revision, launch, and support all have different jobs.

Discovery

Clarify the real job of the website. For a Castlegar contractor, that might be better quote requests. For a Nelson cafe, it might be hours, menu clarity, and reservation confidence.

Design

Translate the business into a visual direction people can trust. Good design should make the offer clearer, not just make the page prettier.

Build

Turn approved design into working pages, mobile layouts, forms, metadata, image treatment, performance hygiene, accessibility basics, and conversion paths.

Revision

Use focused feedback rounds to correct details, tighten language, adjust layout, improve proof, and remove anything that creates confusion or friction.

Launch

Connect the domain, confirm HTTPS, test forms and links, check key mobile pages, verify business facts, and make sure public channels tell the same story.

Support

Define what happens when hours change, staff changes, the menu changes, services shift, products sell out, bookings break, or a seasonal notice needs to go live.

Discovery is where the project becomes a map. Design is where the map gets visual. Build is where the site becomes real. Revision is where the rough edges get sharpened. Launch is where public details must agree. Support is where the site survives contact with the actual business.

That last part matters. A site is not finished just because it is live. Restaurants change hours. Contractors add services. Clinics change practitioners. Guides adjust seasonal trips. Retailers move products. Tourism operators deal with weather, smoke, roads, and availability. A sane support path keeps the website current instead of slowly turning into a fossil.

What the designer handles

You bring the business knowledge. The designer should carry the technical weight.

Technical setup

Hosting, domain coordination, HTTPS, deployment, redirects, forms, email delivery checks, image sizing, metadata, and basic analytics setup where included.

Mobile and accessibility

Responsive layouts, readable text, tap targets, keyboard paths, form labels, contrast, and content that does not collapse on small screens.

Search foundations

Clear titles, headings, internal links, crawlable pages, useful content structure, local facts, and no keyword-stuffed garbage wearing a name tag.

Launch safety

Final checks, rollback awareness, contact path testing, Google profile alignment, ownership notes, support handoff, and the first post-launch cleanup list.

What you should not have to decode

You should not need to become fluent in hosting, DNS, SSL, Core Web Vitals, schema, responsive breakpoints, redirects, browser security, form delivery, or metadata. You should know who owns the accounts, what the site is supposed to do, how to request changes, and what the designer is checking before launch.

A good designer explains technical work through business impact. Mobile layout matters because customers are checking you from a phone. Page clarity matters because people are impatient. Accessibility matters because real people use different devices, vision, motor control, and attention. Search foundations matter because Google and customers need to understand what you do.

Feedback rules

Clear feedback moves the project. Vague feedback feeds the swamp.

Batch the feedback

One organized note beats twelve scattered texts. Gather comments from every stakeholder, remove duplicates, then send the designer one clean list.

Name the problem

Say what feels wrong and why. Too formal, hard to read, wrong customer, weak call button, missing proof, or not local enough are useful signals.

Separate taste from function

Preference matters, but it is not the same as a business problem. A section can be your least favourite and still be doing the job.

Use customer language

Frame comments around what visitors need to understand. That keeps the project from becoming a committee fight over favourite colours.

Protect the scope

New pages, new features, booking tools, copy rewrites, and fresh integrations may be good ideas. They still need scope, timing, and price clarity.

Choose one final voice

A project needs one decision-maker. Input is welcome. Chaos is not. Someone has to make the call so the site can leave the cave.

Bad feedback: make it pop. Better feedback: the page feels too polished for our trail guide business, and the book now button disappears on my phone.

Feedback is where many projects get weird. The goal is not to win a taste debate. The goal is to make the website more accurate, more useful, and more persuasive for the right customer.

If three people are reviewing, collect their notes before sending anything. If something feels wrong, name the business reason. If a request adds a new page, feature, integration, or full copy rewrite, call it what it is: a scope decision. The little monster is easier to control when it has a name.

Kootenay business context

A local website should account for town, season, service area, and how people actually choose.

Trades and home services

Service area, quote process, before and after proof, seasonality, drive time, job size, emergency rules, and towns served matter more than glossy filler.

Restaurants, cafes, and food businesses

Hours, menu accuracy, patio status, reservations, takeout, accessibility, parking, holiday updates, and current photos decide whether people visit or keep scrolling.

Tourism, rentals, and guides

Visitors need dates, availability, meeting points, weather or smoke policies, road access, what to bring, cancellation rules, and confidence on mobile signal.

Clinics and wellness providers

Services, practitioner fit, privacy expectations, booking path, accessibility, location details, intake steps, and trust signals should be calm and easy to understand.

Retail, artisans, and product brands

Inventory, pickup, shipping, market schedule, product photos, story, local proof, and gift or seasonal demand should shape the site before decoration does.

Regional service businesses

Castlegar, Nelson, Trail, Rossland, Creston, Nakusp, Cranbrook, Christina Lake, and Kootenay Lake customers do not all use the same route to trust.

Kootenay context changes the project. A Trail clinic, Rossland guide, Nelson restaurant, Castlegar contractor, Christina Lake rental, Creston farm shop, and Kootenay Lake accommodation do not need the same website dressed in different boots.

The designer should ask about how people find you, where they travel from, what seasons change demand, which towns you serve, what customers worry about before contacting you, and what proof actually closes the gap. That is not decoration. That is how the site becomes useful.

Source ledger

The process is human, but the standards are not made up in a coffee line.

Google Search Central: SEO Starter Guide

Google frames useful sites around crawlable pages, clear titles, descriptive headings, helpful content, internal links, images, and pages that make sense to people first.

Google Search Central: page experience

Google points site owners toward Core Web Vitals, HTTPS, mobile usability, avoiding intrusive elements, and a page that helps visitors complete the task they came for.

Google Business Profile help

A launch handoff should not stop at the website. Business hours, phone numbers, photos, services, and website links should stay aligned with public Google profile details.

Google Search Central: LocalBusiness structured data

Google documents local business fields such as address, phone, opening hours, geo, departments, and location details, which helps explain why accurate business facts matter.

WCAG 2.2 quick reference

Accessibility basics affect real people: contrast, labels, keyboard access, focus states, form errors, text alternatives, headings, and readable content.

Government of British Columbia: emergency info

Kootenay businesses that deal with smoke, road closures, seasonal access, or sudden operation changes need a practical update pattern before the notice is urgent.

What a healthy launch handoff includes

A proper handoff should leave you with a live site, working forms, tested key links, mobile confidence, ownership clarity, and an update path. If you use Google Business Profile, booking tools, social profiles, directories, or printed material, the public details should match the website.

The handoff should also explain what happens next. Who handles text changes? Who updates hours? What if a form breaks? What if you need a smoke closure notice, holiday hours, or a last-minute booking change? Launch without support clarity is just a grand opening with the keys tossed into the snow.

Want the full KMD version?

Our process page shows how a local website project moves from first conversation to launch without turning into a mystery box.

Read the process →

What to fix first

If the project feels stuck, fix the decision leaks in this order.

Scope clarity

Confirm what is being built, which pages are included, what is excluded, who approves, and what decision unblocks the next stage.

Business facts

Fix phone, email, address, hours, service area, booking rules, team names, pricing context, and current offers before debating visual polish.

Content gaps

Find missing service details, FAQs, policies, process notes, bios, product descriptions, menu details, and proof that the page needs to make sense.

Photo and proof gaps

Choose the strongest current photos, reviews, examples, credentials, local references, project proof, and trust signals for the first decision points.

Primary action

Decide whether the site is trying to create calls, bookings, visits, quote requests, orders, reservations, audit leads, or support requests.

Mobile path

Test the main action on a phone. If a thumb cannot call, book, map, submit, or read without hunting, the page is not ready.

Public alignment

Match website facts to Google Business Profile, social profiles, booking tools, directories, printed material, and any existing campaign pages.

Support path

Before launch, decide who handles updates, what counts as urgent, how requests get sent, and what happens when the business changes.

If a project feels stuck, do not start by changing fonts. Find the blocked decision. Is the scope unclear? Are the photos missing? Is the main call to action undecided? Are three people giving conflicting feedback? Is nobody sure who owns the domain? Fix the decision leak first. The design work gets calmer after that.

One afternoon triage

You can make the project easier before dinner.

Hour 1

Gather the raw materials: logo, photos, service list, hours, contact details, reviews, current website link, Google profile link, and every must-answer customer question.

Hour 2

Mark the gaps. What is missing, stale, wrong, unclear, or trapped in your head instead of written where the designer can use it?

Hour 3

Choose priorities. Pick the main visitor action, top services, most trusted proof, local context, and the pages that must exist for launch.

Hour 4

Send one clean package. Include questions, constraints, deadlines, and decision-maker notes so the designer does not have to excavate the project with a spoon.

When the project is not ready yet

Sometimes the best designer response is not a proposal. It is a cleanup list. If your business facts are outdated, photos are missing, services are changing, nobody can access the domain, or the decision-maker is not available, starting immediately can create more waste than progress.

That does not mean you are stuck. It means the first move is prep. Collect the essentials, decide the primary action, confirm ownership, gather proof, and write down the questions customers ask before they trust you. Once those pieces are visible, the project has traction.

The clean rule: if a decision changes the scope, timeline, price, ownership, or launch risk, get it written down. Villains love ambiguity. Projects do not.

If you are deciding whether the site needs a refresh or a full rebuild, read our guide to website refresh versus full rebuild. If the main question is budget, start with what a website should cost. If you need to understand the offer side first, see KMD website services.

Written by

Kootenay Made Digital

We build websites, local presence, and calm AI setups for Kootenay small businesses. No jargon, no agency fog, no surprise fees. Just clear work that makes you easier to find and easier to choose.

About Process

Frequently asked questions

What should I prepare before working with a web designer?

Prepare your business facts, best photos, logo files, contact details, service list, rough page list, strongest proof, and the main action you want visitors to take. You do not need a polished brief. You do need enough truth for the designer to build around.

Do I need to know what design style I want?

No. You only need to describe the business, the customer, and what feels wrong with the current online presence. A good designer can translate that into direction, then use the first design pass to give you something concrete to react to.

How long does a small business website project usually take?

A simple site can move in a few weeks when scope, content, and feedback are ready. Larger builds take longer because there are more decisions, pages, integrations, photos, revisions, and launch checks. The proposal should state the expected timeline and what can slow it down.

What does discovery mean?

Discovery is the first serious map of the project. It covers goals, customers, offers, pages, competitors, local context, proof, content, functionality, budget fit, timeline, and what success should look like after launch.

What should be included in the proposal?

The proposal should name the scope, pages, deliverables, timeline, responsibilities, revision process, price, payment schedule, what is excluded, what happens after launch, and what decision is needed next. Vague proposals create expensive fog.

How many revision rounds should I expect?

The proposal should state this clearly. Many small business projects work well with two focused rounds, but the important part is not the number. The important part is consolidated feedback, one decision-maker, and knowing what counts as a revision versus a new request.

What is good feedback during design?

Good feedback names the issue, the business reason, and the preferred direction. Instead of saying make it pop, say the page feels too formal for our restaurant and the reservation button needs to be easier to find on mobile.

What if I have no photos?

Tell the designer early. The right move may be a quick photo plan, a focused shot list, temporary placeholders, or simple image direction for staff. Real photos usually build more local trust than generic stock images, especially for Kootenay shops, clinics, trades, food businesses, and tourism operators.

Do I need to understand hosting, DNS, SSL, accessibility, or SEO?

No. You should not need to manage the technical layer. You should understand the plain-English choices: who owns the accounts, what gets launched, how visitors contact you, how updates happen, and which standards the designer is checking.

What should happen on launch day?

Launch day should include final content checks, mobile checks, form tests, link tests, analytics or conversion checks where relevant, domain and SSL confirmation, Google profile alignment, backup or rollback awareness, and a clear support path.

What support should I expect after launch?

You should know who handles edits, how requests are sent, what response time to expect, what is included, what costs extra, and how urgent changes are handled. A calm support path matters when hours change, staff changes, menus change, booking breaks, or smoke and weather notices need to go live.

What are red flags when hiring a web designer?

Watch for no clear scope, no written proposal, unclear ownership, no mobile plan, no content plan, no revision boundary, no launch checklist, no post-launch support path, and design that looks pretty but ignores calls, forms, Google visibility, accessibility, and the local customer journey.

Pick the weapon. Build the revenue path.