Every product has its language. We at Frontitude believe it’s as important as design and technical implementation. The product language is composed of components called Copy, which is every word or a sentence that is responsible for communicating with the user. It’s what driving users to engage and use your product in the way they should. The process of managing the language of a product is therefore called Copy Editing and involves the writing of copy for new features and also updates of existing ones.
As a developer, although you might don’t want to be a part of it, you are a critical link in this process.
Let’s take a look at the average development cycle of a new product feature:
You can see that most of the stages involve writing (or re-writing), which means that UX writers come up with a new word, or revising current ones. Why is it such a repetitive process? It’s simply because in every stage writers (and UX professionals in general) get additional information that helps them to improve the language: Wireframes to Mockups, Mockups to Live elements, Live elements to Production version with usage statistics. On each one of these hops, they get a greater sense of how to product feels like, and go back to their table to revise their work.
Those changes and revisions come with a price for the entire team; a lot of maintenance of strings done by developers, merging it back to the codebase. Not only it takes their time, but it also involves repetitive and tedious work, which can be frustrating sometimes. When developers need to sync new strings, it’s almost always an offline process of asking the product or UX guys where should they take them from — Design tool? Sent over Slack? A spreadsheet? Is it the final version, or they’re still working on them? Then, they copy and paste the new values into a huge JSON file and commit.
Developers were not hired to do that. Instead, they should focus their real work, like building a fast search mechanism or write a cache layer to improve performance.
We think that developers should be kept outside of the loop when it comes to copy editing. Period. They can support the process and have the ability to raise flags, but copy editing should not require their time and effort.
First, we assume that developers are not embedding the strings inside the HTML (or any other template engine), which is a really bad practice in big applications. Therefore, the ONLY friction developers should experience during the copy editing process is the transfer of keys that are going to link to the strings in the code, which should happen only once per string. Then, when the keys are in the code, their values should be managed somewhere else by the UX professional. The developer is basically finished now, and ready to work on the really important stuff.
The optimal workflow lets the UX professionals (specifically UX writers) update and deploy copy changes completely by themselves. We know that as a first step, this isn’t feasible since it’s hard to change existing processes such as CI/CD pipelines. Also, such a high touch solution can bring security and privacy issues, which we prefer to avoid for now.
As a first step, we’d like to ease the process by simply letting developers escape this workflow and in the same breath making copy editing much more efficient and pleasant for the UX professionals, which are currently lack of specific tools for this job.
We believe that giving these tools to product teams will enforce a better copy editing workflow, which eventually will improve user experience and save precious time.
Stay in the know with more stories about UX, content, workflows, and in between. You’ll be the first to know when we post new content.