This is an excerpt from a private email sent to a fellow designer who asked me for tips on how to work better with engineers. I’ve had my fair share of successes and failures when it comes to this particular kind of relationship, which I hope to be better at over time. I love working with engineers and I don’t think I’m alone in thinking that sitting next to them could potentially increase the quality of your work as a designer. At least from my experience, the best pieces of software work I’ve designed and shipped were also the best times I’ve collaborated with an engineer or two.
I don’t think that is a coincidence.
except written last: Jan 28, 2020
On working with engineers:
1. Do your research (on the technology) -- majority of engineers won't expect you to code and in many cases, you shouldn't have to. However when it comes to designing an interactive app or a digital product from scratch, they do assume you would know the foundations of designing for one, or at the very least, you're educating yourself of it. Doing a web application? freshen up your knowledge on web accessibility, UI grids, semantic HTML and anything that is in the realms of responsive web design. Got tasked with an iOS mobile app? Apple's human interface guidelines is your friend (and maybe a few iOS sketch/figma UI kits). Windows desktop app? Fluent design system should be an interesting read, as well as Microsoft Design's blog. I think what I'm trying to say is no-one knows everything, that is not what's being asked of you. It's your ability to learn, re-learn and hack your way into the business of creating great and usable products that makes you a standout collaborator, with engineers and beyond. I hope you're enthusiastic about this because I get excited just by typing this! :)
2. Find your ally -- This is something no-one taught me but has absolutely been a game changer especially with working with engineers. Use your researcher hat and try your hardest to empathize with the devs you'll work closely with. Figure out what their preferred methods are, their patterns, their collaborating styles (do they work autonomously? are they more open to inter-department design exercises? do they easily get annoyed by random slack messages? do they prefer brainstorming over countless back and forth on emails? if you send them a link to a relevant article, would they read it? how interested are they with UX?). This is the hard part -- if for instance, they don't really care about UX or design but they absolutely have to work with a designer, make sure, no matter how incompatible your work chemistry may seem at first, make sure to really crack the solution to the problem you are trying to solve. In other words, prove to them the value of design.. by producing a core and practical solution that really aligns with engineering. Go beyond the screen. Once you're able to do that, it will be hard to convince a person or two otherwise to do any software work without a designer. You would want to be that designer. Bookmark: Thinking like a front end dev
3. Don't be afraid to ask questions -- InVision wrote about alignment (or lack of) being one of the common problems that designers struggle with when it comes to collaborating with engineers. During the course of the project, or the sprint, it's crucial to keep engineers in loop even when you're quite confident of the design already. More often, they provide valuable feedback when it comes to handoffs all in the name of execution, which skilled engineers are typically obsessed with. Think of it this way: the clearer your communication is, the better the quality of the execution will be simply because there's little to no barriers to the end goal which is anything from a new feature to a design overhaul. One trick I've learned when it comes to dealing with the anxiety of working with new or difficult people: respect their time enough to actually schedule it. Be accessible when it comes to asking for information, avoid slacking things randomly but instead, try and consolidate your questions or messages into a longer-form slack message or even on google docs so that they only have to check it a few times a day rather than every hour, and finally, write it in a way that it is digestible like for example:
Subject: designing components
Message:
Hey! a few things regarding this:
On component breakdown -- would you prefer on a written documentation or can I walk you through InVision's Inspect feature?
How would you like the SVGs to be handed off?
Had a different naming system for the typescale --- instead of h1, h2 etc, I've decided to go for this route. Let's discuss.
Thank you for reading!
Nikki