The User Experience Team of One. Leah Buley

      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