Design-system copy review with the Figma plugin

The bottleneck in most design-review cycles isn't the visual work — it's the words. A staff content designer reviewing copy across 40 components for 12 product teams cannot scale. They miss things, they rush, they end up shipping "Submit" buttons they'd never have approved on a quiet Tuesday.

The Figma plugin was built for this. A designer runs it on a frame before handoff; it grades every text layer and highlights findings directly in the canvas. The staff reviewer spends their review cycle on the 15% ContentRX can't decide (strategic fit, brand-specific voice), not the 85% it can.

This guide walks through what the plugin catches on a typical design-system component review, using a settings panel as the example.

Setup

Assumed stack:

  • Figma with a design-system library (shared components used across product files)
  • A designer with edit access to the design-system library
  • A ContentRX Free, Pro, or Team plan account

Install the plugin from figma.com/community (search for "ContentRX"), sign in with your dashboard account, and the plugin appears in Menu → Plugins → ContentRX.

What you'll see — a settings panel frame

Open a settings panel frame with these elements:

  • Heading: "Account settings"
  • Section title: "Email preferences"
  • Toggle label: "Product updates"
  • Description under toggle: "We'll let you know when there are updates to the product."
  • Button: "Submit"
  • Secondary link: "Click here to cancel account"

Run the plugin. It scans every text layer and surfaces findings inline in the plugin panel, with "Go to layer" buttons that zoom the canvas to each flagged string.

Finding 1 — "Product updates"

  • Structure [warn] — toggle labels are microcopy, and "Product updates" doesn't front-load the user's relationship to the setting. Suggested rewrite: "Email me about product updates" — the channel is explicit, the opt-in is active.

Finding 2 — "We'll let you know when there are updates to the product."

  • Structure [info] — combined with the toggle label, this repeats information ("updates to the product" is already on the toggle). Microcopy at the paragraph level reads better when each line carries new context.
  • Voice & tone [info] — "We'll let you know" hedges. Confident, direct statements read better here. Rewrite: "We email about once a month." — direct, specific, adds frequency information the toggle label didn't carry.

Finding 3 — "Submit"

  • Voice & tone [block] — one of the most common findings in the library. Voice guidance is explicit: prefer "save," "send," "export" over "submit" or "process." Suggested rewrite: "Save preferences" — names both the verb and the object.

Finding 4 — "Click here to cancel account"

  • Accessibility [block] — "click here" and "learn more" are the two phrases the voice guide singles out as never-acceptable standalone link text. Suggested rewrite: "Cancel account" — drop "click here" entirely; the hyperlink already signals the action.

The fix

After the plugin pass, the designer rewrites the strings:

| Before | After | |---|---| | Toggle label: "Product updates" | "Email me about product updates" | | Description: "We'll let you know when there are updates to the product." | "We email about once a month." | | Button: "Submit" | "Save preferences" | | Link: "Click here to cancel account" | "Cancel account" |

Re-run the plugin: zero blocking findings, a couple of [info]- level notes the designer and reviewer can discuss in the handoff meeting instead of relitigating every copy decision.

Why this scales

A staff reviewer doing 8 component reviews a day, each 20 minutes, is looking at the wrong 160 minutes. The plugin takes 10 seconds per frame. The reviewer's time moves upstream: they set voice and tone expectations once (and tune per team via the team-rules surface in the dashboard), and the plugin applies that across a thousand frames a week without anyone reading each one.

Running this on a whole library

The plugin accepts page-level and selection-level scans. For a design-system library:

  1. Open the library file.
  2. Select the top-level page.
  3. Plugin → "Scan selection."
  4. Fix what's flagged.
  5. Re-scan; iterate.

For production design files (the ones that use the library), run the plugin on each frame before handoff to engineering. Handoff notes should include the "ContentRX: 0 findings" status as a checkbox, same as you'd tick "accessibility reviewed."

Categories on the public envelope

Each finding the plugin surfaces is tagged with a customer-facing category — Voice & tone, Mechanics, Structure, Accessibility, Inclusion, Big picture. The same categories appear in the editor diagnostic, the PR comment, the CLI output, and the dashboard. The Figma plugin's panel groups its list the same way.