[HN Gopher] Launch HN: Ditto (YC W20) - Keep product text in syn...
___________________________________________________________________
Launch HN: Ditto (YC W20) - Keep product text in sync from design
to production
Jess and Jo here, and we're excited to share Ditto with you all
(https://dittowords.com). Ditto is a way to manage product copy--
the text found on user interfaces--all the way from design to
development. Think of a headless CMS but with the text from your
design files. 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! :)
Author : jessouyang
Score : 168 points
Date : 2021-05-13 15:07 UTC (7 hours ago)
| atian wrote:
| The visuals on https://dittowords.com/ were a breath of fresh
| air. Congrats on the launch!
| jessouyang wrote:
| That means a lot, especially because we handle all of the
| design (including the landing page) in-house. Thanks for the
| support!
| CodeWriter23 wrote:
| Why limit Ditto to only text assets?
| jolenam wrote:
| While there's a chance we expand to other types of assets in
| the future, we want to tackle text first. We think text is
| often more cross-functional than images or other assets -- it's
| worked on by people from legal, marketing, customer success, in
| addition to engineers and designers -- but there isn't a
| unified suite of tools focused on text right now. There are
| lots of areas around text we still want to tackle and integrate
| into an end-to-end solution: localization and
| internationalization, A/B testing, intelligent suggestions and
| linting, etc. A lot of these are text-specific use cases, which
| allows us to do things like help teams build out a component
| library dedicated to text, and then surface component
| suggestions based on text in their mockups.
| CodeWriter23 wrote:
| There is a unified set of tools for working on text, either
| Office 365 or Gsuite, both with their +/- but definitely get
| the job done. They have revision control, visualization, etc.
| the problem is finding the dang file 6 months from now...
|
| 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.
| jolenam wrote:
| We definitely agree that there's huge potential in becoming
| the "authoritative repo," or as we like to call it -- the
| single source of truth -- for all assets, accessible by
| tools used by every role. Hoping to focus on text first,
| but not ruling this out for the future.
|
| 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.
| red_hare wrote:
| Images seem like the next natural progression but it's a more
| complicated user story. Suddenly they're either an image host
| themselves or they need to integrate with and manage
| (adding/deleting) their user's static assets.
|
| 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.
| RocketSyntax wrote:
| i use diff messaging pretty much everywhere based on the medium
| of communication and audience
| jessouyang wrote:
| We're actually launching a feature called Variants to tackle
| this very use case (and translations) in our app in the next
| few days! It's definitely been highly requested by teams using
| Ditto and will hopefully allow them to create variations of
| text for different mediums, audience, user segments, etc.
|
| 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?
| thesimon wrote:
| Advanced security is only included in the $30 plan. Do I have to
| worry about the safety of my data if I pick a cheaper plan?
| jolenam wrote:
| Sorry that's unclear - we have security measures in place for
| our app as a whole, regardless of the plan. "Advanced security"
| refers to the fact that we'll work with enterprise teams to
| implement custom security measures they might request.
|
| 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.
| andyjohnson0 wrote:
| Call it "custom security" or "enterprise security" or
| whatever, and price it much higher.
| te_chris wrote:
| For $30??? You're massively underpricing that!
| spookthesunset wrote:
| "$30 Per editor, per month"
| MattGaiser wrote:
| > "Advanced security" refers to the fact that we'll work with
| enterprise teams to implement custom security measures they
| might request.
|
| Should add some zeros to your fee for that then.
| dpix wrote:
| Congrats on the launch, looks great! Couple of questions:
|
| 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
| jessouyang wrote:
| 1. At the moment, we've seen teams use Ditto to localize if
| they already localize their mockups (i.e. have mockups in
| different languages). However, we're releasing the ability to
| create variants of text (i.e. for translations, user states,
| etc.) not mocked up in the design in the upcoming week. It's
| been in development for a while (and to be honest we were
| hoping to release it before today), but still requires a bit
| more testing.
|
| 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.
| valyagolev wrote:
| Thank you. This seems very useful, and I'm considering proposing
| this right now to a couple of companies I work with.
|
| 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.
| spoonjim wrote:
| Small companies are like 10% of the software market -- 75% of
| the revenue is sitting in large enteprises. So, frankly, while
| getting you on board is great for marketing and customer
| development (a lot easier to engage with a small company than a
| big one)... don't expect them to really care.
| valyagolev wrote:
| Sad but true. I'm not making any demands, just telling why
| it'd be a reluctant sell in some cases
| jolenam wrote:
| Definitely understand where you're coming from. The main reason
| we decided to go with a monthly pricing model is that we see
| Ditto as a tool that spans the product development process and
| roles of a company. Compared to localization management
| systems, which might come into play mainly at the end of a
| project, we've seen pretty consistent usage of Ditto across the
| drafting, design, development, and post-launch phases with our
| current customers. Oftentimes, designers and writers will use
| our Figma integration in the early stages of a project (taking
| advantage of the text component library to reuse existing text)
| and then other stakeholders like legal or marketing will come
| in to Ditto approve/review copy. In parallel, devs can fetch
| the latest copy from their command-line whenever there are
| updates as they're building. Post-launch, updates to copy can
| be made in Ditto, and then easily pulled in by engineers.
| valyagolev wrote:
| Yeah, I understand. The clients of mine I'm thinking of are
| small, non-technical companies. They would absolute love
| something like this, but they're just not developing and
| redoing stuff as much as they'd need to justify this expense
| (in their minds).
| medhir wrote:
| Congrats on the launch Jessica and Jolena! Really cool to see
| your progress on Ditto since you first started, hoping nothing
| but the best for your continued success.
| slimjimrick wrote:
| What Jessica and Jolena are building is looking to be quite
| special. And adopting Ditto will not only make copywriting
| easier; it will make your copy better because you get to focus on
| copy and never on process.
|
| 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.
| mdu96 wrote:
| This is fantastic, congrats Jess and Jo on a really impressive
| product!!
| barefeg wrote:
| How would it handle translations?
| jessouyang wrote:
| Right now, teams in Ditto use it as a translation/l10n solution
| if they already localize their mockups. However, we are hoping
| to support this more fully in the very near feature (likely
| this upcoming week!) with the ability to create variants of
| text in mockups in Ditto (including languages, user groups,
| states, etc.).
| xbar wrote:
| This is a good problem to go after. Go forth and crush it, Jess &
| Jo.
| jessouyang wrote:
| Thank you for your support!
| lukeramsden wrote:
| The amount of time I've had to spend making PRs to multiple
| branches across multiple codebases just to change full-stops...
| I've sent this to some of my colleagues.
| jessouyang wrote:
| Definitely been there as an engineer as well. The amount of
| overhead and engineering time it takes to make punctuation
| changes, fix spelling errors, and even simple iterations to
| copy in-app only increases as a product's surface area
| increases. Thanks for forwarding us along!
| eggbrain wrote:
| First off, congrats on launching, the product looks super smooth!
| Had a few thoughts off the cuff:
|
| 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!
| jessouyang wrote:
| Thank you! That means a ton.
|
| 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 :)
| nwsm wrote:
| This looks really great! My team wanted a CMS but didn't find the
| budget. We manage our copy in JSON files in our apps, much like
| this seems to do, so I actually think this would be a very
| straightforward transition, though we'd need to overhaul our copy
| keys.
|
| 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?
| jessouyang wrote:
| That's great to hear! We've definitely seen an increasing
| amount of teams separate product copy out into JSONs
| ("decoupling copy and code"), and we hope Ditto can help them
| manage that.
|
| 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!
| nwsm wrote:
| The JSON decision has served us well. We knew we wanted to
| support multiple languages from the start, so it was pretty
| essential.
| sdfhbdf wrote:
| Hey Congrats on launching. Do I understand that your service
| offers kind of a localization service? How is it different and
| what's the value over services offering translations as a
| service? Like POEditor[0]? or Localazy?
|
| [0]: https://poeditor.com
|
| [1]: https://localazy.com
| jessouyang wrote:
| Many localization services / Translation Management Systems
| (TMS) (like those listed) or developer tools (Lokalize, Phrase,
| etc.) tack on l10n as a layer at the very end (after
| development). Especially with these 3rd party contractor tools,
| a lot of the time the l10n happens without context of the
| design / product -- they just translate the strings that exist
| in production.
|
| 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.
| tejaskumthekar wrote:
| Hey this is Tejas. I remember exploring the product and chatting
| with Jess way back in August 2020. Great to see Ditto here on HN.
| Congrats on the launch :)
| jessouyang wrote:
| Hey Tejas, great to see you here on HN! Thanks for the support
| both then and now :)
| whoisjuan wrote:
| I understand the problem that you guys are trying to solve. I
| experience this pain eveyday at my job.
|
| 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.
| arkitaip wrote:
| I think the front page does a good job at communicating
| considering how specialized this tool is and how small the
| audience it targets.
|
| But maybe they could move the demo video closer to above fold?
| Also, is booking a demo really the most important CTA?
| jolenam wrote:
| Thanks for your feedback -- definitely want to make sure our
| landing page explains Ditto clearly. Any specific suggestions
| for what to improve on or what's confusing?
| alex_g wrote:
| I agree with the parent comment.
|
| 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.
| jolenam wrote:
| Super useful, thanks for the advice. It's definitely been a
| challenge to figure out the right language/vocabulary to
| describe what we're working on, especially since what we're
| solving for isn't talked about.
|
| A clearer graphic that demonstrates the "magic" is also a
| great suggestion!
| whoisjuan wrote:
| I feel that is not entirely clear how you enable this
| workflow that keeps all this text dependencies at sync. The
| collaborative part makes sense. But what's more important
| about this tool is explained with a somewhat vague graphic
| (https://uploads-
| ssl.webflow.com/5fb84e8c68f67b29553103fa/604...)
|
| 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."
| jolenam wrote:
| Really appreciate these suggestions -- thanks! Excited to
| make some updates to our landing page based on the feedback
| we've received here.
|
| 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.
| sefrost wrote:
| This is a great idea. I think the length of an iteration could be
| shortened on every single project I've been on if designers used
| production copy when designing - as problems with the design
| often come up during development as copy isn't as the designer
| thought it would be.
|
| Good luck!
| jessouyang wrote:
| Totally -- even beyond just spacing/fitting in content into the
| designs, the text in-app strongly informs what the user knows
| and understands, which is critical to the design itself.
| Designing with lorem ipsum and other placeholder text has a lot
| of potentially negative downstream effects, in addition to
| slowing down product development.
| aparsons wrote:
| Simple, beautiful app solving a real pain point. Kudos to OP and
| team! I have some general questions, not directly related to the
| product, but rather, the company:
|
| - 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
| jessouyang wrote:
| Thank you!
|
| - 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.
| aparsons wrote:
| Thanks for the response. Very impressive, and best of luck!
| cvg wrote:
| So excited about your launch. Congrats! I've seen this issue of
| copy-pasting copy at nearly all the companies I work for.
| jessouyang wrote:
| Thank you for the support! It is kind of crazy how much copy-
| pasting there is for every single role involved. We think a
| large part of it has to do with the fact that copy exists and
| is worked on horizontally in an org -- unlike more
| verticalized, role-based tools (devtools, design tools, etc).
| kcolford wrote:
| This is a great idea. Have you considered moving into the closely
| related field of localization? If your managing copy all the time
| then you also have to manage it in different languages. There
| could be a lot more you can do with that...
| jolenam wrote:
| Yes, localization has been on the roadmap from the very
| beginning! As a first step, we'll be launching the ability to
| create "variants" of text (ie. for each language translation)
| in Ditto next week. This way, teams will be able to add
| translations to text and view it in their mockups, without
| having to manually mock up each language for every screen.
| These variants will also be available to fetch via our API/CLI.
|
| 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).
| jfk13 wrote:
| Looks great!
|
| 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.)
| jessouyang wrote:
| Wow, great catch with the Safari font issue; we've just fixed
| it. Thanks for finding that!
| nt2h9uh238h wrote:
| Congrats on the launch, love the demo!
| jolenam wrote:
| Jo here -- thanks so much! Really excited to get thoughts and
| feedback on what we've been building.
___________________________________________________________________
(page generated 2021-05-13 23:00 UTC)