Why we built a design tool for copywriters
An introduction to Kopie
Earlier this year a designer shared a Google doc with me. It had dozens of screenshots in all different sizes. It wasn’t the first time he had shared a doc full of screenshots for a feature we were building, but this time I thought, ‘What backward way of writing copy is this?’.
As the sole native english speaker on our team (the product manager, too) I was tasked with copywriting. I wrote the copy for every new feature that we designed.
I wasn’t a real copywriter. I didn’t have any experience to help me judge the right or wrong way of doing things — I just went along with it. I went along with the Google doc comments, the InVision annotations, and the spreadsheet tables. I went along with all the feedback from designers: ‘in other places we say it like this…’, ‘I’m not adding a warning!’, ‘that’s way too short — can you write another line?’. I went along with the whole whack process.
This ‘process’ was painful for designers and writers, and it hurt the end result: a product or website.
So I started paying closer attention to the way my team worked in the hope that I could find a better way to do copywriting for web and product design (and avoid dealing with annotated screenshots ever again).
The wrong page
Before I could feel comfortable with copy I had written I needed to see it in the actual design. There’s a huge visual component to writing for web and product design — a box with plain text doesn’t cut it. Doing copywriting with comments or annotations in a Google doc felt totally detached. It made writing feel peripheral.
When the designer changed the colour of a UI component in Sketch he immediately saw the impact it had on the rest of the design. Whereas I wouldn’t know how the copy looked and read until someone else had added it to the design — it was like writing blind.
I spoke to designers and writers at other companies and agencies. It seemed like word counts, line breaks, and text sizes were causing far more trouble than they should. The disconnection between what was written and how that writing looked as part of the design meant a waste of time and bad results.
Finding a way for writers to be more aware of the visual impact their copy had was the most obvious area for improvement.
Out of sync
The fact that designers and writers don’t share the same toolset creates a huge barrier for the two disciplines to work well together. The linear nature of the design and copywriting process is an obvious side effect— ‘I do my part in my tool, then you do your part in your tool’.
Most product design begins with mapped user flows, described in writing — no UI, just words and arrows. At this stage in the process I saw that it was easy for designers and writers to get a common understanding about what they wanted the design to do. This was due to the tools they were sharing: a whiteboard, Post-It notes, pens and paper. As the design became higher fidelity and changes were made it became much harder for designers and writers to keep that common understanding — writers got left behind. When a UI component was being changed as a result of user-feedback, often there was no consideration for whether the copy should, too. And when there was? It meant exchanging screenshots for copy snippets over Slack.
The process needed to guarantee that the design’s intention was shared by both parties — from mockup to production to iteration.
No win-win?
Along with all the tools designers have at their disposal, the workflows design teams use are incredibly refined, and design systems are almost ubiquitous. Every aspect of what a designer contributes has some kind of tooling to support it. It’s an impressive ecosystem.
But when copywriters got more involved it usually meant spending money on more licenses for design tools — where those licenses were underused. It meant disrupting design workflows with tasks like compiling screenshots or copying and pasting text. It also meant designers were waiting around for copy to be supplied (where the alternative was adding lorem ipsum once writing it themselves became a chore). Improving writing seemed to have the opposite effect on design.
If copywriting was going to get better then designing shouldn’t suffer.
A solution?
Having lived the problem for months, heard our peers’ frustrations, and picked apart our design and copywriting workflows my friends and I started working on a solution; one that focusses on the following:
- Copy has to look great and read well. The actual design should be the writer’s page, and UI elements should respond to the writer’s input.
- Everyone needs to be in-sync, all the time. When a design changes it should be easy to update the copy, have it reviewed, and get it approved.
- Improve writing, improve designing. Writers should become an integral part of the design process, without changing the design process.
Meet Kopie
That solution turned into Kopie, a tool that lets writers add copy to designs directly from a web-browser.
With Kopie:
- Designers can sync their Sketch files to the cloud and writers can add copy that syncs back to Sketch.
- Writers can see exactly how the design responds to their copy.
- Writers and designers can give each other feedback on their changes, and ask for approval from stakeholders or managers.
- Designers can get real copy as soon the first mockups are ready, without disrupting their workflow.
We want Kopie to be the tool that makes copywriting become more like designing. It’s great copy that charms visitors, represents a brand’s voice, and discreetly guides users from A to B — and there should be more of it in the design process.
It’s super early days for Kopie, but we’ve got big plans to change the way copy is written for web and product design.
We’ll be running a private beta program in the next couple of months to gather feedback and make sure we’re heading the right direction. You can join the growing waiting list here or keep an eye on what we’re up to over here.
