The design says “Start free trial.” The app says “Subscribe.” The translated screen still says “Continue.” Each version may have made sense at some point, but together they leave the team with a basic question: what should the customer see? This is UI copy drift: wording diverges across the places where a product is designed, built, and translated.
How one button becomes three different promises
Imagine a checkout flow that offers a free trial before a paid subscription. A designer changes the button to “Start free trial” after a review. The developer implements an earlier mockup with “Subscribe.” A translator works from a spreadsheet that still contains “Continue.” Nobody deliberately chose three versions; each person used a different source.
The difference affects meaning. One label highlights the trial, another suggests a subscription, and the third leaves the next action unclear. Before choosing the wording, confirm what the button actually does and what the surrounding screen explains. A shared string cannot fix an inaccurate promise.
Give the decision a stable home
Create a source string such as checkout.trial.button.start. Keep its key tied to its purpose so a wording edit does not require a new reference. Add context: this button starts the trial after the customer reviews the plan; the nearby text explains when billing begins.
Review the label with the people responsible for the flow, then record the agreed source copy in Copycat UI. Use the string status to make its readiness visible. If the action itself changes, revisit the key and context as well as the label.
Bring the agreed wording back into Figma
Connect the Copycat UI plugin to the project, select the button’s text layer, and apply the source string. The layer now has a binding to that string. After a later copy edit, use Refresh selection or Refresh page to bring the saved wording into the design.
Refresh is an explicit step: saving copy does not automatically update an open Figma file. Check the result in its layout, including line breaks and longer translated labels. The plugin can apply approved translations, but that does not replace reviewing the screen in context.
Deliver the same string to the application
Have the application reference the corresponding catalog key rather than a separately typed label. Use your team’s JSON export or read-only catalog API workflow to bring the saved value into the application.
Agree on when the application receives catalog updates. A build that bundles JSON needs a new delivery of that file; an API-based workflow depends on how and when your application fetches and caches values. Saving a string is not proof that customers can see it. Verify the rendered result after the relevant release step.
Review translations when the meaning changes
Changing “Continue” to “Start free trial” gives translators new information. Review the affected locale values against the updated source and context, and approve them before using them in the localized design.
Assign someone to check affected translations whenever source wording changes. A translation can be present and still describe an older version of the flow.
Check one complete flow before release
For the checkout example, compare the design and running application in the source language and each supported locale. Use this short checklist:
- Does the label describe the action the button actually performs?
- Do Figma and the application use the intended string key and current wording?
- Have affected translations been reviewed against the current source?
- Does the text fit, and do nearby messages explain the same offer?
- Has the catalog update reached the application being tested?
Start with the next wording change
You do not need to reorganize every string before improving the handoff. Choose one flow, give its copy clear keys and context, and follow the next edit through review, Figma refresh, catalog delivery, and the running product. That gives the team a repeatable way to answer what should ship.