Is lean UX relevant to the enterprise?

Last time I blogged on Enterprise UX, I examined the UX skills gap, and why it's difficult to assemble the teams needed to create effective - let alone elegant - user experiences. Then I was pointed to the book Lean UX: Applying Lean Principles to Improve User Experience, which frames UX in the context of O'Reilly's "Lean" series.

In Lean UX, author Jeff Gothelf integrations the UX endeavor with Agile/Scrum methodologies. The two have not always co-existed well. The less-structured process of designing UIs that don't suck is not always amenable to a series of sprints.

What drives "Lean UX" thinking?

My interest is broader: do the principles of Lean UX help us to solve Enterprise UX issues - or think about Enterprise UX differently?

Gothelf defines three core drivers for so-called "Lean UX":

• Removing waste from the design process, by shifting from obsessively-documented handoffs to a process that creates only the design elements needed to move the team forward.
• Improving the efficiency of the design “system” - which includes developers, product managers, quality assurance engineers, marketers, and others. This is accomplished via open, cross-functional collaboration. The end result? Integrating key stakeholders who are not designers into the design process.
• Moving away from dependency on "rock star designers" to a focus on systems that exploit rapid experimentation and measurement. Rather than ask a design guru to invent one perfect UI, the cross-functional team evaluates the impact of various designs based on user testing, interaction and researched personas.

Perhaps most interesting, to those of us who are enterprisey, is how Gothelf pulls agile methods and design thinking together:

Besides Lean Startup, Lean UX has two other foundations: design thinking and Agile development philosophies. Design thinking takes a solution-focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works toward product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light. Agile refocuses software development on value. It seeks to deliver working software to customers quickly and to adjust regularly to new learning along the way.

Principles of Lean UX

To achieve the aims of lean UX, Gothelf outlines fifteen design principles. Fifteen is a bit much to review in one post, so I'll give you five that stood out.

1. Progress = Outcomes, Not Output - As Gothelf puts it, "Features and services are outputs. The business goals they are meant to achieve are outcomes. Lean UX measures progress in terms of explicitly defined business outcomes."Although it's not always easy to measure the business results of a terrific UX, it's thinking in outcomes and not in terms of whizz-bang features is a key step in separating Enterprise UI from consumer.

2. Continuous Discovery - One of the biggest software design gaffes of years past is huddling down and designing something that is out of step with customers and their rapidly evolving needs.  "Continuous discovery" intends to change that through "the ongoing process of engaging the customer during the design and development process." Showing customers ideas when they are still imperfect is counter-intuitive to some. But as Gothelf puts it, "Test your ideas with a strong dose of reality while they’re still young."

3. Anti-Pattern: Rockstars, Gurus, and Ninjas - Gothelf warns of the team-wrecking impact of self-appointed design mavens. The collaboration required for modern UX just doesn't play well when an individual is jockeying for position, regardless of talent: "Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars." Gothelf's antipathy towards rock star designers aligns with prior content I have done on Enterprise UX skills, and why the Enterprise UX skills problem is solved by teams, not individuals.

4, Externalizing Your Work  - It's not easy to get in the habit of exposing ideas throughout the design process. But the lean UX approach is about "getting your work out of your head and out of your computer and into public view." It almost doesn't matter which tool is used - Gothelf notes the use of whiteboards, foam-core boards, artifact walls, printouts, and sticky notes. Bottom line: the work gets exposed to team members, managers and customers even when it's incomplete. This is different than how most enterprise Proof of Concepts (POCs) are done, though that's starting to change. Gothelf:

The answer to most difficult questions the team will face will not be answered in a conference room. Instead, they will be answered by customers in the field. In order to get those answers, you need to make the ideas concrete — you need to make something for people to respond to. Debating ideas is waste. Instead of analyzing potential scenarios, make something and get out of the building with it.

5. Learning over Growth - I'd call this one "Prove it before you scale it." Given the need for early stage experimentation, Gothelf sees the process of design and the logistics of scale as contradictory undertakings:

Lean UX favors a focus on learning first and scaling second. Scaling an idea that is unproven is risky. And it might not. If it doesn’t work and you’ve scaled it out to your entire user base, your team has wasted valuable time and resources. Ensuring that an idea is right before scaling it out mitigates the risk inherent in broad feature deployment.

Putting Lean UX into practice

So how do you get started? Gothelf devotes a good chunk of the book to the practicalities of lean UX, including building a hypothesis statement, a business assumptions worksheet, a persona template, a design studio, style guides, prototypes, and an activity calendar.

His "five easy steps to Lean UX" are as follows:

• Solve problems together: make sure all team members are present from brainstorming onward.
• Sketch: Create visual renderings to solidify ideas and build towards consensus.
• Prototype: Move towards actual product quickly - then get validation on those prototypes from customers to ensure the design is on the right track.
• Pair developers and designers: Get developers and designers working together from the get-go to design user interfaces and develop a common language.
• Create a style guide: Consolidate re-usable design elements into "pattern libraries" and code respositories to ensure future designs are built efficiently, and with the same look and feel. This will also reduce the need for continual review of developer interfaces by the UX designer.

My take

I don't have much interest in branded concepts like "Lean." But it's clear that this Lean UX content is relevant beyond a lean startup context. Gothelf's examples come from a range of company sizes, leading to the conclusion that "Lean UX" is, for the most part, just good UX. While principles of transparency and discovery via customer interaction might seem like no-brainers, the fact is that many companies have no modern UX methodology to speak of.

This book provides the talking points for customizing a Enterprise UX framework. But do you have to be committed to agile development methods to use these concepts? Not necessarily. The process of incorporating customer viewpoints into UX teams could be adjusted to waterfall approaches also. Of course, some enterprise teams are under too much pressure to build pilots and prototypes in an experimental context. They have to scale quickly - and improve the user experience across software products within short timeframes.

That's why I view such books less like instruction manuals and more like tools that can be re-assembled to fit your culture and methods. If the principles seem too broad to be useful (a complaint of a couple Amazon reviewers), I'd recommend consulting the book for more specifics on implementing each.

Enterprise software companies all claim to be enhancing the user experience and creating modern UIs. Such trends are welcome. But what if your enterprise software vendor delivers a great new UX on the one hand, but then your company is targeted for an unwanted software usage audit on the other? Or maybe the support and escalation process is one step above dental surgery. Or: the web and mobile app is terrific, but the call center is incompetent. All of that pertains to the overall customer experience, and a spiffy new UI won't solve that by itself, no matter what side of that UI you're on. But a better approach to building UX teams is still a good place to start.

Note: this article is part of a diginomica series I am writing on Enterprise UX, mobile apps design, and the skills required to change the user experience. Yesterday I spent time with Infor's Hook & Loop design team in New York City - I'll have lessons from that visit up on diginomica soon.

Image credit: Skinny guy lifting large rock stone weights © ra2 studio - Fotolia.com

Disclosure: diginomica has no financial ties to O'Reilly or to Jeff Gothelf. I purchased a copy of Gothelf's book in order to review it here.