Eclosion

Have you ever heard of the word “Eclosion”? I hadn’t, but I think it’s a great design word. Let me explain.

As a happy accident, I happened to hear a podcast about a common cognitive bias, “anchoring”,* right around the same time that very thing was rearing its ugly head in a design project (funny how that works). In short, anchoring is our tendency to base our estimates or subsequent thinking unnaturally close to an initial signal, input, or idea presented. In this case I was having trouble resolving an aspect of the design and finally realized the problem: I was trying to make a final version of the previous iteration, as opposed to making the final version the right iteration. My brain assumed that most of the details of the last iterations must be close to final simply based on quantity, source content, and time spent. Each refinement decision was unwittingly tied to a bias to stay anchored to the current details. I was less willing to accept that the right conclusion might require more drastic deviations (or less dramatically, simply some more free thinking).

* This was Jeremy Miller’s Beyond UX Design “Cognition Catalog” podcast on the Anchoring bias, which is often discussed concept most notably attributed to Daniel Kahneman and Amos Taversky’s work. There are many sources to learn more about this, Jeremy’s podcast or even Wikipedia references are a fine place to start. If you happen to have Kahneman’s book “Thinking, fast and slow” there is also a chapter on it, chapter 11 – “Anchors”.

On top of this, I was also battling the sunk cost fallacy.* Managing time and effort, trying to stay on schedule, all create a tendency to stay with the solution you have and stay on the track your on rather than rethink it – the assumption being that it would be too risky, too time consuming and too costly to redesign a new solution at this point. But, as I have tried to unpack in many different ways in the Design UnProcess, the design process is not inherently linear. The problem is that these biases closed me off to a more natural design progression, which at times can be to “blossom” into something rather than just “finalize” the last something. This doesn’t necessarily mean that it will be entirely new or divergent to what came before it, only that it is a realization of the effort that came before it; meaning, we are free to uncover the right idea regardless of its superficial similarities to what came before, which is never truly a measure of rightness or wrongness, only let’s say, the most typical byproduct.

* The sunk cost fallacy is another common cognitive bias describing our tendency to continue on a path we’ve already invested some time and effort into even when it’s becoming more apparent that it is no longer optimal. There is a fairly thorough article about it here from Dan Pilat and Dr. Sekoul Krastev at The Decision Lab .

An inspiring metaphor is a butterfly. If we succumbed to the anchoring and sunk cost biases we’d never know the butterfly, we would only ever produce caterpillars and cocoons… Even in that last stages, when something just doesn’t feel right yet, doesn’t seem to be settling the design problem, despite every sign that it was moving in the right direction, it is critically important to question the pull of anchoring and/or the sunk cost fallacy (and any other biases for that matter). In a sense we have to protect the ability for the design process to play out “naturally” if we want the beautiful solution to emerge in the end.

Borrowing from entomology, I learned a new word that perhaps we can call this difficult dynamic we sometimes face in design:

eclosion “the act of emerging from the pupal case or hatching from the egg”

Whether the final stage design evolves into form with the last few details or ecloses into a seemingly dramatic finish, the design process is functioning as it should. The butterfly is no more able to actualize without the egg, caterpillar, and pupa stages than any other design is able to actualize without the numerous iterations of design, research, engineering and all the other inputs that lay the basis for the final stage design decisions. In theory, the closer you get towards the end of development the less likely you will wholesale change directions on an entire design because presumably the team did a thorough job of managing biases along the way. But, the risk is always lingering for a feature to be taken for granted, or an assumption to perpetuate, or any number of details to slide under the radar, any of which could derail the outcomes the design is intended to facilitate in the end.

During all stages, but particularly as the final design approaches (because that’s when it will be most difficult), keeping our biases and perhaps this metaphor in mind will help remind us to question the details, the content, the decisions. It could be that there are hold overs from previous versions that were never fully vetted, features that served a purpose at one point in the process but no longer serve the needs as they evolved, or had assumptions that had face validity at one time and then never questioned again.* Or maybe, these details will hold up. Either way is fine.

*It’s important to note that anchoring can occur upon any iteration, not just the first input. Although first impressions and inputs are typically referred to relative to this bias, if you are coming into a design new, providing a review, working with others, or simply iterating on your own, my experience is that you can be at risk of unfairly anchoring to a design detail no matter when it occurs.

However, now that I have a word for it, rather than a source of discomfort and stress, I will welcome that nagging feeling that we don’t quite have it yet (that the caterpillar isn’t really going to cut it) as a sign that this design round might be less like the typical last finishing touches and more like the eclosion of a butterfly.