While building Ditto, we've gotten the chance to talk to 200+ teams about what the process of collaborating on copy looks like for them.

Our key finding? Copy is end-to-end — it exists from the early phases of discovery and design all the way to development.

This means that working on copy doesn't just involve writers drafting text on their own. It's the back-and-forth between designers and writers about how copy and visuals can work together. It's conversations with PMs to understand the goals of a new feature and what language will help users navigate successfully. It's working with legal to get a particular term approved for use, or talking to brand about how to name a new feature. It's getting copy translated and following up to fix phrases that are too long in another language. It's handing copy off to developers and making sure it gets into production error-free. It's developers sifting through hardcoded strings when copy already in production needs to get updated.

In other words, the process of getting copy written and in front of users relies on a lot of people.

On most teams, though, this process is still fragmented and unreliable. And though we're seeing companies realize how impactful copy is on user experience and business goals, most still have a long way to go in embedding copy into their product development workflows.

In almost all of our conversations, we heard the same challenges come up:

1. How do we integrate copy into the design process?
2. How do we manage stakeholder feedback and review of copy?
3. What's the best way to hand copy off to developers?
4. How do we establish lasting copy consistency across our product?

In this post, we're sharing what we've learned about the state of copy workflows from our conversations: the issues that teams are currently facing and strategies they've come up with for tackling them.

‍

Copy is as much a part of the user experience as the layout and the visuals. But translating this into your product development process — making sure that copy and visual design evolve together — is tricky. Visuals often get prioritized over copy, and some words inevitably end up getting written last-minute, in a mad dash to replace lingering lorem ipsums.

Part of the reason is that design and copy often don't share a toolset. Designers work in their design tools, but copy can exist in any number of places (think: external copy docs and spreadsheets, design tools, Jira, Slack, email). Between the annotated screenshots being messaged back-and-forth in Slack and copy tables in word documents, copy ends up increasingly detached from its goal of designing for users.
‍

Strategies

From our conversations, we've learned a few tips for fostering more effective copy-design collaboration:

• Think about copy early on. Copy is an integral part of the user experience and should be part of the decision-making process from the start. This means thinking about copy even when the design problem is still being framed and user goals are still being established. Copy is more than just the words that eventually end up in the design. Understanding what content a user needs to feel reassured or successfully complete a task can inform the structure of a user flow or even highlight UI issues.
  In practice, this can look like a few different things: Try designing with real content from the very beginning, and consider mapping out the flow and structure of copy before you start on the visuals. If your company has a dedicated content team, make sure they're kept in the loop on upcoming projects, whether that means inviting them to meetings or sending over post-kickoff notes.‍
• Take an overhead view on copy. As with visual design, successful copy requires thinking about the product as a whole. Consider how the text in one part of the product will interact with copy that already exists elsewhere. Think about how copy for a particular feature fits into the overarching journey of what else a user is reading and experiencing. See if you can reuse copy (more on this below!) to maintain consistency and overall usability across surfaces of the product.‍
• Make sure the mockups have up-to-date copy. This ensures that the text and visuals on a design are continuously aligned.

For teams with dedicated content roles like UX writers and content designers:

• Try using collaborative design tools (Figma, Adobe XD, etc.). Writers will be able to work side-by-side with designers, edit directly in the mockups, try out variations, and view changes in realtime. Just make sure to establish a clear process for how writers should work out of the design files. For example, if a mockup is particularly complex, this could mean creating a separate page in the file just for writers to play around with copy.
• Define a method for giving status updates. If writers are working directly out of the design file, it can be tricky to know what copy is final and what's not. Try indicating status in the file itself (ex: colored badges), or deciding on one communication tool like Slack.
• Determine what level of content work each project requires. While copy is important on every project, it'll be more important on some than others. Chances are, content designers will be supporting many teams at once, so prioritization is key. For writers, establish a process for receiving requests for copy help (we've heard Airtable or Google Forms work well!), and feel free to push back on "quick" requests when you don't have the bandwidth. Try building up a database of reusable text (more on this below) so designers can self-serve.

‍

‍

Part of what makes collaborating on copy challenging is the number of stakeholders involved — almost every role at a company, from writers and designers to engineers, PMs, and legal, can touch the copy during any one project.

Compared to traditional content marketing workflows, product copy review is less linear and more iterative, relying on back-and-forth discussions more than explicit approvals. While compliance and brand teams may give one-and-done responses, folks like product owners and engineers are much more likely to give ongoing feedback as the design evolves.

Even more, every project involves different stakeholders who each have a set of tools they're comfortable with. For every team we talked to, copy review took place in some combination of the following places:

• Design tools (ex: Figma, Sketch, Adobe XD, Abstract)
• Spreadsheets and documents (ex: Google Sheets, Google Docs, Airtable)
• Communication tools (ex: Slack, email)
• Project management tools (ex: Jira, Trello, Confluence)
• Codebase + code management tools (ex: Github, Bitbucket)

When some comments are added to Google Docs and others to an email thread, and the copy in mockups differs from that in the spreadsheet, stakeholders don't know where to find the most recent discussions or even version of copy. Tool overload makes it difficult to find alignment and make decisions, ultimately slowing the entire team down.

Beyond setting up a repeatable process for getting feedback, there are also challenges with getting the right feedback at the right time. Stakeholders (who usually aren't involved from the very beginning of the project) have to get up-to-speed on context — what this copy looks like in the design, where it sits in the UX flow, what the overarching project business and user goals are. Stakeholders also often have the mentality that "anyone can write," which can lead to unsolicited suggestions or unproductive feedback loops.

Strategies

Here are a few ways we've heard teams combat these issues:

• Designate a single source of truth for all the copy in your project, and enforce that! Make sure it's kept up-to-date with the latest copy so everyone can stay on the same page. Limit all copy-related discussion to this source of truth, and make sure it's easily accessible by stakeholders. It should also allow you to easily track progress, record iterations, and document who's making changes and the rationale behind those decisions.
• Ensure stakeholders get the context they need off-the-bat. This could mean linking documentation in the request for review, hopping on a brief call to fill them in, or recording a video walkthrough of the flow. Whenever possible, present copy with visual context. It can also be helpful to include what stage the copy is at (was it just drafted, or has it already been rewritten and reviewed by three other teams?) so you get the correct level of feedback.
• Build up relationships with stakeholders. Sync regularly with key stakeholders, and start to understand their challenges and definitions of success. Look for shared goals and opportunities to advocate for copy and its impact on business and user experience across different parts of the company. Whenever possible, measure copy ROI, tie those to business outcomes, and share those wins so stakeholders are more likely to give copy a seat at the table.

👉 At Ditto, we're helping teams create a single source of truth for all of their product copy.

‍

For all the work that goes into designing and reviewing copy, dealing with copy in production can be equally as challenging.

Several issues that came up repeatedly:

• developers don't know when copy is finalized, or even where to find the latest copy,
• developers have to copy and paste text from the copy doc/mockup/other tool, which is time-consuming and error-prone,
• if copy is hardcoded, even small copy changes require developers to hunt strings down, which diverts them from more impactful work and makes it hard to rapidly change copy or do A/B tests,
• copy often goes un-QA'd, resulting in costly post-production fixes,
• localization involves a whole other set of people, tools, and processes that must also integrate with development.

‍
‍Strategies

Here are strategies we heard for getting copy into production more efficiently:

• Establish a clear process for communicating when copy has been finalized. This was by far the most common piece of advice! When a developer is finished implementing the copy, have them reach out to the relevant stakeholders (for example, by tagging them in Slack) for a final QA run-through.
• Having a single source of truth (see above) can also help dramatically because developers won't be confused about where to find the latest version. If that source of truth isn't the mockups, make sure to link copy to the visuals some other way.
• In practice, we heard teams: set up a specific Slack channel with engineers, update status on the relevant Jira ticket, indicate status on the mockups themselves (if that's what engineers consult for the latest copy).
• Deliver copy to developers in a format that they're familiar with. For many teams, engineers have to manually paste finalized copy strings into their code.
  Minimize potential for error and save developers' time by delivering copy in a format that allows them pull copy into their code directly (ex: JSON, XML (Android), .string (iOS)). If possible, get access to string keys and incorporate them into your copy deliverables to make implementation easier.

• Define a process for requesting changes to copy in production. For most teams, this can be an exhausting, weeks-long process that involves filing a ticket, prioritizing that ticket in the sprint, assigning that task to a developer, having that developer search through repos and resource files to find the right string to update, and potentially requesting new translations from the localization team. You can streamline this process in a few ways:
  
  1. Make it easy for the people who write copy to view the content that exists on the product, or even better, edit it directly.
  2. If it's not possible for writers to edit directly, provide as much as information as possible in the initial request to developers (ex: string name, where it lives), as well as context on why the change is important.
  ‍
  ‍👉 Since starting Ditto, we've been thinking about how to improve this process. We're excited to be launching our API/CLI soon so that developers can directly fetch the latest copy that writers are working on.

• Account for text that's not visually mocked-up (think: error states, empty states). Being clear about this copy can reduce confusion for developers and eliminate future rounds of back-and-forth.
• Learn your team's localization workflow. Many teams already have well-established processes for localization, which can involve software tooling, internal translation teams, or external agencies. A whole other blog post could be written on the complexities of localization, but two general tips we heard:
  1. Be ready for copy (and/or visual designs) to change because of language-specific constraints (for example, "longer" languages can break layouts).
  2. Make sure localization teams are given as much context as possible — it's critical for determining the correct translation.

‍

Finding a process that works for a single team or project is great. But for most companies, the ultimate goal is copy that's consistent across all their teams and products. This requires a process that's scalable.

For almost all the teams we talked to, every piece of copy is written from scratch, even if similar copy exists elsewhere. This results in inefficiencies on the team and an inconsistent experience for users.

Strategies

With copy trapped in the codebase, external copy docs, siloed mockups, or email threads, it's difficult to know what copy even exists, let alone see patterns and standardize similar content. Many teams take a stab at this with voice and tone guidelines or terminology glossaries, but find that these are rarely referenced or are hard to maintain.

It's been exciting to see that more and more teams have begun to tackle the issue of copy consistency by thinking about text as a system. In the same way that you can catalog UI elements to create design systems and front-end code components, you can form copy components by aggregating text that's reused across related products and experiences. While it takes time and effort to set up, in the long run, teams can save time and move faster because core decisions around copy are standardized, and content won't need to be written from scratch every time.

Here are tips we've learned for starting to implement text as a system on your team:

• Start building an archive of copy. While some teams have the resources and bandwidth to do a comprehensive content audit all at once, most don't, and that's ok. When a project is finished, save the final copy somewhere and add notes on where and how that copy is being used. If possible, enlist the help of a developer, who will likely be able to pull hardcoded UI strings based on criteria (ex: all placeholders in a specific feature). As you add more entries, you can start looking for patterns:
  ‍
  1.  What are the different types of copy that exist? (ex: instructional text, CTAs, error messages, legal disclaimers)
  2.  How does the language and tone change across users, products, or even stages of a user flow?
  3.  What pieces of copy are slight variations of one another or are duplicates altogether?

• Identify reusable content. As you build up the archive, look for content that is or could be reused. Explore relationships between content so you can start stringing them together to form modular content groups. Try putting your library of reusable copy components into a tool that can be referenced and searched by stakeholders (tools like Airtable or Ditto — that's us! — can help with this).
• Publicize this library internally. Link it in your company wiki, and reference it during meetings and discussions so stakeholders across the company know this resource exists. Show how teams can save time and speed up their work by using existing or standardized copy instead of re-writing it.
• Build content into your design system. If your team has a design system, start a conversation around how content can be incorporated. This could mean creating specialized content components, adding text to existing design components, or providing guidelines on grammar, tone, and usage. Make sure to show real examples of what and what not to do.

👉 Ditto makes it easy to set up a text component library for your team.

‍

As the idea that copy should have a seat at the table becomes more widely recognized, teams will have to decide how much they're willing to do to make sure that's reflected in their product development process.

We think collaborating on text from end-to-end should be seamless. And the insights we've shared above inform how we're building Ditto to help teams do just that.

How does your team collaborate on copy? Have tips we didn't mention? Share your thoughts on Twitter and mention @dittowords.