High quality design requires mental toughness.
If you want to find a great design solution for a problem, you need to be at peace with not having any solution at all. At least for a little while…
Problems are uncomfortable. They don’t sit right and they make us feel uneasy. Solutions take a problem and neutralise it. Conversely, hasty solutions can have nasty effects outside of the problem space they are applied within, meaning that they can actually create more problems elsewhere.
I used to work night-shift at a mail sorting facility. Every night a few truckloads of mail would come in and get dumped onto conveyor belts to go out to different sorting areas. The productivity of the entire shift depended on processing time. One night I said to the floor manager, “I could decrease our processing time by at least 200%.” She was keen to hear me out and asked how, so I gave her my solution, “Just put all the mail in a pile and burn it.” The extra problems this would cause in areas not monitored by processing time are clear.
So, problems are nebulous and scary, and solutions are concrete and soothing. Humans tend to prefer the latter set of things. This leads to a desire to find a solution as soon as possible, potentially at the expense of understanding.
Within design, I feel like this is a fairly common struggle. As a young designer, I regularly catch myself being lulled by my first solution and the comfort that it brings. How do I stay uncomfortable and move on from that first solution? Luckily, I get to work with plenty of more experienced designers and I’ve started to pick up a thing or two…
1. Expand your problem-space
Sometimes, I’ll be working on a pesky problem that just won’t resolve itself into a nice solution. I outline a couple of approaches and try to weigh up the pros and cons of each in order to arrive at a decision, but deep down I’m not entirely happy with any of them.
“Let’s take a step back”
I’ve heard this suggested in many design sparring sessions and it’s proving to be one of the more impactful things to consider. Even if the solution isn’t found in a wider context, it’s still good to take a step back and think about the broader system that a problem exists within — it’s troubling how easily this broader view can be forgotten. How long is the overall journey? Are you intervening at the right stage? Could this be solved upstream? Downstream? Can you anticipate anything based on what you know of the destination? Where has the user come from? Can we leverage ANY of this information?
Sometimes you find out that the problem is actually better solved elsewhere, or from a different direction.
2. Let someone else break it (whip up a quick test)
First solutions, like first children, sometimes receive special treatment. They are subconsciously protected and handled with care. Don’t be a ‘Helicopter Designer’, let your designs play in the mud and climb trees!
“I like it, but let’s go see how other people react to this”
A year or two ago I was designing an interface for a generative sound device. I was familiar with how it worked and could make use of the interface with ease. I didn’t bother with any early user testing — it worked, after all. A friend thought that the instrument looked like fun so I let her try it out. She approached it in ways I hadn’t accounted for, overloaded the inputs, and caused total system failure.
We talked about why she used it the way that she had. This uncovered the non-communicated aspects of the interface. After letting more people break it and collecting their expectations, I ended up designing most of the interface from scratch.
Using an interface or acting out a flow that you have designed can be a little bit like playing hide-and-seek with yourself. Your inability to fail at using the design might not hold much relationship to the quality of the design itself. Get your design into someone else’s hands early on to help keep your thinking divergent and honest.
3. Consult the morphological charts, tea leaves and other occult ephemera
What if you feel the need for an approach that is a little more novel? A little more esoteric? Try a morphological chart.
Morphological charts are a method first introduced to me whilst studying Industrial Design. It involves breaking down a product into functions and sub-functions and exploring variations of these, so that they can be recombined in a systematic and analytical manner to form new permutations.
The chart is typically intended for solving design engineering problems, but it is an effective discovery tool because from a small set of things you can instantly and systematically generate many avenues of discovery.
“I don’t think you can design anything just by absorbing information and then hoping to synthesize it into a solution. What you need to know about the problem only becomes apparent as you’re trying to solve it.”
It might sound complex, but in reality morphological charts are actually a lot like one of those mix-and-match books where you can create new characters through different combinations of head, body and feet.
Though heavy-handed, I find morphological charts can be helpful when trying to design in an environment in which a large number of factors for success are at play and you find yourself gravitating towards a singular idea over and over. Consider any software project and the wide range of factors involved. There are many decisions to be made around abstraction of data vs. raw information, interface complexity vs. simplicity, linear vs. nonlinear flows, discrete vs. continuous representation, omnipresent vs. contextual navigation. Morphological charts help facilitate thinking about the interplay of these factors by combining them in unconventional ways.
• Morphological Charts via Design Wiki
So, there you have it, three ways to keep yourself thinking about a problem long after attaining a first solution. Remember that as humans we are great at finding solutions, but that not all solutions are created equal. The immediate problem of a leak can be solved by a large bucket, or a roofing repair.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.