Reading the The Lean Startup by Eric Ries was one of those foundational mind-shifting books for me. The Build-Measure-Learn feedback loop, using the scientific method of starting with a hypothesis and defining ways to test it up front, and the concept of the MVP have changed the way I think of software development. I’ve been pressed recently in how to integrate UX into our Scrum team so I sought out Jeff Gothelf and Josh Seiden book Lean UX: Applying Lean Principles to Improve User Experience. It’s a quick read with some great practices for UX in agile environments. Here are some of my takeaways.

Differentiating Product Discovery vs Product Delivery

Two different outcomes. One is learning. One is value add to user. Do we sometimes trick ourselves in crafting user stories thinking we are adding value to the user when really a product discovery story aimed at learning what is valuable to the user would be more beneficial? The authors even suggest doing away with user stories and instead use hypothesis formed backlog items to be fully honest about the assumptions we are making.

We believe [this statement is true]. We will know we’re [right/ wrong] when we see the following feedback from the market: [qualitative feedback] and/ or [quantitative feedback] and/ or [key performance indicator change].

Gothelf, Jeff; Seiden, Josh. Lean UX: Designing Great Products with Agile Teams (Kindle Locations 720-723). O’Reilly Media. Kindle Edition.

The common understanding of the term ‘spike’ in the agile world is that it is an item of work that won’t be providing direct value to the user, but rather used to research, prototype, or learn. I admit I’ve had a negative connotation around user stories framed as spikes and have spent many cycles looking to reframe spikes as value producing user stories. That shifted for me reading through Lean UX. A Spike may not add immediate value to the end user but it enables Product Discovery. Could it be that the product backlog is overly invested in product delivery and not enough invested in product discovery?

We Will Start Building the Wrong Thing

With one of the principles of Lean UX being “No rock stars, gurus, or ninjas” there is a really attractive team dynamic of shared humility. With no single ‘hero’ for dropping the golden architecture, wireframes, or product direction it frees the team to accept and even embrace that we will make incorrect assumptions. The mindset then shifts to how can we learn as fast as possible. This brought new light to the 4th principle of the Agile Manifesto “Responding to change over following a plan”.

The assumption in Lean UX is that the initial product designs will be wrong, so the team’s goal should be to find out what they got wrong as soon as possible. As soon as the team discovers what’s working and what’s not, they adjust their proposals and test again. This input from the market keeps teams agile, constantly nudging them in a “more right” direction.

Gothelf, Jeff; Seiden, Josh. Lean UX: Designing Great Products with Agile Teams (Kindle Locations 324-327). O’Reilly Media. Kindle Edition.

A culture where there is permission to fail starts with accepting that we are probably wrong much of the time. A wonderful analogy was laid out by the authors explaining the grading system for a ceramics class. One group of students were told on day 1 that they would be graded on the quality and aesthetics of a single piece of pottery. The other group of students were told that they would be graded purely on the cumulative weight of all pottery produced during the term. What happened at the end of the term? Well, the group that was focused on rapid iterations, trying out all types of failed experiments had pieces of work that far outshone the group that tried perfecting just a few pieces over the term.

Keep Design Artifacts Lean

The agile software movement has largely moved away from BDUF (Big design up front) in software for a long time now in favor of embracing changing requirements, evolutionary design, and shorter feedback cycles. Can these same practices be applied to UI designers, UX researchers, and interaction designers as well? I was challenged in reading Lean UX in that BDUF wireframes and designs are just another form of inventory.

Lean strives to eliminate excess inventory. One way of doing this is by embracing what’s called a demand-based pull flow. With the immediate business objectives at hand can the product team pull from the designers just enough artifacts to build and ship value?

Another key to eliminate excess inventory is small batches. Can the design work be split into smaller batches to increase throughput and flow?

One takeaway for me in keeping design artifacts lean is what Jeff Gothelf and Josh Seiden call a Design System. A design system is a type of asset library or kit to enable a consistent style and approach for all visual elements in the application.

In practice, a design system functions as a single source of truth for the presentation layer of a product. Teams can sketch at the whiteboard and then quickly use the elements found in the design system to assemble a prototype or production-ready frontend.

Gothelf, Jeff; Seiden, Josh. Lean UX: Designing Great Products with Agile Teams (Kindle Locations 1211-1213). O’Reilly Media. Kindle Edition.

Not being a designer I’ll admit I don’t have know all the specific challenges in UI design. How does one ensure a consistent look and feel? How does one avoid half-baked functionality that may upset the user? How does one avoid confusing the user by changing elements around? I wonder though, are the arguments for BDUF in visual design different than the same argument for BDUF in software design? I suspect the same benefits in Lean Software Development apply to Lean UX and it is a matter of finding the right approaches, techniques, and mind shifts to remove the pains of BDUF and embrace the Lean principles to see faster feedback cycles, increased throughput and reduced waste in the value stream.