Working with a web design company goes well when the client owns the business truth, timely decisions, factual approval, and control of critical accounts while the agency owns discovery, professional recommendations, project leadership, design, development, testing, and a usable handoff. Shared decisions—priorities, tradeoffs, scope changes, and launch readiness—need one named final owner. If “everyone” owns an approval, congratulations: nobody does.
TL;DR: Do not arrive with a homemade sitemap, a preselected tech stack, and pixel instructions for a problem nobody has diagnosed. Bring the business facts, customer evidence, proof, access, constraints, and a decision-maker. Require the agency to lead the professional method, document responsibilities, explain tradeoffs, and prove what it delivered. Every dependency needs an owner, an input, a due point, and a stated consequence if it moves.
This guide begins after provider selection. If you are still comparing agencies, use our guide to choosing a web design company without getting trapped. If you are trying to understand the full buying journey, start with how to create a business website without buying the wrong thing.
Reviewed: August 2026. Conceptual review cadence: annually, or sooner if Scope Design changes its delivery process or standard project documents.
In this guide
“Good collaboration” is too vague to run a website project
Nearly every agency promises collaboration. So do group projects where one person does all the work and four people change the font at the end.
The problem is not whether people are friendly, responsive, or invited to meetings. The problem is whether the next consequential item has a clear owner. Website projects stall when content is “being worked on,” access is “with IT,” approval is “circulating,” and a new feature is “probably included.” Those phrases are project purgatory wearing business casual.
A functioning relationship answers more useful questions:
- Who owns the business decision?
- Who owns the professional recommendation?
- What evidence or access is required?
- Who can approve the answer?
- When is that decision needed?
- What changes if it arrives late?
- How will the team know the work is accepted?
This is not bureaucracy for its own sake. It is how both parties avoid paying for confusion twice.
Use the Scope Design No-Limbo Project Map
The Scope Design No-Limbo Project Map gives every important dependency four fields:
- Owner: one primary person accountable for moving it.
- Input: the evidence, access, content, or decision required.
- Due point: when it must arrive relative to the next dependent task.
- Consequence: what changes in scope, schedule, cost, or acceptance if it moves.
The key word is primary. Several people may contribute. One person still needs authority to move the item. W3C’s draft Accessibility Roles and Responsibilities Mapping decision tree uses a similar distinction: one primary owner is accountable while secondary owners and contributors support the task. The guidance is specific to accessibility, but the ownership principle travels well.
| Responsibility lane | Primary owner | Supporting role | Acceptance question |
|---|---|---|---|
| Business truth | Client | Agency investigates and challenges assumptions | Is this accurate, authorized, and commercially meaningful? |
| Professional method | Agency | Client supplies constraints and context | Is the recommendation defensible and inside the agreed scope? |
| Content truth and rights | Client unless production is scoped | Agency structures, edits, or produces as contracted | Is every claim accurate and every asset permitted for use? |
| UX, design, and technical execution | Agency | Client provides business and user evidence | Does the work solve the approved problem and meet the acceptance criteria? |
| Accounts and access | Client owns; agency accesses | Both follow security and handoff rules | Can the business operate the asset and replace the provider? |
| Tradeoffs and scope changes | Shared, with one named business approver | Agency explains effect on solution, cost, and timing | Was the changed decision documented before work continued? |
| Launch and handoff | Agency proves delivery; client accepts business readiness | Both resolve defects and assign operations | Are ownership, training, documentation, support, and ongoing care explicit? |
The map is deliberately not “client owns the what; agency owns the how” in every situation. That shorthand is useful, but reality has seams. A client owns its pricing and legal claims. An agency should still challenge whether the information is clear. The agency owns the interaction design. The client should still flag that a proposed workflow contradicts how customers actually buy. Shared context does not require shared ambiguity.
What should the client prepare before kickoff?
You do not need to do the agency’s job before the agency begins. If you could correctly diagnose the problem, map the experience, write the content, design the interface, select the technology, and test the result alone, hiring the agency would be an oddly expensive social event.
You do need to bring the things only the business can supply.
A business result, not merely a page request
Explain what needs to change in the business and why it matters now. “We need a new homepage” describes a deliverable. “Qualified prospects cannot tell which service fits them, and sales keeps re-explaining the same distinctions” describes a useful problem.
Bring whatever baseline is available:
- current inquiries, sales stages, or booked appointments;
- important entry pages and traffic sources;
- common customer questions and objections;
- services or products the business wants to prioritize;
- operational steps after a visitor acts;
- known technical, legal, timing, or staffing constraints;
- what has already been tried and what happened.
Do not invent precision because the analytics are thin. Five useful sales-call observations can be more honest than a dashboard nobody trusts.
Our constraint-first website strategy guide explains why the requested deliverable is not automatically the real constraint.
Business facts and proof
The agency cannot manufacture the truth of your business. Prepare source material for:
- services, products, pricing context, and geographic availability;
- process, timing, limitations, and right-fit or wrong-fit conditions;
- qualifications, licenses, awards, and affiliations that can be verified;
- case studies, testimonials, outcomes, and permission to use them;
- team, location, contact, support, and policy information;
- existing photography, video, diagrams, documents, and brand assets;
- legal or compliance requirements identified by qualified advisors.
The material does not need to be pretty. It needs to be real. A chaotic folder of source documents can be organized. A beautiful claim with no evidence is just well-dressed bullshit.
An honest inventory of systems and access
List the systems the website touches: domain registrar, DNS, hosting, CMS, email, forms, CRM, scheduling, payments, analytics, search tools, advertising platforms, product data, inventory, customer portals, or legacy databases.
For each system, identify:
- the business owner;
- the current administrator;
- whether access still works;
- what data enters and leaves;
- whether the system must remain, migrate, or retire;
- known vendors, renewals, licenses, and dependencies.
Do not paste a password spreadsheet into ordinary email. Use controlled access, delegated roles, or a secure credential-sharing method appropriate to the system. The client should generally keep ownership of critical accounts while granting the agency the access required to do the work.
One accountable decision-maker
Stakeholders can contribute expertise. They do not all need veto power over every heading, color, and form label.
Choose one person who can:
- consolidate internal feedback;
- distinguish mandatory requirements from preferences;
- resolve contradictory stakeholder requests;
- approve scope, content, direction, and launch;
- understand the effect of a late decision.
The executive who appears for the first time at final review and overturns three months of approved work is not adding strategic oversight. They are becoming an undocumented project dependency with excellent timing.
Real internal capacity
Name the people who will attend discovery, locate records, review content, answer specialist questions, test workflows, and approve milestones. Put that work on their calendars.
The business does not need to be available every hour. It does need to be available when the project reaches a decision only the business can make. A deadline agreed by someone with no internal time is decorative.
What should the web design company own?
Client preparation does not excuse agency passivity. “Send us everything and tell us what you want” is not a professional process. It is order-taking with a mood board.
Diagnose before prescribing
The agency should turn the business problem into a testable project definition. That means examining the audience, offer, evidence, workflows, content, current performance, technical environment, constraints, and post-launch ownership before locking in the solution.
It should be willing to say that the requested feature is not the first thing to build. Our strongest real projects have become clearer when discovery exposed operational dependencies beneath the visible website request. That is not scope inflation. Done responsibly, it is the difference between solving the system and decorating the symptom.
Define deliverables, dependencies, and acceptance
The agency should state:
- what is included and excluded;
- what each phase produces;
- what the client must supply;
- which assumptions affect the estimate;
- how review and approval work;
- what counts as a revision or scope change;
- how delays affect the schedule;
- how the work will be tested;
- what “accepted” means;
- what the client receives at handoff;
- what happens after launch.
The AIGA Standard Form of Agreement for Design Services is useful professional context because it separates proposal-specific terms, client responsibilities, deliverables, reusable designer tools, intellectual-property options, and discipline-specific terms. It is a starting point, not personalized legal advice. Significant agreements deserve review by qualified counsel.
Lead the professional method
The agency should recommend the information structure, user journeys, content approach, visual system, technology, accessibility practices, performance requirements, test plan, and release method appropriate to the approved problem.
It should explain tradeoffs in business language. “We chose this because users need X and the system must support Y” is useful. “This is the trend now” is not a reason; it is a weather report from Dribbble.
Run a visible project
The agency should make the current stage, next decision, open dependencies, and schedule effect understandable. That does not require twenty-seven dashboards. It requires one reliable source of truth and communication people will actually use.
A reasonable process includes:
- a kickoff tied to the signed scope;
- named contacts and decision rights;
- a shared place for approved files and feedback;
- milestone presentations with specific review questions;
- written decisions and changes;
- early warnings when an input threatens the schedule;
- a clear route for urgent issues;
- launch and handoff criteria.
Prove the work before calling it done
The agency should test what it built. The exact plan depends on the site, but it commonly includes responsive layouts, key browsers, navigation, forms, email delivery, integrations, accessibility, search controls, analytics, redirects, content accuracy, performance risks, permissions, backups, and rollback readiness.
W3C’s planning guidance for web accessibility recommends documenting goals, scope, responsibilities, resources, acceptance testing, milestones, and ongoing monitoring. Accessibility is not one line the client can assume the developer “handled.” Its design, content, development, testing, procurement, and ongoing publishing responsibilities need owners.
How should client and agency decisions work together?
Some decisions cannot be thrown over the wall in either direction.
| Decision | Client contribution | Agency contribution | Final authority |
|---|---|---|---|
| Business priority | Revenue, operational, customer, and organizational context | Diagnosis, feasibility, dependency, and risk analysis | Named client decision-maker |
| Messaging claim | Factual truth, proof, permission, and business commitment | Clarity, hierarchy, positioning, and user interpretation | Client approves truth; agency owns execution if scoped |
| UX direction | Real customer behavior, exceptions, and operational reality | Research, architecture, interaction design, and validation | Agency within scope; client approves material business tradeoffs |
| Visual direction | Brand truth, audience context, and constraints | Visual system, accessibility, responsive behavior, and craft | Agency within approved direction |
| Technology | Existing systems, internal capacity, ownership needs, and budget | Architecture, integration, security, maintainability, and portability analysis | Shared business decision after agency recommendation |
| Scope change | New need, changed priority, or newly discovered constraint | Impact on solution, cost, schedule, risk, and existing work | Client approves change before work proceeds |
| Launch | Business readiness, staffing, policies, and final factual approval | QA evidence, migration plan, rollback plan, and technical readiness | Named launch owner using agreed criteria |
The agency is not entitled to make unapproved business commitments. The client is not entitled to overrule professional decisions without understanding the consequence. Either party can say no. Both should be able to explain why.
How to give design feedback without becoming the designer
Open Brain contains a simple design feedback loop adapted from progressive-design material:
- Present the work.
- Gather directed feedback.
- Interpret what the feedback means.
- Decide what to change.
- Iterate.
The crucial distinction is that the client gives business and user feedback. The designer translates that feedback into design decisions.
Describe the problem you see
Useful feedback sounds like:
- “Our highest-margin service feels secondary, but it is the main reason we are investing.”
- “Customers use these two terms interchangeably, so this label may confuse them.”
- “The people approving a purchase need the certification before they will contact us.”
- “Most customers call from the job site; this action needs to work without completing a long form.”
Less useful feedback sounds like:
- “Make it pop.”
- “Can we make the logo bigger?”
- “I don’t like that blue.”
- “Move this three pixels left.”
- “My spouse prefers the competitor’s homepage.”
Preferences are allowed. Just label them as preferences. A personal reaction should not impersonate user research or a business requirement.
Match feedback to the stage
Early concept review should ask whether the team is solving the right problem and exploring the right direction. Wireframe review should focus on hierarchy, content, tasks, and flow. Visual review should evaluate brand fit, clarity, consistency, responsive implications, and accessibility. Functional review should test real tasks and edge cases.
Reopening the entire strategy during final visual polish is expensive. Arguing about button radius during discovery is merely adorable.
Consolidate before sending
The client should resolve internal contradictions before handing feedback to the agency. If sales wants prominent pricing and leadership refuses to discuss price, the designer cannot fix the organizational disagreement with typography.
Send one review containing:
- mandatory factual or legal corrections;
- unmet requirements;
- user or operational evidence;
- business-priority concerns;
- clearly labeled preferences;
- the final decision where stakeholders disagreed.
Explain why
“Change the headline” is an instruction. “The headline implies this is only for enterprise buyers, but most qualified customers are regional owner-led firms” gives the agency a problem it can solve.
The why protects the project from blindly implementing a symptom.
Does all website content need to be finished before design starts?
No. It does need an owner, a production plan, and enough real substance to shape the experience.
Early discovery and structural work can begin before every sentence is polished. The team still needs to understand:
- the main claims and offers;
- the audiences and decisions;
- the content types and approximate volume;
- available proof;
- key actions and workflows;
- required legal or policy material;
- who writes, reviews, and approves each item.
Designing an entire site around lorem ipsum and pouring real content into it at the end is how teams discover that the actual business has inconvenient things such as explanations, tables, exceptions, and customers.
Content responsibility should be explicit:
| Content task | Possible owner | Must be settled |
|---|---|---|
| Business facts and claims | Client | Accuracy, evidence, authorization |
| Content strategy and hierarchy | Agency if scoped | Audience, intent, page job, narrative order |
| Copywriting | Client, agency, or specialist | Deliverables, interviews, revision rounds, approvals |
| Photography and video | Client, agency, or specialist | Shot list, rights, formats, accessibility alternatives |
| Product or service data | Client | Source of truth, completeness, update method |
| Policies and regulated language | Client with qualified advisor | Required language and final approval |
| CMS entry and migration | Agency or client as scoped | Volume, formatting, cleanup, redirects, QA |
| Final proofreading | Client and agency roles defined in scope | Factual, editorial, visual, and functional checks |
The business remains accountable for the truth and rights behind what it publishes even when the agency writes or edits the material.
Who should own the domain, hosting, CMS, and source files?
The business should generally control the domain registration and have appropriate ownership or administrative control of hosting, CMS, analytics, search, email, and other critical business accounts. The agency should receive the access needed to perform its work, not become the only human who can reach the fuse box.
Ownership is more specific than “we paid for the website.” Separate:
- Client materials: the client’s existing brand, copy, photographs, data, trademarks, and supplied assets.
- Final deliverables: the specific designs, code, content, or configured system the agreement says the client receives.
- Reusable agency tools: frameworks, libraries, processes, utilities, and pre-existing components that may remain the agency’s intellectual property.
- Third-party materials: fonts, stock media, plugins, themes, software services, and other items governed by separate licenses.
- Working or source files: design files, drafts, repositories, raw production assets, and intermediate work that should be named explicitly rather than assumed.
An AIGA Los Angeles source-file explainer makes the practical point: finished work and source files are not automatically the same deliverable, so expectations should be discussed early and written clearly. Again, this is general business context, not a substitute for legal advice.
Our small-business website cost guide explains why ownership and exit terms belong in the cost comparison, not in a surprised email three years later.
What happens when feedback is late or the scope changes?
First: changes happen. Discovery can uncover a requirement nobody knew existed. The business can change priorities. A vendor can alter an integration. A regulator can ruin everyone’s afternoon. The goal is not to pretend change is a moral failure.
The goal is to stop pretending change has no effect.
A late dependency moves dependent work
If approved content is required before page production, a content delay affects page production. If access is required to investigate an integration, the estimate may remain conditional until access exists. If the only decision-maker disappears for three weeks, the project cannot magically preserve the same delivery sequence by glaring at the calendar.
The agency should identify the effect promptly. The client should not expect the agency to hide the delay by compressing QA or displacing other committed work.
A scope change deserves a written decision
A request may be small to say and large to implement. “Can customers just log in?” can introduce account security, password recovery, permissions, privacy, data, email, support, testing, and maintenance. The number of words in the request is not the unit of scope.
For a proposed change, document:
- the new or changed requirement;
- why it is needed;
- effect on current work;
- cost and schedule effect;
- new dependencies or risks;
- what is removed, deferred, or added;
- who approved the change.
No agency should quietly perform substantial unplanned work and unveil the invoice later. No client should expect consequential added work to materialize from the phrase “while you’re in there.”
What should you expect during the website project?
The exact phases vary, but a responsible project usually makes these jobs visible.
Discovery and definition
The team defines the business problem, audiences, evidence, current environment, requirements, constraints, ownership, measurement, and acceptance boundary. The output should be a clearer decision—not just meeting notes and a strangely confident sitemap.
Content and information planning
The team inventories current material, identifies missing proof, maps user questions and tasks, defines content ownership, and creates an information structure based on the real material.
UX and visual direction
The agency develops journeys, wireframes, components, interaction patterns, and a visual system. Reviews use stage-appropriate questions. Approvals are documented before dependent work proceeds.
Development and integration
The agency implements the approved system, migrates or enters scoped content, configures integrations, and tests assumptions against real data and workflows. Newly discovered requirements enter change control rather than sneaking into the build under a trench coat.
Quality assurance and acceptance
The team tests agreed requirements and critical tasks. The agency resolves implementation defects. The client verifies business facts, permissions, operational fit, and acceptance conditions. Testing is not a final scavenger hunt performed the night before launch.
Launch and handoff
The team confirms backups, migration, redirects, forms, notifications, analytics, search controls, accounts, documentation, training, support, and rollback readiness. The client knows who owns post-launch monitoring and maintenance.
To understand all the disciplines a complete build may include, use our guide to what website design actually includes.
Website project kickoff checklist
Use this before work begins. It is a conversation tool, not a substitute for a project-specific scope.
Business and audience
- ☐ The business outcome and current constraint are stated in plain language.
- ☐ Primary audiences, buying context, and critical user tasks are identified.
- ☐ Existing evidence, analytics, sales feedback, and known limitations are available.
- ☐ Success and acceptance are defined without invented precision.
People and decisions
- ☐ One client decision-maker has final approval authority.
- ☐ Specialist reviewers and their review stages are named.
- ☐ Feedback will be consolidated before it reaches the agency.
- ☐ Review windows and delay consequences are understood.
Content and proof
- ☐ Every content type has a writer, source, reviewer, and due point.
- ☐ Claims, testimonials, case studies, and assets have evidence and permission.
- ☐ Content volume and migration assumptions are visible.
- ☐ Legal and regulated material has an appropriate qualified owner.
Technology and access
- ☐ Domains, hosting, CMS, email, analytics, integrations, and data sources are inventoried.
- ☐ The business knows which accounts it owns.
- ☐ Access can be granted securely and removed after the project.
- ☐ Existing data, exports, and representative samples are available where needed.
Scope and delivery
- ☐ Deliverables, exclusions, assumptions, and dependencies are written.
- ☐ Revision rounds and change control are defined.
- ☐ Testing and acceptance responsibilities are clear.
- ☐ Handoff, training, warranty, support, maintenance, and recurring costs are named.
If half this list produces blank stares, pause. A kickoff meeting is not holy water. It will not bless missing ownership into existence.
Frequently asked questions about working with a web design company
What should I prepare before starting with a web design company?
Prepare the business outcome, audience context, customer questions, current evidence, services and pricing facts, proof, brand assets, content sources, system inventory, required access, internal stakeholders, one decision-maker, and realistic availability. Do not predesign the solution unless the agency specifically asks for a bounded input.
Do I need all website copy finished before design starts?
No. Discovery, content strategy, and structural design can begin before every sentence is final. The team still needs the main claims, proof, content types, approximate volume, required functionality, and a clear writing and approval plan. Detailed page design should not proceed indefinitely against imaginary content.
Who should write the website content?
The client, agency, or a specialist can write it. The scope should name who owns strategy, interviews, drafting, editing, SEO research, approvals, CMS entry, and final proofreading. Regardless of who writes, the business must approve factual claims and confirm rights to supplied material.
How involved should a client be in website design?
The client should be deeply involved in business truth, customer context, constraints, evidence, tradeoffs, and approvals. The agency should lead UX, visual, content, and technical methods within its scope. Involvement is valuable; directing every pixel is not the same thing.
How should I give feedback to a web designer?
Describe the business or user problem, provide evidence or context, distinguish requirements from preferences, explain why the issue matters, and consolidate stakeholder input. Let the designer translate the problem into design changes. Match feedback to the stage instead of reopening strategy during final polish.
How many people should approve a website design?
One person should hold final approval authority, even when several specialists contribute. Legal, sales, operations, marketing, accessibility, or executive reviewers may be necessary, but their roles and review stages should be defined. Multiple uncoordinated final approvers create contradictory direction and rework.
What happens if the client misses a feedback deadline?
The dependent work and delivery sequence may move. The scope should explain review windows, hold or rescheduling rules, cost consequences, and how work restarts. The agency should communicate the effect promptly rather than silently compressing testing or other obligations.
What counts as a website scope change?
A scope change alters agreed deliverables, requirements, content volume, pages or templates, functionality, integrations, revision rounds, acceptance criteria, schedule, or responsibilities. The agency should explain the effect and receive written approval before performing consequential added work.
Who should own the domain, hosting, CMS, and analytics accounts?
The business should generally retain ownership or appropriate administrative control of critical accounts. The agency should receive necessary access with sensible security and return or remove that access at handoff. Ownership, billing, renewals, and exit procedures should be documented.
Does paying for a website mean I own every source file and tool?
Not automatically. Client materials, final deliverables, reusable agency tools, third-party licensed components, and working/source files can have different ownership or license terms. The agreement should identify what transfers, what is licensed, what remains with the agency, and what third-party rules apply. Obtain legal advice for consequential agreements.
How many website design revisions are reasonable?
The right number depends on the project’s complexity, review stages, and how clearly decisions are made. Defined rounds with directed, consolidated feedback are usually more useful than “unlimited revisions,” which often leaves the acceptance boundary undefined. The scope should say what a revision includes and what reopens approved work.
What should be included in a website handoff?
Include the deliverables promised in the agreement, account and access status, administrator roles, documentation, training, licenses, third-party dependencies, backups, analytics and search access, source or working files if contracted, known issues, warranty terms, maintenance responsibilities, and a process for removing unnecessary agency access.
How long does a website project take?
It depends on the number of unique decisions, content readiness, stakeholders, integrations, data migration, accessibility and compliance requirements, review cycles, testing, and launch risk. Page count alone is a poor schedule model. The useful timeline identifies dependencies and decision points instead of promising a universal number.
A good web design company should make the relationship clearer
The client should not outsource accountability for its business, claims, decisions, or accounts. The agency should not outsource professional leadership back to the client.
The healthy middle is not mushy “collaboration.” It is explicit ownership with useful communication: the client brings truth, evidence, access, and decisions; the agency brings diagnosis, method, execution, testing, and handoff; both document the tradeoffs that change the project.
That is how you avoid project limbo, committee-designed oatmeal, and the final-week discovery that nobody knows who owns the domain.
If your website project is still a vague pile of pages, features, and stakeholder opinions, talk with Scope Design. We can help diagnose the actual job, define responsibilities, and turn the work into a project someone can responsibly approve and operate.
