Fast, Loose, and Oh-So-Very Wrong: How I’ve Come to Love Agile UX Design

By Leo Frishberg

Published: April 1, 2013

“I began to formulate a theory of my design practice…. In essence, it mirrored Bill Buxton’s discussion of the fundamentals of design: sketching, critique, and reflection.”

Historically, crafting world-class user experiences has required an investment in research, modeling, and design up front—before the process of software design and implementation can occur. But, more recently, agile approaches to software development have raised concerns about doing “big design up front” and, as a consequence, investing too much time and effort before delivering concrete business value. These are very real concerns in organizations that are transitioning from waterfall to agile, but as this article suggests, we can easily reconcile them.

Back in the Day, When I Was a Young Designer

I started my design career way back in 1974 as a young architectural student. By 1979, as I entered graduate school, I began to formulate a theory of my design practice—something I fondly referred to as the Barf method of design. In essence, it mirrored Bill Buxton’s discussion of the fundamentals of design: sketching, critique, and reflection.

Every day, I would draw things, then throw them away—or sketch, critique, and reflect. In Architecture school, the cycle was far faster than I was used to; the problems far bigger than I could handle. During those years, becoming attached to my creations, not allowing a free flow of ideas to emerge, and defending my ideas rather than accepting criticism were hallmarks of my experience. And so it went.

But eventually, I came to understand the power of critique and reflection. I learned to hear other designers’ points of view and appreciate how their perspectives could both influence and improve my designs.

A New Design Space: Software

“If you can’t imagine the user experience well enough to describe it to the user, you can’t specify the project.”

Then, one day, I embarked on a new adventure: designing and developing software. My wife and I had an established design business with several employees—all working in CAD. We noticed that the software we used wasn’t taking advantage of the computer to change the way we worked. It merely made our manual processes faster—or worse, forced us to change our well-established work models to meet its needs.

We made the leap into developing software that would help us—and, we thought, other architects and designers—to work more naturally in a CAD environment. But we had no idea how to actually develop software.

When we discussed our project with software developers, they kept asking for specifications—a term we knew from our architecture practice, but one we couldn’t begin to fathom in this new domain. A trusted advisor made a profound suggestion: write the help text first. If you had to describe what your product did, as if the user needed help using it, what would you describe?

I still recall the moment I had that conversation: It was early in 1990. I was sitting in our newly furnished offices, staring at the white walls, talking on the phone with him, when it hit me: if you can’t imagine the user experience well enough to describe it to the user, you can’t specify the project.

From that day forward, I’ve started all of my projects with the end state. As it turned out, this principle aligned beautifully with my original Barf method of design: imagine the end state, sketch it, critique it, and reflect on it, then try something new.

Practicing Presumptive Design

“I crafted a more mature model of design that I call presumptive design. … The major difference between presumptive design and the usual design process is the relationship that designers have with users as part of the design cycle.”

Ultimately, I crafted a more mature model of design that I call presumptive design. In brief, presumptive design is a form of participatory design—which Ilpo Koskinen, John Zimmerman, Thomas Binder, Johan Redstrom, and Stephan Wensveen had earlier referred to as constructive design research in their book Design Research Through Practice: From the Lab, Field, and Showroom. This approach is rapid, iterative, and familiar to designers. It is merely a slight twist on the sketch, critique, reflect cycle. The major difference between presumptive design and the usual design process is the relationship that designers have with users as part of the design cycle.

Actually having a relationship with users during the design cycle is different from merely presenting a design to users or clients. As a form of participatory design, presumptive design expects users to participate in the design critique process, during the design phases. This subtle shift in posture and attitude makes all the difference. Designers are not simply the creative visionaries; we become facilitators and researchers whose task is discovering users’ needs, desires, and mental models. And we do it through our designs.

This shift raises many questions and concerns: How can users participate in the design process when they aren’t designers? Do UX designers become short-order cooks who are simply implementing user-imagined solutions? Why would our clients hire us only to have the users do the work? If users are part of the process, what sort of designs should we show to them?

Note—I’ve captured my notion of presumptive design in print and in a presentation.

Agile Purists Opposed Big Design Up Front

“Agile purists raise concerns about doing ‘big design up front,’ which seems to them to be a waterfall phase during which the UX team designs everything—from the concept to the software—before the development team gets started.”

About five years ago, my company asked me to lead the transformation of my product group into an agile team. If you think back to 2008, agile folks hardly mentioned user experience, and UX folks discussed agile only with great concern. Alan Cooper’s address to the Agile Conference in 2008 was a heroic attempt at diplomacy.

Imagine my surprise at discovering agile! I had found a rapid development method that is closely aligned with my sensibilities about design.

Agile purists raise concerns about doing “big design up front,” which seems to them to be a waterfall phase during which the UX team designs everything—from the concept to the software—before the development team gets started. Since agile is about delivering concrete business value as early as possible, their goal is to avoid anything that would delay fulfilling that promise.

At the UPA 2009 Conference, I was fortunate enough to participate in a panel on agile and user experience. One of my fellow panelists, Thomas Lissajoux, told the story of a Pharaoh and his architect.

In telling this story, Thomas challenged me, in front of the audience, to refute his position against big design up front. From the agile developer’s perspective, big design up front results in wasted work because customer needs frequently change—whether during the design phase or throughout the course of development. I was delighted to rise to this challenge because it was obvious to me that Thomas’s concerns were unfounded. As the story nicely illustrates, the architect’s problem was decomposing a design into components that could be built effectively, not envisioning a design up front.

In the case of the Pharaoh and his pyramid, we might not understand what the Pharaoh meant when he asked for a tomb—even if he used the word pyramid. Maybe the Pharaoh actually meant elephant when he said the words pyramid and tomb. Such misinterpretations are the bread-and-butter of UX professionals. Nothing agile has to say about building software can resolve such problems of interpretation. But presumptive design can—and it does.

Presumptive Design Is an Agile Method of Visioning

“We use presumptive design as the method of capturing user feedback on our vision. Through low-fidelity … prototypes, our team … brings sketches of the vision to users for their critique.”

Agile requires the Product Owner to have a vision—a definition of an end state that all members of the team can keep in mind as they write and decompose user stories, develop acceptance criteria, and enumerate tasks.

During Iteration 0, the agile team is responsible for figuring out infrastructure needs, making architectural proposals, identifying major spikes to reduce risks, and in our approach to agile, rapidly establishing a vision for the project.

We use presumptive design as the method of capturing user feedback on our vision. Through low-fidelity—often paper-and-glue—prototypes, our team comprising UX designers and researchers, along with product marketing planners, technical leads, and other key members of the development team, brings sketches of the vision to users for their critique.

During facilitated research sessions, users attempt to complete tasks using the prototypes. For usability professionals, these look similar to standard usability-testing sessions, but with a twist: The team is not seeking feedback on the prototypes. We’re seeking feedback on our assumptions that underlay the prototypes. As a result, the design of the prototype itself differs from one that we would typically craft for usability testing. We’re not presenting a proto-solution for evaluation. We’re building a prototype to drive a conversation with users about our assumptions. This is a nuanced difference that supports a subtle shift in posture.

Presumptive Design Is Agile UX

“We take quick turns, or iterations, to get to the right design as quickly as possible. Most important, our sensibility is one of critique and reflection, not presentation and defense.”

There are several beautiful things about presumptive design, many of which dovetail with the agile way of thinking:

  • Presumptive design starts with the belief that you’re wrong from the outset. This drives the right way of thinking: There is less investment of time and ego in any solution. We take quick turns, or iterations, to get to the right design as quickly as possible. Most important, our sensibility is one of critique and reflection, not presentation and defense.
  • This approach is iterative. Knowing that you will get things wrong—not just once, but perhaps several times—builds in the expectation of doing design again and again. As in the development process, you stop when you run out of time, money, or in this case, fail to learn anything new.
  • This approach scales. Whether you’re trying to get the vision right, understand a specific design solution, or even test something as specific as the labeling of fields, presumptive design works. Its usefulness isn’t limited to Iteration 0. You can apply presumptive design throughout the development cycle to elicit user feedback on your deliverables. During development iterations, presumptive design starts looking more like a typical usability study because the focus of the testing becomes the actual design rather than the assumptions behind the design.

The Moral of This Story

“Presumptive design is a rapid, iterative method of converging on a shared vision that looks and feels very much like agile software development.”

UX design is fundamentally agile. There really isn’t much that separates the two disciplines at a conceptual level. As a professional colleague once said to me, “Agile attempts to solve a problem that we’ve never had.” Namely, getting the vision right. And many in both the UX and development communities would agree. Agile development had never really addressed UX design. According to their conception, agile developers were addressing a problem of software implementation.

Our challenge, as UX professionals, has always been to find ways of getting to the vision as quickly and accurately as possible, so we can start working toward it, before it shifts out from under us. Presumptive design is a rapid, iterative method of converging on a shared vision that looks and feels very much like agile software development. Putting these two approaches together creates an amazing marriage between UX design and development teams.

2 Comments

Thanks for sharing this. Am I right in thinking that the activities you describe in presumptive design all happen before anyone writes any production code?

I ask because, while I agree with you that UX design is fundamentally agile, I can’t see anything in your article that addresses the issue of how to incorporate UX design into sprint backlogs—or at least sprints in which developers are also expected to implement UX designs. In my experience, that’s actually impossible, but you seem to be framing the issue in terms of the debate about BDUF. I’m therefore curious as to why you think presumptive design is related to agile, or at any rate Scrum, which is what most people mean when they say agile in terms of an implementation of an agile process.

Otherwise, this is a nice description of a design process that works for you. I shall add it to my collection of descriptions of design processes that work for the people who write about them. :-)

The actual term, agile, might imply that the development model itself would be open to iterative improvement—as something cleaner, clearer, or better is encountered. If we believe UX processes meant to identify business needs, prioritize key user goals, and validate appropriate interaction patterns have a place in solution design, where do these fit in? Should they happen while coding is aggressively underway, simply because a Scrum Master’s rule book has mapped this out? Is immediate and iterative coding the primary mandate of a successful agile cycle? Or can UX inquiries and tools blend into sprints that may or may not result in code? If so, how can UX activities be rescoped to integrate into rather than derail reasonable sprints with tangible results? Rapid prototyping incorporating presumptive design, as Leo has proposed, is one way to clarify and communicate iterative direction. It seems our challenge will continue to lie in resolving the friction between coding before we know enough and delaying too long whilst we consider every potential user-oriented concept.

Join the Discussion

Asterisks (*) indicate required information.