Work together to make the words work
Use The Microcopy Canvas to collaborate, not design by committee
“A camel is a horse designed by committee.” Allegedly, Sir Alec Issigonis, designer of the iconic Mini car, made this comment, referring to what results when teams lose sight of their vision. Maybe he didn’t like working in teams at all, or maybe he was someone who had a tyrannical, Steve Jobs-like approach to design. He might not even have said it, but somebody did, at least as far back as the 1950s.
But no matter how much we value teamwork and collaboration, and regardless of how good we are at cooperating, everyone probably recognizes this frustration. You’re working on a shared problem. You’re all tired. The loudest voices and strongest personal opinions get heard. Someone suggests gathering data, and nobody listens. Somebody else, usually with a loud (and almost always wrong) opinion tries to push a “disagree and commit” approach to winning the conversation, and everyone eventually and exhaustedly agrees to a least-worst option just to get out of the room. And the thing you’ve created is the design equivalent of a camel, when the brief specifically asked for a pony.
Now that a lot of product and design teams have writers on them, this is the reality of how a lot of the writing gets done. (I see you, Writer, and I send you my solidarity.) There’s a lot of advice on how to work together. How to co-create experiences. Establishing clear tone and voice. And there are articles that echo the frustrations a lot of writers feel on teams: we’re in the room, finally, but why do we have to keep proving our value, every day, to people we work with? All of these things are true (and I recommend all of the articles I just linked), and none of the tactics I’m about to suggest will work at all if the fundamental problem on your team is a lack of respect for writers (there’s a lot of writing yet to be done on designer snobbery toward writers).
But on teams that are keen to figure out how to incorporate, not just writing, but writers, I see two main problems that can be solved with some dedicated energy and space for conversation.
Problem 1: Identity issues
Just like with visual design, wireframes (if you still use them) and prototypes, everyone should be empowered to have impact and influence over the words, but unlike some of the other specialist skills on the team, most people feel they can write a little bit. Some designers and developers have been saddled with the writing for a long time, and while they might welcome the addition of a dedicated writer, it can be a minor blow to their identity to suddenly have someone whose skills overlap with theirs. Whose work might make them worry that all those words they wrote in the past were…bad.
It’s not that visual designers want to see themselves as writers, it’s that we all want to feel like we’re good at the aspects of our job that we end up doing, especially if those things end up public-facing. Giving up a little bit of the job you were doing before can be hard, even if it’s not a part of your job that you enjoyed, or felt capable at. It’s great that writers can do the writing for you because words are hard. But it’s also hard to let go of a thing you used to do. It’s ok, designers, I see you, too. We’re in this together.
Problem 2: Feedback is hard
Learning to give feedback that focuses on the right things — it’s hard. Really hard. Most of us who’ve been writing for a long time have had to learn the hard way, both from giving and from receiving feedback that was unhelpful, even when it’s been good.
My strongest feedback skills came from spending two intense years in a writers’ group, where we had extremely strict rules around feedback, and around how we addressed and understood each other. Every two weeks, we would spend 5 or 6 hours sitting in front of my little fireplace, yelling at each other about words, making each other, not into the writers we thought each other should be, but the writers we each wanted to be. We were like a little family, except functional. We poured so much into the personal relationships of support that one of the guys in the group even ended up giving me away at my wedding. Strong feedback processes give you unbreakable bonds, but they are a level of emotional work that most teams aren’t prepared to do.
But if professional writers find it hard to handle feedback processes, how can we expect a team to do this without any training at all? Without any time spent learning how to talk about words with one another?
It’s not that it’s never right to say something like “I hate these words all the way down in my guts,” it’s that it doesn’t answer the question: are these the right words, for the right people, at the right time, and delivered in a voice and tone that is authentic, and recognizable as our brand? In an ideal world, we’d have time to introduce our skillset to the team, maybe even with a series of workshops and talks, but in reality, most of us are thrown into busy situations where everyone is learning the project, learning the tools, and learning about each other on the fly. Writers usually surprise you with what we bring to your team’s existing process (Oh wow, you can code qualitative interview data? Thank god!), but we’re still frustrated by what you don’t know about what we do, about our process, and about our needs.
Especially about giving feedback, which is why people end up relying on personal opinion. Which is exactly how everyone gets tired, the wrong-and-loud people win, and you don’t even “disagree and commit,” you “agree quietly and then feel like you want to commit yourself.”
And that’s how, even with a brilliant writer on your team, you can end up with copy that looks like a camel and makes everyone feel like an ass.
One tool you can try: The Microcopy Canvas
The Microcopy Canvas is not a tool for writing all of your copy, although you can do it this way if you have the time and the will to take a slow, considered approach to it. It’s really designed to be an artifact for conversation: between writers, between writers and non-writers, and for teams that don’t have writers but still need to write the words. Even if you’re clear on your voice and tone guidelines, what does it mean to implement them, and where, when, and why do you need to say it one way instead of another?
In truth, I’m not a big fan of the word ‘microcopy’ because I fear it will become erroneously synonymous with UX writing, in the way that ‘wireframes’ continues to plague UX design. But microcopy is a word that sounds small, achievable, manageable. Something you can do over a coffee. It’s not threatening, like content strategy (which is the overarching thing that we do).
If you’re a writer, you can try this tool with your team, in order to show them the kind of thought processes that go into the crafting of the words. Because nobody has read your style guide (I really really see you — I do) and even if they have, they aren’t always sure how writers write, and expecting them to simply follow the guide (which, again, they haven’t read) is like expecting we can cook Michelin-quality food just because we got the recipe. People might appreciate the output when it works well, but in order to give the best kind of feedback, the kind that improves, not just your writing, but the whole process, everyone needs to understand the inputs, too.
If you’re a team of writers, you probably have your own process, but you can use this to try to work out some different approaches, spending a little more time in the problem before jumping into a solution. Playing with how you need to say something in a modal versus a notification versus an automated email confirmation. Checking if you’re assuming an emotional state, or if it’s reflected in any data. Showing stakeholders, so they can give more informed, specific feedback.
If you don’t have a writer at all, you can use the canvas as a way to start appreciating how and why to write the words together, in a way that works for users. And in doing so, you’ll have documented some kind of rationale or hypothesis, at least for some of your choices. So when you find out the hard way that your users don’t want you to constantly high-five them, or they hate your Star Wars references (seriously, just make a clear 404 page), or they didn’t realize they’d never be able to edit their username, you’ll be able to go back and understand where you might have gone wrong. Was it a vague choice of words, or did you misunderstand their needs in the moment? Is the data showing that everyone looks at this on a mobile, when you designed it for someone at a desktop?
The Microcopy Canvas can be an ephemeral tool of discussion, or you can use it as part of your documentation. And when everyone on the team feels safer understanding the relationship between inputs and outputs, and has the language and framework for it, they’re in a better position to offer writers the right balance of support and autonomy to write better words, have better days, and have fewer emotional breakdowns (I really really super see you, Writer).
And that’s how you get a pony.
If you try the canvas, please let me know how it goes for you! This is version 2.0, and I’m eager to make the next one based on feedback. Tweet me or find me on LinkedIn.
And thanks to the awesome Jamie Feola for making the canvas look so dang pretty. Designers rule.
