No Chute Required: Designing without Preconditions
If one really wishes to be a master of an art, technical knowledge of it is not enough. One has to transcend technique so that the art becomes an “artless art” growing out of the Unconscious.
Zen in the Art of Archery by Eugen Herrigel
Learn the rules like a pro, so you can break them like an artist.
Attributed to Pablo Picasso
There is a rule of thumb used by practitioners of improvisational theater called, “Yes, and…” It means that to advance the scene, one shouldn’t say no, but instead always agree, and add something new. So, if a performer states that it’s a good day for skydiving, instead of responding “no, we’re in a car,” which negates the premise, the scene partner could reply, “Yes, and it would be so much better if we had brought our parachutes.”
There are several important factors needed to make this work, instead of creating an endless digression. In the case of the improv troupe, they generally start with a suggestion from the audience (“name a location”), or some other mutually agreed upon context. The actors are mostly likely all well trained in the form, and can recognize moments that are ripe for exploration, as well as possessing the skills needed to bring their colleagues and audience along when the story changes direction. And finally, and perhaps most importantly, there is the spirit of collaboration, with each person adding elements to strengthen the overall concept, and having trust in their partners to do the same, even if their initial objective isn’t entirely clear.
As I try to reconcile some of these ideas with my understanding of user centered design, a few things stand out. We’ve all been in the situation where we’re asked to create something where the objective is already determined. It may be in the form of overly prescriptive requirements. It might involve an expectation of a particular end-state. Or it could just be the result of someone basing decisions on an untested assumption.
We also bring our own perspectives into the mix; relying on what we consider best practices, our domain knowledge, specific approaches or methodologies, even bad habits or biases.
The paradox here is that the more that is known about a problem or target end-state, the less likely we are to allow new or competing information into the process. We have already determined the filters that we will use to evaluate new ideas. This is a type of cognitive pitfall known as confirmation bias, which is the tendency to interpret information in a way that confirms one’s preexisting beliefs.
In my current role, I’m lucky enough to be on a project that has a dedicated “discovery” phase, where, while we do have a project scope, the use case or problem statement is still loosely defined. But this is a double-edged sword: it’s great to have the freedom to explore, but a blank canvas can be intimidating! When the possibilities are wide open, where does one begin?
Back to our improv example, some context at the beginning is important, especially with a team. We need to have an agreed upon understanding of the users, the environment, and the question we’re exploring. At least in general. So, “Setting: Airplane!” gives the group a common framework and a place to begin. For designers, it might mean a product coming to market, a redesign of an existing site or system, a user or business need that is not addressed by the current process, to cite some examples.
Along with a general sense of the area to explore you should also have a good idea of the customers that will use your eventual product. In UCD, understanding user needs and motivations is critical. Face-to-face, one-on-one interviews are the best way to gain user insights. You should make every effort to include them in your project schedule. When it comes to the interview itself, avoid trying to direct the conversation too much, as you could miss patterns and insights as they reveal themselves naturally. Our team uses a loosely structured discussion guide as opposed to a fixed script. This lets us engage in active listening, and allows the conversation to have its own life and direction. It encourages the participant to tell their story in the way that makes the most sense to them. We use open ended questions and follow up with prompts for describing things in detail (very much in line with the yes…and approach).
After you have interviewed a number of users (we like to have at least 5 for a given profile or persona), themes should start to emerge that you can then use to distill insights and formulate a strong use case or specific problem to solve. As much as possible, this should be a team process, with representatives from product, engineering, and design working together to frame the direction of the effort. This can and should include sketching or ideation sessions to brainstorm various approaches. Good ideas can come from any source, so try and remain open to different voices.
You might be wondering when your design work actually begins. From my perspective, an experienced designer can’t help but be formulating opinions as to the “right” approach from the very start. Indeed, the trick is to let go of preconceptions. As new information is added to the mix, it should inform fresh ideas, or even suggest a change in direction. If you are married to a specific plan, the more likely you are to discount or overlook observations that could send you down a new path.
In this model, the designer occupies the tranquil center of the whirlwind, divining order out of chaos. Or, if that is too new age hippy-dippy for you, we’re MacGyvers, building a parachute out of a paper clip, an inner tube, and several yards of twine. A good day for skydiving after all.
