Escaping Einstellung

Would Spoc be susceptible to the Eistellung effect?

You don't have to dig deep into design language to find the cliche, "Fail Early, Fail Often." While I find in practice that true failures aren't necessarily embraced the way this implies they should be, I wholeheartedly agree with testing, iteration and pivoting throughout the product cycle. Wow, out on a limb there, right? But in a recent article in Scientific American I was reminded of the Einstellung effect and I realized that it aligned very well with a recent talk at IBM Design

"The Einstellung effect is the brain's tendency to stick with the most familiar solution to a problem and stubbornly ignore the alternatives."(1) Unless the most familiar route to success is blocked, we often miss solutions that may be better. Abraham Luchin's water jug experiment is one of  "most famous examples of the Einstellung effect."(2) Luchin presented a water volume puzzle to volunteers who quickly realized a pattern to solving the puzzles. Luchin then presented a puzzle with an easier solution as well as the patterned solution that had been established and many of the volunteers persisted with the patterned, longer solution.(3)

If we apply this theory to design thinking, we can assume that our patterned attack on user problems could be missing simple, more elegant solutions. Merim Bilalic and Peter McLeod recently applied the Einstellung effect to the arena of chess at the grandmaster level. Except for the very tip-top players among the volunteers, the chess grandmasters missed a quicker way to beat their opponent until the familiar route was blocked. (4) So, perhaps the smartest of us designers is avoiding this issue. But for the rest of us, how do we block our familiar routes to scare out possible better alternatives?

At the IBM Design studio in Austin last Friday, Tim Brown, CEO of IDEO, stressed that we need to be careful not to go straight from research data to design too quickly and too strictly. While this pattern is familiar and relatively safe, it can be the kryptonite to our designer "superpowers." Research data has its place, yet once design is established directly on top of the data, some creativity is likely lost. The suggestion? Design constantly. Create solutions and use the data to disprove design hypotheses from the start.

If designers look at problems and begin to solve them throughout the research and discovery process, the familiar, cover-your-butt solution of deeply rooting design in established data can be blocked in the same manner that familiar chess routes were for Bilalic and McLeod. This isn't to say that design solutions should not be deeply rooted in data, but that the familiar patterns of data-use should be questioned and disrupted. In addition, we must recognize and address failures in the design when data disagrees with the solution rather than becoming too attached to a particular solution, no matter how badass we think it is.

The idea of blocking familiar routes to solutions can break down to the nano level in design but the overall lesson is more macro in nature. We must design solutions at all times along the product cycle with the full force of our superpowers. Use data to check designs with an open mind. Fail early and fail often, but don't discard your routes to failure. They may be the groundbreaking solution to a different design problem.

(1),(2),(4) "Why Good Thoughts / Block Better Ones", Merim Bilalic and Peter McLeod, Scientific American,Volume 310, Number 3; March 2014.
(3) Luchins, A. S., & Luchins, E. H. (1950). New experimental attempts at preventing mechanization in problem solving. Journal of General Psychology, 42, 279–297.