The User Experience Team of One. Leah Buley

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