Definition of Design

January 29, 2018

It's Loaded

The word “design” is loaded. It can mean any number of things to a myriad of industries. Typically when we think about design, we think about visual or user experience design before thinking about software or architectural design. Of course, this point of view only exists inside software engineering circles. If you ask a mechanical engineer about design, she will start talking about 3D models and forces. The definition of design, however, is broader than just visual design, and it’s useful to recognize this broader definition in work.

A note on words: they matter. Words represent ideas, and ideas influence the way we interact with each other as we do work. The word “design” needs a broader definition than that put forth in The MOMA Design Store. Believing a fancy, multi-colored clock is great design while failing to recognize the brilliance of the Redux architecture is a massive missed opportunity for visual designers and software engineers alike. One side believes there is a magical, elusive element to design that is unattainable and thus, not worth looking into; the other side, though, fails to see the elegance in the architecture. When one side owns the definition of design, the other side fails to integrate and vice versa. This separation in thinking is detrimental, especially in an industry where collaboration is key.

We are software engineers and visual designers, and the reality is, we’re just designers. What we do day-in and day-out is solve problems under a set of constraints. Boxing ourselves into arbitrary titles is useful for organizations that like to treat people like bolts in a machine, but it’s a horrible mindset to have when trying to solve a problem. Proposing a user experience design change that will result in three months less engineering work could be detrimental for those that make money on engineering work, but it could be the right solution for the problem at hand. If we are going to spend our lives tied to a narrow definition of design and isolate ourselves in that definition, then we will lock ourselves in a corner and end up with hamster wheel solutions that keep us spinning in our own disciplines.

We need a clear definition of design to free us to solve problems in the best way possible, and frankly, to protect our lunches from being eaten by someone or something else that’s not afraid to step outside the box.


Design is not an object; it is a way of thinking that some might call a way of life. Design needs a definition, so here it is:

Design is the creation of a plan or convention for the construction of an object or system that solves a specific problem given a set of constraints.

Design is the creation of a plan or convention...

Design is a process - not the product of the process. A clock is not good design. A clock is a clock. The process that led to the creation of the clock is what should be considered “good” design. This distinction between process and object is important, because it helps us determine where to put our focus: the process, not the object.

Steve Jobs famously rejected the logic board inside the original Apple II computer, because the lines were not straight enough. The idea worth keeping from this anecdote is not that the logic board itself was insufficient, but the thought process that led to the design was insufficient. The object was not poorly designed; the process that led to the object was bad design.

...the construction of an object or system that solves a problem...

For the second part of the definition, it’s worth going back to the The Present Clock. If the problem the clock is trying to solve is to help people tell time, well, it fails. The clock has a single arm, but it doesn’t have any numbers so it takes a minute to figure out what time it is. We can take out our phones, unlock them, and get the time faster than it takes to get the time from the clock. The clock is a poorly designed object.

But wait, The Present Clock is not designed to tell us the time of day; it’s designed to tell us the day of the year. Oh man, I almost missed that. Tricky tricky. But that is the point: we should not be confused about the problem an object is trying to solve. A circular object with an arm hanging on the wall by and large means a clock telling the time of the day. Being artistic here is confusing. Not only does it fail to inform us about what we expect - the time of the day - but it also fails to inform us about what it's "designed" purpose is - the time of year. So by having unclear design, we don't get either result - time of day or time of year.

Good design is a process for creating objects to solve a specific problem well. Good design thinking led to the fork. We don’t look at forks and think, “These are for writing.” We look at forks and know what to do with them. Forks are obvious now. The Present Clock is not.

...objects are designed within a set of constraints.

Now of course, at this point, I might be called out for picking on the The Present Clock, because it actually solves a problem given a specific “set of constraints.” So if this clock was intentionally designed for people who fully understood that a circular object on the wall was a clock that told the time of day or one that told the time of year, it would be more obvious. Perhaps this group also knows that one hand means the time of year, and two hands means the time of day. The constraint here is that the target users must have had knowledge outside the object itself that helped to explain the purpose of the object. Similar logic can be applied to the fork as well. There is a long history of cultural norms that allow us to understand a fork - and its purpose - on first sight.

When we begin a new design, we should turn the definition on its head, focusing on the constraints first, then the problem, and finally the design process. We are often so tempted by the problem and process of solving it that we miss the constraints in which we are working.