Imagine the view you’d see if you were hiking along a mountain track on a misty morning.
Your goal is to get to the highest point on the track. And as you move forward on the track it’s obvious that you’re gaining height, but you can’t clearly see where you’re going.
After a couple hours you reach a point where it feels like you’ve stopped making progress, and a while after you realize that you’re loosing height so you backtrack to the place that you feels like is the turning point of where you stopped climbing. You’ve done it! you’ve reached the highest point.
But because of the mist you can’t see the view, and you can’t really be sure where you are, and if you’ve really reached the highest point.
There is a field of computer science called evolutionary computing where incremental changes are made to the program’s ‘DNA’ and the program is set loose on a set of sample data. The best performing programs from each generation are combined to see how their children perform.
This method of programing mimics the approach of biological evolution except that it works on a time period of hours instead of billions of years, and works surprisingly well on some sets of problems.
The problem of this approach is that if either you don’t start with a diverse enough population of programs, or if you don’t have the right measure to determine which programs can continue to the next generation, and you miss opportunities to create the best performing program.
This is called a local maxima, because through an iterative generations you’ve incrementally improved the behavior of the programs but because improvements have occurred through inheritance, with each new generation taking on similarities of it’s parent, that a program that potentially would perform even better hasn’t had the chance to exist.
For me the design feels like trial and error (it sounds more professional if you call it experiment and iterate) and can experience the exact same problems as a genetic algorithm.
The most common problem with design is that we don’t start off with a diverse enough population of ideas. We succeed in making incremental improvements from those initial concepts, but skip entire potential directions.
Another issue is deciding how we evaluate early concepts as having future potential, and how to choose which concepts to continue to explore and refine.
At this step it can be easy to rely on our intuition as a key part of the creative process, but doing so we risk sticking with sameness56 and fail to make inductive leaps to potentially better solutions.
Designers who produce great work can often explain the process they took to get to their solution from a reflective narrative of what they did, but a pivotal decision in these narratives can often be reduced to a eureka moment that can’t be traced further than some subconscious insight.
Design is a profession where many of us do amazing work, don’t fully understand how we do great work, and so struggle to pass on knowledge to the next generation.
We pass on knowledge around the tools that we use, how we structure work, and give critique around trends but generally7 don’t attempt to talk about how to be creative.
Thinking tools are a collection of techniques I use to help my creativity. They’re not intended to be a replacement for intuition, but instead act as a jump start to try and get to that eureka moment sooner.
A common technique that designers use to understand an existing product is an expert review, where they evaluate the website or app on a pre-existing set of heuristics or criteria.
However, the act of evaluating something requires you to form an opinion which will only further alter future observations. This subjectivity that enters this process is one reason why expert reviews should be performed by several different people.
An antithesis to the expert review is a technique that I call intentional observing, and is as straightforward as looking at your product and writing down a list of anything that you see.
Looking at a website homepage you might start by writing that content is structured in a three column layout, that the website is designed for a fixed width, that the color palate uses soft pastel colors, that the font used is a humanist font.
The trick I find isn’t to worry if what you’ve noticed is consequential or not. Just write it down and move onto your next observation. What I find happens when I do this activity is that each observation leads to another observation, which leads to another observation which eventually lead me to quickly seeing things that I would have otherwise overlooked.
There’s a clickable area in your app, what best describes what you call it: button? link? affordance? call to action? The words we use to describe something may seem trivial, but they’re subconsciously unpacked to a bunch of implied assumptions8.
We’re often not aware9 of it, but language is powerful too in its ability to shape our thinking so we should use that to our advantage!
A recent example that comes to mind is Peter Jones’s book Design for Care10 where he uses language to reframe the role of a patient.
In healthcare practice and design, the vocabulary and perception of the human subject is dominated by three primary frames: user, patient, and consumer. All three designations are passive, objectified representations that constrain a person’s significance as a “health actor” to a transactional role. These roles designate people as users of products (user), clients of institutions (patient), or recipients of services (consumer). If we examine critically the ways in which designers participate in projects, advise on the design of IT and systems, and select research methods, the attendant design values of these roles show up in dialogue and decision making.
By repositioning the individual health seeker as a deciding and knowing agent of his or her own experience, health services can be designed to facilitate a whole-person approach to health.
Not to get all Oprah on ya, but the names we give ourselves are influential in the roles we do. If today you call yourself a user experience designer what would happen if you started identifying as an interface problem solver, or a product designer?
A more specific example is a feature Google added to it’s Chrome browser and has since become standard. Before 2008 browsers typically had two textfields at the top of their frames: one to enter a URL, another to perform a search. Both were just fancy textfields, but had very specific expectations.
Google changed this by combining both of these roles and using some assumptions on what was entered to decide if the text was a search request or a URL, and christened this multi-purpose textfield a omnibox. Later Safari followed with a similar approach, but also including it’s omnibox as an affordance to bookmarked, and frequently visited sites.
Looking back, it feels odd that we ever had browsers with two dedicated specialized text fields, but it took many versions of Chrome before this occurred and in part I think the labels we were calling these textfields were probably restricting the our thinking of what could be possible.
So, this thinking tool is simply a powerful question to ask yourself: “how might language be limiting our thinking?”.
Until my final year I was officially enrolled as a Chemistry major, and I was not a good practical chemist. In pretty much every lab something would go wrong and I would need to repeat the experiment a second (or a third) time around.
One lab when I was cleaning up long after my lab-mates had left I was grumbling to my lecturer that I seemed to spend double the time in labs than anyone else.
She changed my perspective completely by telling me that I should see this as an unfair advantage. I was still finishing labs and getting good grades, but above that by repeating experiments and spending more time in labs I could be learning a lot more from my failures than others from their success.
I didn’t think about it much at the time, but after graduating it’s become a moment that I most associate with my time as a student, and shapes a lot of how I approach design.
In one sense I think it’s encouraged me to intentionally seek out opportunities to be wrong. Not because I like being wrong, but because I like learning from being wrong.
One principle that I use to practice this is looking for ways to be specifically wrong over being generally right.
I often catch myself writing or saying something in a project that is true, but also so ill-defined or broad that it’s hard to dispute11.
So this thinking tool is a check on the level of abstraction you’ve taken your thinking and to make sure you’ve found the right balance between abstract and concrete.
If you read the start of this post you’ll now have a new understanding of a local maxima— an specific idea that surprisingly can be applied to fields as broad as biology, computer science, and design (dwell on it and you’ll undoubtably start to see it pop up in other areas too).
Language is a powerful tool in that it allows us to take complex ideas and pack them into a handful of words.
A domain specific language (DSL) is another term from computer science which describes a computer language that’s specialized to a specific industry or purpose, where a general language wouldn’t be efficient.
One DSL that you’re already familiar with is HTML, which is a specialized version of SGML12 which preceded the web by 7 years.
Borrowing this term and applying to to design, I use this to describe the specific language we use in the design community, and also a shared language that a team creates or uses around a specific product.
Mega menu, breakpoint, accordion, modal, flat, hovercard, hamburger, empty state. These are a few simple phrases that come to mind that that in our industry have a specific meaning, which can quickly and clearly be communicated, but can also be unpacked to more complex ideas.
This thinking tool is to examine your design and look for opportunities where you can use language to take a complex idea and find a way to clearly name it with a short phrase.
The outcome isn’t just a fancy name for an aspect of your concept, but the process of finding a name that fits can help clarify your own perspective, and like Chrome’s omnibox can help frame the way you think about that collection of ideas.
If you’ve been involved in giving or receiving feedback on a design concept, chances are that you’ve heard some variation of the phrase “I like this, what happens if you take this further?”.
This is our intuition sensing the seed of something interesting, but needs further development before it grows into a great solution.
One activity that adds some structure to stimulate these types of reflections is what I call the intuition pump13.
This activity takes a product or concept and attempts to describe it by categorize it on a set of scales of opposing attributes.
For example, to describe a website you might categorize one aspect of it’s structure as somewhere between ‘deep’ and ‘shallow’, the organization could be described as a ‘hierarchy’ or a ‘graph’, and the number of pages as ‘single page’ to ‘hundreds of pages’.
There’s no pre-defined set of qualities, but like the activity of intentional observing start by writing down something, and more qualities will follow.
On this set of scales you will be able to describe the current concept. The thought experiment that follows is to imagine what would happen if you move some of these qualities to extremes.
I like to imagine each of these qualities a lever or dial on a control board and push them up to the extremes and see what happens.
For example what would happen to the concept if you pushed the structure from a hierarchy to a graph? or if you turned the dial down so that the entire concept existed as a single page?
Many of these outcomes will be nonsensical, but some of them might help you jump out of your current frame of thinking to see an alternative direction which might lead to a great idea.
A lot of these tools have been based around manipulating language. But one major flaw of language is that (at least for me) it always feels like an intermediate step into how we actually think and requires some sort of internal manipulation before you actually understand it.
On the other hand, visual representations of ideas, like charts or diagrams, can represent their ideas so well that it’s almost impossible to view them without understanding their core message.
I believe that every product, regardless of how simple or intuitive it may seem, can value by creating a diagram that represents it’s essence.
And like creating a domain specific language, the value of this activity isn’t just the resulting diagram, but the process of finding the right way to visualize your concept, and the understanding that comes from that.
I bet that you can recall several times where you’ve been faced with a complicated decision or problem, and in the process of asking for advice you’ve written an email to a friend or mentor asking them for their advice.
To give them the context of your question you first need to clearly explain the problem so you break it down into smaller points.
Before you finish writing the email, you realize that you’ve answered your own question in the process of explaining the problem.
This thinking tool is simply to take a concept that you’re struggling with, and attempting to explain it to someone who doesn’t have any context of what you’re doing.
This is another opportunity of being specifically wrong, and is a great opportunity for improving your own understanding of something16.
There’s no specific output for any of these tools, but the outcome will hopefully help see your problem from a new perspective.
These tools might seem obvious, but like a lot of obvious ideas they are things that people don’t often talk about.
A lot of these tools might also fall under your category of common sense, and you’re using them without even realizing what you’re doing. If so, that’s great, but I encourage you to be aware of your process if only so that you can share this with others in your team and pass on your experience to a new generation.
Availability heuristic: A common assumption we take that examples that come easily to mind are also the most important. ↩
Curse of knowledge: A bias that makes it difficult for experts on a topic to think about problems perspective of a novice. ↩
Survivorship bias: The tendency to focus on winners and to try and learn from them. ↩
Bandwagon effect: A preference to do what others also do. ↩
Status quo bias: The preference for things that are the same, or to stay the same. ↩
Mere exposure effect: A bias where we prefer things that we are familiar with. ↩
Crazy 8s are the exception. For example Google Ventures publish great resources around running group sketching sessions, which, is one of my favorite group design activities. ↩
In this example, a button suggests an action, a link probably means navigating to somewhere or something, affordance talks about the quality of the clickable area being interactive, and call to action suggests an element of persuasion. ↩
If you want to be more aware of how language is used and often misused search for freshman lectures or textbooks on reason and argument or critical thinking. This one course I took on a whim probably ended up being the most influential in my after-school life. ↩
I can’t find a term that best describes rhetoric-anti-pattern other than ‘over simplification’. Would love to hear if there is more written about this. ↩
The philosopher Daniel Dennett describes a collection of thought experiments as intuition pumps Amazon YouTube. I’m inaccurately reusing this phrase to mean one specific activity. If that’s too ambiguous I’m also think of this as the lever & dials activity. ↩
If for any reason you don’t write a blog because you feel that you don’t know enough about some topic to write about it authoritively, then I sincerely ask you to rethink that perspective. My advice is to write a blog not for anyone who might read it, but for the purpose of your own learning. In this perspective it doesn’t even matter if not a single person reads your latest post. ↩