by Leah Buley
The term user experience probably originated in the early 1990s at Apple when cognitive psychologist Donald Norman joined the staff. Various accounts from people who were there at the time say that Norman introduced user experience to encompass what had theretofore been described as human interface research. He held the title User Experience Architect, possibly the first person to ever have UX on his business card. Norman actually started out in cognitive psychology, but his writing on the cognitive experience of products, including technological products, made him a strong voice to lead and inspire a growing field (see Figure 1.8). According to Don Norman, “I invented the term because I thought Human Interface and usability were too narrow: I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.”
FIGURE 1.8
Norman’s book The Design of Everyday Things is a popular text that deconstructs many of the elements that contribute to a positive or negative user experience. It’s still pretty much required reading for anyone who is interested in UX.
UX and UI: What’s the Difference?
You may find that the average person is more familiar with the term UI than UX. UI refers to the user interface, or the screen through which a person interacts with a computer or device. Because most people have used computers at one time or another and have had encounters with UIs that were both good and bad, they often have some idea of what a UI is, and why it matters. UX, on the other hand, is a more intangible concept that encompasses not just UI, but also the hardware, the user’s context of use, and the user’s goals and motivations. That’s a lot harder to cram into one mental picture. To explain the difference to others, it can be helpful to provide a tangible example. For example, PayByPhone is a service that integrates with parking meters to solve a basic problem: paying for parking even if you don’t have change. The picture on the left in Figure 1.9 is the app’s user interface, or UI. The picture on the right conveys some sense of the broader user experience of needing to pay for your parking, discovering that there’s an alternative way to pay, and then trying to figure out how to do it.
FIGURE 1.9
With the PayByPhone service, the user interface is just one part of the overall user experience.
With the rise of personal computing in the 1980s and then the Web in the 1990s, many of these trends converged on each other. Graphical user interfaces, cognitive science, and designing for and with people became the foundation for the field of human-computer interaction (HCI). Suddenly, more people had access to computers and, along with it, a greater need to understand and optimize their use of them. HCI popularized concepts like usability and interaction design, both of which are important forebears to user experience. In the Internet bubble of the mid and late-1990s, new jobs with titles like “Web designer,” “interaction designer,” and “information architect” began cropping up. As people became more experienced in these roles, a deeper and more nuanced understanding of the field of user experience began to develop. Today, user experience is a rapidly growing field, with undergraduate and graduate level programs being developed to train future generations of professionals to design products for the people who use them.
Where UX Professionals Come From
The field of user experience grew primarily out of human factors and usability—both fields with very strong ties to the world of software development. As a result, people often connect UX with user interface design. This isn’t completely inaccurate, but it’s just one part of the story. Increasingly, UX doesn’t even have to involve a technical product. Service designers, industrial designers, physical space designers, and those people who are designing for an increasingly networked world are all working on the same basic problem. How can they design flowing experiences that respect, empower, and delight real people?
So does that mean that anyone can be a user experience team of one? Not necessarily. Certain backgrounds are better grooming for user experience than others. You’re a good candidate for user experience work if you have past experience in one or more of these areas:
• Web or software design and development. This is a natural one. Many of the elder statesmen of the UX world started out as Web masters or Web designers. And indeed, a big focus of their work may still be Web-oriented, depending on what type of product they work on. People with this background make good UX practitioners because they’ve probably seen firsthand how users make sense of and interact with unfamiliar designs. The fact that they know a bit about Web technologies helps, too.
• Editing, journalism, or copywriting. This field is also a common pathway into user experience because it is fundamentally about how people consume and make sense of content. That’s true whether it’s in print or digital. People with this background are naturals at thinking about the reader’s needs and perspectives, which translates directly into the user’s point of view. These folks also think a lot about how voice, tone, and structure influence a reader’s perceptions and experiences with a medium. That’s a good thing.
• Graphic or print design. The user experience is impacted by decisions that are made at every level of the product. But when end users think of the product, they usually think of the parts that they can see and interact with—the visible, surface level. Graphic and print designers are trained to think about how people see and respond to layers of visual information. They have the ability to create designs that convey practical information, while also evoking a desired emotional reaction. People with this skill know how to design for understanding, as well as meaning, which is a very user-centered ethos.
• Research, sociology, anthropology, and psychology. Understanding and empathizing with the user’s perspective is a vital foundation for user experience design. People with this background know how to conduct studies or experiments to uncover what people really do and why. That can be harder than it seems. It’s very easy for the observer to unconsciously change the behavior of the observed. But sociologists and anthropologists have rigorous methods and techniques for getting at what people really do. They also have the ability to turn a dizzying array of observations and data points into broader themes and ultimately meaning. These themes and their significance become the foundation upon which user experience design decisions are made.
• Engineering. Engineers and developers write the code and build the systems that make the experience real. That moment when a flat concept on a page becomes a working, functioning, interactive thing is like making life. It’s incredibly rewarding. It also enables them to see and understand how it will feel and function for the end-user. And sometimes, it doesn’t feel or function like they thought it would. So they iterate and adjust. Engineers are skilled at jumping back and forth between the two mindsets that make this possible: the maker’s mindset and the tester’s mindset. This cycle of making and adjusting and making and adjusting is the fundamental flow of user experience design.
• Product management and business analysis. People in these roles are often the bridge between many different parties who contribute to product design. Consequently, they have one of the broadest views of the ins and outs of the product. That holistic perspective often enables them to envision where the weak points are—not just from the perspective of the project plan or the business goals, but also the user experience.
How about you? If you have one of the titles listed above, you may already be doing user experience work, whether you realize it or not. Or you may have come to user experience by a circuitous path. Possibly you started out in one of these fields and are now crossing over. Whatever your origin, you are here now, and you believe that user experience matters. You understand that it makes the difference between products and services that must be suffered through, and those that delight and inspire. Now, how do you start working as a UX team of one? In the next chapter, we’ll take a look and find out.
NOTE A UX TEAM OF ONE CAN COME FROM ANYWHERE
I know
of one UX team of one who started out as a general contractor. Thinking about questions like how close to make the electrical outlet to the sink naturally got her thinking about user-centered problem solving more generally. And that led her straight to user experience design.
If You Only Do One Thing...
This chapter establishes some basic information about the field of user experience. What is it, where does it come from, and what skills are required? We begin this way because understanding what user experience is and being able to explain its importance to other people is the first, and often the hardest, thing you need to do. As a UX team of one, you are pretty much guaranteed to find yourself in situations where you are asked to clarify what UX is and justify why it’s important.
So the most important thing you should take away from this chapter is an understanding of how UX is defined. Even better, try to think in terms of examples—either the example given in this chapter or one of your own. Examples are effective at triggering memory and imagination. A well-chosen example will help you illustrate the complexity of user experience and what design elements must be executed well to create a distinct and positive user experience.
CHAPTER 2
Getting Started
Get to Know the UX Toolkit
Establish a Point of View on the Work to Be Done
Get to Know Your Users
Start Designing
If You Only Do One Thing...
Many people make their way to user experience by crossing over from an adjacent field. These crossovers are the people who are carrying UX forward, taking it to new levels and new organizations.
Learning about user experience can often feel like a discovery. For many, that moment of discovery might feel like a revelation, as if they’ve found a calling. Because it’s an experience that can ignite a lot of passion, crossovers are often enthusiastic ambassadors for user experience. Crossovers can come from engineering, visual design, technical writing, and project management. There are other areas, too; it’s a diverse community. The reality for many crossovers is that UX or usability is now and may remain just a part of what they do. Even so, there’s nothing stopping a new crossover from getting started. Many seasoned UX professionals started out by seeing an opportunity to improve something and seizing it. In this chapter, you’ll find a basic framework for diving in. In fact, framework may be overstating the case. It’s really just four simple steps:
1. Get to know the UX toolkit.
2. Establish a point of view on what can be improved.
3. Get to know your users.
4. Start designing.
Get to Know the UX Toolkit
Many models and diagrams have been created to illustrate the typical UX set of offerings, and they can be a great place to start in understanding the UX process, and how it fits in with other business processes (see Figures 2.1–2.5).
Figure 2.1 shows a model that was created by Todd Zaki Warfel when he was at Message First. It gives a good sequential overview of the activities that are conducted in a typical user-centered design process, with helpful distinctions made between functional design, content analysis, interaction design and information architecture, and engineering.
By contrast, the model in Figure 2.2 from David Armano at Edelman Digital places more emphasis on the major conceptual phases of work that you go through in a user-centered design process. His Uncover > Define > Ideate > Build > Design framework is nice because it helps you think about the higher-level goals of each phase.
FIGURE 2.1
Todd Zaki Warfel’s UX model.
FIGURE 2.2
David Armano’s UX model.
Figure 2.3 shows a model from Namahn Design in Brussels. Styled like the London Underground map, it shows the relationship between specific methods and activities.
For a different way to visualize the UX process, the model in Figure 2.4 from independent consultant Stephen P. Anderson focuses not so much on phases or deliverables, but rather on the primary considerations to take into account when designing user experiences.
Like many of the previous models, the model in Figure 2.5 from James Kelway of the Danish design firm Hello Group shows the key phases and activities or deliverables within each—but in a sketchy, low fidelity way.
FIGURE 2.3
Namahn Design UX model.
FIGURE 2.4
Stephen P. Anderson’s UX model.
FIGURE 2.5
James Kelway’s UX model.
My Crossover Story
Here’s how I discovered UX. When I was growing up, I always wanted to be a writer. When I graduated from college, I got a job in what seemed like the most logical field—working at a magazine. The trouble was, I kept nodding off over my copyediting. There was one part of my job that I loved, however, and that was updating the website. I had picked up some rudimentary HTML skills in college. Soon I found that my favorite part of each week was the time I got to spend on the website. So I decided to take the leap and become a full-time Web worker.
I put my resume online and quickly got in touch with a recruiter from a tech firm. It was the 1990s tech bubble, and HTML skills—even rudimentary ones—were in high demand. I tinkered around as a front-end coder for a few years, but couldn’t shake the growing conviction that I would really rather be doing what those people with that funny title “information architect” were doing. Not writing code, but thinking about things from the human perspective and designing systems that were intuitive. So I went back to school to study information architecture. While I was working on my master’s degree, I took what I now realize was my first “team of one” gig. My title was “tools developer” for a boutique firm (that means little company) that helped law firms manage all the data that they had to keep track of when companies filed for bankruptcy. Glamorous stuff. They hired me presumably because of my technical skills, but they liked and benefited from the fact that I was interested in design and usability, too.
It was a good training ground because they had a lot of funky, homegrown applications that needed plenty of UX help. It was a great place to test out the principles I was learning in school. I designed a slew of software interfaces. I spent time thinking about solutions for navigating large repositories of information. I conducted usability tests. It was also a great place to discover how little other people understood or valued the concept of user-centered design. Or, to put it more fairly, it exposed me to the challenges of getting people to prioritize user needs and design when there were so many other fundamental and urgent business issues to be addressed. And finally, it was where I learned the hard lesson that not all companies need or are ready for their team of one. That’s okay. Eventually, I knew it was time to move on. What I learned there I put to good use in my next job, another team-of-one gig, but this one was a lot more rewarding.
So, what skills and experiences got me on the path? Just a handful:
• Familiarity with the concept of user experience
• Interest in how people think, understand, and see
• A little bit of technical know-how
• An opportune environment to tinker and practice
• Just enough education to fuel my experiments
As you can see from these examples, while there’s no certified process that all UX practitioners follow, you’ll find a relatively standard set of activities and deliverables that they all use. A large UX team may have the luxury of conducting most of these activities on a given engagement. Teams of one use many of these methods, too, just sometimes in less depth or without putting quite so many methods together into a full-fledged work plan. It’s helpful to start with an understanding of the full roster of options, though, and then think a bit about which ones seem most useful in the work that you’re doing.
NOTE FOR MORE INFORMATION ON THESE METHODS
Most of the methods described here are further explained in Part II, “Practice,” of this book. Where that is the case, you will see a cross reference.
What follows is a fairly exhaustive list of the activities that may take place in a typical UX process.
• Discovery. Figuring out where you stand and what you need to do so you can design products that meet the business’s needs.
• Stakeholder Interviews. Spending time with key decision makers to understand their expectations for the product, plus any other important considerations that you should be aware of. (See “Listening Tour” in Chapter 5, “Planning and Discovery Methods,” for a lightweight way to conduct stakeholder interviews.)
• SWOT (Strengths, Weaknesses, Opportunities, Threats) Analysis. Various methods for assessing the strengths, weaknesses, opportunities and threats that impact the user experience of a product. First developed as a strategic planning tool, a number of UX techniques such as competitive review, content audits, and heuristic or expert reviews ultimately fall into this category. (See “Opportunity Workshop” in Chapter 5 for an inclusive technique that gathers SWOT information with the help of a team.)
• Requirements Gathering. The process of working with business decision makers and others on the team to determine what must go in the product and, in some cases, how it must be implemented. (See “Strategy Workshop” in Chapter 5 for a method that uncovers explicit and implicit requirements.)