Is your process working for you or against you? Are you sure you know the answer?
Design process gets a lot of typing action. The online article pile collects more opinions every day. To be successful, they say, you must have a repeatable process. You can’t win on dumb luck. Not more than a few times. And man do we love to jump in. We can’t get enough of those design process debates.
We’ve gone through all the possibilities, too. Over the past couple of decades, we’ve seen and tried every process we could. We’ve got LEAN. We’ve got Agile with a capital A (despite that almost no one is strict about it). Before that, we had User Centered Design (which then became “design thinking”). Before that, it may have just been called “winging it.”
Has the hype about process helped us? Does your process stick to the rules the world keeps trying to lay out for you? Does it even stick to your own rules? It’s easy to latch on to the first thing you try and turn it into a life lesson. But the truth is, the best design process is a flexible process.
I’ve been walking into corporate and startup conference rooms as a consultant for the last 10 years or so, and as an in-house design-slinger for a few years before that. If I’ve learned anything, it’s that absolutely no one has a process they can rely on all of the time.
Constraints change on every project — resources, time, budgets, skills, technology — you name it. If it affects a project, it’ll be different next time around than it was this time. You can meditate on your theoretical process all you want. That very real project you’re about to start is going to kick you in the head.
Process may be repeatable, but it doesn’t guarantee success. It can’t. There are too many variables on any given project, not the least of which are the skill sets and motivations of the people involved, which can make a dramatic difference from one day to the next. Success is a vague and elusive thing on the best of days. We can’t possibly expect to achieve it in its many forms by applying the same process template to every layer of complexity it throws over us. We’d spend half our time redefining “success” just to make it fit what we get.
“Winging it,” it turns out, has merit.
Running with Scissors: The Value of Improvising With Tools
Jared Spool has done some research on this. You know the guy — he’s the one who’s been running a design research company and think tank since the ‘90s . Few people have spent more time talking to designers and companies than Jared.
Know what process he’s learned is the one employed by the most consistently successful design teams? It’s the same one I find every time I walk into one of those conference rooms with a great team.
The improvised process. The one defined specifically for that project, and often not defined at all.
As it turns out, the teams that do measurably good work on a regular basis, with the fewest issues and the fewest failures, are the ones without a de facto process. They’re teams which devise a custom process for every project, and frequently go into a project without one at all. Conversely, the teams which most consistently accomplish the mediocre — that dirty, awful word — are the ones who live and die by their processes.
I know. It’s nuts. But is it? Think it through.
The teams who succeed the most are the teams full of people who work well together — who communicate well together — and who have a broad range of skills and tools they can apply at any given moment. They approach problem-solving in a way that works with the constraints of the situation. They have all the UX tools you can find — strategy definition, user research, UI design, prototyping, usability testing, data analysis, and on and on. To do their work, they pull out what they need, when they need it.
- At the beginning of a project, gather around and decide together what design activities will be appropriate for the situation, whether thorough user research combined with rapid usability testing with paper prototypes or some other combination of things that will give you the best insights.
- At every point of the project, hold design brainstorms and reviews so that everyone can continually keep each other in check with regard to the goals of the project and how well the team’s ideas support those goals.
- Ensure that everyone knows who has final design decision-making power, and that this person relies heavily on evidence and solid rhetoric rather than whim.
Not Just Tools, but Tools in Many Sizes
Not just that, but these teams are able to adapt the way they use their UX tools.
- On a tight deadline, they can run rapid usability tests using paper prototypes at the coffee shop across the street.
They can perform user research remotely, in short interviews, cross-referencing subjective responses with prior data to validate hunches and ideas.
- They can prototype collaboratively in a variety of tools (whether in UXPin, Keynote, PowerPoint, or something else) in an afternoon just to hash out a possible design direction and get quick feedback from the team and from users.
Strategy Dictates Process
Of course, there is a catch.
Successful teams also work from a strategy. They take on these projects with a strong, mutual understanding of the goals and differentiators, and they collectively aim at the same target.
In the best situations, they start with an actual strategy document. Even a quick and dirty version that outlines the basic vision, design criteria, and success metrics for a project does a far better job of keeping everyone on the same track than an allegedly shared understanding based on a hallway handshake.
When ideas need vetting, the strategy doc reminds you of the direction and shows you whether or not the idea fits in. When the project scope starts to bleed out into the fringes of reality, the strategy doc reels it back in. There is simply no better way for a team to tighten up its focus and stay within the confines of a project’s constraints and keep it feasible. By definition, that’s what success is to a design team.
Here’s a few tips to do this:
- After creating a strategy doc, communicate it to everyone involved. Assuming it was built on research and insight and agreement, the team can trust it from then on to be the guiding light for all design decisions.
- Refer back to the strategy doc early and often. When an idea forms, pit it against the success metrics laid out in the strategy as a quick way to determine whether or not the idea supports the project goals.
- As a sanity check, bounce ideas off each other for which design activities to perform and how so that no one ends up wasting time, and so that everyone is in a position to help the collective whole.
- Remember that a strategy doc enables individuals to make good decisions on their own. Avoid micro-managing the situation and let people do what they do best.
When is the best process not a process at all? Right now. Yesterday. Tomorrow. Always.