Part 6: Why is a Raven Like a Writing Desk? PrD and Lean UX

Published on

by Leo Frishberg.

Tenniel drawing of Alice with Hatter and Hare

In this and several other posts, we address a corollary to Lewis Carroll’s famous riddle. In our case: “Why isn’t Presumptive Design like                                  ?” In this post we tackle the comparison between Presumptive Design and Lean UX.

See these posts for other comparisons.

In their 2013 book, Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf and Josh Seiden proposed a radical approach to UX design. Inspired by the Lean movement (a method of reducing waste and improving efficiency on the factory floor) and agile software development, Lean UX promotes creating a solution in lieu of creating “deliverables” (the documentation usually associated with a design such as wireframes, specifications and the like).

The casual reader, simply scanning the table of contents of Lean UX and Presumptive Design, might conclude the two books describe the same process: capturing the team’s assumptions to rapidly create a proto-solution (in the form of a prototype) that is refined iteratively over a short period of time. Because both approaches have agile-like qualities of rapid creation and testing, it’s easy to get them confused, but the two methods are significantly and subtly different.

Why PrD is not like Lean UX

Identifying Assumptions

Both methods require the team to identify its assumptions, and both promote activities to capture those assumptions. The methods diverge once the assumptions are identified: In Lean UX, the team uses the assumptions to define problems statements; in PrD, the team immediately creates an artifact from the assumptions. In Lean UX, the problem statements lead to hypotheses which are then tested using real code. In PrD the assumptions, as embodied in the artifact, are tested immediately to determine how well the assumptions resonate with end-users. This major distinction between the two methods results in radically different work-streams.

MVP vs. Artifact

We discuss the difference between PrD and Rapid Prototyping elsewhere, so we won’t repeat why the PrD artifact isn’t a prototype. In Lean UX, the key focus of work is in building the smallest possible outcome based on the hypotheses. That is, after fashioning a suitably sized hypothesis, the team then builds a suitably sized prototype to test it. These become part of the MVP. As the authors state: “With the parts of your hypothesis now defined, you’re ready to determine which product ideas are valid and which ones you should discard.”

The operative words in that directive are: “product ideas.” MVP is all about the product…the solution. For Lean UX, the development of a product is the discovery process – there is no difference. This is an amazing breakthrough, when compared to the usual plodding process of discovery. The authors are also very clear that there are two different types of MVPs: MVPs designed for learning, and MVPs designed primarily for deployment (which should be usable for learning as well).

In PrD, in contrast, the team focuses on that problem statement, or more broadly, the problem space itself. Rather than crafting problem statements, or crafting a minimally viable product, the team crafts an artifact sufficient to achieve the team’s learning objectives. Technically, the PrD artifact could be considered an MVP designed for learning, but it differs so substantially from the Lean UX definition of an MVP the artifact is something very different. Specifically, the artifact must be designed to illuminate how the team’s perception of users’ and customers’ problems may be very different from those stakeholders’ actual problems. This is a hugely important differentiator: Rarely do businesses interview end users when they do their market research. Rarely is the users’ perspective accounted for in business or product strategies. PrD asks the team to be skeptical of any problems it has identified. This is where the PrD artifact is used to inform the business and product strategists; since the artifact doesn’t have to work, or actually even represent something that even could work, it is not viewed through a minimalist’s lense.

Problems vs Solutions

Lean UX promotes the notion that only by creating working solutions can problems be tested. PrD promotes the notion that problems can’t be identified until users have a chance to work with an artifact. It sounds as if both methods are saying the same thing, but this is the crux of the difference. PrD doesn’t delay engaging with end-users until there is a working prototype. Instead, it requires the team to move quickly, perhaps within hours of crafting the artifact to test it. PrD artifacts illuminate a wide landscape of possible problems, many of which will likely not have been on the team’s radar at all.

The two methods, although formally very similar, focus their attention on completely different parts of the development process. They are both designed to maximize learning, and to permit the business to pivot quickly, but they are fundamentally solving very different problems in the product lifecycle. As a result, they are complementary.

The Double Diamond diagram indicating where PrD and Lean UX ope

How PrD and Lean UX Complement Each Other

PrD and Lean UX use similar terms, have similar intentions and are focused on an agile way of working. But they focus on two completely different parts of the product development cycle: PrD focus on getting the problem space well defined; Lean UX focuses on rapidly designing and developing a solution.

Complementary notions about assumptions

Lean UX requires the team to make its assumptions explicit. It proceeds by embodying those assumptions in working code to test them. This approach is perfect for assumptions that can be characterized by small features, or incremental innovation. For example, slapping up a web page to determine if a call-to-action will work is a fantastic way to test, in the real world, the team’s assumptions about that call-to-action.

But inventing the future often involves huge, disruptive innovations. In these cases, the team may not be able to devise incremental tests that adequately capture their concerns or risk. In PrD, the artifact is designed to do just that: offer an end-user a magical artifact from the future that she is asked to believe actually works. How it works (or even if it can be engineered to work) doesn’t matter in this case, because the team doesn’t even know if its assumptions about the users’ problems are close to correct (or worth pursuing). PrD poses the question: why should the business invest in any engineering if the entire assumptions are wrong to begin with?

A decision making framework articulated by David SnowdenComplementary focus on problem statements

Lean UX assumes the business’s problems represent their end-users’ or customers’ problems. Although both methods expect the internal team to generate the problem statements, Lean UX uses them as jumping off points to develop working code. Through the real-world fielding of that code, the business learns how accurate its understanding of the problem really was. As above, for small, incremental efforts, this is an efficient and relatively low-risk way to proceed.

But again, for large problems that fall within the “unknown unknowns” quadrant, no amount of incremental testing will identify what the team doesn’t know. In PrD, such large-scale problem statements are viewed with skepticism: the artifact is constructed to explicitly test whether the problems, as perceived by the business, are viewed the same way by the customers and users it serves. Here again is where PrD complements Lean UX: a magical artifact is designed specifically to calibrate the business’s problem definition with their customers’ problems.

Complementary acts of creation

A key pillar of Lean UX is that working code leads to better design than design “deliverables,” specifically through a “collaborative design” process. Because the process doesn’t distinguish between “designing” and “developing,” the collaboration with the development team is constant and on-going. Further, the method strongly promotes getting out of the building and working with customers as frequently as possible to validate the team’s ideas.

PrD wholeheartedly shares this point of view. It takes it up a notch. Yes, designers must collaborate with developers to both identify assumptions and craft the solution, but, PrD demands the team collaborate with end-users before crafting any solution. Together, collaboratively, the team must determine with end-users the “fitness” of the team’s assumptions and problem statements. PrD’s motto is: We can sketch a stupid idea faster than you can code one. Both processes drive new learning: in the case of PrD, the business may identify a completely different product (because the problem itself was not aligned with users’ needs). In the case of Lean UX it may mean a completely different prioritization of features (because early customer feedback opened up new opportunities within the product definition).

Complementary embracing of Pivoting

Perhaps one of the most important ways the methods complement one another is with respect to “pivoting.” Both processes underscore the need to keep prototype fidelity low in the early stages so that the team can pivot, meaning change direction should the initial experiments not pan out. Early on in the product definition stage, the business is not clear on the value of the opportunities they face. PrD is a risk reduction strategy to rapidly evaluate (test) the business’s perceptions of their opportunities (problems). In this part of the double-diamond, the business may swing first one direction and then another. For example, there may be no product at all one day, a service offering the next, and a whole range of other possibilities in between two days later. When businesses have not yet decided on the product strategy, have not yet passed the “decision point” of pursuing a particular path, they have far greater opportunities to pivot. Once past the decision point, PrD transitions cleanly into Lean UX, having raised the team’s confidence the overarching problem space they’re solving for is a winning proposition.

Is your team ramping up on Agile or Lean UX? Contact us to learn learn how PrD can complement your current approach and reduce the risk of pursuing the wrong problem, or buy the book!