Presumptive Design Completes Agile

by Charles Lambdin.

In our previous post about Presumptive Design’s relationship to agile, we positioned Presumptive Design as a fast and efficient way to incorporate UX strategy work into an agile process. Let’s say some more about this. Agile, which focuses on executing, assumes you already know what you’re building. But do you really know what the right thing to build is?

Before debating the best and most efficient way to climb a hill, someone should see if there are other, better hills to climb. This is where real ROI comes into play: opportunity costs. It’s easy to obsess over efficiency (because it’s easy to measure), but if in the end your team is asking, “Why is adoption low? Why is usage infrequent? Why aren’t users satisfied with the offering?” you failed—to some nontrivial degree. What are you going to do to really reduce your overall risk?

At some point in any project a decision is made about what it is that’s going to be built and delivered. Who made this decision? What was it based on? Was it informed by any user research? Or was it just the “HiPPO” (the Highest Paid Person’s Opinion)? Peter Merholz, cofounder of Adaptive Path, uses the UK Design Council’s “Double Diamond” to illustrate this point:

When anyone brings up the left diamond, agilists worry about the revenge of waterfall and the return of “BDUF” (Big Design Up Front). The problem, however, is that agile doesn’t offer a solution here. It focuses only on the right diamond. Presumptive Design is like an antihistamine for the agilist’s reaction. The method offers a way to cover the left diamond in an agile manner, effectively and efficiently pulling UX strat work back into the agile framework. Most agile UX approaches don’t do this. Lean UX doesn’t do this: it eschews (quite blatantly) UX strategy. But UX strategy is needed. It’s necessary.