It’s been said that “Plans are useless but planning is indepensible.” There’s a similar truth with the idea of UX process. Process is an indispensable aspect of what makes UX “UX”, but the moment any process encounters the real world, it begins to break down.
Why? The real world is complex, fast-moving, and unpredictable. In such a world, every project is a continuous work-in-progress.
Thus the tension. A standard process, checklist, or approach is a good presumption, a useful default, as well as a toolbox to draw on with wisdom and prudence. But it can’t be made into a ridid, hard-and-fast rule without serious consequences.1
Broadly speaking, when I’m approaching a new product or flow in a relatively stable environment, my process looks something like the following:2
- Understand the problem (from user, business, and technical POVs)
- Determine the nature of the complexity
- Use the appropriate tools—content maps, flows, lists, job stories, etc—to manage the complexity, guide the conversation, and render risky assumptions visible
- Wireframe (if appropriate)
- Set design direction
- Present early, present often
- Explore/ship/iterate, measuring along the way
The Real world
But let’s be frank: a process like above is nice, and it works for some things. But it’s rarely followed exactly. “Relatively stable environments” are rare and usually manufactured—a fruitless self-deception.
I believe that our modern design environment is complex, fast-moving, and unpredictable. (Not a novel insight, but an important one to always remember!) That fact, together with the reality of how we can get design feedback asynchronously in teams anytime from nearly anyone anywhere, means that any strict process breaks down. It’s either impossible (or if possible not desirable) because it works against the grain of our how things really are.
This is diagnosed eloquently by Yuhki Yamashita, Chief Product Officer at Figma, in his excellent article Welcome to the WIP—IMO, one of the most important articles published on design in the last few years:
Products today never get built in such a clear, linear, and picture-perfect way. The reality is so much messier. So why do we act like it isn’t?
Well, for a long time, this was the process. Back when product design meant physical products, it was materially important that everyone follow a carefully constructed, linear process. As the world became increasingly digital, the spaces we designed for became faster to build and iterate on. Product teams can ship an update in a matter of minutes versus leaving their users stuck with a design for years to come. Today, every digital product is a work in progress. And this has changed how we design.
Yamashita historicizes design, pointing out that this linear mindset worked at one time; but it works no longer. Other authors have made this same point. In their book Sense and Respond, Gotthelf and Seiden call this the “manufacturing mindset.” In his book The Art of Action, Stephen Bungay describes this same phenomenon as “legacy thinking,” consisting of three basic assumptions:
- It’s possible to know all you need to know to be able to plan what to do
- Planners and doers should be separated
- There’s only one right way to do things (or, “There’s the Process!")
Bungay makes the same point Yamashita does: we live in a complex, fast-moving, unpredictable environment, and none of these assumptions hold true any longer.
Dealing with Uncertainty
So in an ideal world, there’s less a linear process and more of a system of recurring practices that help usher products into the future. Gotthelf and Seiden call this “continous deployment”—we’re always learning, always treating our project as a WIP.
Outlining some recurring practices that might facilitate such continous work, Yamashita suggests these recurring practices:
- Reviewing work at a predictable cadence versus the perfect moment
- Considering the form feedback takes as much as the feedback itself
- Be less precious about the work that ships
Now, I still think it’s useful to have a rough process to follow. The process itself is a jig, a tool for managing the daunting complexity of building modern products.
But we can’t treat any process as a hard-and-fast rule. Rather, we ought to treat the process as a toolbox—each part designed to perform certain things. And if we approach design less as a checklist or hard-and-fast rule, but rather as a system of recurring practices where we can look at our assumptions, draw from the “process toolbox”, sensing and responding along the way—only then can we respond adequately to the modern reality.
Cass Sunstein wrote a phenomenal 1998 article on second-order decision-making, where he outlines a distinction between a rule and presumption. A rule is hard-and-fast, rigid. A presumption is a default: we presume it, unless some condition holds. A process can be like that. ↩︎
This process is heavily informed by Matt Damon Smith’s own approach, which he details in his excellent Shift Nudge design course. ↩︎