Don’t worry, friend. I’m here. We’ll get the writing done. The first step is to accept a hard truth: someone has to do the writing. Some teams seem to build their whole process around not writing. They fill wireframes with lorem ipsum (that fake Latin text that confuses stakeholders) and write CTA goes here on their buttons. I’ve been handed my share of comps where anything remotely word-based was represented by a bunch of squiggly lines. You know that comic about how to draw an owl? Step one: draw some circles. Step two: draw the rest of the fucking owl. That’s you with your squiggly lines. Rude. Everything left unwritten is a mystery box of incomplete design. These mysteries beget other mysteries, and pretty soon you’ve got dozens of screens of things that kinda-sorta-maybe make sense but none of them can really be final because you never wrote the words. Choosing words and writing what appears in an interface forces us to name components, articulate choices, and explain things to the user. It’s part of design. We know this, don’t we? We knew it at the beginning of the design project, and yet here we are. Why did we wait?

Writing is part of design

Words are one of the most powerful design materials available. They convey deeply complex meanings in a compact space. They load fast. They’re easy to manipulate and easy to transmit. And the best part is, you don’t have to invent any of them! You just have to use them. Sometimes words get written off (see what I did there) as mere “details” in our designs. True details can wait until the end of your design process. Words, however, are deeply integrated throughout the user’s experience of your design. Look at your favorite app, site, or interface. Take all the words away and what do you have? Not much! Even if the particular thing you’re designing seems light on words, take a broader view and you’ll find words hiding everywhere:
  • error messages and recovery flows
  • confirmation screens
  • user-visible metadata like page titles and search engine descriptions
  • transactional emails
  • in-app user assistance
  • support documentation
  • changelogs
  • feature descriptions and marketing copy
These are as much a part of the design as the layout, graphics, and animations. Designs depend on words. Even if your design were simple, beautiful, and intuitive, writing can take it one step further. Writing can reinforce how you want users to think about your design. Writing can explain the approach or philosophy that underpins your design. Writing can guide users through complex processes. Writing can even help cover for the quirks and compromises in our designs—hopefully not our first resort, but valuable nonetheless. Sometimes the writing isn’t done because we’re trying to solve everything with “pure design.” Supposed UX thought leaders throw around baloney like “Good design doesn’t need explanation” and “If you have to use words, you’ve failed.” Come on. I hope my pilot knows what all those switches in the cockpit do, but I also hope they’re labeled, just in case. To keep things simple in this book, we’ll be talking about three general categories of writing you might have to do to support your design work:
  • Interface copy: Often referred to as UI copy or microcopy, this is the text that’s deeply integrated within the interface, like labels for form fields, text on buttons, navigation labels on a website, error messages, and similar. It’s often made of single words or short phrases. If the interface would “break” or be extremely hard to use if you removed this text, we’ll call it interface copy.
  • Product copy: Writing that’s integral to the function of the site/product/app/experience, but not necessarily a direct part of the interface—the body of an onboarding email, for instance, or a description of updates to an application in a changelog. This is content focused on helping/supporting the reader.
  • Marketing copy: Longer-form writing that is primarily filling a sales or promotional sort of role. This is content focused on persuading the reader.
Depending on your product and organization, you might have many more buckets of content, or you may find the lines especially blurry even between these three. That’s okay! These buckets will just make things easier while we talk about writing in this book. Cool? Cool. (Oh, and “copy” is just a way to distinguish words written by a designer from the more generic idea of “text,” which could be just about anything in your system, including user-generated input.)

Dalīties