The User Experience Team of One

by Leah Buley

  • Strategy. Establishing a vision for the target user experience so you can design products that are coherent and unified.

  • Design Principles. A small handful of characteristics that collectively embody how the product design should be experienced by users. (See “Design Principles” in Chapter 7, “Design Methods,” for more information.)

  • Vision Artifacts. Diagrams, schematics, storyboards, or vision movies that convey the essence of the user experience and give a taste of how a person might experience a product that follows this strategy in the context of their normal lives. (See the tips for planning a “Strategy Workshop” in Chapter 5 to learn how to create low-fidelity vision artifacts with the help of your team.)

  • Roadmaps. An analysis of what needs to be built first, next, and last in order to deliver on the target experience.

  • User Research. Learning as much as you can about who your users are and what motivates them so that you can design products that meet their needs.

  • Primary User Research. Various methods for learning from users firsthand. Could include field research, diary studies, surveys, and other forms of guerilla research. (See “Guerilla User Research” in Chapter 6, “Research Methods,” for quick and dirty tips for conducting primary user research.)

  • Secondary User Research. Reviewing an aggregation of third-party research that has been conducted into this user population. Could include publicly available research or research that’s been conducted by other parts of the organization. (Marketing segmentation is one of the most useful forms of secondary user research for UX professionals to review, so if your organization has done segmentation work, definitely start there.)

  • Personas, Mental Models, and User Stories. Documents that synthesize what you’ve learned about users through primary and secondary research and distill the key points into a handful of memorable profiles, with supporting diagrams and stories for how the product should fit into their lives. (See “Proto-Personas” in Chapter 6 for more on personas. Indi Young’s book Mental Models is also an excellent resource on mental models.)

  • Design. Envisioning and specifying how a user will encounter a product or service from moment to moment in the most fluid, intuitive, and enjoyable way possible.

  • Information Architecture/Site Map. Documentation of how the system is organized, including major groupings, categories, or sections, as well as other pertinent information structures such as search capabilities, taxonomies, tags, or other forms of metadata. (Information Architecture for the World Wide Web by Lou Rosenfeld and Peter Morville is a comprehensive text, if you’re interested in learning more about information architecture.)

  • Process and Task Diagrams. Models for how users will interact with the system step-by-step, and how the system will adapt or respond based on what the user does. (See “Task Flows” in Chapter 7 for more information.)

  • Wireframes. Schematic diagrams of each page or state in the system. Usually, this means each screen in the user interface. (See “Wireframes” in Chapter 7 for more information.)

  • Design Comps. Detailed visual designs for each page or state in the system. If wireframes show a screen at a schematic level, design comps show a page exactly as it should look when implemented, including visuals such as color palettes, photography, typography, and other graphical elements.

  • Detailed Specifications. Extremely detailed documentation of how the system should function. Detailed specifications include things like how the product adapts in response to user interactions like clicks, swipes, and keystrokes. It also includes how to handle error conditions, and how the system adapts and evolves in response to various system and user states (for example, signed in vs. signed out, first-time visiting vs. repeat visits, and so on).

  • Style and Pattern Guides. Documentation of standard conventions for repeatable patterns. For style guides, this could be standard conventions for visual design or content. For pattern guides, this could be standard interaction conventions.

  • Prototypes. Functioning or semi-functioning examples of how the design should behave and operate once implemented. (See “Paper and Interactive Prototypes” in Chapter 8, “Testing and Validation Methods,” for more information.)

  • Implementation. Ensuring that the design works for users and that it is implemented according to plan.

  • Usability Testing. Various methods for assessing whether and how easily people can use the design to accomplish anticipated tasks. (Chapter 8 includes a range of testing and validation methods.)

  • Implementation Oversight. Sustained involvement between user experience designers and the engineering team to address additional UX questions as they come up and ensure that the design is implemented as planned.

  • Metrics/Analytics Tracking. Ongoing monitoring of key usage data to determine how people are using the product or service and to identify opportunities for future improvement or enhancement.

  One way to get clear on the boundaries of your work is to create a one-page summary of what services you provide—and, by implication, what services you don’t. Think of it as an offering card: a clear, one-page artifact that clarifies the range of activities you are responsible for. Figure 2.6 shows an offering card that I created when I was a UX team of one at Barclays Global Investors. (This can also be an incredibly useful tool if you’re a UX freelancer.) Figure 2.7 shows how you can use an offering card to clarify what updates you’ll be conducting for a specific project.

  FIGURE 2.6

  As you can see, this offering card is not a perfect match with the general process described previously. This particular one was customized to the specific activities that I conducted in that particular company and in that particular role.

  FIGURE 2.7

  When I worked on specific projects, I highlighted which methods were being used, to help people understand how this project fit into the broader user-centered design approach.

  NOTE A UX STARTER LIBRARY

  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 with and put designs in front of actual users. The “Guerilla User Research” method (Chapter 6) is a great starting place.

  Start Designing

  It’s a funny fact of user experience work that people expect that you’re going to produce designs that are just undeniably better. Lovelier. Simpler. More intuitive. You know, better. And you certainly don’t want to disappoint them. The challenge is that many of us come to this field by other routes, and don’t have formal design backgrounds. As a result, it’s not uncommon for a team of one to find himself or herself in a position of defending a design without necessarily believing or knowing with 100 percent conviction that it is, in fact, a better design. The challenge for user experience professionals is to understand user needs well enough to look past the prosaic solutions to discover the elegant ones (see Figure 2.11).

  FIGURE 2.11

  Sometimes the right user experience solution can be deceptive. While this giant remote may solve one problem (visibility and motor control when using a TV remote), it may also introduce other ones (the awkwardness of handling a remote the size of a TV dinner tray, perhaps).

  In fact, for many of us, our first taste of design is through a software tool that makes laying out a page easy, but doesn’t necessarily teach us anything about how people encounter and make sense of features and information in an interactive medium. While it’s tempting to throw yourself into the software and get lost in the satisfying process of laying out a page, that’s not necessarily the best way to ensure that designs are being developed that successfully balance user expectations, business expectations, and team expectations. This is where many of the tools of classically trained designers can come in handy for UX folks—in particular, sketching, critique, iterative improvement, and seeking inspiration from the world around you. Here’s how you can bring these techniques into your work as a team of one:

  • Sketch your ideas. The simplest and most beautiful designs are seldom born that way (see Figure 2.12). It takes a lot of work to make something simple. That process often starts with sketches and back-of-the-napkin inspiration, and evolves over time as you iterate, refine, and mold your ideas into increasingly higher fidelity. Chapter 7 provides a range of methods that you can use to guide yourself and your team through the sketching process.

  FIGURE 2.12

  Paradoxically, beautiful designs often start in an unattractive place, as mere sketches on paper or scribbles on a whiteboard.

  • Enlist colleagues to generate design ideas. Host activities that invite others to participate in the design process (see Figure 2.13). See Chapter 7 for a variety of techniques for planning and hosting such sessions—especially “Sketchboards,” which are tailor-made for this purpose. Figure 2.13 shows what a successful cross-functional collaboration between a UX team of one and her team should look like: lots of sketches and visual artifacts, and lots of notes as a record of the conversation.

  FIGURE 2.13

  An example of a completed sketchboard, explained in further detail in Chapter 7.

  • Learn from other successful products. Create inspiration libraries to keep abreast of current standards and have a place to turn for multiple ideas when working on a new problem (see Figure 2.14). But also question things. Spend time asking yourself “What makes a particular design work?” Equally importantly, when something doesn’t work, see if you can pinpoint why. You might even go so far as to practice verbalizing these thoughts (either to a friend, or to your mirror, if you’d prefer). Being confident in the language of critique is one hallmark of a
strong designer, and it goes a long way in helping nondesigners understand objectively what works and what doesn’t in an otherwise subjective medium.

  FIGURE 2.14

  An inspiration library can be as simple as a folder where you keep screenshots of designs you’ve encountered that are notable, either for being good or bad.

  If You Only Do One Thing...

  This chapter covers the building blocks of any UX practice. First, establish a point of view on where to start. Then figure out a sensible process with an appropriate balance between user research and design. However, the most important concept here—and indeed, the most important concept in the whole field—is to actually talk to users.

  So if you only have time to do one thing from this chapter, focus on getting started with user research. Usually, even a little bit of time spent investigating the needs and realities of users will lead to “ah-has” so important and obvious that they will create their own momentum to get you started.

  A Typical UX Team of One Job Description

  If you happen to be in the job market, it can be helpful to know how to spot a UX team-of-one situation. Few UX jobs are advertised as a team-of-one gig, but there are usually telltale signs that give them away. Figure 2.15 shows a job description that is adapted from several real jobs posted to a popular UX job board.

  FIGURE 2.15

  This is, in many ways, a standard UX team-of-one job description. This employer shows a clear awareness that user experience is essential in creating a competitive product, but the employer might not know how it will integrate with the company’s existing way of working.

  This job description shows an employer who is looking for someone who can drastically improve the quality of the user experience. The product will be “elegant,” reduced to the “bare essentials,” and “beautiful.” People may not say it directly, but there’s usually an expectation that having someone who will focus on UX will result in changes to the product that will immediately wow everyone. This can be a tricky expectation to manage, since design improvements often happen gradually, over time. The design methods in Chapter 7 show you how you can improve the quality of the product and bring people along with you in the process.