It's been over a year since we launched components in Ditto, which allow teams to build a reusable text library to keep text in sync across projects from design to development. Since then, teams have used Ditto to create 3500+ components to sync across 20,800+ instances of text. They've used components to systemize everything from header copy to legal text to button CTAs, with several teams maintaining over 300 text components in their library.
Building a text component library means thinking about the text in their product at both the macro and micro level — both how it scales across the product and how it concretely functions in the instances where it's used, from design all the way to production.
One of the most common questions we get asked by teams getting started with Ditto is:
How are other teams using, organizing, and thinking about their components?
To answer this question, we did a deep dive into how teams are currently establishing their component libraries in Ditto. Here's what we found.
1. Getting started with components
It can be intimidating to start a component library from scratch, especially as a lot of teams are still transitioning over from writing product copy ad-hoc and understanding what text currently exists in their product.
Here's some advice from teams that have worked to establish robust text component libraries:
- Start small — although it can be tempting to try and create a text component library that immediately captures and organizes all of your product's text, lots of teams have found it helpful to start small and first tackle componentizing areas of their text that already follows clear conventions: taglines, legal text, CTAs, or even text that gets repeated within a single design file.
Once teams have a base of working components, they can build off of them to cover adjacent use cases or product areas. Additionally, with a small starting set of components, teams can use Component Suggestions to automatically find matching text in other design files.
Like all systems (design systems, components in code, etc.), a text component library will change and evolve. As components get edited, renamed, and reorganized, they'll still be linked to their attached instances. That way, teams can get started on creating components even as naming conventions and other standards solidify.
- Building in conjunction with design systems — If your team has existing design components, it can also be helpful to start building components in Ditto by referencing your team's existing design system. By thinking through the text that might be used in each UI element and creating text components for each, teams have found this to be a quick way to understand which pieces of copy are most commonly used in the product.
- Transitioning over examples from style guides — if your team has style guidelines for content, it can be helpful to convert examples from the style guide into components. Using the notes field to describe the style guide rules in place can help educate other team members on context and reasoning behind the text used, and serve as a starting point for future components.
2. Organizing Components
As component libraries grow, teams in Ditto have found different ways to organize their components to support the designers, writers, and developers using them. The Ditto component library explicitly supports up to three levels of nesting, in addition to notes and tags like all text in Ditto.
- Naming components based on their use case — this makes it easy for others to reuse them and find text that fits their purpose. Using the forward-slash naming convention, a common structure we've seen a lot of teams use is: [product area] / [UI element] / [text purpose]
• Pricing Page/Card/Subheader
With this convention, it's easy for a team member searching for text for a specific product area, UI element, or text purpose to find what they're looking for.
- Establishing naming conventions across design and content — if there are existing naming conventions set for UI elements on your team, naming text components so that they match with the design component they should be used with can help designers find the right text components to use.
3. Getting organizational buy-in
Just like any other system that gets reused across multiple teams (design, engineering, even marketing and legal), a content system requires organizational buy-in and communication.
- Introducing Ditto as a part of your design and engineering toolkits — copy is end-to-end, from draft to design to development, which means that it touches the workflows of several teams. Explaining how Ditto works, how it can be used, and how it might improve different types of workflows can transition the component library from being a static reference point to a living source of truth for your product's text.
- Systemizing text helps teams treat text as a core part of the user experience — from teams that have integrated Ditto components into their workflows, we've heard that treating product copy as something that exists in a system helps teams understand text as a core part of the user experience, rather than something that gets written or included ad-hoc.
- Localizing components — for teams where localization is a core aspect of the product's content, localizing the component library with variants helps keep text in sync across locales. Using component variants requires some upfront coordination between design and development, but can yield lots of saved time by reducing duplicated work and parallelizing development.
Working on components, our own team has thought a lot about how text exists as a system. After all, understanding how teams use and think about their text in context of other processes is essential to how we build features at Ditto.
A huge thank you to all of the teams that shared their wisdom and helped provide insight into how they built their own component libraries within Ditto. 💛 We're super excited about all of the teams building component libraries in Ditto, and can't wait to show off the features currently in development.