Designers vs. Engineers
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
This is something I’ve been meaning to write about for a long time, but I never quite got around to doing so until now. It’s a frustrating topic that involves a lot of tension between people who are a part of two seemingly different worlds — designers and engineers.
It was this statement on Hacker News that finally drove me to write this essay:
If you want to design table lamps and dribbly teapots, keep churning out this hogwash. If you want to change the world, start designing with your brain, not your felt tip pens. The world is full of vital, urgent, life-or-death design problems, but they need substance, not style.
While I don’t entirely disagree with the gist of this statement, it’s intentions (in and out of context) provide a real disservice to everyone, especially designers and engineers.
First, let me give you a little background: my life choices have put me in a particularly interesting position of having thoroughly experienced both worlds. By day, I am a design student and by night, a web developer. I build, design, code, conceptualize, implement, and envision. I have an understanding of the frustrations of poor kerning, bad typographic choices, and frustratingly unclear design decisions. I also understand poor coding standards, the necessity (and avoidance) of writing good tests, and the value of optimization.
With that said, there is a frustrating dichotomy between designers and engineers. Why a dichotomy? Simple — designers and engineers are cut from the same cloth: we’re all solving complex problems, using our background knowledge to derive a valuable and functional solution.
The Engineer’s Perspective
I’ve had discussions, at length, with engineers who seem to feel that design is “unnecessary” or a “waste of time.” A time-worn and tired example oft given by engineers is that of Google: “Well, Google didn’t use designers to build their website!”
Yes. That’s true. We get it, Google hit the nail on the head, relative to other web design at the time. However, it is an exception, not the rule. And guess what? In 1999, they hired Ruth Kedar to refine and redesign the logo. Additionally, the home page has seen countless revisions and changes over the past 13 years, with the help of (data-driven) designers.
To an engineer, design seems like an unnecessary and tangental part of the creation process. “It just needs to work,” we say, “it doesn’t need to be pretty!” That simple little statement ignores designers’ years of experience dealing with how humans perceive and interact with the things they use on a daily basis. Colors, shapes, forms, grids, typography — these are all aspects of design chosen with a careful eye and an understanding of how they will affect the overall perception of an object, thing, or experience. Not simply a haphazard attempt at creating something “pretty” or “nice looking.”
The Designer’s Perspective
Designers, on the other hand, see engineering in a completely different light. Given a task, we set out to create something with, often, little regard for the implementation aspect of a design. It is not with cruelty and inconsideration that we do this, however, but with the best of intentions: we apply our skills as we know them best, putting to use our understanding of how people perceive “things.”
However, we should truly work to have an understanding of the engineering difficulties we are creating through our designs. That is not to say we should not push the envelope, bend the rules, and break tradition — but to do so with the knowledge of the difficulty involved in implementation.
To ignore the history and the reasoning behind a particular aspect of engineering — writing it off as merely ugly or “bad design” — is to be a bad designer. While it that may be true a portion of the time, it would be irresponsible to overlook.
Happiness in Consideration
In the web development world, I often hear developers insisting that web designers must learn development to be able to design properly. I also frequently hear designers venting their frustration about an engineer who does not see the need for a certain level of precise detail in a design.
I’m not advocating that designers should learn all the ins-and-outs of development, or how to cast metal forms, or how to vacuum form plastics. I’m also not advocating that engineers should learn all the intricacies of typography, color theory, or the grid.
However, if you’re working with a designer or engineer, it would be nice to at least have a basic — even just surface — understanding of what is involved in their work. Ask questions, do some research, try to find out more. Everyone will get along a little better.