Hello PH, We're excited to launch Strings, a tool for writers and product teams to browse, search, and edit your app’s actual copy without learning how to code. For most product teams, app copy is locked away in code repositories, far removed from the writers and designers who are tasked to own that copy. Seemingly trivial changes can take weeks to work their way through the product development process and waste valuable resources. With Strings, we empower the owners of product content to view and edit in-code copy in a writer-friendly environment while keeping the final approval with the engineering team to ensure stability. 👩‍💻 Developers changing copy is a terrible use of engineering time From our experience editing a single copy string can be a painful process for product development teams: 1) The UX writer documents what needs to be changed. Either they create a task themselves, or they might ask someone else with access to the engineering issue-tracking tool to do so. 2) The task then needs to be prioritized. A product manager (PM) goes through the backlog of issues and has to understand and evaluate how the copy change ranks in importance compared to all the other engineering requests. 3) Let’s assume the copy edit makes it to the top of the list of priorities (which many do not and therefore get buried in the backlog), the PM then asks an engineering lead to estimate how many tasks can be completed in a given sprint. 4) At last, the sprint starts and an engineer picks up the task for the copy edit. She looks at the edit request and maybe jumps into the design tool to look at the screen in question. Then she goes to find the right string file in the right repo and find the correct copy string to edit, copying or retyping the updated content. A seemingly trivial copy change involves many people, handovers, context switches, processes and may take weeks to get to the users. It creates so much organizational waste and friction that many copy improvements die a slow death. Content bugs and typos live on, inconsistency hurts the brand and the user experience suffers as a result. Writers feel disempowered because they lack control over their work. ✍️ Empower your writers to own what they were hired to do Strings is a tool that sits on top of your code repository allowing writers, designers and product managers to browse and edit in-app copy. Its purpose is to remove the friction and handover steps required to edit copy in a controlled environment where developers retain the final approval. It empowers writers and frees developers. Let’s look at some use cases: - You ship a new feature and inevitably you find a typo or realize a slightly outdated version of copy was shipped. - The team wants to change the name of a feature throughout a product and across all platforms but doesn’t even know all the instances where it occurs. - You work on a product that’s almost 10 years old. There is a lot of legacy content. The people who wrote it have long moved on and nobody really knows what’s buried in that old code base. - You want to see all error messages and assess if they are clear and actionable to the user. - You want to do a content audit of words you want to replace, like “blacklist” and “whitelist.” With Strings you can take care of these changes in minutes. You can search for copy across all your products and see all instances of a given word or phrase. If you want to edit something, just change it in Strings. The tool automatically generates the right code changes and sends them to the engineering team for final approval in Git (via a pull request). Something that may take weeks of process and handovers is done in minutes. ⏱️ Strings only takes a few minutes to set up Lastly, Strings doesn’t require any complicated implementation. Developers install the Strings GitHub app and link their string files. That’s it. Try it out here and let us know what you think. Your Strings Team

Jasper Platz

Strings

Maker

5yr ago

Adam Rodnitzky

TapMeasure

I've been waiting for a product like this! How are permissions managed for different levels of writers?

@rodtwitzky Thanks Adam. The permission structure is basic at the moment - the admin can decide who can join. Devs have final approval rights for any edits that make it into the apps. In the future we are planning to build out more permission functionality that supports more complex workflows like internal approvals.

@jasper_platz Awesome, sounds like a great path. Looking forward to giving this a try!

PratheeP /../

Great product! I’m hoping large teams adopt this so it would make the life of devs and Ux people much smoother. Good luck!

@pratheepch Thanks, that's the hope. Especially as most product development teams are constraint by their engineering time so the more they can handover the faster the team can move.

Strings

In-app copy editing for UX writers and product teams

In-app copy editing for UX writers and product teams

Strings

In-app copy editing for UX writers and product teams

In-app copy editing for UX writers and product teams

Similar Products

Do you use Strings?

Do you use Strings?

You might also like