Last Fall, we were working on a product for a client whose industry was undergoing substantial disruption. The project involved a robust upfront discovery piece running the full gamut of customer insights, competitive analysis, and even business model exploration. We undertook lots of primary and secondary research, thoroughly analyzed the data, and generated a nicely synthesized plan. When we presented our carefully crafted strategy to the client, they were happy and agreed to have us go ahead with the design phase.

Then circumstances caused the brief to change. Massively. And in many respects, we were back to square one. We had done all of this work to get senior client stakeholders to buy into our initial vision and plan of attack, and we didn’t have the time to do it again.

Huddling together as a team, we decided to try something that seemed bold at the time. We realized that, even in light of the changed brief, we still had convictions about what needed to be done. We had some early design exploration and had a handful of data points and rationale that we believed were compelling. So we pivoted, and called the client into our office to pitch them on what we had in mind.

This time around, there was no PowerPoint deck. No highly refined proprietary insights. No shiny new personas, design principles, or other polished artifacts of strategic synthesis. Just a high-level model of the problem as we saw it, the solutions that we thought were in reach, and some quick sketches of how this all might play out in design. We stood at the whiteboard and within about 15 minutes, had gained consensus and a fresh mandate for our designers to move ahead with.

In retrospect, what seemed at the time to be an almost reckless attempt to salvage a project in distress turned out to be the right course of action. We were trying to develop a minimum viable product; but it took a near crisis to realize that what we also needed was a minimum viable strategy. Over time, I've become convinced that this approach to UX planning—let's call it "lean strategy"—is more often than not a better option.

What Lean Strategy Means

Lean strategy in UX design means getting to a simple, actionable statement about what problem we are going to solve for the user as soon as possible, so that the design process can proceed. In fact, lean strategy often happens in concert with design, enabling us to be more adaptive and to more easily apply our thinking to our designs. It's about being less precious and profligate with our decks and deliverables, freeing us up to bring greater clarity and focus to our ideas. It's strategy in motion, pressing us forward rather than holding us back until everything has been figured out and proven with mathematical certainty.

What Took So Long?

So what took us so long to discover the merits of lean strategy? I think there are three main factors that have traditionally held designers back.

1. We don’t actually know what strategy is.

Think fast: What is strategy? Business development consultant Blair Enns has a personal hobby of collecting responses to this question. A few choice examples: “Strategy is how you do what you do” ... “Strategy is an idea that describes a journey to a position of advantage” ... “Strategy is how you're going to be unique, and use that uniqueness to competitive advantage.”

Note that these definitions do not necessarily entail a regimented methodology of inquiry, copious amounts of data, or even highly refined proprietary insights. Those may be important depending on the circumstances, but they are not necessarily essential. Rather, strategy is about the organizing principle that gives our actions and decisions meaning and purpose. It is the ideational focus that lets us set priorities and make intentional choices. To borrow a phrase from Soren Kierkegaard, (that pioneer of lean strategy), "purity of heart is to will one thing." No matter how many data points or insights you have, if you don't know what that "one thing" is that you're trying to accomplish, I would suggest that you don't have a strategy.

2. We aren't incentivized to do it!

This is especially true for UX practitioners in the client services industry, although I've seen many overwrought business cases and strategic plans generated internally as well.

We often feel pressured to develop and deliver exhaustive, elaborate strategies because we get compensated/credited for the time we spend making them. Lean and adaptive strategy efforts may even be perceived as disruptive inside of businesses that want predictive power and certainty. But adding more complexity to our process can often work against our ability to reliably assess and predict. Moving to a value-based compensation model can help incentivize us to be effective rather than excessive in how and where we invest our time and energy.

3. We lack confidence and overcompensate.

Sometimes over-delivering on strategy happens as a sort of unconscious hedge. We're working on a problem and we don't know what the solution is, so we generate a lot of smoke to obscure the uncertainty. This can result in big, complicated strategic reports and decks that appear to be highly rigorous and substantive, yet ultimately take us nowhere. In fact, experimental evidence shows that we are hard-wired to over-evaluate the perceived utility of additional information. Information bias causes us to believe that we need more information before committing to a decision, even if that extra information is irrelevant.

Pushing back against this information bias requires discipline and courage. Ultimately, the results from this push back can be better communication and more engagement with those we are trying to persuade. Consultants with McKinsey are trained to put their main findings and recommendations at the very beginning of their decks. This is because C-level executives don't have time to deal with all of the material; rather, they selectively engage with specific items in a more interactive way. Lean strategy means getting to the point sooner so that our clients and stakeholders can quickly become active in the process.

How do we practice lean strategy?

Here are some good starting points:

Distill what you deliver into its simplest possible form

Complexity is truly the enemy when it comes to lean strategy. In fact, according to Bain & Company's co-head of global strategy Chris Zook, complexity is generally one of the most disruptive forces in modern business. Having an extremely clear articulation of differentiation, or creating a handful of "non-negotiables" that follow from this differentiation can be very powerful elements in a successful lean strategy.

Develop a reusable framework

It can be difficult to formulate and deliver lean strategy if you have to work from first principles every time. That's why Blair Enns (who was mentioned earlier in this article) advocates developing a framework that you can work from in a repeatable fashion. Having an established point of view or a working theory to start from—so long as you're conscious of the bias that comes along with it—is a great way to interrogate a brief and start sparking new ideas right away.

Go to a playbook model

Consider developing a strategy "playbook" that gives your team ready-to-hand tools and methods (the more lightweight, the better) to use selectively depending on the circumstances. The key here is that rather than a systematic, exhaustive strategic process, a playbook lets you use only those tools that fit the job. This idea works particularly well in conjunction with "developing a reusable framework."

Fuse strategy and design exploration

Strategy should never impede design, but rather animate and propel it forward. We needn't wait for the strategy phase of a project to finish before undertaking some form of design exploration. In fact, the converse is true: getting into early design exploration based on what we provisionally know can inform and enrich strategic exploration. Creating something tangible, even if it means failing early, is a powerful way to gain a fresh vantage point—which can in turn help us crystallize our strategic ideas and outlook.

Stage-planning as an ongoing track in your project plan

By thinking of strategy and planning as a continuous endeavor over the course of a project (instead of a discrete, initial phase) we relieve some of the pressure to get everything right from the start. This frees us to focus on what we're sure about, identify our assumptions, and acknowledge where critical knowledge gaps exist. Then, as the project evolves, we can refine and revise our plan in light of much more reliable data than we could have projected at the outset.

Strategy Wants to Be Lean

Imagine what it must have once felt like setting out on an ocean voyage to some uncharted place. How would you plan and prepare? Maybe you'd sketch a map or plot a course using various accounts from other travellers. Perhaps you'd study the tides and weather patterns that will impact your outbound route. You would certainly need to build a team and assign roles and responsibilities for each member. These are all great steps to take, but until you actually get in the boat, none of them get you any closer to your destination.

And consider this: the most valuable and reliable tools and methods for finding your way—a compass, celestial navigation etc.—only work once you're in the boat and on the move!

I want to be clear about one thing: I am not saying there is a one-size-fits-all way to execute strategy for UX design. There are no shortcuts that let us bypass or opt-out of disciplined inquiry. Rigorous investigation and analysis has its place. Ultimately, however, strategy only becomes meaningful when it can be proven out one way or another—just as our sketched map only becomes useful once we're moving toward our destination.

Effective strategy is bold enough to make claims and stake out territory. Yes, these claims need to be evidence-based, but that doesn't mean they can never be wrong. Lean strategy for UX encourages us to move forward based on the claims we can make right now; it prompts us to gather our courage and our wits and actually get in the boat. Real discovery can only happen when we embark on the journey.


Compass image courtesy Shutterstock


To be totally blunt, it's surprising for me to see UX designers adopt the lean startup approach because in my experience, they are contradictory. The basic UX assumption is that there are reliable methods that you can use to understand your users' needs. Lean startups make the opposite assumption that you can't know your users' needs, all you can do is build and measure, optimizing for a chosen success metric.

To use David's ocean voyage metaphor, lean startups just get in their ship and set out with no map. They take one small step in a random direction and measure the new distance to their destination. If they are closer, they keep going or alter the direction to get there faster. If they're further away, they try a new direction. Then they iterate: take the next step, measure distance, change course as necessary, and so on.

This is supposed to be useful if the terrain is uncharted. But it should be obvious that this method is only guaranteed to work when you do know the terrain, and you know that you can draw a straight line from start to finish. That's the only situation where the travel plan of decreasing the distance will get you there. Lean startups set out by hoping they're in that situation. When they hit a wall, they pivot, which means picking a new destination and hoping there's a straight line to get there. That's great, but what if you don't have the luxury of picking an easier problem to solve?

UX strategy can tell you about your users and what they need, and give you solutions for how to get there - the linear optimizing path is one solution among many. Much of this work has to be done upfront, just like you have to plan a trip before you leave. Yes, you can develop your strategy adaptively, planning your trip while you are on the trip, but what's the point of doing that? Then your strategy looks backwards, recording decisions instead of guiding decisions.

Hi there, thanks so much for your thoughtful questions and comments! Anastasia hit on a point that I probably could have made more clear, which is that this is really all about how we approach strategy—the philosophy and framework we bring to bear. What I am definitely not trying to do is declare what counts as strategy vs. what doesn't.

That's why I agree with Jordan that research, analysis, and deliberative/critical thinking can all be important tasks for the strategist to take on where appropriate. But what I've come to question is a) how exhaustive do we need to be in these tasks before we start designing; and b) whether these tasks ought to constitute a distinctly independent mode and/or phase of a project in the first place. I'm suggesting that the answers to these questions are a) "not as much as we think", and b) "err, no."

Nick, I didn't mean to imply in my opening story that if only we had executed a lean strategy, the project mandate wouldn't have shifted. (I mean, it may have been the case that if we had gotten to something tangible earlier, then things would have played out differently, but that's entirely speculative.) The story was really only there to explain how we stumbled onto this realization that a leaner approach to strategy was viable. As I said, it took a near crisis to force us to take this step that, now in retrospect, seems quite sensible, but at the time felt like a real leap of faith.

At any rate, I take your point that we were probably able to successfully pivot in part because our initial strategic effort had been instructive (perhaps even in ways that we may not have fully realized at the time). But at the same time, I'd have to push back against the notion that all we were doing was re-synthesizing or repackaging the same set of data points. It's not really appropriate to get into the details, so you'll have to take my word that the brief changed substantially enough that we pretty much had to move to a fresh strategic foundation.

One last thing to add, and this circles back to Anastasia's remarks: I think where lean strategy really starts to make a lot of sense is in product and service design, where the trick is to solve actual customer problems that are more often than not rooted in utility. Here, quickly getting to a concrete expression of exactly what problems you're solving and how you're going to solve them is the name of the game. And a a lean approach to strategy is a great way to make that happen.

I would say that what David is promoting is more about approach than formal 'strategy'. However the principles he outlines for 'lean strategy' are spot on. Products/services/life are in a constant state of flux and have a life of their own: good design strategy/approach should address both the past and the future, and be flexible, nimble, and generous enough to adapt to and incorporate the unknown.

I'm not sure if you're talking about strategy as it pertains to a project, or strategy as it pertains to how you approach UX... I mean, I'm sure you not suggesting that a strategist shouldn't examine data, understand KPI's, and figure out a communication plan; but it kind of sounds like that's what your suggesting in a couple places.

I think there is a case to be made for a strategist beyond a group sketching exercise. I agree that everyone wants to get the broad-strokes of any plan down as quickly as possible, but there are things like SEO, differences in mobile mindsets, and ecosystem design that require some research and critical thinking.

If you're suggesting that the UX portion of a project should take a lean approach, I'm definitely more in agreement, but would suggest that it's not possible to work that way with every client. I think a lean approach to UX upfront will require an infusion of UX (and someone to evangelize UX) throughout the project lifecycle.

Thanks for sharing this point of view. My struggle with the article is that it's hard to take much away from this without more understanding.

Why did the project shift? Because the evidence suggested it should or because of another reason? You could say the "strategy" piece was a success if it caused the product focus to change.

Could you have followed this lean approach if you hadn't done the initial research? I read this as you did a bunch of research, a bunch of synthesis, then changed direction and chose not to polish the revised synthesis. But you had done a lot of strategy up to this point to have a strong sense of what to do.

Questions aside, this approach works when you have a decent sense of the domain you're designing for and a pretty good understanding of the people you're designing for. And if the team you're working with is small, has a good handle on the users to design for, or senior buy-in is not a major requirement for project success. I don't think of personas or principles as strategy per se so much as the output (design tools) of all the work that's happened so far to help the team focus conversations throughout the design phase. And presenting polished ppt decks for the sake of it is something we could all do less of. But cutting research and synthesis time is something to do sparingly as this is a necessary process we go through to understand the problems we're challenged with and the people we're designing for.

I was delighted. Thanks so much for the article.

Insightful article. I've read a ton on the importance of planning, strategizing, and preparing in a lot of online resources we all relate to. As a developer who incorporates UX heavily into my work, it's refreshing to hear another side of this story. Thanks!