Читать книгу The User Experience Team of One - Leah Buley - Страница 21

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.)

• 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.