The brief was to design a lunchbox that could also serve as a bag and a pencil case. While he was looking over the entries, the presenter asked Ive how he would tackle the design challenge:
”If we’re thinking of a lunchbox, we’ll be really careful not to have the word ‘box’ already give you a bunch of ideas which are … quite narrow.”
Labels Have to Exist
Labels have to exist because we have to talk about projects with people when we’re working on them, and if an element doesn’t have a name, we need to give it one so people know what the hell we’re talking about. That we can’t avoid.
Initially, designers use ambiguous, temporary labels, like, “the activity thingy where we can see the stuff” in conversation. Even then, we know what will happen if we label it and we’re trying to avoid it. No one wants to pigeonhole that feature or project. No one wants to kill off all of the potentially amazing other ways in which that feature could manifest.
But after it’s been mentioned a few times and needs to be typed somewhere, the terminology quickly evolves into something that’s more efficient to handle: something a lot less ambiguous. Eventually, we choose a label: the “notifications” feature. That’s it. That moment right there. That moment, when we create a specific label or name has the power to both crystallize and limit the potential of the project. Our jobs just got harder, and I think that’s just what Ive was referring to.
Labels in Digital Product Design
I face this challenge in digital product design. I notice as we gear up for the next stage of a project that I start thinking, right, next is the “Profile Page.” Just this generic label alone starts the design process in my head. Immediately, my subconscious cross-references all the profile pages I’ve seen and compiles a generic layout for me. Off we go, that’s what profile pages look like.
This all started long before I’d even had a chance to contemplate the project at any length during my morning shower. Oh yes, this seed started germinating quietly in the background three weeks ago, when the product manager mentioned something in passing. After my internal compiling and cross-referencing, that seed is now an unruly tree obstructing a sea view.
The most beastly type of labeling I’ve encountered comes during a re-design. Not only does the label exist: so does a previous attempt (often someone else’s) at bringing that label to life. It’s right there in front of you, you can see it, use it, and touch it. People talk about it and form opinions on it. That’s a lot of legacy to cut through.
We’re Wired for Labeling
“It’s almost impossible for the human brain to produce a really fresh and unique thought. Every thought, opinion, or idea is somehow connected to previous concepts stored in the brain.”—Roni Horiwitz, Ph.D. in creative problem solving and design
As Horiwitz points out, it’s not our fault, it’s (hopefully) not because we’re bad designers, but because of how our brains are wired to work. The association that occurs is an unconscious process that plots its commute along well-worn neural pathways that are formed and reinforced everyday as we work, and discuss design. When we use labels, we’re automatically pulling references from our brain and drawing patterns between them.
Finding the Familiar
It’s not all bad news: these same subconscious associations can be very powerful when invoked by a person interacting with our designs. Using familiar design patterns that already have a degree of precedence allows a user to quickly familiarize themselves with an interaction or concept, having already learned the basics elsewhere.
So doing the expected, the familiar, can have its benefits, and of course reinventing the wheel isn’t always necessary. In fact, inventing for the sake of inventing can cause unnecessary cognitive load for users in a lot of situations.
So if the familiar can be helpful, even desirable, what’s the problem? It’s when we simply don’t allow ourselves that extra step in the design process to at least question the assumptions that come along with those labels. I find that’s when redundancy and inefficiency can creep into a design.
Break them into Groups
The main thing I try to do in combating the negative aspects of labels is to question and group everything at the beginning of the project. I’ve found this approach really useful when trying to shed labels or the stigma of an old design.
I break down each potential element of a page or feature, analyze them, and logically group them. This is essentially ravenously questioning everything and organizing whatever survives. It gives me a set of rules to refer back to and makes it very easy to spot what belongs where, and what doesn’t belong at all.
Sometimes the wildcards that don’t fit anywhere mean you end up rethinking the entire existence of what you’re working on. This process may sound crude, but labels are responsible for a lot of assumptions in design, and going through this early on in the project ensures none of those assumptions slip by without a serious interrogation.
When it’s done right, people using your designs digest these frameworks as well, whether they recognize it consciously or not. This makes the product easier to use as they subconsciously pick up on the conceptual grouping of elements. I also find that simply being aware of the assumptions and associations we make when using labels at the start of a project can go a long way in helping to make the right design decisions.
It can be hard enough to maneuver our creations through the meat grinders of internal politics, awkward collaborations, and stakeholders. Putting our own obstacles in the way can stunt the design before it even gets a chance to leave our brains, so I’m trying to think a bit more like Ive. This means catching myself before I venture down those narrow, predetermined paths of thought which don’t offer any of us many favors.
Image of bento box courtesy Shutterstock.