The Bumpy Path from Copywriting to UX
It doesn’t happen overnight. Your teammates don’t wake up, yawn, and decide it’s about time for you to write some interface copy.
UX tasks usually sidle up to you bashfully, one at a time. Front-end needs a notification that tells the user their payment fell through. Another time there’s a new pricing plan in production and someone has to fill in the blanks for a switch flow—that someone happens to be you.
Slowly but surely, developers and designers adopt the idea that it’s probably not their job to write copy within the app. Maybe, maybe, someone knowledgeable in language would be a better fit for the task. Fast forward a couple of months—you’re writing everything for the product and no one taught you how.
Molding a new role is hyper-exciting but feels like a free fall. It’s terra incognita, with no rules and no guidance.
Large companies can usually spare a buck or two for an experienced UX writer (even though the term, as well as the position, have only crystalized recently), but early-stage startups can hardly afford a copywriter at all, let alone a designated product writer.
For me, and for a huge number of copywriters out there, this is exactly how it happened. I started off as a marketing copywriter and adopted the new product-planning responsibilities on the go. If you’re caught up in this transition or know a fellow writer who’s struggling, know this—you’re not alone, and there is help. It’s mostly online, since chances are you’ve ended up in this position because there was no one to help at your company, but Google and articles like this one always have your back.
The worst thing you can do as a copy-to-UX switcher is keep doing what you had done before: write copy, employ the knowledge you had, and shove those pitching points and hard-sell formulas right down your users’ throats.
And the best thing you can do is return to basics and remember one key element: write to the objective. Your objective is completely different once the user is inside the product. It’s not to sell anymore but to delight, to explain, and to lead them forward.
It sounds blatantly obvious but you’d be surprised how hard it is to unlearn the pitching habit. Pushy CTAs and urgency-provoking benefits sneak into your copy like tiny car salesmen. And it takes a lot of focus to notice and drive them away.
How to be a UX writer on the team where there’s none:
- Inform the whole team that every line of text within the product is your responsibility, not theirs.
- Ask designers to sit down with you for wireframing and early-stage prototyping.
- Find common ground with designers by learning the basics. You don’t need to go deep into color palettes, just a bit on composition, structure, layouts, grids.
- Also, you’ll speed up your daily work greatly if you learn the tools your designers use: Sketch, Figma, InVision. Just enough to operate.
- Aaaand get to know the basics of HTML/CSS. That’s it, I promise. This one is good for understanding the development process and the web.
Try creating simple layouts of your product in design tools, just to get a sense of how it’s done. Read about UX. There are hardly any books on UX writing at the moment but it seems myopic to focus exclusively on writing. You know how to write, you need to know how to make products.
There are plenty of courses online, all of them pretty similar in terms of substance, while the form might vary. Pick a lecturer/writer you like and finish at least one course or book on UX. Not start, finish.
Don’t make me think, The Design of Everyday Things, and Hooked are three wildly popular books I’ve stumbled across that I thoroughly enjoyed, with a lot of solid, practical advice. There’s also a lot to pick up even on Medium, from publications like uxdesign.cc and Shopify UX.
Four things I learned the hard way about product writing:
- Ask for context. Four times out of five the phrase you’re asked for is either unneeded or should convey an entirely different message.
- Plan for the future. Make sure you know the product roadmap for this particular case and can predict how the functionality will be expanded.
- Have proof. Whenever you suggest a change, don’t just do it intuitively. Ideally, have examples, data, or at least some credible foundation.
- Kill your darlings. With interface writing, you have to be ready to rewrite 15 times and the final version might not be your favorite. Accept that.
It’s been two years and I love the new role and its responsibilities. It feels like I’m in the right place, making sure the users have a good time after they sign up. I’m trying to think ahead, think of different levels of user’s proficiency, different stages of their journey and what they need. It’s fun.
Until someone comes around and tells you “we cannot do it the way you want it because [technical jargon].” So it’s going to be either [horrible inconvenient option] or [another terrible option]. And you’re left to choose.
