The problem, for me, is this: It is becoming just another way for UXers to talk to ourselves about ourselves, and in the process continues to position UX as a tactical discipline with little strategic value.

At its best, it challenges us to bring a “think-make-check” discipline to our projects, thus transforming how our organizations create valuable digital products. As such it is a key part of formulating product strategy. At its worst, it indulges our laziest propensities and reduces creativity to pure production (see David Malouf on The Corruption of Making in Design for an eloquent take on this). To me, there’s way more promise in the former.

In this discussion, I’d like to explore how Lean UX gets us closer to being strategic actors not just more efficient and productive bit players.

The purely tactical

Here’s the stuff that for me is purely tactical, of little long-term consequence, and least compelling; yet these ideas have good traction within our discipline and often dominate our thinking of Lean UX.

Deliverables and documentation don’t matter anymore

Some tendencies within Lean UX treat deliverables and documentation as the equivalent of clerical work, or worse as “waste.” To me, systems with any strategic value to our organizations require you to think through complex user stories. This will require some thought experiments, many of which need to be written down and shared with others who are not part of the small, co-located team. I have to agree with Austin Govella: “Deliverables are not the problem. User experience practitioners are not in the deliverables business. We’re in the business of finding and evaluating problems and solutions.” Sometimes it takes deliverables to facilitate the thinking process.

Further, anyone who has needed to communicate design decisions for a complex set of use cases to a team that is not co-located with you knows that you have to document what is going on. The fact of the matter is that you’re going to do it anyhow. Questions will arise about what happens under different use cases. If you haven’t documented these, then you’ll either miss them in your design (and have to rework), or you’ll end up communicating your assumptions in writing — probably via the ephemeral medium of email — when questions inevitably arise. Just do it formally and get it over with. The extended team will thank you when it comes time for testing. (Yeah, that still needs to be done.)

Prototypes communicate everything

“The prototype now become[s] your documentation. It is ‘the Spec.’ Very little if anything more is needed” (Lean UX: Getting Out of the Deliverables Business). A prototype can be many things, but the complete specification is impossible (unless you’ve embedded notes in it, or you’ve hooked it up to a fully representative database). If the prototype communicates everything, then it is–by definition–the product. You haven’t built a prototype; you built the thing itself. Prototypes work well for getting stakeholders to remember requirements that they “forgot.” They work well to test with users when lower fidelity deliverables won’t do it. They work well to communicate to developers how transitions between screens work. But a prototype can’t, by its nature, cover all use cases. You’re going to need to document the exceptions not covered in the prototype.

Waste is the thing to be avoided

It’s not all about production. To arrive at what is truly valuable, you need to overproduce and throw stuff away. You learn from “waste”. Thought experiments that seriously and honestly engage a complex problem are not waste when they fail. They teach you something about the right solution. That’s not waste. Documentation that helps an offshore development team efficiently turn around code is not waste. It may seem like waste to those who think documentation is “boring” or clerical. But it isn’t waste. Get over it; write it down. The prototype and your sketches are not covering everything.

What’s Old Is New Again

Finally, much of what passes for Lean UX isn’t new, which is why so many UXers claim to have been doing it all along without realizing their business-as-usual approach needed a(nother) brand name. (Check out this blog post.) Anyone who has done a clickable prototype to test some assumptions with real users was doing it. (See @DesignStaff’s recent post, which doesn’t mention Lean UX but makes a compelling case for a UX technique that has existed well before we embraced the “lean” label.)

All that aside, I do like Lean UX

Here’s what makes the most sense to me, and what I have found truly transformational in my own practice no matter the size and complexity of the project.

Business-savvy design

Good, business-savvy design has always been about systematically finding the core features that matter most to users – no more, no less – and finding them at the cheapest possible cost. Design is almost always a process of trying to identify what is really valuable to users and what is less important. Doing it systematically is smart business and good design. Lean UX in this sense is good business..

Moving as quickly as possible through the “think-make-check” loop

Giving yourself time to think about the problem you’re trying to solve is important. But don’t assume you’re right. Spend your “thinking time” figuring out what you need to learn and what you can build to get the right answers. This is the work of a UX strategist. Writing down hypotheses and describing how you’ll validate them is hard work that is valuable whether you’re consciously doing “lean” or not. Some of those hypotheses will not be strictly related to UX. Some of them may go the heart of the overall Customer Experience your organization is trying to create. Knowing when your invalidated hypothesis is more than a system issue is an important strategic skill. You’re going to need to communicate that — with a deliverable, in writing.

Creating the most effective, least-cost deliverables to yield “validated learning”

The “Minimum Viable Product” (MVP) concept is central to Lean Startups and Lean UX. Though it is often confusing, it’s valuable. Designing just enough to deliver value and learn what to do next is also smart business and good design. As a discipline, we UXers don’t typically think too much about cost and benefits. We’re not typically held accountable to profits-and-losses. But MVP’s are a good discipline for us — they make us think about how to cost effectively make good decisions. They reduce product strategy to its fundamentals — what features move the business forward, fastest. That’s not typically the way we think.

These are the parts that I find useful and valuable no matter the size of the project. Whether it’s a startup or a large organization, there is always uncertainty and the opportunity for validated learning. Lean UX gives you a way to systematically deal with the uncertainty.

More important for UXers, it gets us closer to product strategy. Focusing on cost-effective ways to reach a market, creating a competitive differentiator, introducing a true innovation, or discovering that your company’s assumptions about its customers are wrong — these are strategic outcomes that will require deliverables beyond prototypes. Those deliverables (formal or informal) are where the strategic thinking gets done and communicated. Don’t give them up to someone else. Relegating ourselves to pure production is to further constrain the UX discipline as a subset of IT. That’s not where, I think, we want to be.

Source: Forrester Research Inc.

But these jobs aren’t made for us. We’re not even considered because UX isn’t a business discipline like sales, marketing, and operations. Those disciplines are tied to profit-and-loss much more than we ever have been. They also produce people who can maneuver through complex organizations much more easily than the typical UXer can.

Indeed, how many UXers can hold their own in a board room, or in front of the CEO alone making the (expensive) case for revamping the CX? Read The Customer Experience Fiasco and honestly ask yourself if you can imagine the typical UX designer in the role of the fictional Dana Chase. Her job is to find all the organizational problems that are leading her company to create a bad CX. She has to make a complex business case to senior management and ask for $80M as a starting point, and better UI’s don’t come into it. We’re not equipped for this. We’re not trained to look at our organizations this way and make these kinds of business cases.

Why? UX design has done a great job in the last decade of redefining (for the better) how we define requirements for products with digital UIs. There is no doubt about this. But this has come at a cost of upward mobility in our organizations. We’re functional players that make tactical work more efficient. We’re not strategic players that help our organizations transform themselves. The closer we look at UIs, the more pigeonholed we’re likely to be.

I agree with Leisa Reichelt when she writes, “Given the choice of having a Chief Experience Officer (CXO from a UX background) or a Chief Customer Office (CCO from a marketing/CX background), I’d probably choose the latter – for the more comprehensive, well rounded view of the organisation and all its working parts than the interface obsessed UXer is likely to be.”

(This is, of course, different if you’re a UX professional in a tech product company that values UX as a core part of the products they sell. In this post, I’m focused on the vast majority of other companies.)

Whether or not these jobs should be ours is one way to think about the issue. Another way to look at this is honestly understanding what we bring to the CX initiative. What can we do to get a seat at this table and move up the organizational food chain?

Alliance Building

Samantha Starmer addressed this about a year ago: “We need to act now to be part of the broader CX solution. If we don’t proactively collaborate across divisions and organizational structures, we will be stuck playing in the corner by ourselves. If we don’t figure out how to manage partnerships with other departments in a collaborative, creative, customer focused way, the discipline of UX as we know it is at risk.”

Where do you look for these alliances? It depends on your organization. I recommend looking into Jeanne Bliss’s discussion of the Power Core in The Chief Customer Officer. The Power Core is “the strongest skillset in the company or the most comfortable to senior executives…. [it] is one of the biggest determinants of how success, metrics, recognition, and company growth are defined inside the corporate machine.” Aligning with the groups that make up the core competencies of your organization gives you the best chance of success.

That said, for the UX designer, a promising place to look is in the relationship between the CCO and CIO. Even though CCO’s tend to come from outside of IT, the scope of their work inevitably affects the way technology is used to transform customer experiences. Take a call center for example. The agents may have incentives to achieve “one call resolution,” but this doesn’t happen unless technology makes this possible. When the issue is integrating a coherent CX across multiple channels and devices, then the relationship between CCO and CIO is filled with opportunity for UX practitioners willing to step up to the strategic challenge.

But stepping up may mean stepping out of our comfort zones. Whatever alliances we build, we can’t go in waving deliverables – our standard bulwark. We have to step out from behind our wireframes and prototypes and think strategically.

Call it UX strategy or digital strategy or whatever you want. The basic idea is this:

From the CCO’s perspective, a strategy-oriented UXer has the ability to understand the organization’s desired customer experience and can translate that into appropriate product and service concepts and designs that occur at each customer touch point.

Focusing on the Touch Points

The term “touch points” (as CXers and Service Designers use it) is important and can help shift the way we UXers think about what we can do. This is how The Customer Experience Fiasco defines them: “any interaction between the company and a customer, whether face-to-face, over the phone, on TV, or otherwise.” The touch points are going to be a mixture of people, processes, and technologies.

To be effective, we have to set aside our penchant for finding solutions in UIs and embrace the “experience design” part of what we do. (Is this starting to sound like “Service Design”?) Again, Samantha Starmer: “I view [CX] as an extension of UX, where non-digital experiences and services are just as important as screen interactions, and the full range of touchpoints with a brand across time has to be explicitly designed.”

To be sure, technology will almost certainly play a role in any high priority touch point, but the UI will not always be the primary consideration. We need to free ourselves from the bias of fixing things with UIs so that we can see more effective CX solutions.

For example, a common CX problem occurs when a technician is dispatched without the right equipment to fix the customer’s problem. This happened to me recently when my stovetop stopped working. When I called the company (otherwise known for good CX), the rep knew which model it was without me having to tell her. I described the problem in enough detail that the company should have known what the likely problem was. (The technician confirmed this when he told me that there only only two things that can go wrong with this stovetop.) So, armed with their knowledge of what stovetop I own and what the symptoms were, first-time-resolution should have been a slam dunk. But it wasn’t. Two trips were required — one to figure out the problem (which could have been diagnosed over the phone) and another after the part was ordered and in stock a week later.

Diagnosing the root of this CX problem and designing a solution is not likely to be UI intensive. More likely the issue is related to a communication process or poorly integrated trouble ticketing, inventory, and dispatching systems, not to mention training. The UI perspective that we typically bring to the table narrows our focus to the point where we can only think about and design one channel at a time. But the CX specialist has to be a multi-channel thinker. The CX specialist needs to see how touch points interact. The CX specialist is a business person who has to prioritize solutions according to budgets, cultures, and politics — and present the multimillion dollar price tag to senior management for approval.

Making the Transition

If UXers want to play in the CX world, we need to lift our heads up from our desks and step out from behind our clickable prototypes (“lean” or otherwise) from time to time. To finish this, I’ll discuss two different ways to begin the self-transformation: seeing CX problems that are often disguised as UX problems, and embracing the emerging discipline of Service Design.

Seeing CX Problems Disguised as UX Problems

UXers need to cultivate their ability to understand when we are dealing with CX problems disguised as UX problems — or even as a usability problem. This happens all the time. We just need to learn how to see it, and when we see it, call it out.

For example, I was asked recently to do a “usability” evaluation of a proposed new system for a financial services company. The system hinged upon two key assumptions about the customer. If either assumption proved wrong, the system would fail no matter how well-designed the screens were. Those assumptions cut to the heart of the CX that the company wanted to create.They were also out of alignment with the new brand image the customer was pursuing. I talked with executives, who expressed some trepidation about betting success on these assumptions. The project needed a CX strategy defined at the highest levels of the company before my project could or should become a UX project. We adjusted the work to focus on validating these assumptions.

How many times does this happen to us — we see a situation where the fundamental assumptions about “the user” are obviously flawed, but we plow ahead trying to design our way through these flaws? If you find yourself asking for personas and scenarios that don’t exist, chances are good that there is a larger CX problem, not just a UX problem. If you are designing a customer-facing system and you can’t get a straight answer about how it relates to other customer-facing systems from the customers’ perspective, then you have a CX challenge. Call it out.

The Career Case for Service Design

It seems to me that Service Design is another place for interested UXers to start looking for career growth in CX-oriented organizations. I’m no expert, but Service Design is so closely related to Customer Experience that at times I think of Service Design as a tactical extension of strategic CX. Service Design is about designing experiences that are appropriate to the larger CX strategy, which itself should be aligned to the company’s brand promise.

This discipline stretches our strategic thinking abilities more so than exclusively UI-focused methods. Being able to assess the customer’s experience across multiple touch points and understand the full scope of operational challenges in making this a good experience will bring you face-to-face with some sticky challenges that will stretch your skills significantly.

Closing Thought

The closer UXers can get to customer touch points in their organizations, the closer they get to where the strategy lives. Getting there will mean fine tuning our sense of profit and loss, improving our abilities to maneuver within complex organizations, and build alliances where we haven’t had to do so before. There’s nothing but upside in doing so.

Minimum Viable Products–what does this mean?

If you read any article or listen to any talk about minimum viable products, you will notice that the word “confusion” shows up early and often:

• Steve Blank: “This minimum feature set (sometimes called the “minimum viable product”) causes lots of confusion. Founders act like the ’minimum’ part is the goal.  Or worse, that every potential customer should want it.” (Perfection by Subtraction – The Minimum Feature Set)
• Eric Ries: “One of the most important lean startup techniques is called the minimum viable product. Its power is matched only by the amount of confusion that it causes, because it’s actually quite hard to do. It certainly took me many years to make sense of it.” (Minimum Viable Product: a guide)
• Marty Cagan: “One of the most important concepts in all of software is the notion of minimum viable product (often referred to as “MVP”.)  But if you’ve been around software products for a while, you know that term is used in many different ways, and while the term intuitively resonates with people, there’s often a lot of confusion about what this really means in practice.” (Minimum Viable Product)

It’s not just that the concept is confusing. It is. And it’s not just that introducing articles with the promise of clearing up confusion is a common trope. It’s an effective one, and these articles cited above are great pieces that do clear up a lot of confusion. The relationship between confusion and MVPs runs deeper than all that.

MVPs are born from confusion:  the “extreme uncertainty” that Ries defines as a fundamental condition of a startup. Hypothesis by hypothesis, MVPs allow you to run head first into the uncertainty and chip away at the confusion. The creativity necessary to invent effective MVPs makes it hard to specify a formula or procedure for MVPs in general. This makes MVPs confusing, compelling, and energizing all at once.

Making Sense of MVPs

Rather than trying to definitively make sense out of MVPs, I stress that “making sense” is what MVPs are about:

MVPs are mechanisms to create meaning where little or none currently exists.

It doesn’t matter if it’s actually a product in the traditional sense. It doesn’t matter what the words “minimum viable product” really mean. It matters that the work you do makes meaning:

• What is a meaningful set of features for customers?
• How do we produce meaningful lessons learned from what we put in front of customers?
• What does this concept mean for how we go about defining a product strategy?

Each one of these questions has an impact on how we go about our work as product strategists and designers. That meaning-making breaks down into three areas:

• Meaning as vision
• Meaning as learning
• Meaning as method

Meaning as Vision

An MVP is a down payment on a larger vision. This larger vision gives meaning to what your customers are buying now. Here’s Blank on the importance of vision:

“You’re selling the vision and delivering the minimum feature set to visionaries [“Earlyvangelists”] not everyone….These Earlyvangelists are first buying the vision and then the product. They need to fall in love with the idea of your product.  It’s the vision that will keep them committed the many times you screw up.” – Perfection by Subtraction – The Minimum Feature Set

The here-and-now meaning of the minimum set of features you’ve delivered lies in the “idea of your product,” the realization of which lies somewhere in the future: Earlyvangelists “will need to hear what your company plans to deliver over the next 18 to 36 months.” Meaning is stretched out over time and therefore requires adept storytelling.

Here sense-making is an artistic endeavor—telling a story of the future that gives a greater meaning to what you are doing right now. It’s more art than science because it’s more about tapping into emotions than appealing to the intellect. An earlyvangelist is emotionally connected to what you are doing. Simply presenting a list of planned features isn’t going to do it. Part of our work as entrepreneurs, designers, or product strategists is to convey that meaning – to tell that story over and over again and make it emotionally resonate. The story is as much a feature as any code that is written.

To be sure, selling vision has always been a part of the relationship between software vendors and customers. MVPs just push vision to center stage in the relationship because uncertainty is at the heart of the matter. For established markets, there is little uncertainty to contend with.

Rather, you are contending with the relative certainty of competitors where vision can be a differentiator at most. But in the extreme uncertainty of a startup, you don’t even know if there is a market for what you want to do. Uncertainty is fundamental, and vision is how we make sense of it to ourselves and our early customers and prospects.

Meaning as Learning

The fundamental skill required for defining effective MVPs is the ability to isolate exactly what you need to learn and line up a prioritized set of hypotheses: what sense do you need to make of the situation you face; what confusion do you need to overcome right now?

In discussing Lean UX (with its strong ties to Lean Startup and minimum viable products), Leisa Reichelt makes this point beautifully in comments she made on a recent blog post:

“This is the thing, for me, that makes Lean different to Agile or Guerilla or all the other ways that we’ve packaged up sets of UX/Design techniques over the years. Not the MVP, not the guerrilla testing, but making LEARNING the measurable unit rather than the stuff we make.”

A disciplined approach to sense making; a technique for learning: these are the fundamental qualities of MVPs. Product strategy conducted in the realm of science – hypotheses, experiments, definitive answers. This is clearly articulated by Josh Seiden on the Luxr blog:

• “First, you declare your assumptions, and express them as a testable hypothesis.
• Then, you write your test–what signal will you get back from the market that will let you know if your hypothesis is true?
• Finally, you ask the question, “what’s the smallest thing I can do or make to test this hypothesis? The answer to this question is your minimum viable product, or MVP.”

The production of signs and signals (the vehicles of meaning) are at the heart of scientific sense-making: “what signal will you get back from the market” that proves (or disproves) your hypothesis? Indeed, what sign will we receive, what meaning will be made from our MVP?

But there is more to it than just experimentation for the sake of learning. There is a sequence and a priority that needs to be respected. We are pursuing a larger vision with our tests. The artist creeps back in: our storytelling must guide our priorities and help us understand what comes first in this larger story we are telling.

To be a little more concrete: the first thing the product strategist must figure out is what should be learned immediately. Sometimes easier said than done. There are several ways to break down uncertainty and confusion when creating a product strategy using MVPs:

• Value: Will people find value in the product vision enough to express genuine interest in using initial releases?
• Hurdles: Are people willing to get over the fundamental hurdle your product vision puts up?
• Sustainable Differentiation: Can you hold off competitors long enough to establish differentiation that is not easily copied?
• Love: What will make customers love your product, use it over and over again, and encourage others to use it?
• Scalability: Are there enough people out there that will find value in what you are doing?
• Money: Can you turn that value and scalability into a sustainable revenue stream?

Knowing what you need to learn right now is fundamental to defining the MVP. Figuring this out starts with being brutally honest about what you already know. What sense have you already created about your situation?

Let’s say that you have signed up a bunch of customers for your initial release. Your analytics tell you that they are going into the system, but they’re not returning over and over again as you had once hoped, or as your financial model requires. It’s usually not a disaster. You’ve learned that people will sign up based on some portion of your vision. That’s the first step in overcoming uncertainty. The product strategist must now get out of the office, talk to customers, and make sense of the situation:

• Exactly what part of your vision has been validated?
• What exactly are the hurdles to engagement?
• Have they found a competitor as a substitute?
• Is the problem you think you’re solving not the one that customers want to solve?

This is a systematic meaning and sense making enterprise—a scientific enterprise—but guided by the vision of the artist who imagines a better and more fulfilled future.

Which brings us to meaning as method.

Meaning as Method

The idea of the MVP has given product strategists another concept that helps us make sense of our work in new ways. It’s not that we haven’t gone about systematic learning before. We have lots of techniques for this – ethnographic research, analytics, focus groups, surveys, A/B split testing, the list goes on.

It’s about a disciplined ability to know what we need to know right now and devise ways to end the confusion and uncertainty about a particular issue – “LEARNING as the measurable unit”. It’s also about the ability to keep that artistic vision of a better future visible to ourselves and our early customers as we create our experiments. MVPs change the way we make sense of product strategy by forcing sense making as the heart of method.

Here is where meaning-as-vision and meaning-as-learning ground the discussion of method. Without vision, MVPs make no sense. Without a mindset obsessed with validating (or overturning) that vision step by step, MVPs make no sense.

Just as vision gives meaning to MVPs, vision gives meaning to the work of defining the longer term product strategy. The product strategist must know what needs to be learned now and what can wait for later. The product strategist always knows what he definitely knows right now and what he needs to know next. The product strategist is at home when she is sorting out the confusion that stands between the here-and-now and the future. She is unfolding a story. It has a general direction guided by vision, but it may change—a “pivot” in Lean Startup terms. The product strategist is comfortable with that.

MVPs and Interpretation

This uncertain space between the here-and-now and the realized future is where flexibility and creativity rule; but it is also a place where discipline and method must guide creativity (and vice versa). It is a place where the mind of the product strategist is constantly looking for signs and interpreting meaning. “What signal will you get back from the market?”

Interpretation is an essential skill of the product strategist, along with creativity in inventing hypotheses and experiments. There is no one way to do MVPs. This is why so many of the discussions of MVPs involve piling up examples. Many of those examples don’t even resemble products in any traditional sense of the term – as Dropbox famously proved with just a video to measure interest.

Even when shown to be a method, the method itself is very specific to a larger context. For example, Zynga’s approach to “Ghetto Testing” has a lot of great techniques. Their systematic approach is very specific to a business with an existing high volume of traffic and a need to create a large pipeline of new, viable games. A lot of uncertainty has been removed from the equation.

For early stage businesses without this kind of volume, other approaches to MVPs are more appropriate and will require adept skills at collecting and interpreting more qualitative data. For many entrepreneurs, working very closely with your earlyvangelists as a “concierge” may be a better approach. It takes creativity and imagination to understand what experiment is best.

To make sense of MVPs—to interpret what they mean for conducting product strategy—the entire context needs to be explained. This is why “The Lean Startup” devotes so much space to detailed, context-rich examples. It’s very difficult to nail it down to a reproducible method – first do this, then do that, and out comes this. We need to continue to pile up examples, not in the hope that final meaning and method emerge, but with the purpose of sparking the creativity necessary to make sense out of extreme uncertainty. Seeing how others do it helps the rest of us figure it out for ourselves.

Final Thought

MVPs are not formulaic, as Ries put it in “The Lean Startup.” “It requires judgment to figure out, for any given context, what MVP makes sense.”

There are those words again hanging out inconspicuously at the end of that sentence, easily dismissed as a standard way to bring a sentence to an end. We do it all the time. But “makes sense” is actually the heart of the matter. MVPs must make sense by creating meaning out of uncertainty and confusion.

I’ve been watching two trends recently in the realm of digital product development. First is the incorporation of gaming concepts into products that seemingly have nothing to do with gaming. Second, the importance of designing products that are not only easy to use but a pleasure to use.

To be sure, these trends aren’t new. My point is not to shed yet more light on what we already know. Rather, the potential impact of these trends as they go mainstream is significant for UX designers– our skills are becoming strategic rather than tactical.

Let me explain. A wireframe is a tactical output that (hopefully) partially fulfills a strategic direction for a system. But working with a product manager to figure out how to incorporate gaming concepts into a product moves us, the UX designers, in a strategic direction. This changes the opportunities in front of us as designers. The term I use to encapsulate these opportunities is “digital product strategy.”

What is digital product strategy?

Product strategy binds business strategy to product management. Marty Cagan put it nicely in a April 2009 blog post: “Think of it this way. The business strategy and business portfolio planning provides a budget and a set of business metrics. The product organization then lives within that budget to pursue as aggressively as possible the best ways to hit those business metrics.”

Product strategy (let alone digital product strategy) is a relatively unused term – no Wikipedia article exists as of yet, and it ranks fairly low as a competitive keyword (at least as I write this). As such, there’s not a lot of consensus as to what it encompasses. So, I’ll provide my thoughts with an emphasis on products that are digital by design – they make heavy use of software as part of their interaction model or delivery mechanism.

To me, a good digital product strategy brings together seven areas of expertise:

1. Market/industry expertise: A deep understanding of the domain you are engaged with;
2. User expertise: Engagement with actual or potential users of the product;
3. Competitive expertise: Commitment to finding “sustainable differentiation” – the “secret sauce” that cannot be easily copied;
4. Related-Industry expertise: Engagement with other industries or markets that you can learn from to create a better product for your industry
5. Design expertise: knowing how to make a product easy and fun to use with the latest design techniques for many different devices
6. Technology expertise: Knowing what is technically possible today and in the future and the devices that make sense
7. Business expertise: Knowing how the product will fit into the operational realities and capabilities of the business

Here’s an example, I have been working with a customer over the last few years to help them introduce a direct business-to-business channel alongside their traditional distributor-based model. The main channel became an e-commerce website, and our “product strategy” was about achieving parity with two main competitors. From a digital product strategy perspective, the website became the primary delivery mechanism for a tangible product, and thus a huge part of the product UX.

As we emerged from the parity phase, we consciously moved to an innovation phase. What once appeared as “solutions” in the first phase – an e-commerce website – looked like a limitation when we focused on the market and the users from this new perspective. Customers were using the website during lunch hours, and we knew that they were walking from the storage cabinet to the PC with written notes about what they need to restock. These two things pointed to a fundamental inconvenience in usability. This inconvenience couldn’t be fixed by a more usable website, however. It was a great opportunity for a mobile application with a bar code reader for replenishing inventory.

Had our product strategy remained focused on the website, we would have run repeated usability tests to fine tune the features, and we would have continued to focus on competitors to keep up with new features. The idea of a mobile app that really addresses that fundamental inconvenience wasn’t possible until we shifted our perspective. By combining our knowledge of the market, the users, existing technology capabilities, and design expertise, an innovation became imaginable. A new product is conceived that can move into the more traditional product management processes.

Product Strategy and User Experience Design

The example above points out how UX design is a strategic skill. As the realization of business strategies become more dependent on the development of digital products (or products that make heavy use of digital technologies), the UX designer offers the unique combination of:

1. How to understand the real life of users;
2. The capabilities of technologies and devices;
3. How to make something easy and fun (or at least really convenient) to use—three of the seven areas of expertise I described above.

This moves us closer to business strategy and simultaneously requires a change in our deliverables. In an earlier article, I discussed how the requirement is a “somewhat strange and antiquated way to capture what a software system is supposed to do.” We have to develop new deliverables to replace the requirement as the first and best way to express the system we want to design. Conceptual wireframes, sketches, storyboards, and user models (like the famous Flickr model) are more appropriate deliverables for product strategy work. Companies that consciously do product strategy as a discipline know this, but there’s plenty of opportunity left in the mainstream projects many of us work on each day.

As such, we supplement the work of the CTO, whose job is to set a technical direction. Martha Heller describes this role well: “… the digital product groups hire a CTO, who designs and executes against the digital product roadmap.” In other words, the CTO is the technical expertise part of digital product strategy, while UX design is the easy-and-fun-to-use part and the knowledge-of-real-users part.

UX Design, Product Strategy and Gaming

A new opportunity exists for the UX designer as gaming concepts become part of product strategy. Who else is better equipped than the UX designer to bring this discipline to the table?
To decide that a product is going to be structured as a game rather than, for instance, a document sharing system is a strategic product decision, not a tactical one. When we start thinking about incorporating gaming concepts into our products to increase engagement, we’re making fundamental decisions about our products.

A lot of people are talking about gamification of digital systems. I could choose any number of people to quote about the fundamental structures of good games and how they can be applied to digital products. I like the succinctness that Jane McGonigal provides, so I’ll use her definition: “When you strip away the genre differences and the technological complexities, all games share four defining traits: a goal, rules, a feedback system, and voluntary participation.”

There are two conclusions to draw from this for UX design:

1. These are not simply features we add into our digital products; they invite us to think about our products in a fundamentally new way;
2. The UX designer is the best equipped discipline to bring the full force of these concepts to the product strategy conversation.

Blending these traits into an engaging and compelling UX – that is fundamental to the product itself – is really what the UX designer is equipped to do. That companies are now getting on board with the engaging power of gamification in formerly utilitarian software systems yields lots of opportunities for our once tactical discipline to become strategic.

In my years of reading requirements, I’ve come to loathe the genre. As a written statement, the “requirement” is a somewhat strange and antiquated way to capture what a software system is supposed to do. I have no desire to discuss new and better ways to write requirements in this article, since others have written powerfully and persuasively about transforming this oddity into more useful forms such as user stories, use cases, and “minimum viable product” specifications.Learning how to deal with badly written requirements is part of our job, but they can be a trap for the designer. How can the user experience designer handle the inevitable dysfunction that badly written requirements create in his or her relationship with the business analyst? In this article I’ll offer some practical advice on how to deal with this dysfunction and position the designer as someone who needs to be included early in the project–before requirements are written.

The Dysfunction of Requirements

The causes of the dysfunction are at least twofold.

First, large internal IT projects are scoped by the two roles least equipped to come up with great user experiences: the business analyst and the stakeholder. Neither typically has any formal training for envisioning highly intuitive and usable systems, and the stakeholders are typically pulled in multiple directions. As a result, the requirements usually are incomplete and written in haste.

Second, project-budgets and timelines often are defined with the hastily written requirements as the primary input. This puts designers into a difficult position as our work inevitably leads to new features and requirements that may greatly improve the outcome but not fit into the budget. What is worse, you are often stuck designing a system that can never be usable, but you’ll get blamed nevertheless.

I suspect that the reason for these dysfunctions dates back to a time when software systems were largely about automating internal processes. The 1990’s drove an acceleration of this approach mainly in response to “Y2K” and ideas like “business process re-engineering.” A lot of IT spending and hiring was driven by the removal of home-grown systems and replacing them with big packaged systems from SAP, Oracle, PeopleSoft and the like. Many of the business analysts writing requirements today got their first jobs then. They became skilled at decomposing and diagramming processes – swim lane diagrams, workflows, and, yes, spreadsheets full of requirements.

At the heart of this approach is a key assumption – the users will be trained. For this reason, there is no need to think seriously about a high quality user experience. Any difficulties in the UI will be addressed in training. The users are also assumed to be frequent, repetitive users: they’ll eventually learn how to overcome the idiosyncrasies of the system.

As the ‘user experience’ has become essential to the success of many systems, the relationship between the stakeholder and the business analyst has not been kept up to date. Many projects still start with the same approach – quickly make a list of requirements and establish a budget under the assumption that the requirements are comprehensive and complete. This creates problems for designers. How do we break into this relationship and get an early seat at the table?

Respect the Situation and the Work

The first thing we need to do in these situations is respect the requirements and reference them in our deliverables to make clear that we are paying attention. Be prepared to recognize when your design introduces new requirements or significantly expands existing ones. We need to be up front about this and call these situations out as part of our design process.

Here’s an example from a recent project, typos and grammatical and spelling errors intact:

Some business analysts reading this will say, “These are terribly written requirements.” And I agree, but unfortunately, this is typical of large-scale projects. They are desperately trying to be complete, but what a terrible way to describe the scheduling of an appointment. There is nothing that explains the context of use and the goals of the system. You could certainly design a system to meet the requirements, but without additional context, it wouldn’t likely meet larger business objectives. Our design turned the requirements into design patterns for a calendar day that includes an interaction model, design justification, guidance for the visual designer, reference to specific requirements, and relevant source systems.

In these patterns, our design defined a new requirement that would automatically select the first available appointment. (We usually assume that fewer clicks in a call center application has direct financial benefits, so why make the CSR search and find the first available appointment?)

As written, BR95 said:
Available Scheduling Message Box
Once the User has selected an Appt Time Slot the following message box will be displayed :
Appointment Scheduling:
The Date you have selected is:
Day, Month, Date, Year (Ex: Wednesday, February 9, 2011)

This requirement implies that a user always has to select an appointment. We didn’t just let it slide, hoping that it would just get through. We called the business analyst and the architect to openly discuss it with them before a formal review with stakeholders. They were fine with it, and even appreciated being brought into the process.

A big win for the designer. But the bigger win happens when it opens the door for getting involved before budgeting in the next project. We just have to have the courage to take that step.

Collaborative Clarification

In another situation we were given the following vague requirements:

We used this as an opportunity to introduce user stories as a way to clarify and unpack all the functionality necessary to make sense of these.

We presented this to the business analyst and stakeholders to solicit additional detail before we tried to design anything. This gave us an opportunity to steer the conversation toward method and introduce an alternative way of formulating requirements in the future. As the designer, your challenge is to be ready to have methodology conversations for the next project that brings these realities to light.

Final Thoughts

As traditionally written, requirements are designed to produce conflict. It is an item for IT and “the business” (to use the common IT term) to negotiate when money and timelines take center stage. That they were hastily written in the first place only makes the conflict more likely. It also sets the designer up to be the fall guy for a poorly conceived system. Recognizing their inherently conflict-driving nature, the designer can work to diffuse the situation and get a seat at the table when the next project starts.

Here’s how it went as we reviewed the designs for the shopping cart with the client:

Stakeholder 1: What about when the customer realizes they are purchasing using the wrong contract? Can they change it here?
Designer: Not in this design. Is that something that they should be able to do at this point?
Stakeholder 1: Yes.
Designer: But then their prices will change. Right?
Stakeholder 1: That’s right. And they might have products in the cart that they won’t be able to buy on the new contract.
Designer: [internal dialog] #$%!
Stakeholder 2: What about the ‘prompt pay discount’? I see ‘discounts’ but does that include prompt pay?
Designer: What’s that?

It’s common knowledge (or it should be) that discovering requirements during page design  is a recipe for madness. But no matter how much we believe this and strive to avoid this, it still happens. We’ve come to terms with the fact that it’s quite natural for clients to recall an infrequently-used feature or edge case when they see a page design. In this case, it’s easy to blame the customer for not having their requirements defined and communicated. Surely, we’re the victims here.

The reality is that the problem is ours. We rush into the creative process without fully understanding everything that our solution needs to do. If we are going to be successful, we need to figure out how to hold our creativity accountable to the full demands and scope of these complex projects. Unless we take the lead in defining the full scope of these projects, we will never be successful.

Checklist Thinking and Accountability

Last year, one of our clients mentioned to me Atul Gawande’s “The Checklist Manifesto”. She was reading it for its insights into health care. My insight was this: for our creativity to really deliver a solution, our deliverables cannot stand alone; they must work together as a related set of checklists. “Checklist thinking” makes the complex, enterprise-wide digital systems we work on much more manageable.

At my company and with our clients, I talk a lot about deliverables being “accountable” to other deliverables. I’ll use an example. In an Agile process, everything that takes place in a sprint is referenced back to one or more user stories. Our page sketches must address all of the user stories in the sprint. In other words, our sketches and page flows are held accountable to these user stories. Similarly, many software projects involve some listing of requirements. User stories should be held accountable to those requirements.

Checklists enforce accountability among deliverables. Framing our deliverables as checklists helps us do three things:

• First, we can lead our customers through the process of defining the full scope of complex digital systems.
• Second, we can hold our creativity accountable to everything required of the solution called for.
• Third, we can hold the customer accountable to their inevitable changes. We can always go back and say, “That’s a new user story that we haven’t discussed. Let’s get that on our list.”

This accountability allows our creativity to be truly effective.

Types of Checklists for Complex Digital UX Projects

A checklist can take many forms, but there are five that we find crucial for ensuring that design projects don’t spin out of control and that stakeholders and customers are held accountable to their earlier decisions.

Checklist #1: Scenarios
Checklist #2: Business Requirements
Checklist #3: Use Cases (or User Stories if you’re using Agile)
Checklist #4: Flow Maps
Checklist #5: Wireframes (or prototypes or sketches or whatever you use to define what happens on a page)

These are not new deliverables, and some of them are certainly not typically the domain of the interaction designer. Nonetheless, the trick is treating each as sequence of checklists and not just an exercise in siloed documentation or your own personal creativity. For example:

• Do the requirements (checklist #2) account for all of the scenarios (checklist #1)?
• Do the use cases (checklist #3) account for all the requirements (checklist #2) and scenarios (checklist #1)?
• Do the flow maps (checklist #4) address all of the use cases (checklist #3)?
• Have I created all the required wireframes or page prototypes (checklist #5) reflected in the flow maps (checklist #4)?
• Does my prototype (and any associated documentation) illustrate all the use cases (checklist #3) and scenarios (checklist #1)?

Key to success is public visibility of the connections among deliverables. For instance, when showing page flows, start by showing the user stories as a setup for the flows. Or if you are developing user stories, start by reminding everyone of the personas and scenarios. This ensures you have the best chance of making sure the next deliverable is as complete as possible. You also can more readily identify new scenarios, requirements, and user stories without feeling defensive, or like you missed something. If you’re doing this right, you should start to hear your clients say, “This sounds like a new user story!” when new functionality inevitably comes up.

Final Thoughts

The work we do does not yet have a clear place in the well-worn processes of complex digital systems. Others will not define it for us. We have to do it. Embracing the art of the checklist means figuring out how our deliverables fit with others. Treating deliverables as checklists for other deliverables is one way to ensure that what you do not only addresses the work that came before, but will inform and shape the work that is yet to be done.

These checklists are method-independent. If you’re doing waterfall, then use them for waterfall. If you’re doing Agile, then integrate them into your sprints. Checklist thinking allows you to slip into any of the reputable software-development methods without being “certified” in any of them. Checklist thinking keeps you focused on 1) what your deliverable needs to cover to be complete and 2) what your deliverable will be used for downstream.