Designing Lunch Boxes

Labels & Assumptions

Jonathan Ive recently made an appearance on the children’s show Blue Peter, where he was the guest judge for a lunch box design competition (what a guy). 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 already quite narrow.”

Labels have to exist. They 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, we’ll 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 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.

Personally, 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 compiling, cross-referencing, and germinating quietly in the background 3 weeks ago, ever since the product manager mentioned something in passing. Now, that seed is no seed anymore; without me noticing, it’s already become an unruly tree obstructing my overpriced view.

The most beastly type of labeling I’ve encountered is when re-designing something - not only does the label exist, but 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, touch it, and people talk about it and form opinions on it. That’s a lot of legacy to cut through.

“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 Roni points out, it’s not our fault, it’s (hopefully) not because we’re bad designers; it’s just how our brains are wired to work. The association that occurs is an unconscious process that plots its commute along existing well worn neural pathways, that are formed, and reinforced everyday as we work, and discuss design. When we use them, we’re automatically pulling references from our brain and drawing patterns between them.

Of course 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 a user in a lot of situations. So what’s my problem? Well, hindering radical innovation isn’t really all I’m concerned with - it’s when you simply don’t allow yourself 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.

The main thing I try to do to combat the negative aspects of these labels is to question and group everything right at the beginning of the project - I’ve found it’s 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 and then logically group them - essentially ravenously questioning everything, then organizing what survived. 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 those 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 I find 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. And if done right, people using your designs digest these frameworks as well, whether they recognize it consciously or not, it 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 that are the internal politics, awkward collaborators or various stakeholders of any given project, without us putting our own obstacles in the way and stunting the design before it even gets a chance to leave our brain. So, I’m trying to think a bit more like Ive, and catch myself before I venture down those narrow, predetermined paths of thought which don’t do us many favors.