<- Back to all posts

Thinking about text as a system

Jessica Ouyang
|
September 14, 2020

Merriam Webster defines a system as a regularly interacting or interdependent group of items forming a unified whole.

Almost every aspect of product today exists in and is thought of as a system: design systems, UI patterns, React components, variables, constants, and inheritance in engineering — we could go on. At Ditto, we think text should also be thought of (and implemented!) as a system.

Let’s take a step back. What is the purpose of a system?

  • Systems make the relationships between individual items in a group explicit. Codifying implicit connections provides the space to be intentional and consistent about how things are related.
  • Improving something in a system improves the entire system. Rather than one-off changes that exist in isolation, making changes to a system improves it as a whole.
  • Systems help identify outliers. As things grow and scale, things don’t always fit into existing patterns. Systems help to identify outliers to your existing structure — and how to grow your system to fit new constraints.

Why should we also think about text as a system?

When we think about text without an understanding of its reuse and context, improving it is like redetermining the font, size, and color each time a designer creates a new button.

So much of text — and specifically product copy — is written ad hoc. Why should that change?

  • Communication is context-driven. What does the end user already know? What do they expect? In design and engineering, these contexts are commonly codified as states — error states, progress states, etc. The mapping of these states to what a user sees (and reads!) provides consistency in a user experience.
  • Text is inherently reused and interconnected. Over time, users build familiarity around a glossary of terms unique to your product. (I mean, what is a Facebook Wall or an Airbnb Experience or a Slack Channel but an understanding formed from repeat exposure?) But these individual terms don’t exist on their own — they function as building blocks that ladder up to entire sentences, content blocks, and paragraphs that get repeated when the user enters a similar context.
    Text in product is also frequently interconnected, whether branching off from different translations, states, or variations of an A/B test.
  • Product copy exists from end to end. The role of text in so many existing systems (design, product, i18n, legal, development) makes it all the more crucial that it’s managed in its own overarching system. Because most teams currently update copy manually, outdated copy is so often scattered across different places: docs, sheets, mockups, and codebases.
  • Style guides (often) aren’t systems. Although style guides lay down a lot of groundwork in identifying the edges and boundaries, they have little control over how text (or design!) is actually carried out. They rely on the ability of individual contributors to remember and replicate, even as they get changed.

What does text as a system look like?

Rethinking the process as it is today — a patchwork of copying/pasting between documents, spreadsheets, and designs — means no longer treating product copy as a series of one-offs. Thinking about text as a system informs how we build Ditto, especially in the absence of existing tooling for product text.

We’ve started to tackle this in a couple of ways:

  • Components – Similar to design components/symbols, text components in Ditto allow teams to build a reusable bank of text (and corresponding metadata) and sync copy across projects (and Figma files!).
  • Blocks – Even independent of the design, product copy exists in groups and hierarchy — whether as headings, sections, lists, or more. To bring this text-based organization into Ditto, we’ve recently built the ability to drag and drop text into labeled groups (aka Blocks!).
  • API / CLI – Bridging the gap from design to development has been top-of-mind since we first integrated with Figma. We’re currently in the process of beta testing our API (and corresponding CLI), which brings the latest copy directly to production files.

We’ve just scratched the surface on what working with text as a system looks like! Communicating clearly and building great product are both immensely complex tasks, each with a lot of remaining pieces to improve and figure out. However, we think the first step is taking a big picture view and recognizing how the words across your product work together.

———

P.S. Interested in dev tools, design tooling, and how it impacts with the way people work and communicate? We’re hiring!