Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?

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.

Conclusion

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.