Setup your workspace 🛠
Streamlined workflow 🤝
Supported use cases 💪
Feature guides 🚀

Best practices for maintaining an organized Copy Library 📚

This guide explains how you can organize your Copy Library in Frontitude to ensure you and your team have a clear overview of your product's copy. Utilizing these practices also makes it easier for all team members to reuse copy during the design phase, as well as with other Frontitude integration.

💡 Copy Components are the building blocks of the Copy Library. If you are still not familiar with this feature, we invite you to read this first.

Copy Library is the single source for your UX copy

Frontitude’s Copy Library is a copy repository where you store all your repeated copy. It stores all texts, documentation, discussions, and more on this type of content in one place. This allows other members of your team to consume it and integrate it with their workflows via Frontitude's integrations. One of them is the design tool integration, which enables you to reuse Copy Components directly from the design tool.

Use a consistent naming convention for better organization

To help you build an organized copy repository, we have applied a naming convention inspired by design systems. After all, UX copy is a design component and can be structured as such.

The Copy Library supports this convention natively, and we recommend following it. By following this convention, you will be able to organize copy in a three-level hierarchy, which will give your team a better overview and reusability through Frontitude's integrations.

Frontitude supports the following naming convention:

Category / Type / Name

  • Category - The main category the component belongs to (Buttons, Empty states, Tooltips, etc.).
  • Type (optional) - The type of the design component that the Copy Component is part of or the messaging type the copy is written in (CTA, Error, Shopping cart, etc.).
  • Name - The Copy Component name.

By using this structure, the Copy Library lists all of the components on a three-level hierarchy interface, making navigation and organization much easier. If the Type part is omitted, the structure will be as follows: Category / Name.

Other recommended rules to keep

  • We suggest sentence casing for each of the name parts, although it isn't mandatory.
  • We don’t recommend using camelCase or kebab-case conventions since they are more difficult to search.
  • Use plural nouns to define the Category part. This is more intuitive for search. For example - Use Buttons, not Button. Messages, not Message.


Here are a few examples of component names that can be a great use of the conventions we introduced:

  • Messages / Success / Added to cart - An info message that pops up after an item was successfully added to the shopping cart.
  • Messages / Error / Reached plan limit - An error message that pops up once the user has reached their current plan limit.
  • Empty states / Shopping cart / Title - The title of the shopping cart’s empty state.
  • Buttons / CTA / Book now - A call-to-action button in a hotel booking app.
  • Buttons / Sign in - A generic component that can be used as a call-to-action button or a navigation button label.
  • Navigation / Home - A navigation button label that can appear in the web app navigation bar, or on the 404 page as a link button to navigate to the home page.