How Not to Make Your Engineer’s Life Completely Terrible

or ‘I’m a Designer, I Don’t Need to Understand’

Charlie Deets
Jul 8, 2015 · 5 min read

I’m a designer. I like engineers. Maybe I like them a little too much. When I joined the Groups team at Facebook I remember foaming at the mouth the first time I talked to an iOS engineer who had been on the team for quite a while. I started spouting out stories of things I’ve written in Objective-C. I felt like I was a freshman in high school trying to prove to an upper classman that I was cool enough to hang around.

I notice that a lot of designers don’t really know how to talk to engineers. They definitely talk to them, but they don’t try to actually relate. That’s why I wrote this. It’s part of our job as designers to understand the struggle of a software engineer. Doing so ends up making the process of creating a product more efficient.

Welcome to the DOM.

Part 1: Learn to Code

I find that being able to understand basic principles of programming really helps inform creating designs that are implementable. If you can anticipate what will be happening in the actual execution, you will end up much closer to being on the same page with your developer from day one.

If you are going to be working with gridded layouts in iOS, play with UICollectionView and see how it works. Learn its limitations. If you are designing for the web, understand the frameworks the team is using, learn how and why the DOM is being manipulated. The idea here is to build a shared language of communication so the team can more easily come to mutually beneficial decisions.

Learn what is hard about it.

While you are at it, in your spare time think of the tiniest project you can imagine and try to build it yourself. Learn what is hard about it. Over the course of time, if you do this occasionally, the dots will begin to connect and you will sorta-kinda-maybe know what you are talking about next time your engineer says that the change in your design will require a ‘model shift’.

Remember, it’s not important to be good at coding. You in no way need to become a developer yourself. You are merely learning languages and concepts so you can more successfully communicate with your engineers.

Part 2: Don’t Explain, Prototype

How does it feel when a project manager says, ‘let me sit down with you and talk you through my thoughts while you design?’

It’s important to do your job for the engineers. Your job is to prototype the interactions.

Some might argue it’s faster to say, ‘I just want the box to expand in from the top and then the image to pop in from the center’ instead of taking the time to prototype your design. That’s not designing. It’s your job to prototype the interactions if they are important to the experience.

There is very little ambiguity in a well-made prototype. Engineers can often figure out the animation values they need from a prototype. It does take time to make prototypes, but it reduces the cognitive load and time wasted in trying to explain complex interaction concepts in words.

I’m a huge fan of using Framer for my prototypes. It’s a powerful tool and because it’s code based I can often anticipate and explain complex animations to engineers, because I had to figure them out myself first. (Refer to Part 1.)

A lot of designers at Facebook also use Origami. People often say they can create new experiences in Origami that they couldn’t elsewhere because of how flexible it is as a creative tool. Use the tool that works best for you.

Part 3: Provide the Spec the Engineer Wants

Get to know what your engineer needs and provide them with it. Understand their workflow and once you get into a good groove, you both will end up saving a bunch of time and stop dealing with stuff that doesn’t matter.

Spec by Joe Lifrieri for Facebook’s video player. Ain’t no ambiguity here.

Conclusion

I find it helpful to think of myself as the ‘design-specialist’ on the team. Great design ideas can come from the ‘product manager-specialist’ or the ‘research-specialist’ or anyone really. At the end of the day, I should be the one caring the most about design, but I don’t let that limit how I can help.

Once you reach out and care about the workflows of those around you, you will find that it actually speeds things up, because you can work more as a team, instead of as individuals with responsibilites.

Get to know your engineers, feel their pain, understand their struggle. You might find the next time you think something really needs to be a slightly lighter shade of grey, your engineer might end up being more compassionate to your needs as well.

Pro Tip: For whatever reason, teams really love plush animals. Photo Credit: Caitlin Winner

Feel free to get in touch on Facebook or Twitter. Also, if this stuff sounds exciting to you, Facebook Design is hiring. Check out our jobs.

Also, thanks to Joe Lifrieri, who constantly blows me away with the precision of his specs.

Facebook Design

Designing for the global diversity of human needs.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store