We think product copy is one of the highest ROI aspects of product development today, but also one of the most overlooked. Even more so than the visuals, the text users read is critical to shaping their understanding of how things work. Copy often gets coupled as a part of design or neglected as hard-coded strings, even though it's touched by everyone from design to legal to marketing to engineering. Lack of tooling specifically for copy means it often gets copy-pasted between a patchwork of tools intended for other use cases.
Jo and I have been on teams at both small startups and tech giants, and at every place we've seen product copy being written ad-hoc and scattered across mockups, docs, sheets, and tickets. The back and forth required just to fix a simple typo in production often included a backlogged ticket, several Slack conversations, and a ton of wasted engineering time better spent on building.
The two of us were fascinated by this problem—one that impacted the day-to-day of so many roles across a company but was rarely addressed. We decided to start working on it part-time while still in grad school and put together a simple landing page describing a tool that componentized product text. The response we got—emails from designers and developers from Salesforce to Square asking for a tool that didn’t yet exist—made us realize we had to pursue it full-time.
At its core, we wanted to build a way to treat product text as a system, with the ability to componentize text for reuse (just as we have components for development or design). We spent the last year building out and iterating on Ditto, deciding first to tackle how copy was managed between design files and content writers with our web-app and Figma integration.
However, our intent from day one has been to build a single source of truth from end to end, and have text from Ditto integrate into development. Initially, we took a stab at integrating into development by building a Github app that created pull requests for copy edits made in Ditto. This somewhat did the job (democratizing access to making text edits in development), but we saw users struggle with the maintenance it required. We realized it was a piecemeal solution to a system-level problem: Product text and “microcopy” (think text on buttons, error messages, etc.) has context, structure, and hierarchy just like any other content. Maintaining product copy as scattered, hard-coded strings, however, stripped it of its surrounding context.
We decided instead to build out an API (with a companion CLI and React SDK) so that Ditto could function similarly to a headless CMS and sync text from design all the way to production. The API/CLI fetches up-to-date product copy from Ditto (and the designs) into local directories as structured JSONs with unique IDs for text and text groups. As a locally hosted and updated JSON, you always own your copy, can see copy diffs on commits, and won't have to worry about latency (we're not a CDN).
To check it out (with a quick 3 min video of me talking through the features), you can go to: https://www.dittowords.com/developers. To try out our web-app, you can click the “Get started” button. We also have instructions for setting up / playing around with a sandbox Figma file and React app here: https://developer.dittowords.com/getting-started/use-our-cli....
Building tools for copy inherently means doing our best to learn about the design and development workflows of other teams. We anticipate that the HN community has members, teammates, or friends that work on product teams, whether as developers, designers, product managers, legal or other roles that touch copy. We’d love to hear how your team currently manages copy — and most importantly your feedback. Jo and I are roommates (and have been since college!), and we'll be sitting next to each other answering comments. Fire away HN! :)
by Andrey
Azimov