B2B Website Design System Requirements Before a Redesign

Define the system your team needs to operate

A redesign can look consistent on launch day and become messy after three months of publishing. Teams create one-off sections. Developers interpret the same design in different ways. Editors use rich text to solve layout problems. New campaign pages introduce another button style because nobody knows which rule applies.

A website design system should prevent that drift. It connects brand rules, reusable interface components, CMS structures, code, tests, and documentation. Your designers, developers, marketers, and editors use the same source of decisions when they create or change a page.

Write the system requirements before you request estimates. An agency cannot scope the work from a request for “a component library” because that phrase can mean a Figma file, a coded interface library, or a complete publishing system with governance.

Use the requirements below to define the deliverable and compare proposals on the same ground.

1. Name the business and publishing problems

Start with the problems the system must solve. The list should reflect how your team sells, publishes, and maintains the website.

Common problems include:

• teams rebuilding the same section for each campaign
• brand inconsistency across product, industry, and resource pages
• developers spending time on routine layout requests
• editors choosing from components without knowing their intended use
• inaccessible interactions appearing in new page sections
• slow QA because reviewers cannot see component states in one place
• global changes requiring edits across many pages
• design files no longer matching the production website

Tie each problem to a required capability. If editors keep inventing layouts, require approved page patterns and clear component guidance. If developers duplicate code, require one production component for each approved pattern. If accessibility defects return, require documented interaction behavior and automated checks.

This step keeps the scope focused. You need the parts that support your website program, not an exhibit of every interface pattern an agency can design.

2. Set the boundaries of the design system

State which products, brands, markets, and channels the system will cover. A single B2B marketing site needs a different structure from a platform shared by several business units.

Define:

• the websites and applications in scope
• brands or sub-brands the system must support
• languages, regions, and writing directions
• teams that will design, build, publish, and approve changes
• browsers, devices, and assistive technologies included in QA
• the CMS and front-end environments the system must connect
• any existing brand assets or product libraries the website should inherit

Draw a line around the first release. Your agency can build a sound foundation and the components needed for approved templates without designing every possible future page. Record future needs in a backlog with a process for adding them.

3. Require foundations as decisions, not decoration

Foundations turn the brand into rules that designers and developers can use. They should cover more than a page of colors and type samples.

Your scope should address:

• color roles, contrast pairs, and approved usage
• typography roles, responsive sizing, and line length
• spacing and layout scales
• grids, containers, and breakpoints
• borders, radii, shadows, and elevation
• icon style and sizing
• image ratios, crops, and art direction
• motion principles and reduced-motion behavior
• content width and density
• naming conventions for design tokens

Ask the agency to define semantic tokens such as text, surface, border, action, and status roles. Semantic names let the team change a brand value without hunting through components that reference a raw color name.

Require a clear relationship between design tokens and production code. A polished token page in Figma has limited value if developers recreate the values by hand.

4. Specify page patterns before individual components

Marketing teams publish pages, not component inventories. Define the recurring page types and the jobs each page must support.

Typical B2B patterns include:

• product or service detail
• industry or use-case detail
• campaign landing page
• resource article
• comparison page
• event or webinar page
• contact or consultation flow
• legal and policy content

For each pattern, document required content, optional sections, order constraints, conversion actions, metadata, and responsive behavior. Identify where editors can choose a layout and where the system should enforce one.

Page patterns expose missing relationships. A card may need a category, image, title, summary, and link. The CMS must supply those fields. The component must handle each approved combination. The page template must know how the cards group and respond. Treat the whole path as one requirement.

5. Define every component state

A component name does not describe enough work to estimate or test it. A form, navigation menu, pricing table, or resource card can carry many states.

Require the agency to document:

• default, hover, focus, active, and disabled states
• loading, empty, success, warning, and error states where relevant
• short, long, missing, and translated content
• mobile, tablet, and desktop behavior
• keyboard interaction
• screen-reader labels and announcements
• validation and recovery behavior
• image fallback and crop rules
• combinations that the system should block

Use representative content during design. A card tested with a two-word title may fail when your actual product name takes three lines. A form shown in its success state tells you nothing about validation or a rejected CRM handoff.

The W3C Authoring Practices Guide provides behavior patterns for interactive controls such as dialogs, accordions, tabs, menus, and comboboxes. Your agency should use established behavior and test the implementation rather than adding ARIA attributes after the design is finished.

6. Connect components to the CMS model

A design system can fail inside the CMS even when the front end looks consistent. Editors need fields and controls that match the design intent.

For each component and page pattern, define:

• the content type and fields that supply it
• required and optional fields
• character guidance where layout needs it
• allowed references to products, authors, categories, or resources
• preview behavior
• validation rules
• localization behavior
• image requirements and focal-point controls
• whether editors can reorder, repeat, or hide the component

Avoid a CMS model made of generic page-builder blocks with unrestricted choices. It pushes system decisions onto each editor and makes invalid combinations easy to publish.

Controlled flexibility works better. Give editors enough range to support real campaigns while the content model protects accessibility, hierarchy, and brand rules. Test the model by asking an editor to build representative pages before development ends.

7. Put accessibility into component acceptance criteria

Accessibility belongs in the component definition. A separate audit near launch cannot repair a weak interaction model without rework.

Set acceptance criteria for:

• keyboard access and logical focus order
• visible focus treatment
• semantic headings and landmarks
• labels, instructions, and error messages
• color contrast
• zoom and text reflow
• reduced-motion preferences
• screen-reader names, roles, states, and announcements
• touch target size
• captions, transcripts, and media controls

Require manual review for interactive components. Automated tools can catch some defects, but they cannot confirm that a menu makes sense with a keyboard or that an error message helps the user recover.

Ask who owns accessibility decisions during design, development, content entry, and post-launch maintenance. The system needs a named owner and a defect process, not a compliance badge.

8. Make documentation part of the product

Documentation turns components into a working system. Without it, the team relies on whoever remembers why a decision was made.

Each component should include:

• purpose and approved use cases
• examples of when to choose another pattern
• content guidance
• available variants and states
• accessibility requirements
• CMS field mapping
• design token references
• code usage where relevant
• test coverage
• owner and change history

Tools such as Storybook can develop components in isolation, capture their variations as stories, run interaction and accessibility tests, and publish a shared reference. The exact tool matters less than the workflow. Designers, developers, QA reviewers, and content owners need one current place to inspect production behavior.

Include documentation work in the estimate. If an agency treats it as optional handoff cleanup, delivery pressure will cut it first.

9. Require testing at the component and page levels

Component tests protect repeatable behavior. Page tests catch problems that appear when several valid components share a layout.

Ask for a testing plan that covers:

• visual regression for approved states
• keyboard and accessibility checks
• interaction tests
• responsive behavior
• browser coverage
• CMS preview with realistic content
• performance impact of images, scripts, and embeds
• page-level hierarchy and spacing
• analytics events on conversion components
• form submission and CRM error states

Define which checks run in continuous integration and which require human review. Require the team to resolve failed tests before a component enters the approved library.

Your acceptance process should include representative pages, not a blank component catalog. Test a product page, resource article, campaign landing page, and conversion flow with production-like content.

10. Define governance before launch

A design system needs a way to accept, reject, and release changes. Otherwise, the first urgent campaign creates an exception that becomes permanent.

Assign owners for:

• design foundations
• coded components
• CMS schemas
• content guidance
• accessibility review
• releases and versioning
• documentation
• requests from marketing and product teams

Write a simple contribution process. A requester should describe the user need, show why an existing component cannot solve it, identify the affected pages, and provide acceptance criteria. The owner can approve a new variant, revise an existing pattern, or reject the request.

Define how releases reach production. Small fixes may ship in a patch. A breaking component change may require a migration plan for existing pages. Editors need notice when a field or pattern changes.

Governance does not need a committee for every button. It needs clear authority, a request path, and enough records to keep the system coherent.

11. Ask for handoff and ownership terms

Your contract should state what your team receives and what it can change after launch.

Require:

• editable design source files
• production source code and repository access
• token definitions
• component documentation
• CMS schema documentation
• test suites and configuration
• deployment instructions
• a list of third-party licenses and services
• training for editors and developers
• a backlog of deferred components and known limitations
• warranty or defect terms
• an ongoing maintenance model if the agency will remain involved

Clarify who owns the code, designs, documentation, and accounts. Confirm that your team can move the system to another qualified partner without recreating the work.

Ask the agency to demonstrate handoff with a real task. Have an editor build a page and a developer change a token or component state using the delivered documentation.

12. Use the requirements to compare agencies

Give each agency the same website inventory, page patterns, integration needs, team roles, and acceptance criteria. Ask proposals to separate discovery, foundations, component design, development, CMS modeling, testing, documentation, training, and maintenance.

Review the response for evidence of systems thinking:

• Does the agency connect design components to CMS fields and production code?
• Does it account for states, errors, and realistic content?
• Does it include accessibility throughout the workflow?
• Does it show how teams review components before page assembly?
• Does it define ownership and change control?
• Does it test the system with editors before launch?
• Does it explain what remains outside the first release?

A proposal centered on page count can miss the work that makes those pages maintainable. A proposal centered on a large component count can create inventory your team will not use. The right scope covers the recurring patterns, risks, and publishing work your website has to support.

A compact design system requirements checklist

Use this list in your redesign brief or RFP:

1. Business and publishing problems the system must solve
2. Sites, brands, regions, teams, and environments in scope
3. Design foundations and semantic tokens
4. Approved page patterns
5. Component variants, states, and responsive behavior
6. CMS fields, validation, and editor controls
7. Accessibility acceptance criteria
8. Component and page-level test coverage
9. Shared documentation tied to production
10. Ownership, contribution, and release process
11. Source files, code, training, and handoff
12. Deferred work and maintenance terms

Require a traceable path from design decision to code, CMS field, test, and documentation. That path gives your team a practical way to keep the site consistent as campaigns and content change.

Frequently asked questions

How many components should a B2B website design system include?

Build the components required by approved page patterns and conversion flows. Component count makes a poor target because one well-defined component can cover several use cases, while a large library can create duplicate choices. Start with real content and add variants when a documented need appears.

Is a Figma library a complete design system?

A Figma library covers design assets and rules. A working website system also needs production components, CMS relationships, accessibility behavior, tests, documentation, ownership, and a release process. The design file and the live website should use the same tokens and component definitions.

Should the agency build the design system before the website pages?

The agency should define foundations and core components before it builds every page, then test them inside representative page patterns. This sequence exposes missing states and CMS requirements while the team can still revise the system without rebuilding the whole site.

Who should own the design system after launch?

Assign one accountable owner with support from design, development, content, and accessibility leads. The owner controls changes, keeps documentation current, and routes requests. Name this role before handoff so the system does not become an unowned project file.

Scope the system before production starts

Virdis designs and develops custom B2B websites with the component rules, CMS structures, conversion paths, and maintenance model defined as one system. If your redesign brief still describes a set of pages, Virdis can turn it into a testable design and development scope before production begins.