Taking Notes and Nurturing Your Knowledge Garden with Jorge Arango

Logos

Frequently Asked Questions

These common questions about online learning and design and their short answers are taken from Dan Mall’s book Design That Scales: Creating a Sustainable Design System Practice. You can find longer answers to each in your copy of the book, either printed or digital version.

1. What is a design system?
   A design system can be many things: a visual language, a library of code snippets, a collection of artboards in a design tool, a way of doing design, and much more. In this book, I talk primarily about design systems as an organizational practice. Chapter 2, “Design System Fundamentals,” explores each of these kinds of design systems in more detail.
2. Why are design systems important?
   About five billion people use the internet each day, and the average person spends over six hours online daily. Designing websites, apps, and digital content at scale is imperative for keeping up with the ever-increasing demand for information and services online. Understanding design systems and how to work with them is already a job prerequisite for digital designers, engineers, and product folks at many organizations, and that trend continues to increase.
3. Aren’t design systems just for designers?
   Absolutely not! Design systems are exciting because they are one of the few tools that equally serve the proverbial three-legged stool of design, engineering, and product. Chapter 7, “Roles and Responsi- bilities,” describes all the roles and responsibilities that can exist on a design system team.
4. Will this book teach me how to make a design system?
   Yes and no. If you’re looking for detailed how-to for setting up UI kits in design tools like Figma or prop settings in languages like React or Angular, there are many online articles and courses that do a better job of that. I chose not to cover those kinds of topics in this book because that’s not usually where most design systems fail. Most design systems fail because they aren’t integrated early enough into the grain of how an organization operates, so this book focuses mostly on how to do just that.
5. I’ve made design systems before in just a few days. Does this topic really warrant a whole book?
   It’s true that a skilled practitioner can create design system artifacts like Figma UI kits and code libraries very quickly. However, a design system practice takes time to establish. It’s not that the tasks take long; it’s that design systems practices are exercises in cultural change, and change takes time to permeate through an organization in a way that sticks. Chapter 6, “Governance and Contribution,” explains the who, what, where, when, and why design systems take time—time that’s well spent.
6. Will this book recommend tools that make design system work easier?
   It’s an exciting time in design system tooling because new applications, plug-ins, and software are coming out every day! While there are a handful of tools mentioned throughout the book, the tools are too new and change too often for me to call out any as having stood the test of time.

back to Design That Scales

Frequently Asked Questions

These common questions about service design and their short answers are taken from the book Service Design: From Insight to Implementation. You can find longer answers to each in your copy of the book, either printed or digital version.

1. Is service design just customer experience, user experience, or interaction design?
   No. They are close cousins to service design, but they are not the same, although work in both customer experience and user experience forms part of service design’s remit. We often use the term “user” instead of “customer” in the book, sometimes interchangeably, but sometimes because there are contexts in which a service user might not be a customer or because a service user might also be a service provider (such as a teacher or a nurse). Some projects lend themselves to different language—customers, partners, clients, patients—depending on the project context. Interaction and user experience design are often understood as design for screen-based interactions, but service design covers a broader range of channels than this. Some projects have a strong digital component, of course, so interaction and user experience design have an important part to play, but so do product design, marketing, graphic design, and business and change management.
2. Is service design “design thinking”?
   Service design does, ideally, work at the strategic business level, connecting business propositions with the details of how they will be delivered. It also champions the idea of designing with people and not just for them (see Chapter 3). This may mean the use of terms such as “co-production” or methods that include multiple stakeholders within an organization, such as management and frontline staff. We see service design as distinct from design thinking in that it is also about doing design and implementation. It also makes use of designers’ abilities to visualize and make abstract ideas tangible.
3. Why are there so many case studies from live|work?
   The most obvious answer to this question is that Ben and Lavrans are co-founders of live|work and thus have access to these projects from their own professional experience. The less obvious reason is that many service design projects are about innovation. The results of these projects filter into the public domain through new services or improvements to existing ones, but many companies want to keep their internal activities confidential. On the one hand, this is a good sign that service design adds real value to businesses (see Chapter 8). On the other hand, finding examples not covered by nondisclosure agreements is difficult. This is also the reason why there are few images of behind-the-scenes, in-process project work in the book.
4. You do not mention [insert your favorite method here]. Why not?
   We cover many practical methods in Chapter 4, but due to space considerations we left out several methods that are common to all forms of design, concentrating instead on those specific to service design.
5. Where are your references and sources?
   We have provided footnotes for the key references in the book, where appropriate, but we did not want to turn the book into an academic text. That is not to say our arguments are not robust or rigorously researched. We have hundreds of papers and references in our personal libraries. If there is something we should have credited or that is plain wrong, contact us on the book’s website (staging.rm.gfolkdev.net/books/service-design/) and we will try to make amends, either on the site or in future editions. The Service Design Network (www.service-design-network.org) and Jeff Howard’s excellent sites—Service Design Books (www.servicedesignbooks.org) and Service Design Research (http://howardesign.com/exp/service/index.php)—are good places to find service design resources.
6. What is the best way to convince management to spend money on service design?
   This is the million-dollar question. In Chapter 8 we discuss strategies for measuring the return on investment in service design and how to think about measurement not just in terms of profits but also by considering other metrics in the triple bottom line of economic, social, and ecological benefits.
7. Are you saying that service design can do everything?
   Service design is both broad and deep and necessarily covers many areas and disciplines, but as we argue in Chapter 9, we are not design superheroes who can do it all. Service design works best when designers collaborate with professionals from the disciplines appropriate to the project in hand.

back to Service Design

Frequently Asked Questions

These common questions about video games and design and their short answers are taken from John Ferrara’s book Playful Design: Creating Game Experiences in Everyday Interfaces. You can find longer answers to each in your copy of the book, either printed or digital version.

1. What do you mean when you refer to “video games”?
   Throughout this book, I use the phrase “video games” to refer to computer-mediated games of all types, from World of Warcraft to Words with Friends. This may be a more general usage than a purist would select, but I use it because it’s a conventional and recognizable way to distinguish this subtype of games from other forms. I use the term “games” to refer to the broader class of experiences that includes video games as well as board games, sports, card games, gambling, and so on.
   A more robust discussion of what it means for something to be a game or a video game is found in Chapter 2.
2. Are you suggesting that UX designers should become game designers?
   I’m proposing that UX designers adopt game design as a competency that they can enlist, alongside our existing competencies, to solve real problems. I argue that, to do this effectively, it is critical for us to acquire the theory, skills, and processes that will allow us to build truly rewarding game experiences. This book is intended to lay the groundwork for UX practitioners to begin developing this capability in earnest. So, no, I’m not suggesting that we should rethink our careers, but rather that we should grow within them.
   For more about why we should, see Chapter 1.
3. Are video games really that important?
   This depends on what they’re doing, but they absolutely can be. Today, video games are being designed that forge connections between people, teach subjects in schools, encourage healthier living, support charitable giving, fight world hunger, and promote the cause of peace. I believe that games are up to these tasks and can offer fresh approaches to making the world a better place. See Chapters 11-13 to read more about such real-world examples.More generally, I would argue that play is an essential part of living. It’s the process by which great discoveries are made, industries are built, and people fall in love. The instinctive human drive toward play continuously pushes us to find new ways to understand and influence the world around us.
4. Isn’t this just another way to say that we should try to make things more fun to use?
   Designers can’t just set about designing fun, for at least two reasons. First, it’s a very subjective and cultural quality, carrying a lot of different meanings for a lot of different people. The type of fun you might engineer for one person might be boring, irritating, or offensive to many others. Second, fun is an effect of a well-designed game, rather than something that can be molded directly out of clay. So it’s better to focus on creating a high-quality player experience and allow fun to emerge from the player’s interaction with it.
   I talk more about the motivations that drive people to play games in Chapter 4. See page 36.
   Apart from fun, games also have a lot of other positive effects that shouldn’t be overlooked. UX designers will find great value in exploring how they can make life more intuitive, more engaging, more memorable, more meaningful, more rewarding, more productive, more effective, and more successful.
5. Are you saying that everything people do should be turned into a game?
   No. In this book I show how UX designers can find great opportunity in building on the innate gamefulness residing in everyday experiences to create better ways for people to interact with computers than would otherwise be available. However, this approach is not appropriate in every situation, and pursuing game strategies where there is no game to be found will result in projects that are doomed to failure. For an explanation of such pitfalls, I encourage you to read the Introduction.
   See page xv.
   But I also believe that it’s simply a good idea for UX designers to have a sense of what’s going on in games, because other kinds of benefits can be drawn from them that are relevant to our profession. Many games have amazing user interfaces, which can be a great source of inspiration in our own work. Whether it’s discovering new design patterns or getting a fresh perspective on mediated collaboration, there’s much to learn from the great design work being done in games. So the message of this book is certainly not “turn everything into a game.”
6. How can I get involved with the best communities that are doing work in this area?
   There are a few conferences I recommend attending. Each year the Game Developers Conference (San Francisco, GDconf.com) hosts a rotating set of smaller summits dedicated to games in real-world contexts, and the general conference is a great opportunity to learn practices and methods of the established game design industry. More specialized conferences include Games for Health (Boston, GamesForHealth.org), dedicated to games that improve wellness and healthcare; Games for Change (New York City, GamesForChange.org), which showcases games that promote social causes; and Games, Learning and Society (Madison, Wisconsin, GLSconference.org), which is largely devoted to educational games. I would love to see substantial numbers of UX designers attend these conferences. All of these groups also have very active e-mail discussion communities, which you can join on their websites. Finally, I would encourage you to find a local chapter of the International Game Developers’ Association (IGDA.org) and attend their meanings to learn, connect, and even introduce a UX perspective.

back to Playful Design

Sample Chapter: Writing Is Designing

This is a sample chapter from Michael J. Metts and Andy Welfle’s book Writing Is Designing: Words and the User Experience. 2020, Rosenfeld Media.

Chapter 1: More Than Button Labels: How Words Shape Experiences

Two people stand in a conference room looking at printouts of mobile app screens. The office used to be a warehouse, but it’s been renovated and turned into offices. The printouts are taped to the glass partition that separates their conference room from the hall, because tape doesn’t work on exposed brick. It’s a perfect stock photo opportunity.

“What does that button do?” asks one.

“It saves the user’s data,” says the other. “That’s why it says ‘Save.’”

“Does it save all their data, or just what we’re looking at right here?”

“Oh. Just what we’re looking at here.”

“How will users know that? Should we tell them?”

Conversations like this happen all the time and in all kinds of places—not just repurposed warehouses. Teams who create software spend a lot of time talking about how people will use it.

That’s where the word “user” comes from. People use buttons to take action, navigation to find where they need to go, or the dialog in a voice interface to figure out what their options are.

They also use words. Words help them figure out what that button will do, where that navigation will take them, or what that voice dialog means.

Start by Designing

How should those words be written? Most people have this question in their minds, but it’s a tough place to start. Before you start writing, think about designing the experience you want your users to have. Here’s how we think about these two activities:

• Writing is about fitting words together.
• Designing is about solving problems for your users.

To find the right words, writing and design need to team up in your brain and work together.

Think about the two people talking about the Save button in their mobile app at the beginning of the chapter. How should they know what to write?

• A writing mindset asks: How many words will fit here? How should I describe this action? What terms are we using elsewhere?
• A design mindset asks: What terms are our users familiar with? What happens next? What problem are we really trying to solve?

You can’t have one without the other—and you need them both.

If the people you’re working with don’t understand that writing is designing, they’ll be surprised when you suggest that changing how the experience works is the best way to improve it. Some problems can’t be solved by writing, and learning to recognize when that situation occurs is just as important as learning to write a good button label.

Designing with words requires a broad range of skills, including many that don’t involve arranging letters into sentences. Framing your work this way will make you more effective.

In our own work, we aim to design experiences that are usable, useful, and responsible. How does that apply to the words you write? Here are some questions you can ask yourself.

• Usable: Do the words help people use the interface? Are they clear? Do they help people accomplish what they set out to do? Are they accessible to all audiences?
• Useful: Do the words represent something people want to do? Do they give people control over the interface, product, or service? Does the experience add value to the user’s life?
• Responsible: Could the words you’re writing be misused? Are they true? Are they kind? Are they inclusive? Do they subvert language that people trust and understand to gain a business advantage?

To do this, you’ll need to understand the product you’re working on, along with the vision, constraints, interactions, visuals, and code behind it. You’ll need to spend time facilitating important conversations, conducting research, and aligning on a strategy.

Before you start writing, start designing.

Usable Words

When a product is usable, it means that people can use it without coaching or help. You can find out if your software is usable through usability testing: giving users key tasks and then observing them to see if they’re able to do what your product is designed to do easily.

But writing usable words goes deeper than that. For example, one of the best practices most people seem to know about interface writing is that you should not tell people to “click here.” This advice is easy to remember, but the underlying concept is what’s important. For example, it’s easier for people to use a link rather than words when the link describes where the user will go. See Figure 1.1 for an example of how a link can make text more usable and clear. On the left, the words at the bottom of the list of tutorials tell the user to search for more and how to get to the search experience. The words at the bottom of the list on the right actually take the user to search. The words on the right are shorter and much more usable.

For the visually impaired people who use screen readers to narrate the words on a screen to them, this feature especially helps with usability.

Figure 1.1
This before (left) and after (right) shot of an Adobe Creative Cloud mobile app search page shows some text at the end of a list of tutorials, prompting the user to use the search tool if their desired tutorial wasn’t on that list.

Experts in the field of accessibility provide guidelines and best practices to support screen readers and more, but for the person using a screen reader on the “click here” link, what’s the difference between accessibility and usability?

Sarah Richards, author of Content Design, gave a talk called Accessibility is usability in 2019. She made the case that if the words you write for something aren’t accessible to everyone, then you’ve made a design choice that prevents people from using that thing.

In her book, Richards pointed out that you can make writing more accessible and usable through plain language that people with a variety of reading levels can understand. This practice helps cognitively disabled users, those who have recently learned the language you’re writing in, and even people who are stressed.

“It’s not dumbing down,” Richards said. “It’s opening up.”

Design experiences that are accessible to everyone include different literacy levels, cultural backgrounds, and disabilities. Usable writing works for all your users, no matter who they are.

Useful Words

For your words to be useful, you need to understand and honor the intent of your users. If you don’t respect them, how can you expect them to keep giving you their time, money, and attention? Giving users control and prioritizing their needs is what makes writing useful.

Figure 1.2 shows checkboxes that appear as the user tries to pay for and reserve a hotel room. The first checkbox is required to complete the purchase. It requires that you sign up for the loyalty program, agree to the terms and conditions, sign up for marketing emails, and agree to the privacy clause all in a single checkbox. It also demands that users abandon their checkout flow to unsubscribe from email marketing.

The second checkbox frames opting out of emails as a negative option, so you may leave it unchecked because its logic is reversed from the first checkbox, which could lead some users to sign up for emails accidentally.

Figure 1.2
The tactics Melia uses here to gain loyalty program members and email subscribers aren’t a useful part of this room reservation system.

The team responsible for that reservation system didn’t make creating a useful experience their priority. They used writing and design to force people into the loyalty program and email lists.

By contrast, the Pinterest Terms of Service show what happens when a team is able to build a vision for useful writing across a team that included designers, developers, and lawyers.

Figure 1.3 shows a portion of their Terms of Service, which includes a summary of each section in simple terms, to help users understand what they’re agreeing to.

Figure 1.3
Pinterest’s terms of service uses words to design an experience that’s far more useful than most of the legal agreements users are forced into.

Useful writing focuses on what people want from your product or service and asks how you can balance that with business goals, rather than focusing purely on what the business can get out of it.

Responsible Words

Words should be used for good. As a writer and as a designer, you’re responsible for what you put into the world and your words have power. To write responsibly, you have to consider a wide variety of scenarios.

Irresponsible writing weaponizes language to cause harm to your users. One popular example is the practice of “confirm-shaming.” This situation occurs when an interface asks the user for something and then forces them to say something negative about themselves to decline. In Figure 1.4, a news app call theSkimm forces users to say they prefer to be miserable in the morning (see the last line) to close a form that asks for their email address. (Have you noticed how companies really desperately want email addresses?)

Figure 1.4
No one prefers to be miserable in the morning, but theSkimm forces people to say they do. This example was found on confirmshaming.tumblr.com, which collects examples of this.

But it goes deeper than not being a jerk. Often, words can cause harm in less obvious ways.

Figure 1.5 shows a LinkedIn conversation between two people. The first person is offering help to someone who was recently laid off. The second person responds with gratitude and says they’re going to take some time to process what happened.

LinkedIn’s algorithm suggested that the first person respond with a pre-built message like “Great!” or “Sounds good!” (Figure 1.5), which wouldn’t have been appropriate. This feature is likely designed to help people save time, but in this case there’s something far more important at stake than saving 30 seconds on typing a message. An accidental tap could have made this interaction hurtful and insensitive.

Figure 1.5
“Good luck!” is remarkably insensitive when someone has recently lost their job. “Congratulations!” doesn’t make sense at all.

These pre-built messages probably aren’t being used the way the writer intended, but that doesn’t let them off the hook. As a writer, it’s your responsibility to consider not just how your writing will be used, but also how it could be misused, whether it’s by an algorithm, others in your company, or malicious people outside it.

How Words Build Experiences

What does it mean to design something by writing? It means that your words are building someone’s experience.

Here’s an example that has nothing to do with writing or software: Think about leaving your house to buy some apples from the grocery store. If you’re physically able to walk, and the store isn’t too far away, and your neighborhood was designed to include a sidewalk, it’s easy to take a stroll to get your produce.

But what if you live in a suburban area, with few sidewalks? These neighborhoods are often designed to include sidewalks in a subdivision, but not along the road. So going outside the subdivision involves a choice between walking in the ditch or walking in the same area as cars that are driving at a high speed. In this case, most people choose to drive to pick up their groceries.

What if you can’t walk? If you get around in a wheelchair but the intersections in your neighborhood weren’t designed for wheelchair access by including curb cuts, you may have to drive or rely on others to run your errands (see Figure 1.6).

Figure 1.6
A curb cut is designed to enable wheelchair users to move easily from the street level to a sidewalk. It also typically includes tactile paving that helps visually impaired pedestrians know when they are about to enter or exit a street.

All of these combinations of roads and sidewalks have been designed, but who designed them? Who is responsible for being so accommodating to cars or choosing not to accommodate wheelchairs? Was it the person who drew up the plans for the roads? The government that approved their construction? The developers of the subdivision? The estimator at the construction company? The workers who built them? The answer is that all those people had a hand in designing them. When you make decisions that affect the experience someone else has, you’re designing.

Nicole Fenton, co-author of Nicely Said, describes her work this way in her article Words as Material:

I work on digital products and physical goods, so I’m deeply involved in the design process. But I also want to call out early that my process is the design process. I don’t write fiction or short stories; I use language to solve problems—whether that’s behind the scenes or in the product itself. I use words as material.

Words build digital experiences, and this book is all about creating good experiences for the people who use software on their computers, phones, watches, and other devices. More and more often, people use that software for personal, everyday tasks: paying bills, sending emails, or requesting a rideshare like Uber or Lyft. You’re designing the interfaces that let them do that.

You can’t create these experiences without words, and every word included in those experiences shares the user’s understanding, feeling, and outcome. That’s why this kind of writing is design.

The Words Are Everywhere

Right now, pull out your phone and open up one of your favorite apps. Take a moment to tap through it and take note of all the words you see.

That app you use every day relies on words. Yet, as you can see in Figures 1.7 and 1.8, if you take away the words, how much interface is left?

Figure 1.7
Screens from the DoorDash mobile app with words.

Figure 1.8
Screens from the DoorDash mobile app without words. Designer Mig Reyes did this to popular websites in a 2015 blog post, illustrating how much interfaces depend on writing.

Think, for a moment, about that food delivery app—the one that would cease to function without words.
There are countless companies that will deliver food to where you live. These companies accomplish this through software products that have to be designed, developed, and then used by customers.

The people who use these products call them “apps,” and that almost makes it sound like someone’s weekend project, but this is serious business. Grubhub, for example—one of the biggest food delivery companies in the U.S.—pulled in over a billion dollars of revenue in 2018. Figures 1.9, 1.10, and 1.11 show a few of the different ways a product like this is used.

Figure 1.9
Customers often order from a mobile app (exactly which app depends on their operating system), but could also use their internet-connected watch, voice-activated assistant, smart TV, or anything with a web browser.

Figure 1.10
Restaurants receive orders through a different app (usually running on a tablet or laptop next to the cashier), and the people who deliver the orders use the mobile version of the restaurant app to see customer addresses and update the delivery status.

Figure 1.11
Offices may offer group ordering for their employees, so admins need a place to choose the restaurants, employees need a place to order before the cut-off, and the accounting team needs a place to view the records so they can audit payroll deductions.

It’s a complex ecosystem of software, business, and people working together to get that cheeseburger to your door quickly and easily. There’s a lot to write, too. Here are some of the components in a food ordering app that rely on words:

• App store listings (for each app store)
• Release notes for new versions
• Onboarding information (orientation instructions for new users)
• Login screens and forms
• Account recovery mechanisms
• Account areas and settings
• Payment screens
• Button labels and interface elements
• SMS notifications
• Push notifications
• Email notifications
• Confirmation emails
• Account recovery emails
• Email validation emails (emails about emails)
• Re-engagement emails
• Help content
• Terms and conditions
• Privacy policy
• Contact forms
• Contact form confirmation screens and emails

That’s not even an exhaustive list—each company handles it differently. The words that appear in these areas are part of the experience of ordering food now, and someone has to write them.

The Need for Writing

It’s not just about the apps on your phone, either. Any web app or website has interactive elements driven by words.
Every button has a label. Every form has error states. Every sign-up process has instructions. The words are everywhere, and it’s a mistake to treat them as an afterthought—something that can be filled in later.

In fact, when it comes to certain types of interfaces, words are all there is. For natural language technologies like smart speakers and chatbots, there are rarely—if ever—visual elements involved in the design process (see Figure 1.12).

Figure 1.12
You don’t need any fancy prototyping software to create a design for this thing—just a text editor.

Teams in this situation rarely need someone with design experience in the traditional sense. They need writers with design experience.

Writing the words in an interface first, before any kind of visual design, helps a team understand what they’re working on and gives them something to respond to.

Writers won’t be replacing visual designers anytime soon (or even at all), but on teams where the writer and designer are two different roles, both should be aware that they’re serving the same users and working toward the same goals. It’s not a question of one or the other. One doesn’t come earlier or later. It’s a collaboration that creates the user experience.

Katie Lower is very familiar with this type of collaboration. She has been working with words on various digital design teams for more than 15 years, and she’s found it empowering when her employers recognize her work as design. “I think it gives you confidence—you just show up differently,” she said. “I felt like if someone was calling me a designer, it leveled the playing field for me.”

Lower didn’t set out to design things, but she wanted to make a bigger impact on the product she was working on and the team she was working with. On a project early in her career, a usability specialist shared research findings with her that dictated what words customers were looking for at a certain point in the experience. She became curious about not just what she was supposed to write, but why she was writing it in the first place.

“I know we have these different specialties in design, but that experience, it all felt too chopped up and disconnected. The bigger picture got lost,” she said. “It made me feel like there was something more to this work than being directed and told ‘We need words in this space, put words in this space.'”

She pursued a Master’s degree in Library and Information Science, which gave her an understanding of information architecture—the importance of content structure and how systems retrieve information—all of which are relevant to digital design.

“I wanted to be more than just the writer, and decided at that point in my life another degree was one way to get on that path,” she said. “For me, it was a way to gain some experience and confidence.”

Because Lower was focused on writing, the biggest challenge she faced was being brought into a project too late to have an impact. She would often ask questions to understand the decisions that had been made, and sought out teams that would welcome those questions as part of design.

“I feel like I always need the full context of what I’m solving for, so it’s best for my work when I’m able to be in environments where I can get it,” she said. “If you’re joining a project at the very end and there’s low tolerance for questions, it’s a sign your role as writer hasn’t been well positioned or isn’t well understood.”

Don’t Apologize for Yourself

True story: A group of UX team members sat around a table, getting ready to participate in a design-thinking workshop. It’s the kind of session where the team generates ideas for how to improve a user’s experience with a product.

All but one person in this room had the word “designer” in their job title at some point: the person who didn’t have the title was a writer.

The group opened with an exercise where they were each supposed to create a rough sketch of a solution that would improve a piece of software. One by one, each person presented their idea and explained how it would help the user.

When the group got to the writer, he began with an apology. “Sorry,” he said. “I’m not a designer, but here’s my idea.”

It’s a small thing, but it’s important. This person clearly felt self-conscious, even though he was hired to be on a UX team at a large company. He was in this meeting because his ideas were good. In fact, his design sketches were just as good as everyone else’s, but at some point in his career, someone made him feel like his identity as a writer made his skills inferior to his teammates.

The point isn’t that you should immediately start conversations with your manager about changing your job title or that you should insist on people referring to you as a designer. Job titles are fluid, and most often, they depend on internal company politics.

The “writer” is whoever is doing the writing. The writer could be someone who specializes in the craft: a UX writer, content strategist, content designer, or one of many other variants. The writer could also be someone who works primarily in another discipline: a designer, developer, product manager, or a UX researcher.

Titles don’t matter when you’re trying to do the writing. What matters is that your team delivers words that meet the needs of your users throughout their experience. Writing is part of delivery. To create good software, you need words in it.

Some of the work of a writer involves giving other people guidelines or coaching so they can do their own writing. That’s important work, but it still requires that you think through the problem from the perspective of a writer who is designing the experience—someone who is using words to give meaning to each user’s experience.

Describing writing as design isn’t a power play. It’s a reality of any UX writer’s day-to-day work and an important way to approach your job. Like any other designer, you should be doing a lot more than writing. The best way to spend your time may be by researching user needs, prototyping solutions, testing your ideas, creating a strategy, or building rationale for your decisions. You might even be leading the product team and driving alignment around the direction of the product development.

Treating writing this way is new for a lot of people (and maybe you’re one of those people). That’s okay. It just means that your first task is to embrace your identity as a designer and help your team see it as well. Explaining your work and why it’s important isn’t an exercise in navel gazing or stroking your own ego. It’s part of helping everyone involved understand how words fit into the experience you’re creating.

Build Better Places

As you design with words, you’re creating digital places where people spend their time. It’s a big responsibility. One person who has spent a great deal of time thinking about, working with, and writing about using language this way is Jorge Arango. He’s an information architect and the author of two books on the subject.

Arango believes that one way to learn how to use words more effectively is to learn another language. “The reason I advise that is that it forces upon you, at a very deep level, an understanding that language is contingent on historical factors we take for granted,” he said. “Language is so important to us, and we acquire it so early on, that we can lose sight of the fact that it is a construct, and one that is evolving.”

However, Arango believes that writers have valuable skills to offer the technology industry—especially when it comes to creating names and labels for digital products. “I suspect that most people come to these decisions with vocabularies that are not as broad as the job demands,” he said.

As an example, Arango described how something like a News Feed (used by Facebook and others) brings certain user expectations. “News is the feedback mechanism of our society; we vote based on the things we learn in the news,” he said. “When we take a concept like that and we subvert it for commercial use, that’s something that should give you pause.”
This is the greatest responsibility you have when you use writing to design experiences. You’re not simply coming up with labels for buttons and navigation—you’re changing how your users think.

“Persuasion is a powerful thing,” he said. “If you are the person who controls the form of the environment by defining its boundaries through language, the persuasion will happen without me even knowing it’s happening.”

Writing the user experience may be difficult at times. It’s a skill that’s often underestimated and undervalued. However, it’s exactly what the world needs.

Finding What’s Right for You

Just like a designer designs the user experience, writers write it. There are many ideas in this book that will help you do the work, but it’s even more important that they help you think about the work. Your needs are unique, so don’t try to find one right way to do things. There isn’t one.

Instead, find what’s right for your users and your team. Adapt these ideas to your own work, and then expand on them and develop them. That’s how you go from writing to designing.

back to Writing Is Designing

Frequently Asked Questions

These common questions about card sorting and their short answers are taken from Donna Spencer’s book Card Sorting: Designing Usable Categories. You can find longer answers to each in your copy of the book, either printed or digital version.

1. I wrote our content on cards/sticky notes and our team shuffled it around to create the IA. That’s a card sort, isn’t it?
   Not really. That’s just shuffling content ideas around the table (which is still useful, just not really a card sort). I think the essential element to something being a card sort is that it involves real users of your information.
   See Chapter 1 for more information on what a card sort involves. 
2. I need to test that my draft information architecture is okay. Should I do a closed card sort?
   A closed card sort is where you ask people to slot content into a set of categories that you give them. It is useful to learn about where they think content goes, but a closed card sort will not tell you whether they will be able to find it. If you need to make sure that people can find information in your IA, you should give them a set of tasks and ask where they would look.
   See page 149 for more information on how to test your information architecture 
3. My website is really big. How do I get the card sort to cover it all?
   This can be really tricky because you can’t just give people an enormous pile of cards. You can sort with topics instead of detailed content, focus on just part of the site at a time, or run a series of sorts to get good coverage.
   More tips for large sites are on page 70.
4. How many people should I involve so the answer is statistically significant?
   Statistical significance is really not important–you want insights and ideas rather than the one true answer. You should involve enough people so that you see enough similarities and differences to help with your design project.
   More tips on selecting people are in Chapter 6.
5. Should I let people put cards in more than one place?
   Participants often ask if they can put cards in more than one place, especially when there is not one clear home for a card. I always allow them to do so. It gives me useful information about content that may cross categories.
   See page 99 for more questions participants ask.
6. What do I do with all this data?
   Ah, that is the big question. Spend some time just looking for patterns and “interesting” things in the data. Then dig a bit deeper and look at similarities and differences. You may not get one perfect answer, but you’ll always learn interesting things for your project.
   Read about analysis in Chapters 9 and 10.
7. I don’t remember my university statistics. How do I analyze all this?
   If you don’t know how to do statistics, that’s okay. Don’t try! There are ways to analyze data without statistics–exploring it, looking for patterns, identifying similarities and differences. And you’ll learn more than if you plugged it into a statistics tool and got an answer. But make sure you don’t collect more information than you need, or this will be impossible to do.
   See Chapters 9 and 10 for information on how to analyze with and without statistics.

back to Card Sorting

Author Cohorts by Theme

In 2025, we are organizing our marketing calendar by theme. That will help us to maximize the connections between our events, books, and workshops so we can promote them in a more effective way. If you would like to participate in one of the quarters, please let us know:

• Q2: AI, Technology and Automation
• Q3: Design Operations and Management
• Q4: Service Design, Information Architecture, and Customer Experience

You can participate in a quarter even if its theme isn’t your book’s main theme—they just have to be plausibly related. To participate:

• You’ll create content such as video clips, social media posts, and/or blog posts, and tag Rosenfeld Media in your social media posts and/or send us the assets, so we can promote them on your behalf. We can offer some guidance if you’re new to creating these assets.
• Request a Rosenfeld discount code to promote along with that content to help promote sales.
• Shout-out your fellow Rosenfeld authors in that theme (e.g., suggest their books for further reading, invite them to contribute to your podcast/blog/website, reshare their social media posts on your channels).

The goal is to not only talk about your own content but to support each other, and showcase the valuable thought leadership within our community.

We will help organize author cohorts each quarter, so please fill out the form if you want to participate:

Enterprise UX 2017

Frequently Asked Questions

These common questions about web accessibility and their short answers are taken from Sarah Horton and Whitney Quesenbery’s book back to A Web for Everyone. You can find longer answers to each in your copy of the book, either printed or digital version.

1. I’m not a designer (or I’m not a developer), so why should I read this book?
   It’s difficult to imagine a context in which one person could take a product, from soup to nuts, and make it accessible. There are so many decisions to be made, and accessibility must be considered at every step along the way. A designer or developer can’t make accessibility happen alone.If the decisions you make as part of your work impact someone’s experi- ence of a digital product, you need to know how to make decisions that will not result in accessibility issues. If you are leading an organization or a team, you may need to shake things up and change ow you do business in order to achieve accessibility. You can’t just tack it on and hope it sticks You need everyone to change their processes to make accessibility part of their practice.Chapter 11 looks at putting accessibility into practice.
2. This isn’t part of my job description, so whose job is it?
   The simple answer is that we are all responsible for making our part of a project accessible. Rather than try to list all the different roles, titles, and skills, we identify three big groups:

   Design: How will we create a great user experience for all?
   Design includes all of the disciplines of UX and web design: informa- tion architecture, interaction design, information design, graphic design, and content strategy.

   Content: What does the product say, and how does it say it?
   Content includes the ongoing work to plan and produce text, images, audio, video—all the information in the site or app.

   Development: How is the product built?
   Development includes programming, coding, scripting, markup, as well as the templates and stylesheets that content authors use.

   In Chapters 3 through 10, we identify both who has the primary responsibility for each aspect of accessibility and how all the other roles support it.

3. How big an issue is accessibility anyway?
   The U.S. Census Bureau says that over 47 million Americans have a disability of some kind. The UN and the World Bank say this adds up to 650 million people worldwide. That’s around 10% of everyone in the world.At some point in our lives, disability will affect most of us, no matter who we are, especially as we get older. By the time we retire, over 30% of us will have some disability, even if it is minor.To put a face on these numbers, we’ve created a set of personas of web users. They don’t represent everyone, but they will introduce you to some of the ways people with disabilities use the web. You’ll meet them in Chapter 2.
4. I’m already doing responsive design. Isn’t that enough?
   Working to standards and responsive design are both important criteria for accessibility. One way to think about accessibility is that assistive technologies, such as screen readers and alternate keyboards, are just another kind of device. When a site is designed to be flexible, it works better on all devices.
   Chapter 4 covers how to support accessibility with a solid structure.
   Accessible UX goes further, to be responsive to differences in people as well as devices. It’s about making sure that the ways users interact with your site or application (Chapter 5), navigate (Chapter 6), or read the screen (Chapter 7) allow for user preference.
5. Is content part of accessibility?
   It sure is! There are many reasons why people have trouble reading: cognitive problems like aphasia or dyslexia, physical or vision disabilities, low literacy, or reading in a second language. But even skilled readers can have problems when they are rushed, tired, stressed, or reading on a small screen. Accessible content is written in plain language (Chapter 8) and presented clearly and flexibly (Chapter 7).
6. Should I follow Section 508 or WCAG?
   WCAG 2.0, the Web Content Accessibility Guidelines, is a standard published by the W3C. That means it was created with input from people around the world and reflects the best international consensus. Section 508 is a national regulation in the United States. Other countries and the EU have their own laws and regulations.If your product is covered by a specific regulation, of course you must meet its requirements. But if you are thinking about accessibility for other reasons, WCAG 2.0 is the place to start. It’s a robust standard that is flexible enough to apply in different contexts—websites, desktop apps, mobile apps, even web-enabled teakettles can be measured against the WCAG success criteria.The good news is that most standards are very similar. The even better news is that the U.S. Access Board (the folks who manage Section 508) has proposed that the next version of Section 508 will use WCAG 2.0 Level AA as its requirements for web content. The EU is also working on new accessibility regulations, and we’ve been told that they, too, will be based on WCAG 2.0 Level AA. We have our fingers crossed, because in today’s global technology world, it would be great to have one standard for web accessibility.
   You’ll find a mapping of the accessible UX principles to WCAG 2.0 in Appendix B.

back to A Web for Everyone