Presumptive Design: Design Provocations for Innovation

September 21, 2015

This is a sample chapter from the forthcoming book Presumptive Design: Design Provocations for Innovation, by Leo Frishberg and Charles Lambdin. 2015 Morgan Kaufmann.

Presumptive Design cover

Chapter 1: Introducing Presumptive Design

“The future does not just happen. Except for natural events like earthquakes, it comes about through the efforts of people.”—Jacque Fresco


PrD is a design research technique. Organizations, large and small, use PrD to quickly identify their target audiences’ needs and goals. It is fast. It is cheap. And it is definitely good enough. If you are looking for ways to rapidly and inexpensively reduce risk to your project, PrD is the best technique we’ve found in our 30 years of experience.

PrD differs from—and is complementary to—traditional market-research methods. It provides intimate insights into the desires of end users (for products and services), communities (for social innovation), and internal stakeholders (for strategy). The method reduces risk to our projects by capturing our target audience’s reactions to a future we have envisioned. As we describe in detail throughout the book, the devil is in the details: How we envision that future and how we capture those reactions is what sets PrD apart from other research methods.

Champion Advertisement
Continue Reading…

Consider a typical example from industry: A firm has technology with competitive advantage (it’s faster, more robust, smaller or requires less power than the competition). In traditional market research, the research team identifies target audiences, crafts a quantitative instrument (a survey, typically), and performs a conjoin or other multifactor analysis. The team discovers the technology’s competitive advantage to address current customers’ needs as well as those in adjacent markets. This is absolutely necessary when placing big bets—necessary, but insufficient.

Quantitative research takes time and money; to do a conjoin correctly takes months and many tens of thousands of dollars. In contrast, PrD takes a week or two with the cost of a few days of travel. The insights gleaned from these rapid, inexpensive sessions are fundamentally different from the results of a quantitative approach, but they are no less valuable in reducing the risk of the venture. PrD’s qualitative results inform the design of a quantitative instrument, and vice versa. Although both can be done at the same time, we’ve found greater advantage in using one to inform the other. PrD costs less to execute than a quantitative instrument; its results are much broader.

Here’s how a typical PrD approach would play out: We invite key internal stakeholders (product marketing, technology leads or architects, sales leads, UX design, and the key organization leader) to a “Creation Session” (a “visioning” workshop). The outcome of the Creation Session is an “artifact” encapsulating the team’s presumptions about the new venture. The artifact is something an external stakeholder (a user or customer external to the team) will interact with. Depending on the size of the venture, the Creation Session could take a few hours, or perhaps as long as a few days. Subsequently, a small research team goes on the road with the artifact and works with external stakeholders in “Engagement Sessions.”

During these sessions, stakeholders are tasked with using the artifact to accomplish a goal. Each session may take as little as 30 minutes, and there only needs to be a few of them (again, depending on the size of the venture). Within a couple of weeks, the team will have captured hundreds of data points, reactions, and, most important, clear indications of how the internal team’s assumptions resonate with external stakeholders’ needs (Figure 1.1).

Figure 1.1—A typical Presumptive Design timeline
A typical Presumptive Design timeline

PrD isn’t limited to a product or service. When we use the word “project,” we mean any endeavor with material impact or risk. PrD is an inexpensive and easy tool to inform a strategy. It is a powerful means of identifying disruptive innovation. Disruptive innovation, by definition, is high risk: Discovering latent customer needs may expose an organization to gaps it can’t bridge. For companies facing emerging competitors, PrD illuminates threats early letting teams address these gaps strategically.

This Book’s Value Proposition

PrD will be familiar to any designer because it involves the creation of artifacts for the purpose of engaging with stakeholders. It will be familiar to any UX researcher because it involves understanding end-user needs through a form of interviewing. With that said, PrD shifts traditional ways of working in ways that may be disorienting to both designers and researchers.

For product managers and market researchers, PrD provides a rapid, qualitative-based research method. It supplements large-scale aggregate statistical investigations. PrD is an inexpensive way to explore the customer/user landscape, identifying “white spaces” that would otherwise be hidden or unavailable through quantitative methods. It is a customer-centric approach relying on small numbers to reveal important data.

For business leaders, PrD enables frank and open discussion about pain points in the organization. When rolling out a new strategy, changing the organization’s culture, or providing a vision for moving forward, PrD rapidly identifies the underlying values of the group. PrD, because it is a “codesign” approach, establishes a two-way conversation about what the vision could be. It engages constituents before the final vision is rolled out, starting their investment in it by incorporating their contributions as a part of it.

PrD is not limited to the for-profit world. It is an easy tool to empower communities seeking to improve services, representation, access, and civic engagement. In the world of social innovation, in which communities make their voices heard, PrD rapidly uncovers issues that matter to community stakeholders.

Although one of us (Leo) discovered the process independently, PrD has been around for many years, in a variety of contexts and with a variety of names: Suzanne Howard of IDEO calls it “Sacrificial Concepts,” [1] Koskinen et al. call it “Constructive Design Research,” [2] and Anijo Matthews of the Institute of Design at the Illinois Institute of Technology (ID-IIT) calls it “provotyping” (short for “provocative prototypes”). In spite of it being used by design firms, academics, and applied researchers for over 30 years, we could find no book providing a step-by-step way of doing it. As we dug into the process and teased out its steps, we engaged with other practitioners who had used it. Throughout the book, their stories and case studies help illustrate PrD’s breadth and effectiveness.

A Twist to the Familiar

PrD relies on an approach to problem solving peculiar to the ways in which designers approach their work. The “design thinking” model we use throughout the book is based on a long-standing framework originating from Chuck Owen at the ID-IIT. [3] We go into details of this problem-solving approach in Chapter 2 because design thinking is fundamental to PrD execution and success.

Agile Culture

Because it fits within the context of design thinking, PrD is part of a larger set of tools and techniques emerging in the early twenty-first century. Titles such as The Lean Startup, Lean UX, and Business Model Generation are indications of how the discipline of design is moving from the studio to the factory floor and ultimately to the boardroom. Inspired by Tim Brown’s seminal article in Harvard Business Review [4] (and by the introduction of revolutionary devices by Apple) organizations of all stripes recognize the need for design, designers, and design thinking. PrD and design thinking are inseparable. Design thinking is fundamental to the method’s success.

PrD also aligns with shifts in business thinking and approaches to leadership. Business leaders are being bombarded with messaging about changing the culture, changing thought processes and behaviors. Robert Schaffer’s article on “basic behavior traps” managers often fall in is an example.

“To escape the [behavior] traps, managers have to do battle with their own resistance, as they would in trying to change any well-entrenched habit. Each person needs to experience viscerally the dramatic improvement that is possible, which is why individuals should start with their own modest, low-risk experiments.” [5]

The attraction and benefit of PrD is its immediacy—an antidote to what Schaffer identifies as the fourth of four behavior traps: waiting. [6] With PrD there is no reason to wait.

Another benefit of PrD is its inherent agility. Agile (originally a means of delivering software solutions) is spreading into the boardroom. Its low investment, along with its speed, positions PrD as a research technique well suited to agile cultures—whether in the product development context or in the boardroom.

In their Harvard Business Review article, business consultants Marin Reeves and Mike Deimler list four tenets of contemporary strategy: reading and acting on signals, experimentation, managing complex systems, and enabling people to act, [7] in brief, rapid adaptation. If the context wasn’t managing large corporations, the article might as well have been discussing the culture of agile software development.


Building consensus through a process of inquiry, as opposed to top-down advocacy, has become a standard part of business leadership. [8] This inversion of attitude is fundamental to PrD, leading to PrD’s political implications. This inversion also forms the basis of Participatory Design, of which PrD is a part. Participatory Design is an approach to designing with constituents as opposed to designing for them. In brief, Participatory Design sprang from populist resurgences in the 1960s to provide a voice to labor and to reestablish its influence on the design of national policy. In a similar way, agile software development mirrors that populist ethic. Engaging with your targeted population, in fact, having you as the target of them, is a key transposition of roles and orientation. This mind shift is an essential part of PrD, as you’ll read throughout this book.

Figure 1.2—The emerging landscape of design research approaches
The emerging landscape of design research approaches

In Liz Sanders and Pieter Jan Stappers’s map of research approaches, [9] PrD is bimodal: It has one foot in Critical Design [10] (in which objects are used to provoke reactions to stakeholders) and the other in a generative tool (in which constituents design with researchers) (Figure 1.2).

Figure 1.3—A map of research approaches adapted from Konno and Fong
A map of research approaches adapted from Konno and Fong

In an adaptation of Konno and Fong’s map [11] (shown in Figure 1.3) we position PrD as a qualitative research technique focusing on the goals, attitudes, and mental models of user/customers/stakeholders. To minimize risk to our projects we must learn which of our ideas resonate with these constituents and which don’t. More important, we need to know why those ideas fail.

Looking through the lens of “user intimacy” and time, PrD is quick and intimate as illustrated in the constellation map given in Figure 1.4.

Figure 1.4—Constellation map of user research approaches
Constellation map of user research approaches

A High-Wire Act

In the hands of masters, PrD is a fluid, exciting, and extraordinarily fast method to identify stakeholders’ needs. But, as with any high-wire act, it requires practice to master. Understanding customer and user needs is challenging. Doing it quickly requires nuance, subtlety, and quick wits. With that said, the skills to do PrD effectively are easy to learn and are likely in your team just waiting to be released. And, as with any masterful performance, PrD is immensely fun. At its heart the process is a seriously playful approach to capturing your stakeholders’ needs.

Much of the preceding discussion may sound familiar, especially to individuals who use rapid prototyping in their practice. Rapid prototyping is integral to PrD, but, once again, there is a catch. PrD employs rapid prototyping to capture the internal team’s assumptions about the external stakeholders’ problems. Where rapid prototyping refines a design solution, PrD artifacts focus on the external stakeholders’ problem space. PrD artifacts are designed to be disposable: The artifact is important only insofar as it drives good conversations and illuminates insights.

The Five Principles of Presumptive Design

The following subsections provide an overview of PrD’s fundamental principles. Each is covered in depth in the chapters that follow.

Design to Fail

Consider the following scenario: You are about to engage with a group of people who don’t know you very well, who may harbor reservations about doing business with your organization or aren’t completely bought into your mission. Even if they are not outright hostile, they may not be forthcoming about their needs, concerns, or fears. (In fact, they may not be able to articulate these things.) People rarely have accurate insights into their own needs, let alone their constituents’ needs, and so, if you simply ask them, their answers are likely to mislead. [12, 13] At the same time, you know a change must be made—whether it’s to the operations of the group, the strategy for the company, or a new product or service. It may be as basic as getting access to fresh water. You can’t afford to be wrong; you rarely get a second chance.

This first principle of PrD gives us permission to be wrong. In fact, it outright requires us to assume we are wrong and assumes we will fail. Consider that shift: If we know we are wrong and we know our audience will chop to pieces whatever we’re about to offer them, how might we feel going into the engagement?


And that is exactly the frame of mind PrD requires. We must accept as fact any proposal, whether it’s a new vision or new product, is always wrong, even after it is fielded. Brooks wrote in 1975, “The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.” [14] Let’s face this fact: Nothing we do is ever perfect; we simply need to be “right enough.” Our goal is to raise our confidence we’ve crafted an experience crossing a threshold of “fitness.” PrD requires us to engage with our constituents so they will chop our offering to pieces as early as possible. In engaging our constituents in the process of critique, we engender intimacy and buy-in, not only with the end result but with the process itself, and this in turn helps improve the likelihood of the effort’s success.

As we describe in the detailed chapters, keeping Design to Fail in mind at all times is one of the key benefits and differentiators of PrD.

Create, Discover, Analyze


PrD, being a design research activity, rooted in theories of design thinking, starts with the creation of artifacts. It is distinctly different from other forms of research in which we spend time researching our audience before offering them artifacts, presumably designed based on those discoveries.


PrD proceeds by offering artifacts as provocations, purely in service of making discoveries. Because we know the artifacts we’ve created are wrong, we are assured our audience will have something to say about their fitness to their world view, values, and latent needs.

PrD relies on the design process of critique, but it uses critique very differently from traditional design:

  • Whereas design critiques are focused on the offering itself, PrD critiques focus on the assumptions behind the offering.
  • The objective of design critique is to improve the design; PrD critiques are to improve the internal stakeholders’ (your team’s) understanding of the external stakeholders’ (customers’/users’) problem space.
  • Design critiques are performed by other designers (in design reviews); PrD critiques are performed by external stakeholders (the users/constituents not on your team).

To be clear, design critiques are not the same as design presentations. Presentations are a form of sales and knowledge sharing, from the team to the audience. Design presentations gather feedback from the audience around the desirability of a solution. In contrast, PrD requires audience engagement with the artifact—they are asked to use it to perform a task.

In PrD, the critique reveals elements of the problem space, not the solution space.


Only after the design/research team has had the right conversations with external stakeholders (through offering presumptive artifacts) does it proceed to analysis. But even in the analysis phase the process differs from many social science research approaches. In many traditional research approaches, the team is asked to hold off drawing conclusions or finding patterns until enough information is available. But in PrD, commonalities emerge after only a small number of engagements with external stakeholders. Almost immediately, because the artifacts offered to stakeholders are likely wrong, the team discovers misalignments between its own world-view and those of its constituents.

PrD’s analysis is similar to codifying the stories and conversations ethnographic researchers collect. In PrD, analysis is in service of two outcomes: identifying underlying values, needs, and mental models of the target audience (similar to ethnography) and identifying ways in which the artifact and subsequent interviews can be changed to test these new presumptions (as opposed to simply refining the artifact). As The Case of the Black-Magic Batman illustrates (see Appendix A for all of the cases), Evan and his team were surprised by their users’ reaction to the artifact. Rather than changing the artifact, they changed their protocol.

Make Assumptions Explicit

In The Case of the Business Case, the team set out to test a key assumption: whether external stakeholders would comprehend the concept of an “app store” (à la iTunes) in the context of their work. The idea had already been demonstrated in a marketing deck but had never been tested with its intended stakeholders—that is, key users who would recommend the solution.

A remarkable thing happened during a debrief session after working with the users. The technical lead suggested an app store like iTunes wasn’t at all what he’d had in mind when he first proposed the idea earlier in the year. This came as a surprise to the product manager (and to the UX team who were relative newcomers) since we had been talking about it as part of the PrD for the prior month. How much longer would that misalignment have continued before the team realized they weren’t all talking about the same thing?

We all operate with assumptions about how the world works, how our employees think about us, our organization, our organization’s mission, how our customers think about our brand, products, and services, how our users think about the features and attributes of our offerings, or how our services can improve the lives of our constituents.

As we embark on something new (whether a new feature, a new service, or a new strategy) we harbor beliefs and assumptions about the right thing to do. One of the greatest risks of starting a new venture is beginning with firmly held—and completely incorrect—operating assumptions. Failing to align on operating assumptions leads to disastrous results.

But in many organizations it is those very assumptions driving discussions, plans, and, ultimately, work products. In the worst cases, the teams discover only after they’ve released their offering how wrong their assumptions were. PrD forces the issue by surfacing the team’s assumptions at the outset of the project, when it’s least expensive to learn the most. By surfacing the team’s assumptions to both itself (and other internal stakeholders) and, more critically, the external stakeholders for whom the experience is being designed, the organization quickly learns the value of those assumptions.

Iterate, Iterate, Iterate

Here’s a thought experiment: It’s the kickoff of a new project. Team members are excited to start something new. The early optimistic glow of doing something big, bold, and impactful is in the air. You decide you’re going to try this new approach to delivering value to your customer: PrD. Within a few days of the kickoff your team is in front of real customers with your first artifacts. Hooray! You’re on your way to getting to the heart of their concerns, values, and needs.

What are the chances you will have learned everything you need to know in that first round?


In that first round, you’ve probably uncovered more questions than answers.

PrD depends on multiple iterations for your team to raise its confidence in its findings or, put another way, for you to reduce the risk of proceeding down a specific path. As you’ll learn in Chapter 7, doing multiple iterations with a handful of people (perhaps the same people, perhaps different) will reveal far more insights, far more quickly, than doing fewer iterations with more people.

As with agile software development, Lean Six Sigma, and Transient Advantage, [15] the key here is to experiment, iterate, and learn. You know you’re done when one or more of the following conditions are met:

  • You’ve not learned enough different in the most recent iteration to warrant doing another.
  • You’ve run out of time.
  • You’ve run out of resources.

Getting the most out of PrD requires finding the least expensive ways to iterate (addressing the final bullet) and to find ways to iterate quickly (discussed in the next section). The process requires team members who can quickly identify what is being learned and whether it is novel. This last point may seem odd, but as we discuss in detail later on, teams may not immediately see stakeholders’ disruptive and awesome revelations without some professional interpretation.

The Faster You Go, the Sooner You’ll Know

In his oft-cited article “What Is Strategy?” Michael Porter laid out the principles of strategy for a generation of business leaders. [17] More recent thought leadership from Harvard [18] has argued against Porter’s notion of “strategic positioning through sustainable competitive advantage.”

The world is changing. Fast. Strategies, once thought to last years, are crafted on a yearly or even quarterly basis. Product features are continuously being updated, uploaded, and swapped. Amazon, Google, Netflix, and other giants change their offerings every few minutes.

Even companies and organizations that must move more slowly (companies requiring years of lead time, such as hardware manufacturers or pharmaceuticals) are under extraordinary pressure to find strategic advantages as quickly as possible.

No matter the product life cycle or its timing, every organization faces shorter and shorter cycles to identify desired end results with greater pressures for their success. How do we know an initiative is going to return on its investment? How do we know what the customer and user reaction is really going to be? In brief, how can we reduce risk as quickly as possible?

IT shops across the world are grappling with rapidly changing technical environments—increased demand by employees for consumer-grade experiences (the “consumerization” of IT), increased security threats, greater expectations for immediate bug fixes and updates, just to name a few. The Cloud (Software as a Service (SaaS)) provides an extremely compelling alternative to building “on-premise” applications.

Imagine being able to outsource all of the employee applications to service providers whose businesses are dedicated to building the best possible solution in their application market!

But there are significant experience challenges with that model, even if the financial aspects are compelling. What happens when employees are offered a dozen separate applications, from a dozen different service providers, none of which have the same look and feel, none of which use common vocabulary for similar terms, and few of which connect to one another? How can we presumptively design a solution to this problem to test employee reactions to such an environment, well in advance of actually constructing it?

Before you see our suggestion a little further along in this sidebar, take a moment and consider how you might “prototype” such an environment. What hypothesis are you testing (to put it in Lean UX terms)? [16] What problem space are you trying to survey? What sort of artifacts would you craft to help drive the right conversations? How much time would it take to get in front of customers to have these conversations?

PrD, as a research method, is fast. Really fast. In a matter of days the team crafts an artifact suitable for testing with external stakeholders. In a matter of weeks the leadership can learn what, if any, value there is in pursuing further investment. As new competitive threats arise, the team goes back out quickly and tests their assumptions against the market.

One way to test this hypothesis is given in Figure 1.5.

Figure 1.5—Smartphone home page as componentized experience
Smartphone home page as componentized experience

It’s sitting in our pockets. A PrD session to answer the question of what might be problematic with a multi-SaaS employee experience is as simple as asking fellow employees to try and complete a collaborative task using the elements on their smartphone home page.

Have them demonstrate how they would complete a task (perhaps filling out an expense report) using the apps available on the phone.

  • Design to Fail: Clearly this can’t be a proper solution to the problem—the phone was never designed to solve this problem.
  • Create, Discover, and Analyze: Offer the phone; listen to the reactions. Collect enough to understand the patterns.
  • Make Assumptions Explicit: The primary assumption in this case is the notion separate vendors can offer a coherent solution—somehow.
  • Iterate, Iterate, Iterate: After the first couple of conversations, you might need to switch it up a little, or you may need to use a different artifact.
  • The Faster You Go…: Total time to set up the test: less than 5 minutes. Total time to complete the interviews: 1 hour. Total time to review the results: less than one day. How much faster does it need to get?

Have Fun!

As the next chapter describes in detail, PrD depends on design thinking and, for designers, designing is fun. Think back to times when you had the time to think, and play and simply get silly. For most designers, that was likely just a few minutes ago. The design process requires a relaxed frame of mind.

For designers, the act of creation is massively fun. For others, maybe not so much. As you’ll see in the next chapter, design thinking requires switching “sides of the brain” [19] from left to right and back again. For individuals who have spent their lives on the left side of the brain, the right side can be uncomfortable, disorienting, and in some cases painful. That doesn’t sound like fun! Yet, the design process in general, and PrD specifically, succeeds when teams enjoy the work and explore wild possibilities.

Later on in the book we’ve provided example exercises to increase the fun factor of your team and of your work.

So, Why Bother?

PrD is a powerful means of discovering information leading to strategic advantage through a rapid series of engagements with our constituents. The lessons learned from these engagements inform everyone on the project, from the product managers to the technologists and the UX team. One of the greatest benefits of PrD, and, ironically, its greatest risk, is how easily teams identify disruptive innovations. Because we offer our constituents views into the future, we learn where our predictions don’t align with our constituents’ reactions to them. More often than not, their reactions don’t negate our predictions; instead they adjust them in ways we cannot anticipate. Those insights are the source of game-changing opportunities. 

Discount—Buy Presumptive Design: Design Provocations for Innovation and other Morgan Kaufmann titles from the Elsevier store online, using the discount code COMP315, now through December 31, 2015, and save up to 30% off the retail price.


[1] IDEO. Human-Centered Design Toolkit: An Open-Source Toolkit to Inspire New Solutions in the Developing World. 2nd ed. IDEO, 2011. Retrieved on July 24, 2014.

[2] Koskinen, I., J. Zimmerman, T. Binder, and J. Redstrom. Design Research Through Practice: From the Lab, Field, and Showroom. Waltham, MA: Morgan Kaufmann Publishers, 2011.

[3] Owen, C. “Design Thinking: Notes on Its Nature and Use.” Des Res Q, 2007.

[4] Brown, Tim. “Design Thinking.” Harvard Business Review, 2008. Retrieved on August 11, 2014.

[5] Schaffer, Robert H. “Four Mistakes Leaders Keep Making.” Liberty Mutual Insurance, 2010. Retrieved on August 11, 2014.

[6] Ibid

[7] Reeves, M., and M. Deimler. “Adaptability: The New Competitive Advantage.” Harvard Business Review, 2011. Retrieved on March 16, 2015.

[8] Garvin, D.A., and M.A. Roberto. “What You Don’t Know About Making Decisions.” Harvard Business Review, 2001. Retrieved on July 9, 2014.

[9] Sanders, E.N., and P.J. Stappers. Convivial Toolbox: Generative Research for the Front End of Design. Amsterdam, The Netherlands: BIS Publishers, 2013.

[10] Dunne, A. Hertzian Tales: Electronic Products, Aesthetic Experience, and Critical Design. Cambridge, MA: The MIT Press, 2005.

[11] Konno, M., and B. Fong. Agile UX Research Practice in Android. San Francisco, CA: Google I/O, 2013.

[12] Nielsen, Jakob. “Interviewing Users.” NN/g, 2010. Retrieved on July 21, 2014.

[13] Nielsen, Jakob. “First Rule of Usability? Don’t Listen to Users.” NN/g, 2001. Retrieved on April 21, 2014.

[14] Brooks, F.P. The Mythical Man-month: Essays on Software Engineering. Anniversary ed. Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 1995.

[15] McGrath, R.G. “Transient Advantage.” Harvard Business Review, 2013. Retrieved on August 13, 2014.

[16] Gothelf, Jeff, and J. Seiden. Lean UX: Applying Lean Principles to Improve UX. Sebastopol, CA: O’Reilly Media, Inc., 2013.

[17] Porter, Michael E. “What Is Strategy?” Harvard Business Review, 1996.

[18] Reeves and Deimler, op. cit.

[19] Edwards, B. Drawing on the Right Side of the Brain: A Course in Enhancing Creativity and Artistic Confidence. New York: Penguin Group, Inc., 2012.

Senior Manager, User Experience, at Home Depot Quote Center

Principal at Phase II

Portland, Oregon, USA

Leo FrishbergWith over 30 years of experience in design management and design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions. At The Home Depot QuoteCenter, Leo leads a dynamic team of UX professionals in delivering engaging experiences for Home Depot associates. Previously, as Product Design Manager at Intel, he led UX teams on mission-critical programs. As Principal UX Architect for Tektronix’s Logic Analyzer product line, he filed several patents and spearheaded product vision and definition for the next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 20 years, he has served as Program Chair, Chair, Vice Chair, and Treasurer on the board for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland Chapter of SIGCHI.  Read More

UX Designer & Researcher at Intel Corporation

Portland, Oregon, USA

Charles LambdinAs a UX Designer at Intel, Charles works on tools that employees use to get their jobs done. His background is in human factors, research methods, and behavioral science. Charles approaches user experience holistically, insisting that it be more than an add-on to business as usual. Doing genuine user-centered design typically requires whole-team involvement and process change. Justifying such change entails demonstrating that achieving business goals actually requires getting certain targeted populations—of users, customers, or employees—to behave in certain desired ways that sustain the business. What elicits such desired changes in behavior? UX Design. Thus, UX Strategy is really not very different from Business Strategy. In fact, you cannot achieve the goals of Business Strategy without a successful UX Strategy.  Read More

Other Articles on Sample Chapters

New on UXmatters