Interaction Design is like…
By: Michael Moreau
Tags: Communication, User Experience, Design, Interaction Design, Product Design

So, what do you do for a living?

Inevitably, you will be at a party or Thanksgiving dinner, entertaining friends of friends, or not-so-distant relatives, and between debates on the proper way to serve cranberries (canned) someone will ask you what you do for a living. You’ll finish your bite and say “interaction designer” (or UX designer, or product designer, or whatever your particular title is). The look you’ll get in response seems to say “I know those are words, but I have no idea what you are talking about.” They follow up, “Ok … what does that mean?” and you’ll go into an explanation of what it actually is that you do.

A lot of people like to talk about the process. We study people, and we learn how they do things, and then we build things based on that (Or, as one of my professors put it: “study users, build sh*t”). The problem is that often this doesn’t help. What we do as designers can be abstract and squishy, and therefore hard to explain. It’s abstract because it inhabits a space of action, instead of object, and the results can be subtle. We, as designers, know that good design by its very nature is not always blatant, which can make it hard for people who aren’t trained in design to articulate the differences, even if they notice them.

So, as a backup, we may try and relate to personal experience with the tried and true “Have you ever used an application that was frustrating and hard to use? Or one that was natural and easy to use? That’s the difference design makes.” This explains the results of design but it’s still asking people to think about how two applications, that may have different purposes, behave differently.

After going through this scenario many times, I finally came up with an explanation that I really like:

An interaction designer is like an architect.

An architect doesn’t construct a building but they draw the blueprints for how the building should be laid out based on what it’s going to be used for. The designer then works with a general contractor and construction crew to get the building built.

Oh, I know what an Architect does

There are a couple of reasons why this comparison works so well in practice. One, people are generally familiar with what an architect is. They may not know exactly what an architect does day-to-day, but they know the job from popular culture or personal experience. Architects also produce something concrete (no pun intended) in the creation of blueprints. We all have a vague idea of what blueprints look like, we know that someone has to draw them, and we know that they represent a building.

We also have a lot of familiarity with buildings, and we know that buildings are different, even if they serve similar purposes. The house I live in now is laid out different than the one I lived in when I was growing up, but they’re both houses. You USE a building in a way that’s not unlike how you USE software.

Which door is right for my use case?

As a metaphor, it’s also easily expanded upon to get to the actual details of what we do. For example, a restaurant and a doctor’s office are going to need to be laid out differently because they have different purposes (just like software). Despite this fact, they will share common elements, such as closets and bathrooms, but even those will need some modification based on the needs of the users, i.e. those people that use the building (just like software!). You can really go down a rabbit hole with this (and trust me, I have) but you never get too far away from what people are familiar with.

A couple of other comparisons, just for fun:

Visual design is the paint, the carpets, the look of the building: It’s valuable and helpful but it won’t make up for the fact that a door is in the wrong place or a hallway doesn’t lead where you expect it to.

Navigation is signage: Do you know where you are? Do you know where you are going? What signs exist to help you with this?

It’s easier to revise a blueprint than to rebuild a section of a building.

At some point, you may have to go back and revise the design because the cost, or time, or difficulty of building doesn’t justify it.

Now for the Difficult Part

Obviously, there are limitations to this metaphor and it’s not a perfect one-to-one comparison, but it moves the conversation forward. As hard as it is, though, to explain design to someone who may have no experience in building software, what about explaining it to a colleague? What if you work at a company that is only starting to introduce design? It’s not really necessary for the person at the party to have a deep understanding of what it is that you do (there are other topics of conversation, like a new restaurant) but for someone that you work with directly, it affects your daily life.

Now, helping your colleagues to understand design is way beyond the scope of this article, or any one article, or series of articles. You could easily write an entire book, or series of books, or teach a class on this topic, but there are still a couple of lessons that can be learned from this. When answering the question “What is interaction design/ux/etc?”:

Make it concrete Make it relatable

And that will get you pretty far. This is why storyboards and workflow diagrams are so valuable: like blueprints, they are boundary objects. It’s also important to note that it’s not necessary for them to have a complete and total understanding of design, as long as they are willing to go along with you on the process. The real question to them is less “What is design?” and more “How does design affect me?” To answer this question, you’ll need a little more than a quirky metaphor.