Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?
Published: July 24, 2012
UX strategy is a growing field that promises clearer guidance for UX design projects. Agile UX and lean UX are topics that have caught fire in the world of UX professionals, promising faster delivery and less waste. Do the tenets of rapid iteration and minimal documentation that characterize the lean and agile approaches preclude the research and analysis activities that we typically conduct when formulating UX strategy?
I posed the question in this article’s title—“Is UX strategy fundamentally incompatible with agile or lean UX?”—to the UX Strategy and Planning group on LinkedIn. The responses passionately asserted quite different points of view. Jim Kalbach, Principal UX Consultant at USEEDS in Germany, wrote: “I think they are wholly compatible. In fact, with agile’s sprints and quick iterations, it’s even more imperative to have a strategy in place before digging in. So agile makes UX strategy more relevant.”
Joseph Borne, formerly Director of UX Consulting at Bullseye, in Sydney, Australia, expressed a different view: “I’m sad to say that I strongly disagree with anyone who feels that agile/scrum and strategic UX have any overlap. I’ve worked in many [agile/scrum] environments where it overlapped with strategic UX. The inevitable result was complete and utter disaster.”
Given these widely varying perspectives from people who hold responsible positions within the UX community, as well as the fervor with which people are promoting agile UX and lean UX at conferences, I decided to explore the question further. Before discussing their compatibility or incompatibility, I’d like to provide a quick overview of the three topics in question: UX strategy, agile UX, and lean UX.
In an earlier column, “7 Ingredients of a Successful UX Strategy,” I wrote that UX strategy is about developing a rationale to guide UX design efforts in the foreseeable future. UX strategy uses data to establish a product vision, goals, and objectives. Some of the key components of UX strategy include the following:
- business strategy
- competitive benchmarking
- Web analytics
- behavioral segmentation, or personas, and usage scenarios
- interaction modeling
- prioritization of new features and functionality
- social, mobile, and local considerations
The key takeaway is that the purpose of formulating a UX strategy is to develop a rational basis for design decisions, and developing this rationale depends on our having the time it takes to obtain, analyze, and use the data to construct a basis on which we can formulate a strategy.
Agile development is a method of developing software that attempts to overcome problems that have plagued software development for many years. As Tom Wood, Partner at UX consulting agency Foolproof in the UK explains, “The agile approach [solves] a huge problem that came to head 10 years ago: that IT divisions were incapable of delivering at a competitive pace. Something was needed to smash the old rules, and agile has been really effective at doing this.”
Agile has become a fact of life in many companies that produce digital products and their user interfaces. Agile was created by developers for developers. As far as I can tell, it is completely agnostic with respect to user experience. Executives across a range of organizations have embraced agile development. As Mark Schraad, Director of Mobile User Experience at Sears, noted: “Executives are always quick to back a strategy that promises faster delivery…, and agile teams do commit to that pretty often.”
The “Manifesto for Agile Software Development” clearly states its values and priorities:
- “Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan”
Agile UX arose organically out of the need for a user experience approach to working with agile development teams. Agile sprints did not leave much room for typical UX activities and deliverables, and this was the source of many conflicts and frustrations when agile first got introduced on a large scale. The momentum of agile was so great and the problems it attempted to solve so severe that UX teams had to adapt or become irrelevant. The response was agile UX.
Lean UX has been gaining prominence over the last couple of years as an approach to quickly designing new digital products. Lean UX changes the linear path of define, concept, design, and build into an iterative set of design, prototype, and test cycles. Lean UX grew out of the enthusiasm surrounding Eric Ries’s book, Lean Startup. Teams within startup companies originally applied this approach to UX design. Ries defines a startup as: “A human institution designed to create a new product or service under conditions of extreme uncertainty.”
I first heard about lean UX through Jeff Gothelf’s talk at SXSW, “Lean UX: Getting Out of the Deliverables Business.” His presentation emphasized a collaborative process of working, a drastic reduction in the number and scope of UX deliverables that designers produce, and shipping better products, earlier.
Editor’s note—Jeff Gothelf presented a variant of this talk, titled “Lean IA: Getting Out of the Deliverables Business,” at IA Summit 2011. To read Pabini Gabriel-Petit’s detailed review of his talk, see “Conference Review: IA Summit 2011: Part I.”
I can understand how a lean startup would opt for very small teams that shape a product quickly, with substantial input from customers. Some popular bands take the same approach when composing a new song. They start with a riff or chord sequence that one member has created. They play around with it, add some lyrics and a bridge, play it a few times for friends and small audiences, then change it up, and, finally, release a version that is usually quite different from the initial song. It’s an efficient, productive, and elegant way for a band to compose music. Seems like a good way for startups to get an exciting new product off the ground, too.
In a very short period of time, lean UX has adopted some pretty specific practices. Giff Constable, a partner of Gothelf’s at Proof, defines the characteristics of a lean product team as follows:
- “You are composed of small, goal-driven, cross-functional teams
- Each team is tasked with improving a critical business metric (KPI)
- Features begin as hypotheses to be tested before heavy investment
- Features come not just with acceptance criteria but success criteria
- A feature starts as a minimum valuable feature, and then iterates
- Proof carries more weight than opinion
- The team talks to real customers on a regular basis, including in-person
- The team works in agile sprints, with close collaboration across all roles
- The team communicates regularly with the rest of the organization and is transparent about priorities and work-in-process
- Each team has regular checkpoints where you decide to stop, change, or double-down on pursuing the KPI”
The same description might apply to a lean UX team.
Is UX Strategy Compatible or Incompatible with Agile UX?
Within an agile development environment, agile UX attempts to optimize the user experience of the products that agile teams produces. The articles about agile UX that I read in preparing to write this column focused primarily on three topics:
- participating in an agile team structure
- modifying UX activities and deliverables to fit an agile process
- timing UX activities to coincide with sprints
Participating in an Agile Team Structure
For many UX designers, agile UX means becoming a full-time member of a scrum team. Supporters of agile UX encourage designers to expose other team members to their UX design process and to demonstrate early results, giving other team members an opportunity to weigh in and thus develop a sense of ownership in the results. Detractors say this makes lean UX a classic case of design by committee.
Modifying UX Activities and Deliverables to Fit an Agile Process
It seems to be a foregone conclusion that UX activities and deliverables get cut back in agile environments. One reason is that the agile approach is decidedly anti-documentation. Jim Kalbach, however, doesn’t see this as a conflict for UX professionals: “Agile doesn’t mean no planning and no documentation at all. It just doesn’t require programmers to document their code. You still need to develop business plans and strategy first. So there’s nothing inherent in agile methods that excludes UX strategy [in] any way.”
Another reason for a reduction in UX deliverables in agile shops is that it takes a lot of time just to sit through meetings that focus on non-design issues. How can a UX team member complete the time-consuming data gathering and analysis that are necessary to develop a coherent UX strategy if they spend much of each day in team meetings? David Garrett, UX Engineer Lead at FICO, addresses this issue: “Although agile’s short iterations catch small problems before they become larger ones, if you add up all the extra time spent in meetings—me listening to what four other people are doing that I have nothing to do with, which accounts [for] lost productivity time—the hours wasted become significant.”
Timing UX Activities to Coincide with Sprints
The timing of UX activities gets a lot of attention in agile UX discussions. Agile development sometimes takes place in two week sprints. How can UX strategy have an impact on the overall direction of a product when a team subdivides its development into two week windows? Mikkel Michelsen, Lead User Experience Designer for eBay Classifieds in Scandinavia, wrote that it is essential to work out your strategy first: “To work with agile UX, you need to have gone [down] the strategic path first and sort of scale down [your] processes and methods to a leaner approach.”
Peter Boersma, an interaction designer in Amsterdam, agrees with Michelsen, writing, “An initial UX strategy would have to be developed before UX design and development starts. Agile teams expect their Customer to come prepared with ideas of what products and services need to be developed, and that requires a strategy to be in place that suggests such products and services. In that case, they are not incompatible; one happens before the other.”
Drew Ellis, President of Dreaming Entirely, agreed that timing represents challenges for UX designers on an agile team: “The process of ‘sufficiently in advance’ is one of the biggest challenges for effective UXD.”
Timing during the agile development lifecycle introduces other constraints on user experience. Participating in an agile team means the prioritized backlog of the scrum team determines a designer’s daily activities. Some UX professionals feel that working from the backlog inevitably pushes small, easy fixes to the forefront, while features that would greatly enhance the user experience, but are difficult to develop get pushed down in priority, effectively removing them from design requirements. Along those lines, Joseph Borne writes that UX team members in an agile environment can be “restricted to addressing granular usability issues. In those instances, the changes necessary to fix one section or field can often create more complex issues or even invalidate any way of fixing other sections or fields. The project becomes a no-win scenario filled with logic puzzles.”
Robert Gillham, Principal Consultant at the UX consulting firm Foolproof in the UK, takes this a step further, saying that the attempt to integrate UX and agile development is not in the best professional interests of UX team members: “Tying user experience design to an agile approach is to risk making UX the servant of coding rather the other way round.” He continues: “Why would a UX designer want to be shackled to something as time-limiting and punishing as agile when it solves none of their problems, but introduces so many more?”
Another criticism of the agile development lifecycle is that it doesn’t allocate time for doing due diligence in terms of strategy or vision. For example, in the interest of rapid development, teams often rely on assumptions in constructing user stories rather than relying on hard data. However, Saumitri Choudhury, Head of the Product User Experience Group at GlobalLogic, doesn’t think that the agile development cycle precludes strategic UX: “It only becomes incompatible if you think of UX strategy as [doing] once-done-and-hand-over, big strategy work up front, as against a Strategize > Design > Get Feedback cycle.”
While I don’t necessarily see UX strategy as a “once-done-and-hand-over” deliverable, neither do I see it as something that a small, cross-functional team should modify by brainstorming on and debating its merits. If you’re going to modify your overarching UX strategy, you need to modify it on the basis of superior or more compelling data, not a freestyle debate.
Dana Martinelli, Director of User Experience at Apangea, stresses the importance of UX research to inform team decisions: “UX cannot be done effectively by iterating with developers in sprints without deep research going in.”
So, Are They Incompatible?
My take: UX strategy and agile UX are neither compatible nor incompatible. In an agile shop, UX strategists have to get ahead of the curve and do their work before agile development starts. They need to coach UX team members and convince others on a product team to value the guidance that UX strategy brings to digital design efforts and to follow the strategy in making design decisions throughout the life of the program. Once the agile train gets rolling, it may be very difficult to introduce strategic considerations.
UX strategy can provide the strategic guidance that agile doesn’t attempt to provide. As Liam Friedland, Senior Director, User Experience at Informatica, puts it: “Agile is a process; ergo a set of tactics. Agile is not a strategy. Sun Tzu provides us with a good understanding of the relationship between these two: ‘Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.’”
Is UX Strategy Compatible or Incompatible with Lean UX?
Some time after Jeff Gothelf’s SXSW talk, Jared Spool interviewed him for a podcast about lean UX. During the interview, they discussed the adoption of lean UX by much larger organizations that have little or nothing in common with startups. Such companies are very large, stable organizations that face little uncertainty in terms of running out of cash before their blockbuster product hits the market. They do face uncertainties, of course, such as how to remain competitive in a rapidly changing digital world. But their team structures, availability of analytics and customer data, time and resources for discovery and exploration, brand equity, documentation requirements, and internal processes make them very different from startups. Nevertheless, larger companies are apparently jumping on the lean UX bandwagon, saying, “We need to deliver digital products faster, trim down our teams, ship what customers want, and jettison all those time-consuming deliverables!”
Interestingly, Giff Constable, in his definition of a lean product team, is careful to note that his use of the term lean is “the Eric Ries version of lean, aka lean startup.” Does lean UX make as much sense for large companies, with product and Web teams of 100 to 200 people, as it does for a startup consisting of few caffeine-infused twenty-something year olds, who get by on little or no sleep to achieve the dream of a blockbuster product and an IPO and have a limited pile of someone else’s cash to burn before they have to give up and get steady jobs?
The answer to that question is beyond the scope of this column. Although it does impact my original question: Is UX strategy fundamentally incompatible with lean UX? My answer: It depends on the organization.
For startup companies, UX strategy and lean UX seem like they could be compatible, depending on how one formulates strategy. Joshua Seiden, Founder and Principal at Proof—where Gothelf is also a partner—wrote, “Lean UX is essentially strategic. The central questions it answers are: ‘What do our customers and users value?’ and ‘What will we create to deliver that value?’”
Seiden goes on to differentiate the strategic nature of lean UX from the pragmatic agile UX approach: “People write about lean UX as if it is a synonym for agile UX. It is not. It is a related way of working that uses design thinking, lean startup, agile, and UX methods to go after value. Agile UX on the other hand is a set of practices that UX practitioners can use to integrate into agile development processes.”
Dr. Natalie Hanson, Associate Principal at ZS Associates, adds: “To properly bring lean to an organization and a set of work practices, it, too, needs to be more than just tactics.”
But what about lean UX in large companies? Is UX strategy fundamentally incompatible with lean UX in well-established corporations? After researching lean UX for this article and combining that information with my background in UX strategy in large organizations, my conclusion is: They are fundamentally incompatible.
Am I saying this out of self-preservation? A desire to keep my clients from trying the dark magic of UX strategy themselves and finding out that any three people with a whiteboard can do it? No. I can explain my perspective with a brief illustration. My father used to fly a navy plane, which required taking off and landing on aircraft carriers, where the runways were tiny in comparison to those of typical airports. By necessity, he had to be able to get airborne instantly and to land on a few feet of airstrip. That was the nature of the job, and it was a matter of life and death. However, for commercial pilots, the ability to take off and land a jet in a tiny space is of no value. The size of their aircraft and the safety of their passengers demands that they use the full runway that is available to them.
Startup companies typically have very little runway. They need to get airborne as soon as possible or die. Large organizations have a much longer runway. They can afford to wage a more effective competitive battle and should use every available resource to gain and maintain competitive advantage. The lean UX form of UX strategy is too lightweight, too reliant on small data sets, too malleable, and too subject to the assertiveness of a just few individuals. For a large company that has a deep understanding of its market, its customers, and its competition, and the resources to fund the best path forward, it’s not the optimal approach.
I’ll use few what-ifs to illustrate why I think lean is not only trimmed of fat, but is also missing some of the muscle that a strong UX strategy practice provides:
- What if customers don’t like the quickly constructed prototype you showed them, but would respond very well to a more complete solution? This is a false negative. For example, a half-baked cake tastes terrible, but the fully baked version of the same cake could be a winner.
- What if customers try the prototype and don’t like it, because it is void of the data connections that would make it useful in a real-life context? In this case, a critical factor is missing.
- What if an effective product requires an offline component that would act as a catalyst and lead to its widespread adoption—for example, sales associates’ word of mouth—but you can’t fake this offline component during prototype testing? This is another case of a missing critical factor.
- What if customers like what you show them, but then, in practice, would use something else because of either its superior marketing or the influence of their peers? The result is a false positive.
- What if the metrics you gather during a lean UX get-out-of-the-building (GOOB) exercise with three customers indicates that you’ve got a hit, but you’d actually need to do a quantitative study to accurately assess your product’s potential market share? You’d have an insufficient sample size.
- What if the team creating a complex product is enormous, and your part simply doesn’t work without their part? The whole is greater than the sum of its parts.
In more practical terms, when does lean UX provide an adequate approach to UX strategy? Should a startup trying to invent a manly version of Pinterest use lean UX to guide their design strategy? Absolutely. The vision of their product is clear. They need a design that works, and they need it very quickly. Should BestBuy.com base its UX strategy and roadmap on the ideas of a small team of developers and designers who develop nifty features and try them out on a few customers to see if they fly? No. The latter case is clearly a tactical rather than a strategic approach.
I said earlier that the lean UX process is similar to the process some musicians use for writing a popular song. However, it’s nothing like the process for building a sports stadium or a commercial airliner. Those projects require intensive planning and extensive specifications. Of course, stadium builders and airplane manufacturers could save some time by drastically reducing the scope of the specifications and documentation they create, and they could save money by using much smaller teams of people who merely debate on the best approach, then try it out on customers instead of letting data constrain and define their direction. But the result of such an exercise on products of that scale and complexity would be utter chaos. Will Boeing engineers write the next hit tune? Probably not. Do you want to ride on a plane that the band One Direction engineers? Probably not.
UX strategy is about building a rationale that guides UX design efforts for the foreseeable future. UX strategy can be effective in an agile environment if you can complete the strategy before agile development begins. Following a lean UX process, you can develop a UX strategy that is sufficient when time and money are very tight, and you need to complete a working product at the earliest possible date. However, lean UX does not serve UX strategy well in large companies that can afford the time and resources to collect and analyze the data they need to formulate a strategic UX roadmap that produces a sustainable competitive advantage.