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” (
