Innovation in business

XVII.3 May + June 2010
Page: 34
Digital Citation

Creating a user-centered development culture


Authors:
Arnie Lund

“However beautiful the strategy, you should occasionally look at the results.”—Winston Churchill

The Microsoft IT organization—including the division I’m in—creates the tool employees use to develop Microsoft’s products, websites providing the connection between Microsoft and its partners, and solutions that support customers’ needs when they use the products from Microsoft and its partners. It has approximately 6,000 full-time employees and a similar number of contractors and vendors. Even more than other parts of Microsoft, IT has an engineering culture where the primary goal is to ship bug-free code on time and on budget, and to do it in a predictable, measurable way. There isn’t a lot of tolerance for the mess of the human and the creative. When I joined the organization as an experience architect, at most a handful of human-computer interaction (HCI) professionals and I were being asked to raise the quality of the interfaces being produced and to transform the way the organization was thinking about what it was creating from utility to relationship. I remember one designer asking, “Why would anyone want to take on a task that impossible?” Thinking about the opportunity to influence every product that Microsoft and its partners create, with virtually all of its revenue passing through the systems, and the possibility to improve customer experience worldwide, how could one resist?

Rules of thumb that float around resourcing user experience (UX) work suggest that roughly 10 percent of a project’s budget should be devoted to the interface, or one out of every 20 or so engineers should be a designer or researcher. The likelihood that I would be able to hire 300 HCI professionals, especially at the leading edge of an economic downturn, was clearly zero. We needed a different way to make progress on the problem. The strategy I’ve been experimenting with is to focus less on the traditional path of trying to drive growth in hiring by arguing on the basis of ROI and instead to think about the problem as one of creating a virtuous cycle of user-centered organizational culture change, which creates a transformational demand, and to leverage the gravity that comes with successful design.

I should be clear on the scope we are attempting to address. What I’m interested in influencing is the IT organizational culture, or as Hill and Jones describe it, the “specific collection of values and norms that are shared by people and groups in an organization and that control the way they interact with each other and with stakeholders outside the organization” [1]. What I want to propagate throughout the organization is a system with a common vision that is shared across the organization, a language that all can use to talk about it, a reinforcement structure that motivates people to take the appropriate actions to improve the experiences created and that shapes how individuals interact, and that enhances the way they think about and create artifacts through the development process. Furthermore, the goal is to structure the system as a virtuous cycle of self-reinforcing activity whose impact grows as it operates and virally spreads across the organization. The virtuous cycle of user-centered design culture change is illustrated in Figure 1.

At the heart of our strategy is the vision for the experiences we want to create. The vision provides the language for the common direction and the business rationale for that direction. In the language discussed here, it includes the core ideas that drive business value and adoption. From my past research on how to produce successful products, this involves creating experiences that are satisfying, that engender loyalty, and that users want to extend. These experiences, in turn, depend on the value they deliver; and ease of use enables that value. Overlaid on these experiences, however, are the brand promise and the aesthetics of the experience that signal what users should be expecting. While organizations are not necessarily motivated by theory, they are motivated by sticky ideas, stories, and images that grab their attention and shape their view of the world. The experience vision, therefore, provides messaging that we drive through our communications across the organization as well as how we define the tactics that implement our strategy.

Deliver and Inspire

In the first year of our existence, my team faced pressure to avoid supporting specific projects and instead simply concentrate on creating standards for user interfaces. The best standards and guidelines are grounded in successful design, not pulled out of the air. We have persisted, therefore, in pushing to ensure that the UX teams are focused on the most strategically important projects within those areas of the organization where UX is part of the critical path to success. In addition, we continually search for the difficult business problems facing the organization and identify and provide breakthroughs for the problems within the set centered on the experience.

Our goal in moving into new areas is to invest in setting the direction—the vision of where the design should be several years out (even before there is technology to support it)—and to build it on the user’s needs and desires (the usefulness that drives the satisfaction). That vision is where we attempt to drive innovation in UX. To that end, we create roadmaps of how we’ll get there; the bulk of the team’s work from beginning to end follows and delivers on that roadmap. When great design is delivered, it raises the visibility of design thinking across the organization, and executives become evangelists for the experiences.

Motivate

Inspiring design and a compelling vision are two forms of motivation that move teams to aspire to better experiences. But Microsoft IT is an engineering organization, and the kind of motivation that works its way through the genetics of the organization completely depends on metrics that matter to the organization, that will be tracked, and for which people will be held accountable. The model within the overall vision identifies satisfaction at the heart of what we want to measure. Fortunately, Microsoft has adopted a standard satisfaction metric that it uses broadly, across products, which has been built into the compensation of many senior executives. However it has not been used as consistently across operational or other IT interfaces, so we are attempting to evangelize a more consistent measurement and to drive even broader adoption. By sampling the user population as they use the released application, often via user panels, the value is in motivating release over release improvement. The goal is to build the metric into the system in a way that ensures both its exposure in the standard dashboards used throughout the management chain and that it is discussed during strategic and tactical review sessions.

The next step is to increase the visibility of the metric across the management chain. That alone is often enough to stimulate action. No team wants to have a red or even a yellow box around user satisfaction next to their project. Within Microsoft, however, each employee from the front line to senior management has specific goals they are attempting to meet and has identified ways to measure whether they have been delivered. There is an opportunity, therefore, to drive more activity around satisfaction by building user satisfaction into these goals and identifying additional metrics that clearly drive satisfaction. For more senior management, the goals would include either achieving specific target levels or achieving some percent increase year over year. For people closer to the front line, the goals might include either target levels for usefulness and ease of use, or operationally equivalent performance-oriented goals.

A satisfaction metric alone, of course, does not provide enough guidance about how to make improvements; it needs to be supplemented by more diagnostic tools. Typically, the satisfaction metric is collected as part of a larger study, and if we can define an appropriate framework that deconstructs the experience along the lines of the vision into components that are meaningful to the user, we can identify the degree to which each impacts overall satisfaction and therefore business value. Furthermore, if we can drive a consistent set of user-feedback tools across the organization based on value, ease of use, and other factors, managers will not only have information about what is working and not working for users, but they’ll also be able to compare application experiences and make better decisions about the relative importance of various experiences and where to invest in improvements.

Equip

An underutilized area where the UX impact can be extended is through the architecture, as well as the reuse it enables. The architecture we build into our solutions assumes Microsoft and partner platforms. In the middleware layer, systems correspond to business capabilities. Above the middleware layer, capabilities are combined to support user applications. The applications are then rendered to support an expanding ecosystem of devices as users move from device to device, and to user support groups collaborating to achieve the goals of their activity. This is where the usefulness is delivered—we intend to deliver satisfaction by contextualizing the experience through end-to-end user scenarios that are supported in the design. Integrating UX into the architectures used by the teams is one way to insert the experience into the DNA of the organization.

The goal of the architecture we created is to define user-interface building blocks or design patterns that can be combined in various ways as new solutions are created. By using the same building blocks across applications, the users will associate the family of solutions with the same brand and use the branding as a cue that triggers scripts that will help them know how to use new solutions. It should set up expectations about ease of use and usefulness. In addition, the goal is to assemble blocks into groups, and groups into higher-order groups based on common needs. The primitives should reflect sound usability principles, and the higher-level design patterns should be both useful and easy to use. Moreover, skinning with various brand identities should change the voice and suggest the support for families of scenarios but should not alter the basic ways people use various controls to get things done. This model placed our work on common guidelines and reusable design patterns at the heart of the strategy, which was being used to turn the organization into a more efficient development team.

Having the right architecture is only part of the challenge. The blocks need to be assembled in a way that results in satisfying and compelling experiences. In essence the instructions for assembling the blocks are the development processes that teams use. Teams within IT use variations on waterfall, agile, and, frankly, wagile. We began by defining a user-centered version of the waterfall process that is most commonly used across IT. The standard process includes a planning phase, a requirements phase, a design phase, a development phase (including testing), and then deployment and maintenance. The process is somewhat complicated by the organizational stakeholders. For most of the projects within IT, certainly the most strategic ones, there is a business organization that is the sponsor of the initiative and that drives the business plan. Within IT, there is an organization with the responsibility of translating the business goals into business requirements.

We overlaid onto the existing process the set of UX activities that should take place within each of the phases if teams have full UX support. The core concept is of course user-centered design. Understand the users, translate that into design, test, improve, and iterate—and do it from beginning to end. This is enhanced with the idea of engineered creative design thinking, baking in a process of broad exploration and then prioritization, focus, and renewed exploration for the next phase, and so on. The goal is not just to focus on what the UX team itself does for projects, but rather to enable any team to improve the interfaces it creates.

To ensure that the focus is on users, goals and context persist through the development process. We are baking user scenarios into the process from articulating the value propositions at the start to testing the code and managing bugs at the end. A new step we are introducing is standardizing the expectation that early sketching and rapid prototyping will occur as the requirements and scenarios are being defined [2]. This early prototype provides a kind of common model and language upon which all the stakeholders in the process can agree, and it serves as a representation of how the scenarios might be implemented. It is understood that it isn’t a final design, and indeed is expected to change as the design is more fully explored and tested with users. But as a starting point for user testing, it demonstrates the feasibility of implementation and puts a reasonable size around the design effort (number of screens, number of controls and design assets that will be required, and so on). It also helps to identify where further and more detailed explorations will be required.

Training and Mentoring

While the most critical step in creating tools that will transform the way people do work is to create tools that are usable, provide value, and are easier to use than existing alternatives, just making them isn’t enough. We must support their use and grow design thinking across the organization [3]. That means we need to train and mentor. To do that, we have put together a curriculum for our IT organization that will raise the design-thinking IQ of the entire organization; in addition it will engage senior-management support to grow the UX expertise of a subset of their project managers, developers, and testers.

We have structured the curriculum into levels with basic courses, intermediate courses, and extended courses. Initially we thought we might emulate the Six Sigma black-belt concept, but then felt that we didn’t want to imply that if you had a black belt, you had everything you needed to be a fully skilled UX person. Instead we decided to present the curriculum as teaching the ability to do very specific tasks. The tasks would enable teams without UX to do a better job in what they designed; would enable those taking the classes to partner with UX people more effectively; and would help UX people to scale their impact ad design direction beyond the simple number of UX people on a project. Since the designers and researchers need to deliver inspiring design as the core of their day job, part of the goal is to drive toward as many self-service courses as possible. We also want to leverage the existing training that the training department within Microsoft is offering, and complement it with the training we create that is specific to our local organization. The design of the curriculum also takes advantage of the fact that different UX teams are focusing on their own organizational needs yet can offer training in a way that benefits a much larger community.

There is an introductory class to teach design thinking, the vision, general principles of great design [4], the process and how to apply it, and provide an introduction to the available reusable assets. There is a class in prototyping with wireframes, and a class in simple validation with users that includes several sessions and hands-on labs. There is a class on scenarios, and one on implementing the reusable assets and customizing CSS. There are also hands-on workshops that we are developing with the quality department around resolving UX problems. Other classes leverage courses already developed or being developed by Microsoft’s training department, and we’ll customize them for our environment with our vision, tools, metrics, and other assets. We are also working with the training department to see if we can leverage their registration process in order to track who is participating, and to bake the training into the objectives of individual project managers, developers, and testers who share responsibility for the quality of user interfaces.

What we are creating are user interface (UI) specialists or champions within each of the disciplines. The UI project manager is someone who is responsible for the end-to-end scenarios that deliver usefulness and user satisfaction; this project manager is not so much the person who owns developing the experience as they are someone who serves as a producer who engages others to design and develop the experience and facilitates creation. The UI project manager works well for many teams, ensuring that teams without direct design and research support have a better experience, and improving effectiveness for teams with design and research support. UI developers will be trained in the asset libraries and principles of how to put the blocks together in the most effective manner; UI testers will be trained in how best to use personas and scenarios to frame the questions they ask during testing, in the bug-classification scheme, and in design heuristics, as well as in the use of the automated test tools and templates we are helping create.

Leadership

I’ve found the biggest threat to creating effective UX is UX being treated as a service organization—a team that produces usability studies and icons on demand. To drive culture change, it has been important to demonstrate leadership. Some of that leadership comes with having a vision, some with inspiring, and some with motivating, equipping, and training. But some of the leadership comes with identifying the strategic questions for the organization and the subset that can be answered most effectively through user-centered insights. We then define the big-bet initiatives we want to undertake that will move the needle for the organization’s success in a big way, equivalent to the impact other teams have when they propose and deliver major new software initiatives. These big bets might involve putting in place a major user panel or a global ethnographic study, or working through a major experience design problem whose solution will impact architecture—for instance, implementing identity in a cloud computing environment. These leadership opportunities become the new inspiring examples of the vision from which we harvest assets and best practices that we drive through the organization and the cycle begins again.

References

1. Hill, C. and Jones, G. Strategic Management: An Integrated Approach. Boston, MA: Houghton Mifflin, 2001.

2. Buxton, B. Sketching User Experiences: Getting the design right and the right design. Boston, MA: Morgan Kaufmann, 2007.

3. Brown, T. (2008). “Design Thinking.” Harvard Business Review, June 2008.

4. Lund, A. “Expert Ratings of Usability Maxims.” Ergonomics in Design, 5, 3 (1997): 15–20.

Author

Arnie Lund has been at Microsoft for seven years, innovating and conducting research in areas such as natural user interfaces and creating personal experiences. His work on innovation and storytelling began at Bell Labs and continued with inventing and incubating new product concepts at Ameritech, US West Advanced Technologies, and Sapient.

Footnotes

DOI: http://doi.acm.org/10.1145/1744161.1744170

Figures

F1Figure 1. The Virtuous Cycle of Culture Change

©2010 ACM  1072-5220/10/0300  $10.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.

Post Comment


No Comments Found