The riskiest way to accept a design or website project is to leave every issue until the final day. At that point, the client may suddenly reject the direction, the vendor may treat “it opens” as completion, and the two sides may have entirely different expectations for content, mobile devices, the admin system, source code, and maintenance boundaries.
A more mature approach is staged acceptance: confirm the requirements and scope, structure and prototypes, visual direction, full design, development functionality, production environment, and final assets separately. Each confirmation should correspond to reviewable deliverables and a written record.
01 Align on Four Concepts Before Acceptance
Concept | Meaning |
|---|---|
Stage confirmation | Confirms the direction and scope of a stage so the project can move to the next stage |
Testing | Identifies functional, compatibility, performance, security, and content issues |
Launch acceptance | Confirms that the production environment meets the agreement and can be released publicly or put into use |
Final delivery | Confirms that source files, source code, accounts, documentation, training, and maintenance boundaries have been handed over |
“The client has seen it” does not mean “the client has accepted it,” and “launched” does not mean “all assets have been delivered.” The contract, requirements confirmation, quotation, and stage-approval records should form a consistent chain of evidence.
02 Stage One: Requirements and Scope Acceptance
Before design begins, the subject of acceptance is not the interface but both parties’ understanding of the project boundaries. Without confirmed scope, every later revision can become a dispute over whether it was part of the original requirements or a new request.
- □ Project goals, target users, and success criteria are clear;
- □ The scope of pages, templates, features, languages, and devices is clear;
- □ Responsibilities for design, development, content, photography, SEO, and deployment are clear;
- □ Exclusions, third-party costs, and external dependencies are clear;
- □ Deliverables, file formats, source code, and account scope are clear;
- □ The project schedule, client feedback windows, and delay rules are clear;
- □ Revision rounds, direction resets, and the new-requirement process are clear;
- □ Payment milestones correspond to the accepted deliverables at each stage.
03 Stage Two: Information Architecture and Prototype Acceptance
Prototype acceptance focuses on page structure, user flows, information priority, and exception states—not colors and fonts. Confirming this stage before visual design can significantly reduce the cost of overturning layouts later.
Review Item | Acceptance Question |
|---|---|
Page structure | Do the navigation, hierarchy, and page relationships cover the requirements? |
Critical tasks | Can users complete core tasks such as submitting an inquiry, registering, purchasing, or applying? |
Content priority | Are the hero section, headings, supporting evidence, and CTAs ordered appropriately? |
Roles and permissions | Do different users see the correct content and have the correct actions available? |
State coverage | Have empty, loading, success, failure, unauthorized, and exception states been considered? |
Mobile logic | Are navigation, tables, forms, and actions usable on small screens? |
Scope alignment | Do the prototype pages and features match the requirements list? |
04 Stage Three: Visual Direction Acceptance
The visual direction is usually validated through the home page or a core page first; completing every page at the outset is not recommended. During acceptance, distinguish brand-direction issues from local detail issues. Once the direction is confirmed, subsequent pages expand from that system. Selecting a completely different direction afterward should be handled as a change request.
- □ The visuals align with the confirmed brand positioning and audience;
- □ The Logo, colors, typography, imagery, and graphics are used consistently;
- □ The information hierarchy is clear, and emphasis does not rely on decoration;
- □ Critical CTAs, forms, and action states are clear;
- □ Contrast, font sizes, target areas, and keyboard operation meet project requirements;
- □ The design can accommodate common screen sizes and content lengths;
- □ Licensing for the fonts, images, icons, and assets used can be documented.
05 Stage Four: Full UI and Design System Acceptance
Acceptance Scope | Specific Criteria |
|---|---|
Complete pages | The page inventory, modals, empty states, error states, and responsive versions are complete |
Consistent components | Buttons, forms, navigation, cards, tables, and feedback states are consistent |
Content adaptability | The design can accommodate short and long copy, numbers, English, multiple languages, and real data |
Interaction annotations | Hover, click, disabled, loading, animation, and navigation behavior is clearly documented |
Development-ready | Dimensions, spacing, variables, components, and assets can be read and used by developers |
File management | Pages, components, versions, and names are clear, with no obsolete drafts mixed in |
Asset export | Icons, images, fonts, and motion files are organized as agreed |
06 Stage Five: Development and Functional Acceptance
Development acceptance should be based on the test environment, requirements list, and acceptance test cases—not just observation during a vendor demonstration. The client should complete core flows with real accounts, real content, and different devices.
Test Type | Focus |
|---|---|
Functional testing | Whether each feature, button, form, flow, and state meets the requirements |
Roles and permissions | Whether data access and action permissions are correct for each role |
Compatibility testing | Whether the agreed browsers, operating systems, resolutions, and devices are supported |
Responsive behavior | Whether layouts and interactions work properly on desktops, tablets, and phones |
Content testing | Whether real copy, images, attachments, and data are correct |
Integration testing | Whether payment, email, CRM, maps, customer service, and other integrations succeed and can recover from errors |
Exception testing | How the system handles network loss, duplicate submissions, timeouts, failures, and boundary data |
Regression testing | Whether fixes affect other functionality |
07 Classify Defects Instead of Mixing All Issues Together
Level | Example | Recommended Action |
|---|---|---|
P0 Blocker | System unavailable, critical data loss, or a severe security issue | Do not launch; address immediately |
P1 Critical | A core flow cannot be completed, payment or forms fail, or primary devices are unusable | Must be fixed before launch |
P2 Moderate | A non-core feature fails, a localized compatibility issue occurs, or a clear visual error appears | Fix within the agreed timeframe |
P3 Minor | Small spacing issues, noncritical copy, or optimization suggestions | May be added to a later optimization backlog |
New requirement | A new page, feature, or direction outside the previously confirmed scope | Evaluate as a change request, not a defect |
Defect levels must be standardized within the project; the table provides only general guidance. Risks involving security, privacy, payments, and data should be assessed by the relevant specialists rather than determined through visual acceptance alone.
08 Content and SEO Acceptance Before Website Launch
- □ Page titles, descriptions, H1 headings, and body copy align with each page’s subject;
- □ The production domain, HTTPS, canonical tags, and redirects are correct;
- □ robots.txt and the sitemap align with the indexing plan;
- □ Important URLs from the old site are mapped to avoid large numbers of 404 errors;
- □ Navigation, breadcrumbs, in-text links, and related-content links work;
- □ Image compression, dimensions, alt text, and lazy loading are appropriate;
- □ Form submissions, thank-you pages, and conversion tracking work;
- □ Social-sharing titles, descriptions, and images are correct;
- □ Test pages, demo content, and invalid accounts are not public;
- □ Search Console, analytics, and error monitoring are configured.
09 Performance, Accessibility, and Security Acceptance
Area | Minimum Checks |
|---|---|
Performance | Hero content, images, fonts, scripts, caching, and performance on mobile networks |
Accessibility | Heading hierarchy, keyboard operation, focus, form labels, contrast, and alternative text |
Security | HTTPS, permissions, dependencies, backups, logs, vulnerabilities, and secret management |
Privacy | Purpose of data collection, consent, third-party scripts, and deletion or opt-out methods |
Reliability | 404/500 errors, exception messages, monitoring, recovery, and backup drills |
Automated tools can identify some issues, but they cannot replace testing on real devices, manual task testing, security reviews, or business acceptance. Each project should determine testing depth based on its industry risk.
10 Launch-Day Check Sequence
Time | Action |
|---|---|
Before launch | Back up the existing website and database; confirm the rollback plan and responsible parties |
During cutover | Deploy the production environment, domain, certificate, configuration, and data |
One hour after cutover | Check the home page, core pages, forms, payments, login, and integrations |
24 hours after launch | Review error logs, crawling, indexing, traffic, and conversions |
Seven days after launch | Address real-user issues, missing redirects, and performance anomalies |
30 days after launch | Review SEO, leads, content, maintenance, and next-stage requirements |
11 What Final Delivery Must Include
- □ Final design source files, component libraries, icons, images, and motion assets;
- □ Front-end code, back-end code, configuration, database scripts, and build instructions;
- □ Access to code repositories, domains, servers, the CMS, and third-party accounts;
- □ Deployment, environment variable, integration, data structure, and maintenance documentation;
- □ A licensing inventory for fonts, images, plugins, and third-party assets;
- □ Website content, data, attachments, and backups;
- □ Administrator training, operating manuals, and FAQs;
- □ A list of unresolved issues, known limitations, and future optimizations;
- □ The scope, term, response method, and exclusions for complimentary maintenance;
- □ Final acceptance documentation and the conditions for payment and copyright transfer.
12 A Simplified Acceptance Record Template
Field | Information to Enter |
|---|---|
Acceptance stage | Requirements / prototype / visual design / UI / development / launch / delivery |
Corresponding version | File name, link, submission date, and version number |
Basis for acceptance | Contract, requirements confirmation, page or feature list, and test cases |
Accepted items | Confirmed deliverables |
Items requiring correction | Issue, severity, owner, and deadline |
New requirements | Items to be evaluated separately |
Acceptance decision | Accepted / conditionally accepted / not accepted |
Approvers and date | Written confirmation by the responsible representatives of both parties |
13 The Five Most Common Causes of Acceptance Disputes
- The contract says only “design and development complete,” with no deliverables list or standards;
- Multiple client stakeholders give separate feedback, with no unified decision or stage approval;
- Direction resets, content additions, and new features are all treated as bugs;
- Only the customer-facing pages are accepted, while the admin system, accounts, source code, and data are not checked;
- The sequence for final payment, copyright, source files, and launch conditions is not clearly defined.
14 Final Principle: Acceptance Criteria Must Be Observable and Recordable
“Premium,” “attractive,” “fast,” and “a good experience” are not sufficiently clear acceptance criteria. They should be translated into pages, features, states, devices, files, data, and specific review actions. Brand and visual judgments that cannot be quantified should also be managed through confirmed directions, references, proposal rationale, and written approval from the decision-maker.
Frequently Asked Questions
Does launching a website mean acceptance is complete?
Not necessarily. Launch acceptance and final asset delivery may be separate milestones and should follow the contract and acceptance form.
Can a client demand a complete redesign during acceptance?
If the deliverables do not meet the confirmed requirements, they should be corrected. If the request reflects a new preference or added scope after the direction was confirmed, it should be evaluated through the change-control process.
What does complimentary maintenance typically include?
It typically covers bug fixes and compatibility issues within the delivered scope. It does not automatically include new features, redesigns, third-party changes, or problems caused by client modifications.
How can a company accept a website without technical specialists?
It can perform business acceptance using the requirements list and real-world tasks, then engage independent technical, security, or SEO specialists to review high-risk areas.
How quickly should acceptance issues be fixed?
The schedule should reflect severity, complexity, and the project agreement. Blockers and critical issues generally require priority attention, while minor issues can be scheduled.
Service | View |
|---|---|
Corporate Website Design and Development | |
UI/UX Design Services | |
Project Consultation |
