Don’t Blame the Engineer

I ran a freelance web design company from 2015-2018. It was a fun experiment born from a choice to spend six months teaching art in rural Mexico. Facing unknown and unpredicted challenges, I found that I am capable of a lot more than I’d previously considered. So, I branched out to see what I could learn. Owning my own business gave me the freedom to continue traveling the world, the impetus to learn basic coding, and (most importantly for this story) an appreciation for working with developers and software engineers. They’re a pricy luxury, and for good reason, because they can do things that I can’t.

Because my teams were always very small (5 people or less), we had a lot of time together. We worked side-by-side most days, in our funky li’l co-working space, in our even funkier li’l Central California beach town, a stones’ throw from Silicon Valley.

After a few years, more change was in order. I left freelance life to see what the sky-scraping corporate world had to offer. I thought, “now I’m really going to learn how it’s done with design and development teams.”

The first day that I stepped out of the elevator onto the nth floor, I saw large teams of engineers. I became a member of a comparatively small design team with a big job on my hands. However, I had a collection of software tools, empowering me to communicate my designs to the engineers, right down to the last hexadecimal. I had inherited Discovery Meetings, boardrooms, stakeholders, and so many things that I was sure would transform my ability to communicate design forever.

Plot twist!

What I did NOT see coming is that the skills I already had would be the most valuable thing to me. Those skills are my modesty, my simplicity, and my sincere desire to understand and serve the needs of others. Exactly what I have been cultivating and expressing for the past eleven years I’ve spent as a designer.

Since I’ve been in the corporate world, I have seen time and time again that the most successful designs have these two attributes;

  1. Your Sketch file and the final product actually look like the same thing
  2. The final product functions as any user of the internet would expect it to, with no glaring usability issues

These designs are inevitably created by designers who know how to communicate with their engineers.

Here are a few guidelines I’ve learned in my time with the amazing, capable, fun engineers that I work with. I hope they serve you.

  1. Your engineers are your first users. When you send them your design files in Abstract or InVision or whatever you use, it’s UP TO YOU that those designs make sense and tell the right story. If their product looks radically different from your design, go talk to them and ask what they need from you. Use those research skills that I hope you’ve learned. Interview your engineers. Learn their needs and their pain points.
  2. Be honest with yourself about whether or not your design process is effective. It may be entirely on you to audit whether or not you’re truly getting the data, or the ideation framework, that you need to make human-centered designs. When I first began designing more complex applications, my user interfaces were a big, tangled pile of poo. Processes like user flows, paper prototypes, and basic user research, along with some straight feedback and a little time, have greatly simplified my designs (and I am doing everything in my power to continue that path). Paul Rand said “Design is so simple, that’s why it is so complicated,” and that guy knew his shiz. Make sure you’re not sending over mock-ups that requires your engineers to first create a flying carpet before they can make it happen by next launch.
  3. Be the kind of person that your engineers can talk to. Don’t be that hella dramatic art diva that nobody wants to confront. Your engineers are UP. IN. your product. They know when usability issues come up. Since you are a human being, usability issues WILL arise. It’s ok. It doesn’t mean you are a bad designer. I mean, hopefully you have the support to conduct prototyping and user testing to resolve most of these issues, but your engineers will be your last line of defense before the real world hits. Engineers that will pay attention and come to you when such a thing arises are worth their weight in gold. Value them. Make sure they know it. The final product (which, of course, you care about MUCH MORE than being right) will be better for it.
  4. Finally, to the degree that your company culture permits, HAVE FUN with your engineers. Play darts with them. Ask them about their kids, dates, birthdays, whatever. You’re together for the majority of your waking hours. Remember that they are also human beings, just like you.