Building Products with Words
If you want to build a product, create a stunning UX and hit your KPIs — Content is king. One of the easiest wins when building products is to work with a UX writer from day one. Involve writers in the process as early as possible and let them tell the story.
Most products would be unusable without words. Even the most simple business logic requires words.
You can’t even get started without words. Forget about creating an online store, accepting payments and chatting with customers. As Mig Reyes wrote, Design is still about words.
The workflow at many companies doesn’t reflect this reality. All too often PMs and designers hammer out flows without taking content into account. Instead of this, content, design and product need to be working together from the get go.
Here are three common problems when content is tacked on at the end of building a product.
Stories not specs
It’s tempting to write about features. After all, that’s how we think of our products internally.
That’s why it’s common to see interfaces that look like internal spec docs.
Newsflash: Product managers are the only people who get excited about features. Seriously. Everyone else thinks in stories.
In this flow, taken from Wix Groups, the creator of a group is selecting the privacy type for their group:
Technically speaking, there’s nothing wrong with this, but it feels detached from the rest of the product.
This screen introduces cognitive load. Users have three terms they have to learn the meaning of and remember. It’s also not easy to scan. You have to read every word on the screen to understand what’s actually going on.
When I was given this screen to work with, I mapped these features to user intent.
Nobody wakes up and decides they want to create a public, private or secret group. People simply want to create a group. Then they ask who can see it.
This interface doesn’t change the functionality, but the story is completely different:
This is much easier to use and doesn’t force users to learn a new vocabulary to use the product. It’s designed to be scanned. It side steps calling this privacy, which is a loaded and weighty term.
You get additional future-proofing and flexibility when you don’t use product descriptions as a proxy for interface text. Adding more features doesn’t require changing the current text. Requiring admin approval, adding a questionnaire and making paid groups work with the current text. Just add another toggle instead of creating a Frankenstein group type. Want to join my public-requires-approval-to-join-with-questionnaire-paid group? Didn’t think so.
Intents not types
During the early stages of product brainstorming, we think in static types. Neat and tidy personas use our products. This is a handy shortcut for ideation, but it leads to bad interfaces.
When products are split between “types” of users (or features), the natural instinct is to use this division for navigation. Think of using “Merchants” and “Customers” as starting points. The problem is that these labels can change. The quick fix is to go with “Selling something?” and “Buying something?”.
Take this early prototype for Wix Challenges. In our early research the challenge “type”, meaning the duration and timing, was critical. As important as it was for users, it still made a terrible way to navigate through the create a challenge flow:
The fix was simple: remove this question as the crucial first screen and put it in a more logical place later in the flow. The answer still determines what comes next, but it no longer induces panic and soul searching.
The most extreme form of using types for navigation is when you ask users to put themselves into a group. The Nielsen Norman Group recommends against audience-based navigation. You can take this a step further and avoid relying on any static type for navigation.
The realities of computer science mean that our products require some binary divisions. Good UX writing some smooth these over so they don’t stop a user in their tracks.
Making text more accessible
Writers are the first advocates for accessibility — which is more than just adding alt image tags and ticking a few checkboxes. As Sarah Richards, one of the pioneers of content design, explains accessibility is usability.
The quick wins for accessibility are avoiding technical terminology, not creating new terms and using plain language. Resist the urge to give each feature a cute name that users then need to learn and wrap everything in complex language.
It’s rare that people are going to use our products in a silent room, without any stress and on a perfect screen. In reality we all use products on our phones with one hand, before our morning coffee and while we’re distracted. Accessible language makes your products usable for actual people in real situations.
Building a complete content strategy
These are a few quick hacks to improve overall UX with text. When content and writing are at the forefront of your product vision, you build better products.
A complete content strategy goes beyond the words in a product’s interface. Once the interface is polished in the original language:
- Is the content and design flexible enough for localization?
- Do you have a coherent set of knowledge base articles and links to them in appropriate places?
- Have you set up a system to review support tickets so that you can match user language in the product?
This is how writers and the words inside your product bring value. “Just add some copy” at the end of the process doesn’t cut it for modern products.
