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
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
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
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.
