The story of how my approach to designing experiences evolved illustrates how your perspective can influence how you position your team within the processes and culture of your organization. When I started at Bell Labs as a researcher, one direction the work was taking in my department focused on the paperless office. By the time I left, while research continued to look for new experiences and the value they could bring, much of the industrial user experience work was focused on usability. Usability as a discipline was taking off and its focus was clearly on removing design problems. Many of us have offered critiques of usability methods even as we employ them. They have been useful and fit within the way user experience is implemented within corporations, but many clearly come with inherent limitations and have created a practice that at times is less rigorous than it should be (Gray & Salzman, 1998; Lund, 2006; Lund, 1998). When I was at Ameritech I began to realize that we could remove all the design problems and still have a disastrous product in the marketplace.

At Ameritech, because some of our budget was in the form of common funding that did not depend on individual projects, we were able to study how to create not just error-free products but more important, successful products. This research brought the kinds of insights to the business that resulted in a new brand promise for Ameritech and a new ad campaign. Ameritech was already pivoting around our elevator pitch at that point, and the consumer business unit proposed to put a human factors seal of approval on their products. Unfortunately, no thought had been given about the metrics that would qualify a product for the seal. As a result, we began a project in collaboration with the researchers within the business unit’s market research group and the University of Michigan Business School to understand what made successful products (Schwartz, Thomson, Seifert, & Shafto, 1996). This was the kind of project that provided high executive visibility and made it clear UX could shift an entire business plan.

The study took a wide variety of experiences in people’s lives and evaluated them on a set of experience dimensions. We then looked for clusters in the data that predicted various aspects of the experience. After the study we were able to say things like “Using Caller ID is easier than using a light switch.” That was such a powerful idea that the marketing people represented it in one of Ameritech’s ads (Lund, 1996b and shown in Figure 5.1).

Using data that let us study how the factors predicted usage, we built the model shown in Figure 5.2. The parts of the model that we feel the most confident in shaped the way we describe our vision and mission as well as metrics we have defined to track progress towards business impact. The argument we make is that satisfaction is the biggest driver of usage, so the expectation of satisfaction is the best predictor of adoption or intention to adopt. The biggest predictor of satisfaction is the expectation of usefulness (or past experiences of usefulness). Ease of use also predicts satisfaction, but it appears to operate through usefulness by “revealing” the usefulness. In other words, poor ease of use gets in the way of usefulness.

The nice thing about this model is that it makes it very clear how and why the work we do impacts the business benefits of products and other solutions on which we are working. This set of factors interestingly maps nicely to the ISO 9241 (1998) definition of usability as including efficiency (similar to ease of use), effectiveness (similar to usefulness), and satisfaction. That means as we talk about our mission, we can also ground it in international standards and when needed we can draw on tools built around those standards such as the CIF (the standard research reporting format for summative data) and the CIF-R (the emerging standard for user requirements) to support arguments we are making (ISO/IEC 25062, 2006).

As I was doing this work, I found that it converged with research in the MIS area on a Technology Adoption Model (TAM) based on expectation theory (Davis, 1989; Davis, Bagozzi, & Warshaw, 1989; Venkatesh, Morris, David, & David, 2003). Furthermore, people were beginning to extend the TAM model and related questionnaire instruments to product areas like those in which we were working. This research as well as exploration of models continues to improve the prediction of technology adoption. It has been gratifying to talk to companies who have applied this view of what drives product adoption and success to the organization of their user experience teams, and to see the broad use of the USE questionnaire as a means of assessing user experiences along the dimensions. Whether you have a model like this one or another you like to use, having a clear point of view about how you deliver business value is a powerful tool in defining your team’s role within your organization. It also provides a framework around which you can build standard tools and processes and rationalize their use.

One of my first conversations with Monty Hammontree was about this model. I remember sitting in a conference room with him in the building where I had my office. We were sketching alternative models on the whiteboard that showed what makes great experiences and our thoughts about what we should do to raise the bar on product quality. It has been fascinating to see Monty take the ideas we brainstormed and combine them with the ideas he had been developing and other insights he has gained since then (he is one of the best read user experience people I have ever met in the area of the theory of design and innovation) to develop the vision that he used to energize his team and to transform the broader user experience community.

While educating the organization about why UX work is important for the business, I have been extending the model in a couple of directions. These extensions are based on my interpretation of some of the more recent data on the TAM model, as well as our experience in practice with more personal technologies such as Tablet computers. First, we overlaid the aesthetic factor on the model. There is a suggestion that the visual characteristics (the aesthetics) of the design say something to users about what the functional and ease of use characteristics will be (e.g., see Cheskin & Sapient, 1999, for a discussion of aesthetics and trustworthiness). This appears for some products and applications, but not others. I am still working out how best to present the model, but the version in Figure 5.2 works for most situations within the business. In general, this factor is intended to capture both the aesthetics and therefore much of the visual (or sensory) attributes that are associated with brand. It seems to operate at the point of first exposure by attracting the user to the solution in comparison to other alternatives. A well-designed object has a tendency to lead users to expect ease of use and usefulness even before they touch it.

The visual or sensory aspects of applications can be the goal that a solution is designed to satisfy (like an entertainment product). So we have also expanded the concepts of ease of use and usefulness to the broader concepts of cost and benefit, with the argument that users implicitly or explicitly build expectations of the trade-off between the two as they decide whether they will be satisfied and decide to use something. The costs may include the time it takes to learn, to change from something familiar, the social pressure they will receive, or risk to their data or other factors in addition to issues with ease of use. The benefits may be delight, personal expression, or social praise, as well as functional value.

This model gives us a language to talk about how we deliver value to the business. People tend to get it. We can also talk about the role of visual design as it delivers on the aesthetic, brand, usability, and emotional connection; interaction design as it builds usefulness into the user interface and contextualizes the experience to ensure ease of use; and research as it helps uncover and validate usefulness and as it identifies problems that reveal the usefulness. We can talk about how we need to be involved very early in the process where we can help uncover new opportunities for value. We want to be involved early in the process because that is where we build in the usefulness (saving downstream costs that come from trying to fix things that are very expensive to correct by that time). We also want to be involved later where we polish off the rough usability edges and after release where we can measure how well we have delivered on the initial goals. The model even gives us the language of quality in use, and the metrics that the organization should be focused on throughout the process (using questionnaires like USE for the subjective measurements to complement efficiency and effectiveness performance measurements).

An additional implication of the model speaks a bit more to the end-to-end life cycle story around user experience. One way to look at technology diffusion is seen in Figure 5.3. In this model, people have to become aware that the solution will be useful (they can expect satisfaction), and that the value outweighs the value they receive from current solutions (the value proposition). This happens in the attraction stage. They hear about the value from their friends, press, or advertising. When they see it on the shelf, its design calls to them. The brand leads them to have expectations about the value. UX contributes content to these stories, and this provides a rationale for trying to build a close partnership with the marketing and market research teams within your organization.

If users believe there is a possibility of value, they are more likely to try the solution. The trial stage includes activities like playing with the model at a neighbor’s house; testing it in the store; and taking it out of the package, turning it on, and taking those first few steps to use it. As we design and evangelize our designs we lift the use cases for the core value high in the interface so they pop in the experience and are intuitive to use. These have to be very easy. The ambiance of the design is a part of the initial experience, and the experience must not violate the brand promise and the promise of the aesthetic. If in that initial trial stage the person discovers yes, there is value that justifies the cost of adoption, they begin to move into commitment. Traditional usability, embedded assistance, and high-end design are all critical in shaping an experience that leads to commitment.

This jump into commitment typically takes time and effort. As users step through the commitment process, they need to feel they are getting more value and the experience is becoming easier. To design to reduce the friction of committing to a product requires a deep understanding of the users and how they achieve their goals in context, and the designers need to collaborate with the architects to ensure the solution is architected in a way that supports the expected scenarios of use. This type of research tends to be more ethnographic in nature. This work also uncovers the kinds of stories and scenarios that marketing and sales will want to use. This is another great place for collaboration with marketing, and when you engage project management and development (and ideally even test) up front, they become advocates for the design and the user throughout the design process and are more effective participants in increasing the innovation of the design.

One of the insights gained when I was in the Tablet group was that the life cycle does not stop with commitment. We heard an interesting talk by a consultant from Doblin where the notion of extending the experience was presented. If Disney can get you into the movie, they can get you to buy the toy. With the toy, they get you to Disneyland. From Disneyland you are soon buying the clothing, and going back to the next movie. For many of our products, what we really care about is not just the isolated product but having you buy into the entire ecosystem so that you are buying products not just from us, but taking advantage of the innovations created by our partners. Because you have the products from the partners you continue to be excited about ongoing innovations in our platforms.

I am describing the approach I have taken because it provides the rationale for the strategic plan I developed for my current organization. Other models and areas of focus are certainly possible and could make sense for your context, but what you learn here is that your point of view about how to deliver value provides the rationale for your strategy. It gives you a framework for thinking about what you are doing, how you deliver value, and how you talk about it.

The vision statement answers the question Where are we heading? by painting the picture of the goal with words. Like a vision for a design that aligns the roadmap of planning, the vision for your team should provide a focus and inspiration for your strategy and your tactical plans. It is the destination of the journey. It should not sound like everyone else’s vision statement. It should capture something unique about what you and your team want to do. It should be aspirational but plausibly achievable.

The vision statement typically is internally facing and is a tool for the team. Given its function, it is the kind of statement that should be created by the team. With every team member’s fingerprints on it, it is more likely to engage them all, align them, and energize them to attain the vision together. There is no size limit typically, but it is usually one or two paragraphs. You do not want it to be so long the statement gets fuzzy, but you want enough description for the vision to be clear. Beware of a statement that is so ideal and visionary it could never be achieved and so ambiguous that it could apply to any team.

Here are some ideas that will help to create a vision statement:

One approach is to have your team gather, and after reviewing other relevant vision statements and your own mission statement, set the stage for the dreaming and brainstorm elements of the vision. Put the ideas up on the board. Ask probing questions to stimulate additional brainstorming as the ideas slow down to ensure that you have thought about the future from the various perspectives that might be relevant. These might include the categories in the SWOT analysis; the perspectives of your users, your company, and your organization; and your own passions. Then use affinity diagramming to organize these ideas into clusters of elements that the team wants included in the statement. Finally, grab representative phrases that capture the clusters and put them into some type of logical order. Avoid spending too much time fighting over the wording as a group, because it is easy to get caught up in fighting over individual words and stall the progress. Just ensure you have the main ideas that everyone thinks should be represented in some fashion, and then go away and try to do an editing pass to tighten it up. Take the proposed wording back to the team and do an additional pass or two for refinement. Keep the accountability for the final statement rather than delegating it to the consensus of the team or a vote, since ultimately you need to defend it and drive the overall plan from it. Do try to ensure that it represents reasonable consensus.

I held a couple of exercises to help create the vision and mission statements for our UX community. The first exercise was at my first offsite with my freshly grown UX team. We had doubled in size, and anytime you make a major change in a team you need to go back to that forming stage in the growth cycle. As a result we had an offsite where we talked through our shared values, and we also brainstormed our vision of what the ideal world would be like if we could remake it however we wanted.

For our second exercise, we brought in a colleague from a local consulting company. He had been inside the company, and he and I had been talking about working together to drive a vision and mission definition exercise for the UX community within IT before he joined the consulting firm. Our objective was to create a common UX strategy across IT, a strategy that would emerge from a vision that was aligned with the larger business strategy, the culture of IT, and our brand values. We wanted to develop a game plan that would inform organizational objectives, processes, individual commitments, and other systems that we believed would contribute to the success of IT UX. We knew that this would require a special emphasis on understanding current organizational objectives and strategy, and the pain points around how these organizations currently deliver user experiences. So we began with a discovery effort that uncovered all of the relevant current UX objectives and systems used to deliver on the objectives, and the brand strategy as it was expected to relate to IT. My colleague worked with one of the team members to run it. Over 25 people from across organizations and disciplines with a shared interest in IT experiences participated in a full-day workshop to develop a shared understanding of the current context and to create the strategy for the future. Participants generated over 500 unique insights that informed the work.

Before the workshop we began by gathering relevant vision and mission statements (e.g., from IT), and the brand promise. A SWOT analysis was also conducted, which identified strengths, weaknesses, opportunities, and threats surrounding user experience in its current organizational context. Participants were then divided into teams and the teams worked through a list of strategic initiatives that had been proposed in our initial three-year strategic roadmap. The teams brainstormed objectives around each of the initiatives. They considered the future, what it would take to enable it to happen in the general category of the initiative, and what the blockers might be. The objectives were then clustered into themes, and the themes were used to propose updates to the strategy. This analysis in turn enabled the creation of a mission statement that was built around what the organization is able to deliver, clarity on who is being targeted, and how the mission is accomplished. The statements around the “to be” state were combined subsequently to create a vision statement. The mission and vision statements were then iterated and tweaked with the individual user experience teams, and then edited a bit to work across the entire IT UX community. In addition, specific recommendations were derived from the workshop about how to implement the strategy as it reflected the mission and vision, and to increase the impact of the community. The final vision statement read:

The mission statement is a brief description of the purpose of your team or UX program that answers the questions Why do we exist? and What do we do? It defines the fundamental purpose of the team. It spells out the overall goal, provides direction, and should guide decision making. Often mission statements persist over a considerable period of time, but the vision may evolve as the context evolves. It is not an objective and typically does not have a time line. It is an overall goal that is accomplished as the objectives of the organization that align with your strategy are achieved.

The mission statement certainly contains the purpose or aim of your team, and may include pointers to the stakeholders (e.g., users or the company), responsibilities of your team toward them (e.g., delivering delight, satisfaction, or business value), and the kinds of services offered (e.g., user research and design). It should speak to what you do, but can also make it clear what you do not do. The statement should be broad enough to allow for creative application and change, but distinguish what you do from other teams in the organization. Try to avoid including too much jargon, since many audiences will need to get it on first hearing it and remember it as they think about engaging you in the future. Aim for substance as you create it. Shaping the mission statement becomes most powerful when it is created collaboratively and everyone’s fingerprints are on it. The common misuse of the mission statement is creating one that describes high-sounding values that are unrealistic or not part of how you actually will operate day to day.

Unlike the vision which is internal, the mission statement is typically external and should be freely used to frame what your team is about and set the stage for conversations with clients/partner organizations about how you are going to apply it to their needs. A simple structure for a mission statement is to describe what you do straight out and then describe how you do it. The how section should capture some of the values your team agrees should be part of the way you do what you do (e.g., provide simple, usable design; enable innovation; and create customer relationship). A good way to finish is with the “why” — the spark or passion behind your mission (e.g., “to create customer delight”).

As with the vision statement, a place to start is with the existing context of mission statements of the larger organization and the vision statements (including your own). You can then have team members brainstorm words, phrases, and ideas about the needs you want to address, what you do to address the needs, the principles you want to emphasize and incorporate in your work, and expected outcomes (Figure 5.5 shows one typical session). Once you have everyone’s ideas for content, organize it into categories using affinity diagramming. As a team, identify phrases and words that seem to capture what is being said in the clusters. You can cluster them together based on what you do, how you do it, and outcomes (or another common alternative is “to do outcome X, we do Y by/through Z values”). You will probably end up with several usable statements after the initial pass. It may be worth letting the statements percolate for a bit and revisiting them as a team to further integrate them. Finally polish it and then begin to roll it out. As a good user experience team, you may want to test it on a few key people and bring the results back for a little more design improvement before a broad rollout.

As with the vision statement, the final polishing is best done with a smaller group. It is often better to just rough it in, and then have one or two people (including yourself) edit it into to something that works and that you can personally live with. Then take it back to the group for sign-off and perhaps a little more discussion and revision. You want team members to feel the mission is theirs, but you also want to be designing the horse and not the camel (if you know that old metaphor). The mission statement we came up with for the user experience community across IT is

In our statement, we were pointing out that we do some of the design ourselves (“create”) and we leverage what we do to help others produce better designs themselves (“inspire”). We wanted to highlight the business value we produce (“effective”), but also that we strive for creating an emotional connection that motives adoption (“compelling”). We wanted to speak to how we do it (“research,” “design,” and “best practices”). We also wanted to emphasize that it is not just about usability tests, but it is also about driving insights through user understanding (“deep research- driven user understanding”), and that we springboard to great design on this foundation (“innovative design”). The “innovation” emphasis, the design producing emotion or compelling experiences, and the mention of the connection to the users are also linked to the vision and mission of our larger organization as well as to the brand promise. Furthermore, we have metrics that we argue let us measure whether we have attained compelling and effective experiences. The one thing not included yet is the “why” part. Missing that part has been a weakness of our mission statement. We end up always having to add something around user satisfaction and driving adoption and usage to explain ourselves.

The approach I having been using in the IT organization was recently summarized in Lund (2010). The situation is similar to the one you might face when starting UX from scratch in a company or large organization. The IT organization is made up of several thousand employees and while the majority of the employees are based in and around the Seattle area, significant numbers are based in India, China, and elsewhere around the world. Even in the Seattle area the IT staff is distributed widely across various buildings. IT produces hundreds of applications each year to enable the company to create its products, to support employee development and productivity, and to support operations. It also produces applications used around the world by our many partners, and applications that support our customers as they buy, use, and receive support for our products. The role of IT in helping create a relationship between the company and its customers and partners has been growing even more critical in recent years. When I joined IT it was because there were champions in senior management who believed that user experience is critical to help the company to achieve its goals.

While the user experience population across the company is sizable, within IT the population consists of a relatively small number of professionals primarily distributed across my group and a group supporting internal applications (e.g., Human Resources). If the proportion of UX within IT was based on the demand of a company with a similar size (Lund, 1994b) or based on a proportion similar to the product groups, it would be many times larger. Many in IT, as with most large corporations, fell into the trap of assuming that employees are captive users and will have to use applications whether they like them or not. They neglected to realize that poorly conceived and designed applications hurt the productivity and effectiveness of employees, and therefore of the business, even if they do use them properly. Research and experience at many companies demonstrates that employees may be “captive” in the sense that if told to complete a form they will, but that does not mean the form will be completed accurately and used in the way senior management imagines. We continually run across situations where people work around the system to check off the list of requirements without actually having to experience the pain of the application. They get their jobs done in spite of the applications, not because of them. As a result, decisions further upstream are based on inaccurate information and therefore ultimately hurt the business.

The approach that is wired into many of us in this situation is to grow by making the return on investment (ROI) case, and demonstrate either the bottom-line value that UX brings or at the very least how UX satisfies the strategic goals of the business and of management (Karat & Lund, 2005; Lund, 2007; Lund, 1997a). Even management occasionally asks for the ROI justification, although when provided it does not seem to be as persuasive as people would hope. Dan Rosenberg (2004) eloquently pointed out that these arguments alone in the best of times do not seem to be particularly effective in actually driving UX growth. Often it is far more important to either have a strong advocate in senior management or to leverage the direct value that a team experiences as they receive the benefits of UX work when driving growth. We have been fortunate in having advocates within senior management ranks who seeded user experience and nourished its start. Growth in these circumstances, however, is often slow. On the ground, an organization has to decide whether a vacancy is going to be used to bring in another developer, tester, or project manager or to use the vacancy for a user experience person whose role they are only beginning to understand. Even if growth was not an issue, it would take years to grow to satisfy the need within IT; in the recent economic climate that rate of growth would be unrealistic. These challenges are faced by nearly any large organization or company where UX is just getting a foothold.

The approach that I have been taking is to step back and instead of relying on the incremental approach, to think about what it means to transform an entire organization of thousands of people and to grow a user-centered, design-thinking culture across it, and to do it with a handful of designers and researchers.