The User Experience Team of One. Leah Buley

      If you’re interested in reading more about the fundamentals of UX and how a typical user experience project is structured, start with the books on this shelf (see Figure 2.8). These books ably cover what user experience is, why it matters, and how to practice user-centered design.

FIGURE 2.8 A user experience starter library.

Establish a Point of View on the Work to Be Done

      Before you get started, it’s a good idea to have a clear picture of what work needs to be done and how you can best contribute to it. The good news is, you don’t really need permission to be a UX team of one. You can infuse the UX philosophy into work that you’re currently doing. You can also find small opportunities to get started. You might think that if you want to transition to UX, you should start by changing your title and your role. But asking for a wholesale role change before you’ve gotten people to understand and see the value in UX might be a long shot. It’s better to start doing UX-related activities in smaller, under-the-radar ways, and then build momentum from the positive support that your work causes.

      Here are a few recommendations as a foundation for any crossover. They’re not UX activities per se, but they pave the way for them:

      • Find the low hanging fruit. Entice your colleagues with a vision of what might be. Find the parts of the product that everyone knows need improvement, and then plan your attack from there. However, it’s key to do it in a way that is positive and respectful. Use a “Black Hat Session” (Chapter 8) to get people thinking about where and how your product might be improved, or a quick “Heuristic Markup” (Chapter 6) to do the legwork on your own.

      • Make a plan. If you want to get people to buy into the concept of UX, you’ve got to be offering them something of value. How do you do it? Sit down and sketch out how you’d like to approach a UX project. Think about what activities you’d propose—when and why. Think about what big questions you believe need to be answered, and work your way backward in thinking through how you’d answer them. Write a “UX Project Plan” (Chapter 5) to make it clear in your own mind. And then, ask yourself, “Do I need permission or support to do this, or is it possible that I might be able to do it now?” You may find that the answer is that you can just get started right away.

       NOTE METHOD CARDS

      Method cards are a great tool for identifying quick activities that you can do in the course of a normal workday to infuse a user-oriented perspective in your work. The user experience design firm IDEO has created method cards that can be purchased (see the top box in Figure 2.9). Trading cards from the user experience design firm nForm are shown at right, and they can be found online: http://nform.com/tradingcards/. Or you can create your own collection, as shown at the bottom.

FIGURE 2.9 A variety of method cards.

       TIP BYPASSING OBJECTIONS

      If you encounter objections and you need permission, the following tip might be helpful. Sales pros have a clever technique called the “alternative close.” Instead of asking permission to close the deal (or, in this case, to do the work), they provide two alternatives for how to go about it. Not, “Can I ring you up?” but rather, “Will that be cash or charge?” In UX, an equivalent would be not “Can we do some research,” but rather “We could do a large research study, or we could do a small informal evaluation to get some quick feedback.” Then the negotiation becomes not if, but how.

Get to Know Your Users

      Once you’ve identified some opportunities and developed a rough plan, your next priority should be to get firsthand experience with users, talking with them and learning about their needs. Users are at the core of user experience. Simply put, they are the people who use your products. It’s important to keep these people in mind when designing products because they’re the ones who will endure firsthand the consequences of myriad design decisions.

      Good products eventually become somewhat invisible, sinking into the background as users achieve a kind of flow where they’re actively and fluidly doing whatever the product is supposed to make possible. Not “posting to a wall,” but responding to a friend. Not “formatting a Word document,” but writing. If you’re a product maker, this is nirvana. It’s also darned hard to accomplish. In fact, you’re virtually guaranteed to get some of it wrong—especially at first—which is why the field of user experience places a big emphasis on understanding user needs and testing the design of products with users. This emphasis on connecting with users is so essential that it’s one of the core tenets of user experience: design products for and with users.

      Personally I dislike the word user. I much prefer to call them, simply, people. That helps me remember that it’s the people all around us that we’re designing for. But to design for people, you have to know something about them. That means you must resist the tendency to treat them as flat statistics derived from market segmentation and strive to understand them as the complex, erratic animals that they all are. Eric Ries of the Lean Startup movement has a great one liner that sums it up perfectly: “Data are people, too.” This requires you to suspend what you know and adopt someone else’s perspective long enough to feel their pain and envision better alternatives (see Figure 2.10). That’s harder than it sounds, which is why it’s essential that you take time to actually get to know real users.

      

FIGURE 2.10 A well-designed product enables a user to accomplish his goal efficiently and without confusion or disruption. When a user encounters a breakdown in the system, it really shows.

      It’s shocking how many people say they’re practicing user-centered design, but rarely talk to actual users. Don’t be one of them. Real UX teams of one are committed to knowing not just “users” in the abstract, but the people who really use their products. It pays off. Jared Spool of User Interface Engineering has done research that shows that the amount of face-time a team has with end users directly impacts the quality of the product. You can read more about the optimal number of user “exposure hours” here: www.uie.com/articles/user_exposure_hours/. So it’s very important to start reaching out and talking to your actual users. Here’s how to do it:

      • Figure out what you know (and what you don’t). Learn how to gather available user data and use it as a tool to guide your work in Chapter 6. Specifically, you can use the “Proto-Personas” method to turn users into people.

      • Do guerilla research. Even if you can’t get formal support to do it, there are a host of lightweight ways to connect