This review originally appeared in the October 8, 2020 issue with the subject line "Saving the web from a flesh-eating disease of our own making" with an essay about banner ads and user experience and an introduction to a Halloween writing series.
The early Silicon Valley ethos hinged on engineers building algorithms, user interfaces, graphic design, data collection, and product copy themselves, disdaining the well-honed practices of writers and editors in favor of shipping products quickly.
In the 2010s, the rise of fields like content strategy and content design — and the clear benefits of diverse, collaborative, multidisciplinary thinking — have led more product developers to understand the value of trained writers.
However, the workflow software remained separated. Developers used Github or other similar tools, and writers used Microsoft Office or Google Docs.
When creating or editing product microcopy — from button text to error messages and everything in between — most UX content strategists manually scanned every app and screen, typing out changes to CTAs or navigation items in docs or spreadsheets for developers to copy-paste into their code workflow.
Afterward, everyone QAed (followed quality assurance, or proofreading, processes) the changes after they were made. For both developers and writers, this process has long been a royal pain riddled with errors, compromises and duplicated work.
But a few tools have been recently developed to better structure UX writing for both writers and developers. This week’s tool, Strings, enables product writers to audit and submit corrections into a development workflow.
Strings at a glance
Developers and editors/writers each have their own professional vernacular for certain tasks, even though the actions are essentially the same across disciplines. Throughout this review, I’m going to refer to the development term, followed by the relevant writer/editor term in parentheses.
Like so: Quality assurance/QA (proofreading).
Strings links text editing directly with Github, the industry standard development workflow tool. Once the dev team links Strings with Github, writers can pull all copy strings (sentences, words) from a project (giant hunk of code) or individual code snippets (paragraphs), then they can rewrite and make any needed changes only to text without changing touching the code itself.
The text edits then become pull requests (track changes/suggested edits) that are communicated back to Github. Developers can merge (accept) or close (delete/stet) the changes to the text within their Github workflow. Based on the demo, it’s slick.
Since I’m not using Strings myself, I spoke with a Strings customer, who said the product generally made the product writing clearer for both writers and developers, and eliminated some of the copy/paste work on his end. Strings is still working out a few kinks — mainly around automating communication of product changes — but he noted the customer service has been highly personalized and incredibly responsive for its early adopters.
The customer also mentioned: Strings isn’t really appropriate for minor text changes every now and then, but works best during a larger, more focused effort on product writing as a whole.
Based on this discussion, I recommend Strings for:
- Product teams who are actively auditing and editing large amounts of copy
- Writers and editors who want more visibility into how their brand voice is reflected throughout an application
- Development teams who wish editorial changes weren’t so time consuming
Strings is absolutely a helpful tool for collaboration between wordsmiths and coders and merging multiple specialties into a single product. It solves a very specific problem within product collaboration, helping two separate professional disciplines speak the same language.