Working with engineers is a topic I’ve become rather passionate about, but it’s not something I was thrilled by coming out of design school. When you’re in design school, you’re surrounded by like minds. You can look at an idea posted up on a wall and, without much convincing, you get it. You have a shared background, you’re speaking the same language. You approach problems from a similar perspective, and the process is understood.

In the real world things couldn’t be more different. Product teams are filled with engineers, executives, marketers and customer specialists, and suddenly you’re fighting for design, you’re evangelizing it. Not everyone is on your wavelength, and you find yourself having to shepherd ideas in a way you probably weren’t prepared for. (At least, I wasn’t.)

Imagine a world in which your engineers were, in their hearts, part of your design team. If you help them see the product — and the customer — through a different set of eyes, getting your team to internalize design challenges as product and engineering challenges becomes much, much easier.

What follows are aspirational (but highly useful!) approaches that I fail at every day — so don’t walk away feeling overwhelmed. But I keep coming back to them, because they work for me and my team. And I keep iterating on these ideas, because, like everything in product development, they are a work in progress.

First, let’s walk through a quick definition of design. Setting context is critical because our definition of design directly impacts how we work with others.

First, a quick definition of design.

At its core, design is problem solving. But I want to dress this definition up a little because, while it’s true, I want to capture some of the nuances that are easy to overlook or just plain forget. Here’s a slightly more verbose take:

Design is iterative problem solving for people.

Let’s quickly touch on the words that bookend that definition. The word iterative is an important qualifier: it’s what keeps us real. It should also humble us. We’re not going to get designs right the first time, and we’ll probably never, truly, get them “right.” It’s a never-ending, outright obsessive process as things evolve and change. There’s a bit of unmistakable rigor when it comes to creativity.

Rounding out my definition? People. If we don’t have an audience in mind, if we’re not explicit about who we’re designing for, many things get lost along the way. Notice how I didn’t include the word users. You’ve probably heard this a lot in the past few years and it will continue to be a trend: we’re designing for real, whole people, not just faceless users. “Users” live in generic buckets, if you will. People, on the other hand, have backgrounds, desires, and dreams; they’re humans.

I think this sums it up pretty well. It’s from a former colleague of mine, Margaret Stewart (now leading design efforts at Facebook) which struck me as truthy and essential:

“It’s kind of arrogant to think the only reason people exist is to use what you built. They actually have lives, like, outside the experience they have using your product, and so the first step of designing in a human-centered way is to recognize that they’re humans.”

Iterative problem solving for people. That’s it. That’s my definition of design. It’s not as clever and pithy as some other quotes out there, but I hope it helps take the mystery out of what we do as designers. Design shouldn’t be a mystery to the rest of our team, especially these days when design is such a hot commodity.

Why is working with engineers so difficult?

You may have noticed our definition of design doesn’t make any mention of creativity. So where does creativity fit into all this?

Below is probably my favorite Steve Jobs quote because it removes a lot of the mystery behind what we, as designers, do. It puts all of us on the same level and frames creativity as something we’re all born with, involving everyone in the design process.

“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while.”

It seemed obvious after a while. I thought this was an interesting phrase tacked onto the end. Things seem obvious after a connection made through creativity, (even though there’s also quite a bit of work required to get to that connection).

I strongly believe this whole “obvious” thing is critical to understanding why designers have had such a difficult time getting a seat at the table for the past couple decades. After all the work we put in, solutions to problems look so obvious to us that we feel like explaining it is redundant and a waste of everyone’s time.

We’re simply not compelled to do it, but we have to figure out ways to communicate the things that are obvious to us. It can be tricky, but that’s where the true grit of process comes in.

Okay, onto the practical application…

Sit with them.

We’ve all heard it before but it has to be said. Sit with the engineers. To build something great, relationships matter, big time. Sitting near your team and listening to their conversations is probably the easiest way to soak in knowledge, to get to know all the product’s hard edges, build relationships, and a bunch of other tricks you won’t learn from me.

Engage sooner.

Ideally, there’s not a time when engineering isn’t engaged in the design process. They’re part of the product team, after all. The earlier you involve your engineering team, the quicker you’ll learn where the edges are and where the constraints are. (Teams shouldn’t start with the constraints, but being familiar with them can really save you some pain down the road.)

Another advantage to including engineers as early as possible in your process is that you can get real faster. Get your designs into the environment where they’ll be interacted with: if it’s a website, get it on a browser, mobile phone or tablet and you’ll hit the constraints faster and make sure you’re not fiddling with pixels and polishing the turd longer than you should.

Get to know your backend engineer extremely well.

Not only at the relationship level, but let them help you wrap your head around how your app’s infrastructure actually works, and the process of how tasks occur. Understand the sequence of events following a button-click all the way to the backend, and what happens when the backend walks itself all the way back up to the front end. I guarantee you, you’ll find this information extremely useful.

If you and your team are building a new product from scratch, this is of course much easier to do. But if you’re late to the game and new to your team, you can still take some engineers to lunch and pepper them with all your stupid questions.

Provide the right kind of deliverables.

What are the right kind of deliverables, you ask? This is something you’ll have to figure out on your own, because what works best for my team might not click with yours. However, if you haven’t tried switching things up in terms of how you work and what kinds of artifacts you pass back and forth, this is a really easy place to start figuring out how your team might better engage with you and your process. Here are a few examples from my own experience. (Some good ones, some bad ones.)

One thing I’ve moved away from over the years is delivering the various states of a final design as a stack of slides or something similar. Sometimes it was a PDF, sometimes it was something the developer could click through, like a cheap usability study, but they ended up being more or less stacked on top of each other. It sounds good in practice. It’s how users experience the app: a series of screens, never seeing two different states at once. But it’s just not excellent for working with our friends in the engineering world.

Instead, I’ve found with my team that when the various states of an interaction design are presented side by side on a single canvas, it’s easier for everyone to see connections and not drop screens on the floor. It also means fewer files to muck around with, since every state is contained in one PNG or PDF. No more having to come up with a file naming scheme and manage each of the states.

The above example shows a very simple set of interactions for a button to change the playback speed. (If you don’t know anything about FullStory, it’s a CX platform that features customer session playback.) First I show the base state, then the hover state, and finally the click state. It’s pretty straightforward.

Reduce it down.

One thing you might notice missing in the above example is all the context of the app around the feature. I’ve found that oftentimes when you show the entire app in context for each and every state, all the details tend to wash away and get overlooked. Strictly focusing on the interaction states as a series of vignettes helps solve that problem. You don’t want to overwhelm the person wiring it up; showing them more will very often lead to details being dropped.

While this visual won’t mean much to you unless you’re familiar with FullStory, here’s another example of a deliverable where the app around the feature had been masked out. This UI can be used to invite teammates to your FullStory instance. We originally thought it would be part of the onboarding flow, and maybe live permanently in the settings UI. But in this particular case, when I removed all the surrounding context of the app, it allowed us to think of all the places where this could be used besides the settings page.

When you look at things modularly, you can say “Oh, actually, there are probably a lot of moments when you’d like to invite people.” Reducing it down and looking at it as a vignette helped us discover that insight.

Treat coding as another tool in your toolbox.

You know how we learn to bounce among different tools and mediums to solve a problem? For example, we may initially approach a problem with high-fidelity mocks, only to return to pen and paper. And when that fails, we may try wireframing, only to find the final breakthrough comes when we simply spend time writing? What’s up with that?

Well, in contrast the longer slog of problem solving in design, there are a ton of quick wins to be had when you code. Code is beautifully unforgiving: it either works or it doesn’t. Think of it as a pressure relief valve when you’re stuck. That is, in the design process, you’re often working with a lot of tiny puzzle pieces and it can become difficult to see how they all fit together, whereas coding gives us a chance to step away from all that and mix it up. I find it fires an entirely different set of neurons up in my thick skull.

Another benefit is that when I’m able to commit bits of markup (we’re simply talking HTML/CSS here) I’ve heard it reduces my team’s need to context switch, mentally. They can continue to focus on longer arcs of harder engineering problems, while I work on getting the nitty gritty details right. Red line specs quickly become a thing of the past, helping you avoid those awkward conversations about moving that thing 3px to the left.

So should you be regularly committing code? I don’t know. I do know that thinking of it as another tool in your creative toolbox can be immensely useful in broadening your understanding of a problem.

Invite them in. (And drop in on their meetings, too.)

One of the many internal mantras when I worked at Google was, “Know the user and all else will follow.” Well, if you’re the only one who knows the user, then in order to actually get stuff done you’re going to have to spread that knowledge around. You can’t be the only person on your team who understands your customers and still expect your engineers to agree with every decision you make, especially if the “problem” you’re trying to solve isn’t something inherently broken, from their viewpoint.

Something that’s been useful to me over the years is inviting my engineering teams to sit next to me and watch usability studies together. This was (and I imagine still is) common practice at Google. I’d have to make an effort to drag people along the first time, but once they sat through one session, they were hooked and would want to watch the next round of studies.

At the heart of this process, it’s about sharing empathy. Again, we can’t be the only ones feeling empathy; we have to expose everyone that we work with to real live people in the product.

If I can say so myself, FullStory is perhaps the best way to share empathy. We get together every week or so to watch a random handful of sessions. It’s a process we call Game Film (we’ve even made a fun kit to send to our customers to help them Game Film with their team). It helps spread empathy and it’s given me a lot of leverage as a designer to have everyone exposed to the customer’s usability struggles and successes.

Never “hand off.”

Another thing you don’t want to do is hand off your designs. Never completely wash your hands of something and say, “I’ve done my part, it’s on you now.” Inevitably, towards the end of a project, some new constraint or other will become apparent to your team which could have been circumvented if you had only kept your hands on the work. I don’t have too much to say on this subject that isn’t covered in this extremely apt tweet from @RWD:

“Thinking of design and implementation as separate concerns impacts the quality of both.”

Cozy up with constraints.

There are a lot of ways to impose constraints on a design. You can set a deadline, you can give the problem to fewer people, and you can also have a chat with engineering. When you’re painfully explicit and upfront about all the weird corner cases for a given interaction, it can often lead to a design breakthrough, and due to the way engineers work, they can help you short-circuit the often arduous discovery of those constraints.

This all hit me a few years ago. I can’t recall the exact problem or what the breakthrough was, but it was significant enough that I wrote a tweet summarizing the above. A friend of mine, Dakota Reese, wrote something back that was too true not to feature here:

“The irony is that when you code, you usually check for the edge cases first. When you design, you usually get to them last.”

I think we can all relate to that.

Make decisions just-in-time.

This one wouldn’t have made sense to me early in my career. (“We need to plan! Let’s map everything out long before we have data!”) The just-in-time philosophy stems from the agile development movement, and it’s been of really great use to me. In essence, it’s about waiting until you have real information, something that reacts to input, a prototype of some sort, before you make a decision about a problem with a lot of nuances.

With complex problems and uncertainty, committing too early to a solution means you run the risk of making unhealthy assumptions about the problem. You’ll overthink it, potentially, or jump to the wrong conclusion. Deferring until you have something you can tangibly hold, see, and react to lets you make decisions centered on something real. Practically speaking, this means that when we design, we should be flexible enough so that fewer commitments are irreversible. Defer the irreversible commitments as long as you can.

Always be painting a picture.

Designers must always be painting picture for the engineering groups and everyone else around us. We have a unique position: we get to look broadly across our users and across every piece of our product line to see how they all fit together. Not everyone on the team may have such a holistic view. We have the unique opportunity to move from the big picture, to the details.

I’m lucky enough to be working with a group of engineers who really jump at the trickier coding problems. They never tell me, “Hey that’s too hard.” But building this kind of relationship with your team can be difficult and requires you to paint a picture of the human experience on the other side of your product. To be constantly bending the rules and taking what seemingly works today and rebuilding it — that’s what designers do, but convincing your engineers requires a high level of trust and, of course, shared empathy.

Let’s give peace a chance.

This kind of sums it all up: a design process that includes, informs and pushes engineering throughout is the key to creating an atmosphere of acceptance for design thinking, not to mention getting designers a spot at the decision-making table. You know the old adage: if you can’t beat ’em, join ’em. (And please, friends, don’t beat your coworkers.)

Maybe you have some of these tips in practice at your company, or maybe I’ve given you some ideas. If you have questions or want to chat about your interactions with your team, reach out to @fullstory on Twitter!