Launch HN: Ditto (YC W20) – Keep product text in sync from design to production
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 a...
71 comments
[ 3.9 ms ] story [ 112 ms ] thread[0]: https://poeditor.com
[1]: https://localazy.com
At the moment, we've seen teams in Ditto use it as a localization solution if they already localize their mockups. However, we are hoping to support this more fully in the very near feature with the ability to create variants of text in mockups in Ditto (think languages, states, etc.)
Localization is definitely a pretty big pain point for teams, but we've seen teams struggle to coordinate copy from draft to design to development, even in their primary language.
https://lokalise.com/blog/figma-lokalise/
It's how Slack translated into multiple languages before their IPO.
Moreover, productive workflow is not only about comfortable string management, but also about making it a breeze for the whole team from designer and developer to the contributor.
While we are not currently focused on drafting copy (there are better tools for that), our users especially love the way of work with Localazy. A plethora of solutions provides valuable assistance to the human. We strive to automate as much of the process as we can for you. So humans assist Localazy to get the work done only when they are required to.
Do you have a minute? Check the brief intro: https://www.youtube.com/watch?v=UymDt20nOIc
Thanks for your time. All readers welcome to give Localazy a try.
Best regards,
Jakub
It's been in development/QA for a while, and we were super excited to see all the feedback and questions about localization during our launch.
Frankly we're flattered that our launch has gotten the attention of localization tools (hi localazy + lokalise, thanks for joining us on HN!). Always appreciate others working on solutions for product text in all of its stages.
These two are extremely talented and thoughtful founders who I’ve had the pleasure of being friends with since college. Highly recommend giving their product a try.
For all plans, we have: encryption at rest, encryption in transit, data stored in SOC 1, SOC 2, and ISO 27001-certified data centers, single sign on and mandatory 2FA for employees, secure SDLC (protected branches, PRs), centralized logging and alerting, incident response plan, business continuity plan, and data deletion and retention policies.
Happy to go into more detail and share our official infosec policy over email.
Should add some zeros to your fee for that then.
Just need to sell our product org on the UX of Ditto as we would be buying into Ditto as a major part of our development lifecycle.
I see the pricing is just based on users. Do you have any SLAs on the API?
We don't have a standard SLA on the API at the moment, but in the past, we've negotiated and signed SLAs for enterprise teams. Happy to do so for you as well if you want to shoot an email to founders@dittowords.com!
Having implemented something similar (but very crude) for my company for just text many years ago, I think focusing on text first is really smart.
From my perspective, the problem to solve here is to have an authoritative repo of assets accessible via API, CLI, cloud dashboard, ERP add-on. IMO that's the value play. It answers the "do I have the latest X" in everything from an SOP document to a software build, and enables the responsible parties to push updates across the organization seamlessly. Also, will probably help with the "which dang file is that in" problem products like Teams try to answer but still fail miserably at.
What we’ve also seen from customers is that it can be hard to work on product text in document tooling like Office 365 or GSuite because those external docs feels detached from the context of the designs and the app, and require separate maintenance and manual copying + pasting to move it into the tools where product development is happening (ex: mockups, the codebase). We’re hoping to address this at Ditto with lots more future integrations (like you mentioned!) with other design tools, project management tools, etc.
1. Do you support localization?
2. Do you think there is a benefit to using this in addition to a headless CMS that is already managing authored content?
At my previous company we did a lot of AB testing around product copy in our signup funnel which was surprisingly effective. This could be a really useful feature to include in the future
2. We built Ditto to specifically tackle product copy, whereas existing CMSs (including headless CMSs) are much more geared for marketing copy (longer form, clear H1/H2/body structure, authorship, etc.) -- which we think are pretty different use cases. With product copy and microcopy, teams have to think a lot more about how that fits into the UI/design/implementation; we're also excited about how our CLI can fit into teams' dev processes (like CI/CD) to streamline workflows!
3. Yup, we're super excited about all the potential extensions of Ditto, A/B testing included.
1. From a product perspective, do you worry about relying heavily on Figma? If marketing and design teams move towards different design tools like Invision, or if Figma changes / restricts API access, or decides to move into this same area, I could imagine it could cause issues down the line.
2. From the sales side of things, how do you tackle getting buy-in with three fairly different stakeholders (design / marketing / engineering)? I could imagine the marketing team buying in, but not getting engineering to fully buy-in, causing "success" to rely on inter-office communication, rather than the product itself.
3. On the developer side, how does Ditto handle interactions with other third party libraries or existing code that may also modify text, e.g. using Optimizely to A/B test wording on the page?
Congratulations once again, and look forward to your future success!
1. We integrated with Figma first on the design side due to a couple of reasons: we were really excited about the growth on the platform, the community, and their ability to serve as a single source of truth for design (with live editing). As an early developer on both their Plugins platform and REST API, we've definitely seen their APIs evolve.
Ideally, we want to be design-tool agnostic (including integrating with Sketch, AdobeXD, InVision, etc.) and integrate with everywhere copy lives (including docs, sheets, etc.) once we have enough engineering bandwidth. We think serving as that text layer / infrastructure for text is a fairly different value prop from design tooling, but we do hope to decrease our reliance on Figma over time.
2. Copy is definitely unique in that it's touched by so many roles horizontally in an org (not only in EPD but also marketing/legal/etc.), unlike a lot of role-based tooling (devtools, design tools, etc). We've been really lucky so far in seeing a lot of our growth happen organically by those at larger companies with roles owning the copy (UX writers, content designers, copywriters, etc.) championing our tool to other stakeholders. However, this is definitely something we're still trying to figure out how to do effectively, and we've seen some cases where adoption is held-up because of cross-team communication.
3. At the moment, Ditto brings text into development as structured JSONs, which we keep fairly open-ended on how teams want to integrate into their UIs and 3rd party tools. They can also manipulate the text in development and/or bring it into A/B testing frameworks. In the future, we hope to handle some of those use cases ourselves :)
However this landing page is not doing a great job at explaining the solution. I'm sure once you see the product everything clicks but the current communication is not really explaing well this problem or showcasing well the features and workflows of your solution.
But maybe they could move the demo video closer to above fold? Also, is booking a demo really the most important CTA?
I understood what the problem your product was solving from the title of this Launch HN thread, but viewing the landing page, I think there's big room for improvement for how you explain that.
I think a few things would help:
- Revise your copy to speak more plainly. You're addressing folks working on many different parts of the product, but the language comes off as jargon. As a starting point, I think the title of this thread is way clearer
"Keep product text in sync from design to production" -- Makes sense
"manage and componentize the words across their product from design to production." -- I have no idea what that means
- Replace all of the screenshots and graphics. I see this done a lot, where screenshots are shown and the reader is supposed to understand what's happening, but is not often effective, because they don't understand the context for the screenshots, and it's not clear what part of the screenshot they should be focusing on. I would suggest you provide a very simple clear animation that demonstrates the "magic" behind your application. If it's syncing copy across many different tools and stages of the product, show that magic happening. In other words, if a reader saw nothing but this graphic/animation would they understand what your product is offering them? The demo video is not what I'm referring to, although it is helpful and should remain on the page, maybe even move it up a bit.
A clearer graphic that demonstrates the "magic" is also a great suggestion!
I think it would be more useful to see an explanation that showcases how this text components sync across all tools and how that allows you to always have a single source of truth for your text.
I think another valuable thing to showcase is to showcase the features of this solution by persona. What do you get from this as a writer, designer, PM, developer... That's extremely important IMO. If you don't do this, it's pretty hard to relate to this problem and solution.
Verbalizing the problem in the communication is particularly important. I know this is a problem many cross-functional team have but it's a very discrete problem. It's easy to familiarize and relate to this problem if you explain it.
"Forget about outdated text in your product and the painful and lengthy process to update it.
Ditto is a platform that allows you to write and collaborate on your product text while keeping everything in sync.
From design mocks in Figma to your text strings in your production code, with Ditto everyone gets the same product text seamlessly."
Agreed that we should explain how Ditto syncs text across the stages of product development better, especially since that's the big vision (end-to-end text management).
We do have persona-specific pages for writers, designers, and developers (you can find those in the Product dropdown in the top nav, in the section near the bottom of the page, or in the footer). On these pages, we try to verbalize the specific problems those segments are facing, and then specifically how Ditto solves them.
In the future, we plan to build on top of this and provide more localization-specific features -- things like translation memory and machine translation (for that initial pass).
However, as a person who used things like poeditor in different small places, there was always a concern about monthly payment for something used quite rarely. In this case, they'd pay for 1-2 months of intense use and then cancel the subscriptions.
In those small companies, I think they would gladly pay a one-time up-front fee, or perhaps a one-time small fee scaled with the amount of text in question... but subscribing for a fixed sum a month for something they don't intend to heavily use yet, probably not.
- How long has it been since you released the product? I’ve always been curious as to when exactly in a product’s lifecycle that HN Launches occur. Certainly seems to skew towards somewhat established companies.
- You have some great names using your product! Did you market to specific teams within these companies or to the company as a whole? I’d love to learn how you went about successfully acquiring these “big fish” customers as a young product and company.
Thanks
- We released first released our web-app and Figma plugin around a year ago, right at the end of our YC batch (Jo and I went into YC pre-product). Our developer integrations (API/CLI/SDK and Developer Mode) were released 2 months ago.
- All of our customers (including larger enterprises) have actually found us organically! We were lucky to have the support of different design and content/UX writing communities from the start, and they were able to champion the tool on their teams. We've tried our best to be super hands-on with these teams, offering onboarding and support calls, shared Slack channels, and tips on selling Ditto to other stakeholders in the company. On some teams, however, we're definitely still working to expand outwards from content to design to EPD, especially with our new developer integrations.
Good luck!
One tiny detail: in Safari, the content of the yellow "celebrating the launch" banner unfortunately wraps the final ">" onto a second line, and ends up looking oddly placed as a result.
(I suspect this is a Safari bug rather than something you're doing -- it doesn't happen in Chrome or Firefox -- but you might want to try and avoid it. It seems to be specific to using font-weight:500 with the Inter font there; changing it to either 400 or 600 makes the issue go away.)
Curious to hear what kinds of audiences/mediums of communication you typically account for in your product, and how much variation in the product text is written for each?
I'm curious though, given that such a system clearly would be quite integral to the product development, how would enterprises be comfortable with this as an off-premise SaaS? Like, what if Ditto gets bought next year by Google and killed off 6 months later?
Our software is also an integral part for our customers, and while most of our smaller customers are fine with our cloud solution, all the bigger customers want on-premise installations with full source-code in escrow.
However, we do hope to have an on-prem offering for enterprise customers in the future, especially those with tighter security constraints!
Photo verification before purchase, discrete delivery, available 24/7. Shipment out 12pm next day. we kill competition. we've got what you need and we show proof. lets know what's up Email;teryplugofplugs@outlook.com wickr; ter420