For a word that can so vastly change the fortunes of a company, it’s worth noting that no generally accepted definition of the word design exists. This means when your boss stands up in front of the team at that all-hands and says, “We’ll have a design-centered culture,” there’s a good chance he’s saying nothing at all.

But you keep hearing this word. More importantly, you hear the urgency behind the word. You hear that choosing to design a thing is an important thing to do and the person saying it is also important, so you nod vigorously while silently thinking, “I have no fucking idea what you’re talking about and I’m pretty sure neither do you.”

There is no more evidence required that a magical focus on design can transform a company. In order for this to happen, engineering and design need to party more together, but there’s a fundamental tension between design and engineering and understanding that tension is a good place to start thinking about design.

A Fundamental Tension

To understand the historic tension between the designer and the engineer, you need to go back to when software became mainstream, and in my mind that was with the arrival of the Internet. Software had been around and making piles of money long before Netscape, but it became a worldwide phenomenal when anyone, anywhere could mail anyone else a picture of their cat.

The arrival of everyone (and their cats) presented a challenge to these early software development teams. These teams were used to working with early adopters and their particular needs. See, early adopters are willing to put up with a lot of crap — it’s part of the deal we have with them. “You get to play with the latest and greatest, but it may explode at any point.” Early adopters are cool with these explosions because early adoption makes them feel, well, cool.

When everyone arrived, everyone didn’t want explosions — they just wanted it to work. Engineers hear “just works” as “they want fewer explosions”, but that’s not what everyone wanted. They wanted to send a picture of their cat in the simplest way possible. They didn’t care about JavaScript, security, frames or plugins; they just wanted to mail a picture of their goddamned cat without the application exploding.

Design results in the tangible translation between engineering thought: “fewer explosions” and user thought: “reliable, one-click cat photo mailing”. Good design manages to both showcase the best of engineering efforts while simultaneously hiding them from the user.

After working with a wide of variety of designers, my opinion is that the role of design is:

1. Understanding what most users want.
2. Prioritizing and focusing on the most important of those wants.
3. Using this knowledge to exceed user expectations.

In the mid 90s, we, as traditional engineers, were not equipped for the role I described above. We’d been trained as builders of bits, and we believed that because we could build bits that we could build usable bits, but we were actually good at designing good product for ourselves… not everyone.

We don’t see an explosion as a bad thing because we’re intimately aware of how the sausage is made. We know that when a program crashes, you just re-launch the application and get back to work. Most humans on the planet do not see a crashed application this way. They are, at the very least, alarmed when something explodes. They’re wondering, “Did permanent damage just occur?”

A Note to the Designer and the Engineer

With apologies to the incredible menagerie of design folk out there, this primer primarily focuses on the design denizens and design practices that surround software development. Furthermore, this primer is being written by an engineer for engineers. While I’ve spent a good many years soaking in design, I’m not a trained designer and the following descriptions of your history and your craft will piss you off with their simplicity, imprecision, incompleteness, and engineering bias.

But we’re doing the same thing to design folk. We are well intentioned, but because we haven’t repeatedly experienced the essential details, we are ignorant of them. We assume the act of describing the work somehow is equivalent to doing the work and, wow, are we wrong, but we are in good company because every eager master of their respective craft does this.

Engineers are uncomfortable with ignorance, but worse, we’re bad at asking for help outside of our domain of expertise. This primer is the first step at building a solid bridge between our professions. So, chill. This is not a definitive design guide, it’s a place for engineers to start thinking about design and if you happen to learn something about how we think — super.

The Acronyms Matter

The phrase “we need a designer” is likely the first time you’ll hear about design as a freshly minted software engineer. You wonder, “Well, what are they going to do that I’m not already doing?” The answer is an impressively long list of work that is beyond the scope of this article, but a good place to start is three key acronyms.

Like any profession, design is chock full of acronyms, but I’m going to focus on the three that are going be bandied about now that your boss has decided that design matters.

#1 GD — Graphic Design

How they see the world:

Unfortunately, the most common name used to describe the graphic designer is, confusingly, the designer. The reasons are two-fold: first, he was the first person hired to work on the product who had any skill set outside of engineering, and second, he was placed in charge of the “the pretty”. Someone in charge saw the first working prototype of the product and said, “This looks like an engineer threw it together”, (you nod) and “We need a designer to fix this up” (blank stare).

You: “Fix what up?”

Person in charge: “I don’t know… it just needs to… look prettier.”

Designers who have not yet bolted from this article, yet, are now standing on their chairs screaming at the screen as they read this: “I KNOW THAT GUY.”

Yeah, I know him, too. He’s an idiot, but he has good intentions.

The craft of the graphic designer is a visual one. Via applications like Photoshop and Illustrator, a graphic designer gives visual form to ideas. Yes, the work they do is pretty, but it isn’t just pretty. It speaks. It has an opinion about what it is and anyone who looks at it can see the opinion. Yes, a designer gives your application or website an air of clean, credible professionalism, but a well drawn anything does little to make your product easier to use.

A breakdown occurs when the person in charge walks into the graphic designer’s office and says, “You’re the designer — can you help de-engineer the product?” Now, like you, the graphic designer wants to do more — they want more responsibility — so even though they don’t know how the product works or who your users are, they sign up, thinking, “Sure, I’m a designer, right?”

And they produce. They generate an eye-pleasing prototype in Photoshop that you just want to lick. The graphic designer has done something most engineers cannot, and while important design work has occurred, the design is not remotely done — your product simply has a pretty face. And while it does matter how your product looks, it’s equally important how it works.

For the end of each section of this primer, I’ve selected a set of three design-related books that have shaped my design opinion. Let’s start with design essentials:

• The Inmates Are Running the Asylum
• Meggs’ History of Graphic Design
• Universal Principles of Design

#2 IxD — Interaction Design

How IxD sees the world:

The interaction designer has a fascinating gig: they abstract function from form. Think of how you regularly navigate your favorite application. You follow a familiar path that we’ll call a workflow: it’s a series of mouse clicks and drags accompanied by your rapid-fire keyboard wizardry. This is your interface with the application.

The interaction designer’s gig is the care and the feeding of the workflow. Via the deft usage of wireframes and flowcharts, the interaction designer defines and refines the step-by-step process by which a user can traverse the application.

These low fidelity descriptions of the functionality are confusing to those who don’t understand their intent. Is this how the application is going to look? No, this is the interaction. These are rough approximations of the user interface intended to describe how it will work, not how it will look. But how is it going to look? Could we get drop shadows on that text? I love drop shadows and blue, I love words with a punch. Yeah, ok, right — you need to leave now. The door is down the hall on the left and it’s a lovely shade of blue.

The separation of function from form involves making a mental leap and there are those who believe one cannot be considered without the other. I believe the answer is somewhere in the middle. While I don’t believe you need pixel-perfect comps in order to think strategically about interaction, I do believe working prototypes with sample interaction and animation is a far richer place to have a debate than a whiteboard.

A low-fidelity scribble can describe how your product works, and it does remove many of the subjective elements of design that are apt to derail a perfect good design conversation into a useless debate about drop shadows. But color, typography, spacing — all of these elements contribute to the feel of your product, and how your product feels is equally important to how it works.

There are two other acronyms in close orbit to IxD that you’re likely going to discover that are worth mentioning:

IA or Information Architect is a title falling out of favor in recent years. Perhaps the best model for thinking about IAs is the role of a librarian. The mindset of information architects is what gave us the Dewey Decimal System: a classification system for information. An IA does not sleep well until information has been organized. I haven’t run into one of these folks in a while.

HCI or Human Computer Interaction is another title you’ll discover. It appears this title is one granted exclusively from University and those sporting this title first self-declare their degree, then pause, then add their University. Yes, I have a PhD in HCI <pause> from Carnegie Mellon.

My experience with the HCI folk is that they are often brilliant researchers. If you want to understand every possible workflow your users are trying on your application, the elapsed time to complete these workflows, and the enumerated set of quantified emotional damage these workflows are inflicting on your users, find an HCI guy, give him 18 months, and you’ll be <pause> dazzled.

Continuing with the reading list. These books were selected because I believe they are approachable by anyone. Reading these will not give you a complete design education, they will give you a good solid taste of the different parts of design:

• 100 Things Every Designer Needs to Know About People
• Envisioning Information
• About Face 3

#3 UXD — User Experience Design

Finding the one image that describes how UxD thinks is tricky, so here are three (click on any for further detail):

User. Experience. Design. What do they care about? Well, you care about the whole damned thing. You care about the visual design; you care about the interaction design; but mostly what you care about is the experience of the user.

In my experience, the folks sporting the UxD title have nothing like a degree in UxD. It’s a title they’ve adopted over the years because they know what I know: the title of designer is too general to be useful. Graphic designer and interaction designer are too specific. The user experience designer likely had an acronym in her past, but somewhere in the journey she decided it was to her advantage to care about the whole damned product.

Awesome.

There are a pile of design disciplines that contribute their acronyms and abilities to product design efforts and there is a time and place for each. The reason I seek the person that labels or thinks of herself as UxD is because I’m looking for a person who is willing to step up and be accountable for the entire experience.

The last part of the reading list includes absolute design classics. Yes, a book about comics:

• The Elements of Typographic Style
• The Design of Everyday Things
• Understanding Comics

Party. More. Together.

Usability as a design discipline is conspicuously missing from this list. Thing is, even if it had a clever acronym I wouldn’t include it.

Prior to Steve Jobs’ return to Apple, there was a decent centralized usability team equipped with those fancy rooms with one-way mirrors and video cameras. I’m certain these folks did significant work, but when Jobs returned, he shut it down and he cast the design teams to the wind. Each product team inherited part of the former usability team.

Now, I arrived after this reorganization occurred, so I don’t know the actual reasoning, but I do know I never saw those usability labs used once and I would argue that in the past decade Apple has created some of the most usable products out there. My opinion is that the choice to spread the usability design function across the engineering team was intended to send a clear message: engineer and designer need to party more… together.

I can’t imagine building a team responsible for consumer products where engineers and designers weren’t constantly meddling in each other’s business. Yes, they often argue from completely opposite sides of the brain. Yes, it is often a battle of art and science, but engineering and design want exactly the same thing. They want the intense satisfaction of knowing they successfully built something that matters.

A design-centered culture is at throwaway empty phrase unless everyone responsible for the culture of design is in each other’s faces. Titles and acronyms give you a starting point for understanding what a person might do, but what really matters is the respect that comes when you take the time to understand how they build what they love.