A recent retweet by Jasmine reminded me of a favourite quote I had on my desk for ten years:
“Art hides, design reveals”. It’s a quote about contrast. While contrasting a thing with something else can be a good way to define it, it got me thinking about my personal definition of design with no such comparison:
Design is shaping something by separating what it is from what it isn’t.
It’s pretty abstract! That’s okay. When you spend a long time on design, you naturally end up zooming out. I think that’s more valuable than starting high level without having done practical work.
As a verb
Design as a verb is something you do. Drawing on the above quote, it’s the shaping process. It’s about injecting something with purpose, assigning it utility. You can become good at it through repetition, by learning which patterns to keep and which to drop.
Here’s an example: focusing on solutions instead of problems. Starting from a problem definition, you narrow things down by asking “will this work?” repeatedly until you find something compelling.
Companies like IDEO and Google’s design sprints reflect the idea of design as a thing you do. I learned it on the job, working with dozens of clients and pattern matching some intuitive ways to draw out ideas and collaborate towards a goal. In this sense, design is a discipline that happens in support of something else, like defining a product spec, establishing a business strategy or simply making a blueprint.
Some people write those patterns down and refer to them as design thinking. I’m not really like that; my approach is ad hoc and really depends on what I’m doing and who I’m with. Instead, the most structure I’m willing to assign it is “do whatever, over and over, until something happens”. Great mantra, right?
As a noun
Design as a noun is the product of the above process. Once you remove what it isn’t, all that remains is what it is. As you distill a thing from the ether, you arrive at repeatable rules of what constitutes the design, usually expressed as constraints, which define what it can and, consequently, cannot be.
You can codify these. Today’s hip lingo refers to them as design systems, but they’re a lot of work and our tools don’t really support creating them yet. I used to just hold them in my head, but I admit that’s not a great format for sharing with other people. Not yet, anyway.
So a design (a blueprint, wireframes, prototypes, documentation) is really a communications tool. You can’t collaborate effectively if the design is just in your head. You need to get it out onto some material that can be shared with others. One of the biggest challenges in design is getting everyone on the same page, making sure your vision reflects that of stakeholders, and providing the correct guidance to dependents like developers. For that you need some communicable object that the conversation can happen around.
The smaller the team, the fewer stakeholders, the fewer such artifacts are necessary. That’s why I prefer teams of 2–3 people where everyone assumes multiple roles: you spend more time doing the thinking needed for design and less of the documenting needed to talk about it.
How being a programmer informs being a designer
I’m also a developer. I do a little of both, though if I had to pick one, it’d be design, because I think a good sense of design informs good programming. But the reverse also applies.
In programming there’s a distinction between procedural programming and functional programming. With procedural code, you write down how the computer should execute the steps. It means you, as a programmer, spend a lot of time concerned with the process. “Do this, then this, unless that.” It begets micromanagement, in a way. It also begets bugs, because you have to spend so much time on the details and humans aren’t great at tracking so many possible states and variables.
It’s like using Photoshop to design a UI: you have all this control over pixels, but your tool should be helping you do layout and make sure things line up vis á vis one another.
Functional programming is about writing down the what and then trusting the computer to figure out the in-between steps. It’s about constraints, outcomes and expectations. You spend more time thinking about context, instead of individual steps. It’s more like using a tool like Xcode’s interface designer, which is about rules and constraints.
You might see how this relates back to design: design as a verb vs. design as a noun reflect these two schools of thought in programming. When you combine them, you get truly interesting results, like Subform. Or react-sketchapp, a framework for managing Airbnb’s visual language, which has become so difficult to maintain that they’ve been forced to invent new technology to accommodate it. It expresses the design system as React components (written in Javascript) and generates editable Sketch files that designers can then riff off of before getting together with the programmers and writing out the spec in code again.
And guess what, programming is about doing whatever, over and over, until something happens, too! Programming has the concept of tests that you write and assert against, which help you verify during the repeated process whether you’re still building the right thing. Design doesn’t have tools for that, so you have to fill in that space yourself by continuously asking questions (“will this work?”, “is this still the right way to go?”).
Functional programming is becoming increasingly popular. So are design systems. As both industries mature, our own understanding of them evolves and new methods reveal themselves. It’s almost like we’re slowly designing design itself. 🤔
Anyway, design is weird. So what’s your definition?
