By Ultan O'Broin-Oracle on Apr 26, 2015
By Floyd Teter, Director, Strategy Group, Oracle Higher Education Practice at Sierra-Cedar, Inc., and guest contributor
A few months back, I received an interesting request from my Oracle Applications User Experience sensei, Ultan O’Broin (Mr. @usableapps). Ultan asked me to read and share opinions on the book Lean UX: Applying Lean Principles to Improve User Experience (Jeff Gothelf with Josh Seiden). I read a few reviews myself and got excited about what Gothelf was trying to do: build a framework for applying Lean principles to user experience (UX) design. I agreed to give it a go.
Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf with Josh Seiden
First, let’s be a bit more specific about the book. The intent is not just to apply broad Lean or Agile principles (Gothelf references both, sometimes interchangeably); the real intent is to apply the Scrum methodology to UX. It’s no secret that I’m a bit of a fan and heavily engaged with both Scrum and UX, so I was excited to dive in.
The meat of the book is divided into three sections: Introduction and Principles, Process, and Making It Work. Each section contains multiple chapters.
In the first section, Gothelf lays out the argument for Lean UX: internet-based software distribution, lower barriers to market entry, continuous integration, agile software development, continuous deployment—all activities that put pressure on teams to shorten cycles to release product early and often, critical to meeting the faster innovation cycles in the SaaS and PaaS world.
Gothelf proposes Lean UX as a deeply collaborative and cross-functional method that enables teams to build a shared understanding about UX design by focusing on objective goals rather than being distracted by deliverables and documents. Having presented this argument, Gothelf then discusses the three foundations of Lean UX: design thinking, agile software development, and the Lean Startup method of build-measure-learn feedback loops, originally founded by Eric Ries.
Design thinking, as defined by design firm IDEO CEO and president Tim Brown, is “innovation powered by . . . direct observation of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold and supported . . . a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.” That’s a real mouthful, but it comes down to designing elegant and simple solutions that people will want to use.
Gothelf defines Agile methods by reviewing the Agile core values and utilizing Scrum to apply these core values. This is not new, but it was good to see Gothelf sign up for using Scrum in UX design. Makes sense.
Finally, Gothelf promotes build-measure-feedback loops. I’m still mostly onboard here, although my preferred viewpoint is a build-observe-learn approach (with observe being mostly watching and listening).
Throughout Part I, which is really a discussion of principles and theory, I’m thinking Gothelf could be my twin brother from a different mother. We’re both singing off the same sheet of music. Part II does seem to be more of a “difficult second album” though.
In Part II, Gothelf applies the principles discussed in Part I, a journey where the metaphorical wheels begin to come off the tour bus. Lean UX relies heavily on written deliverables and formal structure for starting up a UX design effort:
- A hypothesis statement, with assumptions, hypotheses, outcomes, personas, and features
- A problem statement, with product and/or system goals, problem description, and a description of an explicit request for improvement that doesn’t dictate a specific solution
- A business assumptions worksheet, including prioritized assumptions
- A recommendation for written subhypotheses
- A written declaration of metrics to be used along with current state of each metric
- A written list of features matched to groups of user personas
After we’re done with writing (he comments “finally!”), Gothelf proceeds to lay out some pretty formal structure for design studio sessions, including time-boxing presentation and critique, iteration and refinement, and team idea generation. Gothelf also argues for creating a style guide prior to design (as opposed to building concurrently as you progress and learn).
This is the point where Lean UX stopped making complete sense in my world. Agile and Scrum make a point of minimizing written deliverables, especially anything that might be a barrier to getting started with the actual design and build work; the idea being the sooner you get into feedback loops, the quicker you’ll deliver a product of outstanding quality. Gothelf acknowledges this in Part I, yet his recommended process is based on the opposite. Gothelf continues with the formality and structure throughout Parts II and III.
I’m now hard-wired against formality in development; software development cycles in the cloud almost demand that. Partners and developers need to create real solutions fast—formality presents the risk of getting wrapped up in management processes that distract from the essential tasks required to design, innovate and build rapidly.
A final point of contention for me comes with how feedback loops are addressed. These loops are mentioned a founding principle of Lean UX in Part I, yet there is almost no discussion of how to leverage their value (by observing and learning). How do you elicit feedback? How is feedback filtered for relevance and priority? What techniques are used to assure the user that he/she was heard . . . which, in turn, elicits even more feedback. Discussion? Tips? Techniques? Zip. Zero. Bupkis. Notta. Nothing.
My own applied techniques? I suggest following the discover-design-deploy approach on the Oracle UX Direct website.
Discover-design-deploy approach from UX Direct
Begin by recording the required features on Scrum story cards, cutting to the essence of what’s important from your discovery stage. I’d then follow the Scrum process for estimating and prioritizing features prior to starting the first design sprint. Now, I’ve tried lots of virtual Scrum boards for geographically-dispersed project teams to keep track of everything, but Trello remains a favorite. Sprint productivity can be further accelerated by use of UX design patterns and guidelines so that developers can focus in on technical areas.
Trello virtual Scrum board
In summary: The book presents great conceptual ideas, but the approach and implementation didn’t rock my world of delivering on enterprise applications UX today. It left me hoping for more.
My point of view would be to stay away from structural overheads and formality, and stay truer to Agile concepts. I’d recommend a mix tape The Elements of Scrum (Chris Sims and Hillary Louise Johnson) and the simple discover-design, and deploy approach to UX on the Usable Apps website.
Splash BI reports app built using Agile
You’ll quickly build simple, elegant solutions.
Read more Floyd Teter insights on ORCLVille.