Design system audit checklist for small websites: a practical review

Design system audit checklist for small websites

A small marketing site with eight pages, two blog templates, and a contact form is not the same problem as a product with 400 screens. Yet the same drift happens in both places: someone changes a button radius in a single page, a second designer picks a slightly different blue, and six months later the codebase has four shades of “primary” and no one is sure which one is correct. A short, focused design system audit prevents that decay. The goal of this guide is to give a working team a design system audit checklist for small websites that can be completed in a single afternoon by one or two reviewers, without buying a tool the team will not use again.

The checklist below treats a small site as a system of decisions, not as a collection of pages. It looks at tokens, components, documentation, accessibility, and the workflow that keeps the system alive after the audit is over. For a broader primer on what a design system actually contains, the existing Design systems: a practical guide for product teams post on this site covers the foundations. The audit here is the next step: a way to measure how well those foundations are holding up on a live site.

Why small sites need a different audit approach

Most public design system audits were written for large product organizations. They assume a dedicated design ops role, a mature component library, and a Figma library with hundreds of variants. Small sites rarely have any of that. A small site usually has a single designer, a small development team, and a Figma file that doubles as the brand guide. An audit that demands a full token taxonomy or a contribution model will feel like overkill and will be abandoned after the first meeting.

For a small website, the audit should answer three narrow questions:

• Is the visual language consistent enough that a visitor cannot tell two pages were made by different people?
• Are the components in the code matched by components in the design tool, and are both used?
• Does the team have a short, written rule that explains what to do when the next page is built?

If those three questions are answered clearly, the site has a working system. If any of them is unclear, the audit points to the specific place where work is needed. The rest of this article is organized around those three questions, with a section on accessibility, a section on documentation, and a section on the follow-up workflow that keeps the system from drifting again.

How to scope a one-afternoon audit

Before opening any file, write a one-page scope statement. The scope decides what the audit will and will not judge, and it prevents the session from expanding into a redesign. A useful scope for a small site includes the device targets, the page templates in scope, the component types in scope, and a fixed time box.

Scope element	What to write	Why it matters
Page templates	List the templates that represent the site: home, landing, article, contact, product or service page, blog index.	Auditing every page is wasteful; auditing one of each template catches most drift.
Components	Name the components in scope: button, input, card, navigation, header, footer, modal, badge, tag, alert.	Limits the audit to what the team actually uses.
Devices	Pick one desktop width and one mobile width for screenshots.	Prevents arguments about responsive edge cases during the audit.
Time box	Set a fixed duration, usually two to four hours.	Keeps the review focused and produces a usable report.
Reviewers	One designer and one developer is the minimum, three is the maximum.	More reviewers dilute decisions and slow the audit down.

Save the scope statement in the same folder as the audit notes. It is the reference document if a stakeholder asks later why a certain page was not reviewed.

The core audit checklist

The checklist below is the working core of the audit. It is grouped into four passes: tokens, components, pages, and accessibility. Each pass has a small set of checks that can be completed with screenshots, dev tools, and the existing Figma or style file.

Pass 1: design tokens and visual language

Design tokens are the named values for color, spacing, typography, radius, and elevation. On a small site, the token list should be short enough to print on a single page. The audit checks whether the values used in code and in Figma match the values listed in the source of truth.

• Count the unique colors used across the audited pages. Anything above the documented palette is a drift signal.
• Count the unique font sizes, line heights, and font weights. Each value should map to a named type style.
• Count the unique spacing values used for padding and margin. A small site rarely needs more than five steps.
• Check border radius values. More than two or three radii across the whole site usually means ad hoc decisions.
• Check shadow and elevation. If shadows are not named, designers tend to invent new ones for each component.

Token group	What to record	Pass condition
Color	Hex values used in audited pages, palette names, semantic role of each color.	Every color in use is named in the palette and assigned a role such as primary, neutral, or feedback.
Typography	Font family, size scale, weight scale, line height scale.	No more than one font family for UI, one for display if needed, and a documented scale.
Spacing	Spacing scale, base unit, allowed values.	A small base unit scale, usually based on 4 or 8 pixels, used consistently.
Radius	Radius values and the components that use them.	One to three radius values, with documented exceptions for circular elements.
Elevation	Shadow definitions and the components that use them.	A small set of named elevations, used only on surfaces that float above the layout.

Pass 2: components in Figma and in code

The second pass compares the components that exist in the design tool with the components that exist in the codebase. A small site should have a one-to-one map: every component in Figma has a matching component in code, and every code component is referenced in the design file. For an introduction to the way these systems are usually structured, the Design essentials: a practical guide to the principles every project needs post on this site is a useful companion read.

• List components in Figma and components in code. Mark which exist in both, only in design, or only in code.
• Check that the variants in Figma match the props in code. A button in Figma with six variants but a button in code with two props is a sign that the library is ahead of the build.
• For each component, check the documented usage. A component without usage notes tends to be used incorrectly.
• Check the naming. Names should describe the component and its role, not its visual appearance, so that “primary button” stays “primary button” if the color changes.

Component	Exists in Figma	Exists in code	Variants match	Usage notes present
Button	Yes or no	Yes or no	Yes, partial, or no	Yes or no
Input	Yes or no	Yes or no	Yes, partial, or no	Yes or no
Card	Yes or no	Yes or no	Yes, partial, or no	Yes or no
Navigation	Yes or no	Yes or no	Yes, partial, or no	Yes or no
Modal	Yes or no	Yes or no	Yes, partial, or no	Yes or no
Badge or tag	Yes or no	Yes or no	Yes, partial, or no	Yes or no

Pass 3: page-level consistency

The third pass opens the audited pages side by side and looks at the way components are used. Token and component checks look at definitions. Page-level checks look at decisions. Two pages can use the right button and still feel inconsistent if the button is used in different roles, with different padding, or in different orders within a card.

• Compare heading hierarchy across pages. Each page should use the same scale in the same order, not a custom heading style per page.
• Compare section spacing. Hero, content, and footer sections should follow a shared rhythm rather than ad hoc padding values.
• Compare image treatment. Crops, aspect ratios, and filters should be consistent, with documented exceptions.
• Compare link and button usage. A link should look like a link, and a button should look like a button, on every page.

Page element	What to compare	Pass condition
Headings	Size and weight per level across audited pages.	Same scale used in the same order on every page.
Section spacing	Vertical padding between sections.	Spacing follows the documented scale.
Image treatment	Aspect ratio, corner radius, and filters.	Images follow a shared style with documented exceptions.
Link and button usage	When each control is used and how it is labeled.	Links for navigation, buttons for actions, and labels are consistent.
Empty and error states	Treatment of empty lists, error messages, and loading states.	States follow a shared pattern rather than ad hoc placeholders.

Pass 4: accessibility and inclusion

An audit that ignores accessibility will look tidy and still fail real visitors. For a small site, accessibility checks do not need a full WCAG audit; they need a focused review of the patterns that appear on every page. The site’s existing Web accessibility: a practical guide to inclusive design post is a good place to send reviewers who are new to the topic before the audit begins.

• Run a contrast check on the documented color pairs. The color blindness overview on Wikipedia is a useful reference for the kinds of vision differences the audit should account for.
• Check focus styles on links, buttons, and inputs. A site without a visible focus indicator fails keyboard users.
• Check form labels and error messages. Each input should have a programmatic label, and errors should be associated with the input they describe.
• Check that interactive elements have accessible names. Icon-only buttons need an accessible label even if the visual is recognizable.
• Check heading order and landmark structure. Pages should have a logical heading order and use landmarks such as header, nav, main, and footer.

Accessibility area	What to test	Pass condition
Color contrast	Text on background pairs across the palette.	Body text meets contrast minimums, large text meets its minimums, and UI controls meet the same standard.
Focus	Keyboard focus on links, buttons, and inputs.	A visible focus indicator appears in the same style across components.
Forms	Labels, required state, and error messages.	Each input has a label, the required state is announced, and errors describe how to fix the problem.
Interactive names	Accessible names on icon buttons and links.	Every interactive element has a name that describes its destination or action.
Structure	Heading order and landmark use.	Headings descend without skipping levels, and landmarks mark the major regions of the page.

How to capture evidence during the audit

An audit without evidence is a list of opinions. Capture screenshots, dev tools output, and short notes as the audit runs, so the report can be reviewed by people who were not in the room. A simple folder structure works better than a heavy tool for a one-afternoon session.

• Create a folder named with the audit date and the site name. Inside, add a subfolder for screenshots, one for token lists, and one for component notes.
• For each finding, capture one screenshot, a short description of the problem, and a one-line recommendation.
• Record token values in a single table so they can be compared with the documented palette later.
• Save the audit scope statement, the findings table, and a short summary in the same folder for future audits.

Finding	Page or component	Severity	Evidence	Recommendation
Heading scale not followed	Article page	Medium	Screenshot of the page	Replace the custom style with the documented H2 style.
Off-palette blue used	Footer link	Low	Screenshot and color value	Swap to the documented link color and update the token reference.
Focus indicator missing	Primary button on contact form	High	Dev tools screenshot of focused state	Add a focus ring that matches the documented focus style.
Card variants not aligned with code	Service page card	Medium	Figma and code screenshots	Either remove the Figma variant or implement the matching prop in code.

What to do with the findings

Findings become useful when they are sorted, sized, and assigned. A long flat list of issues is hard to act on, so the next step is to turn the findings table into a small backlog. A simple approach is to sort findings into three groups.

• Quick wins: small fixes that take minutes, such as replacing an off-palette color or fixing a missing focus ring.
• System work: changes that affect the tokens or components, such as removing a duplicate radius or aligning a card variant.
• Documentation work: changes to the source of truth, such as writing a usage note for a component or recording a token that was missing.

Each finding should have an owner and a rough size. The owner is usually the person best placed to make the change, and the size is a small label such as XS, S, M, or L. A backlog with owners and sizes is much easier to schedule than a list of comments.

Keeping the system alive after the audit

An audit that produces a report and stops has not really changed anything. The system drifts again the moment a new page is built without a reference. The simplest way to keep a small system alive is to make the source of truth a part of the build process, not a separate document. For a small site, three habits are usually enough.

• Treat the token file as the source of truth. Designers and developers should both read from it, and changes should be reviewed in one place.
• Add a short pre-launch check. Before a new page goes live, the reviewer should check that the page uses documented components, follows the heading scale, and meets the contrast minimums.
• Schedule a short follow-up. A 30-minute review one month after the audit confirms that the changes stuck and that no new drift has appeared.

For teams that want to extend this habit beyond the visual layer, the Website strategy: how to plan a site that actually performs post on this site is a useful next read. A working system is not a separate project from the site; it is part of how the site is built.

Common audit mistakes to avoid

Most small-site audits fail for the same handful of reasons. Avoiding these mistakes is often more important than adding new checks.

• Trying to redesign the system during the audit. An audit measures the system as it is. Redesign is a separate project with its own scope.
• Including too many components. A focused list of ten components catches more drift than a fuzzy list of thirty.
• Skipping the accessibility pass. Visual consistency without accessibility still fails real users, and the cost of fixing accessibility late is higher than fixing it during the audit.
• Writing findings without evidence. Without a screenshot or a token value, the finding is just a debate waiting to happen.
• Forgetting to assign owners. Findings without owners do not get fixed.

A short audit script for the day of the review

The day of the audit does not need a long meeting. The script below fits a two-hour session with one designer and one developer, and leaves a written record at the end.

1. Open the scope statement, confirm the templates and components in scope, and set a visible timer.
2. Pass 1: review the token list, mark any value not in the documented palette, and record the count of each token group.
3. Pass 2: open the Figma library and the code components side by side, mark the parity for each component, and note any naming mismatches.
4. Pass 3: open the audited pages at the agreed widths, compare heading scale, spacing, image treatment, and link and button usage.
5. Pass 4: run the contrast, focus, form, and structure checks, and record the findings with screenshots.
6. Sort the findings into quick wins, system work, and documentation work, and assign an owner and a size to each.
7. Save the scope, the findings table, the screenshots, and a short summary in the audit folder, and schedule the follow-up review.

Measuring improvement over time

A single audit is a snapshot. The value of a design system audit checklist for small websites grows when the same checklist is reused. Three small measures help the team see whether the system is getting healthier over time.

• The count of unique values per token group. A drop in unique colors, sizes, or radii between audits means drift is being removed.
• The percentage of components with parity between Figma and code. A higher percentage means the system is being used.
• The count of quick-win findings in the next audit. A lower count means the team is fixing drift as it appears, not letting it accumulate.

These three numbers can be tracked in a single spreadsheet. They do not need a dashboard, a tool, or a new process. They just need to be recorded in the same folder as the audit findings so the next reviewer can compare.

Frequently asked questions

How long does a design system audit take on a small site?

For a marketing site with a handful of templates and ten or fewer components, the audit can be completed in a focused two to four hour session with one designer and one developer. The follow-up work, including fixes and documentation updates, is scheduled separately and usually takes a few days spread across a sprint or two.

Do we need a dedicated tool to run the audit?

No. A small site audit is usually run with a Figma file, a code editor, a contrast checking tool, and a folder for screenshots. Tools that automate token or contrast checks can help, but they are not required, and the cost of setting one up often outweighs the benefit for a one-off audit.

What if the design system has no documentation at all?

Start the audit by writing the documentation the audit depends on. Even a one-page summary of the palette, the type scale, and the component list is enough to give the audit a reference. The audit then becomes a way to find the gaps in that summary, and the documentation grows as the audit progresses.

How is this different from a full design system review?

A full design system review usually includes contribution models, governance, and a long-term roadmap. The design system audit checklist for small websites focuses on consistency, accessibility, and the minimum documentation needed to keep the system alive. A small site rarely needs the governance layer, and adding it usually slows the team down.

Should marketing pages and product pages be audited together?

If they share the same design system, yes. The point of an audit is to compare the same components and tokens across the surfaces that use them. If the marketing site and the product app use different systems, they should be audited separately so the findings do not get blurred.

How do we handle components that exist only in code or only in design?

Mark them in the parity table and decide whether to remove the orphan or implement the missing side. A component in Figma that no one builds is a source of confusion. A component in code that no one designed is a sign that the design file is falling behind. In both cases, the right answer is to reduce the gap, not to maintain it.

What is the single highest-value check in the audit?

The token pass is usually the highest-value check, because tokens drive everything else. If the palette, type scale, and spacing scale are clean and documented, most of the other findings become easier to fix. If the tokens are a mess, the rest of the audit will produce a long list of symptoms rather than a small set of causes.

Can the audit be run by a single person?

It can, but a two-person audit is usually faster and produces better evidence. A designer can speak to the intent of a component, and a developer can confirm how it is built. A single reviewer tends to skip the half of the audit that is not their primary skill, which weakens the report.

How often should the audit be repeated?

For a small site, a yearly audit is usually enough, with a short pre-launch check on any new template. If the team is shipping new pages every month, a 30-minute drift review at the end of each month is a useful addition. The goal is to keep drift small, not to run a long audit every time a new page goes live.

What should we do with findings that are out of scope?

Record them in a separate list and revisit them after the main audit is complete. Out-of-scope findings are useful signals, but they should not slow the audit down. A small backlog of out-of-scope items is often the seed for the next round of system work.

Where can we go next after the audit?

After the audit, the natural next step is to extend the work into the pages that drive sign-ups and inquiries. The site’s Landing pages: how to design one that actually converts post is a useful read for teams that want to apply the system to the pages where consistency has the most measurable effect.

Related reading

• Motion design: what it is and how to use it in a digital product
• Nail design ideas that actually work for real clients