Photo by Francis Luu
A Cheat Sheet for Designers
Once, a long time ago, I was a product manager. Then, I was an engineer. For the past seven years, Iâve been in design. Every single day, I work with people in all of these roles. Every single day, I find new ways to appreciate the responsibilities, challenges, and art behind each of these three pillars of product development. Engineers are the magicians of the crew, who, with a few taps of their fingers, take the plans and the pixels and Voila! A working implementation. As a designer, how do you best keep up with their meme-savvy, self-deprecating, script-loving ways? Keep reading.
Engineers are the translators of ideas into reality.
Engineers make every good proposal real, and this fact should never, ever be forgotten. Even if your company has five, or five hundred, or five thousand engineers, engineers are not a âresourceâ. They are the builders of the foundations, the keepers of everything that makes your product tick. They make it work. They make it work fast. They make it robust and reliable and scale it to millions and billions of users. Generally, itâs the engineers who innovate, who push technology forward with new algorithms, who make sense of the trillions of inputs available and turn those into some semblance of meaning.
All this is to say: engineers are the shit.
Which meansâŚ
Want to make stuff happen? All you need to do is just convince one or two engineers.
Really, thatâs all it takes. Many a legendary product story starts this way: a couple friends, a weekend, a few cans of beer, some hacking. The PM comes later. Managers come later. Start with the basic building blocksâan idea, a design, and an implementation. Thatâs why it pays to have close ties with engineers.
Or, imagine this scenario: some small part of your product irks you. Like really irks you, in an itch-in-an-inconvenient-place kind of way. Something about the design is just plain wrong. What should you do?
A. Bring it up at your next team meeting where itâll get put on a list to be prioritized by a team that triages those sorts of things so they can assign it to some future engineer after sheâs joined and needs a couple âpracticeâ tasks to get through.
B. Be pretty tight with an engineer and walk over to her desk. Ask her to spend 5 minutes fixing the thing. Watch her submit the diff. (Possibly you may need to barter a t-shirt design for her 80s cover band or something, but you are a pro with Illustrator.)
Guess which version gets your thing fixed the fastest?
That saidâŚ
Things go easier if the engineer youâre working with appreciates the value of good design.
Itâs amazing when youâre working with an engineer who knows how to fill in the blanks on a mock without asking you about every little detail because even though you forgot to specify how many pixels are in the margins, she opened Photoshop and measured it herself. Itâs incredible when she throws in a suggestion that makes the design even better. Itâs stupendous when, after sheâs done implementing the first pass, the implementation looks virtually indistinguishable from the mock, thatâs how precise and detailed she is.
How do you work with such engineers? Well, you can hire them. Lucky for you if you can, because awesome UI-oriented engineers are in high demand.
Or you can help every engineer you work with develop an appreciation for good design. How? Donât just throw mocks over the fenceâexplain what youâre doing. Teach them about your values, and why you think the design youâre proposing is worth building. Help them learn how to tell if their implementation matches the mock exactly. Talk to them about whatâs going on in your head when you say something looks bad.
The relationship building matters here. People shift their values and priorities based on conversations with other people. Itâs an old-school but effective way to do things. (âSlow Ideasâ from the New Yorker is a thoughtful, excellent read about this strategy.)
Plenty of engineers donât come to the table with an eye for design details, but most care about the user experience and want to make it better. Iâm not saying every engineer will enjoy doing detailed UI work, but it always helps to expand on the why of a design.
Because the more excited an engineer is about a designâthe more they understand its rationale and see its valueâthe quicker and better itâll be implemented.
Save yourself time; understand engineering constraints early.
As designers, itâs easy to get wrapped up in the world of what-ifs. What if we could read your mind here and know exactly what you wanted to see and showed it to you? What if when you tapped on this button, it explodes into a flurry of particle effects and fire?
Donât go through the heartache of falling in love with a design thatâs out of the question because you didnât understand the technical or time constraints early enough. (And even if it is a design thatâs worth going to bat for, your case is going to be much stronger if you do understand the constraints.) The worst thing that can happen is that you spend your time perfecting a design that has no chance of working out. Good designers are scarce enough as is, and there are enough big problems that we donât need that kind of inefficiency.
So the next time a brilliant idea possesses you but you have a sneaking suspicion that it might be hard to build, donât wonder. Ask the engineer.
The inverse of this holds as wellâŚ
Save the engineers time; help them understand how final the design is at any given stage.
If you give an engineer a design to build but youâre not confident how well itâll work out until you get to play with the implementation, make sure you let them know that thereâs a good chance things will change. Nothing is more annoying to engineers than staying up all night to finish an implementation only to get a memo in the morning that Whoops! The whole design has been transformed! And now theyâll have to throw away all that production-quality code they put painstaking attention into.
Of course, no engineer writes code that never gets thrown away. Itâs part of the job, same as design. Good engineers understand that the product development process is messy, and we donât always know whatâll work until itâs real. Stuff will get changed. Designs will get redesigned. But setting context on what pieces are still exploratory and what pieces are locked down helps engineers figure out how to architect code that is either faster to write or more flexible to modify later.
The best way to ensure designs are implemented as intended is to work extremely closely with the engineer.
Like, sit right next to them when stuff is getting implemented. I canât overemphasize how much easier it is to make sure everyoneâs on the same page when folks are sitting in the same room. Issues surface and get dealt with much faster.
Itâs easy to cast blame when the end product is not something that everyoneâs proud of. Oh, my mock was great, but the engineer didnât implement it correctly. Thatâs poisonous thinking right there. You, the designer, own the product that goes out to users, not the Photoshop mock on your computer. If something wasnât implemented correctly, why didnât you do something about it? Why didnât you ask the engineer to show you the implementation right after she finished it so you guys could go over it in detail? Why didnât you check in during the building phase to see if she had any questions about the design? Why didnât you file a task for her to fix the bug after you saw it?
Thatâs right. Own it.
The quickest way to an engineerâs heart is to be complete with your designs.
Itâs kind of funny that the word âdetail-orientedâ is thrown around to describe designers when in fact most design specs miss numerous cases that end up being identified by engineers who have to implement all the branching paths.
Want to be a design hero for engineering? Make sure your design solutions are complete and consider edge cases like:
- Internationalization: what does this design look like in another language? Notably German with its layout-threatening long words?
- Error states: what happens when network connectivity is lost; databases crash, etc?
- User extremes: what does this page look like if the user using this has no information or activity? What about if the user has tons and tons of information or activity?
- Transitions: what is the precise way that screen A becomes screen B? Good tools are mighty helpful here, as described in How to Survive in Design (and in a Zombie Apocalypse).
Not only does designing the above cases inspire confidence that youâve actually thought through everything holistically, but they help engineers plan out how to architect the system, and give proper estimates for how long things will take. Not to mention, complete designs prevent last minute scrambles to put together shoddy blank states because nobody caught them until it was too late to do something better.
So be a good citizen. Make sure your designs are complete. Donât just design for some idealized use case. Get out of mock-fantasyland. As every engineer knows, what counts at the end of the day is what ships.