A Product Designer's Playbook for Working with Engineers

I’m a product designer. I spend my days working with a handful of product managers, a troop of engineers, a pack of other designers, and occasionally a few other types of people (like user researchers and product experts.) One of the most crucial things I’ve had to get the hang of over the past (almost) year at HubSpot is how to communicate with all of these different people.

As designers, communication is sort of our thing--at its core, design itself is communication. The interfaces, systems, and interactions we create tell our users what they’re seeing, what they can do with that information, and why it matters to them. But sometimes, this knack for communicating doesn’t carry over to our day-to-day interactions, making it harder to collaborate with our teams and deliver good design.

One of the most critical (and sometimes the most challenging) types of communication in this realm is between designers and engineers. When it works, it’s like magic. But when there’s a disconnect, it takes longer to ship products and those products usually aren’t as good as they could have been. I was an engineer at HubSpot before becoming a designer, so I have the advantage of understanding both workflows when trying to find the best ways for design and development to collaborate.  

Define the Design Vision Offline

Right now, I work with about 10 front-end engineers and while the bulk of our communication happens in GitHub, the first step of any new project usually happens offline. Syncing up with developers face-to-face early on makes it easier to get everyone on the same page and bought in on the design direction. I’ll first sit down with the tech lead for the products I’m working on to talk through the problem that needs solving and any constraints (technical, time, etc.) we have. This initial conversation gives me the context I need to start working on a solution.

Once the design is ready, it’s time to sit down with the engineer that’s going to bring it to life. I’ll walk her through the decisions and if necessary, explain what should happen in certain edge cases and the interactions between states (these things can be hard to convey in a static mockup.) One thing I’ve learned to over-communicate in these meetings is how final the designs are. Being explicit about whether I’m still toying with a solution or if it’s ready to go can save the team a lot of headaches down the line. No engineer wants to think her work is done only to find out that the designs have changed and she’ll have to go back and redo part of it. And the corollary is true: no designer wants to see a final product that's changed drastically from her designs.

Of course, sometimes the design does need to change. Maybe user or beta testing shows that our users are having trouble with a feature and we need to smooth some of the rough edges. Or maybe the technical framework we use won’t let us make the right custom UI element and we have to find a different element that works. These things are going to happen so it’s important that designers can admit when their vision is wrong, and be willing to change it. That’s another reason good communication is important; iterating is so much more productive when teams can work together to pivot.

Stay On Top of the Process in GitHub

Once we’ve gone over the design together, the engineers go off and work their magic. (Of course, I’m always available for quick clarifications or to answer any questions they have along the way.) When the work is in a good place, engineers will usually submit something called a pull request in GitHub. These pull requests let engineers review each others’ code before it’s shipped, but they also give me a chance to give things a once-over before our users see them. I set aside time in my day to respond to these threads and give feedback, so that things can keep moving and design doesn’t become a road block.

Getting into GitHub means I can make provide feedback on any changes while they’re still top of mind for the engineers on my team, instead of after the code has been pushed to production. It also gives me control over the design process from start to finish. By reviewing every change, our users won’t see anything that doesn’t have my stamp of approval. In fact, I encourage my engineers to copy me on every UI change that goes out, no matter how small it is. This helps me keep on top of the state of the UI so that these small changes don’t start to pile up.

I also heavily use GitHub’s issues feature. When I see something I didn’t expect in the UI, I’ll create an issue on Github, describe what’s not quite right, and provide screenshots of what it should look like. I’ll then assign the issue to the tech lead to either fix or assign to someone on our team to fix. I’ve found that this works much better than creating a card in Trello or messaging them on HipChat. Embedding myself into my engineers’ process on GitHub means my design feedback stays top of mind without disrupting their workflow.

Own the Final Product

Jonathan Meharry (a fellow product designer here at HubSpot) once said something that really struck a chord with me. He said we don't want to make products that just match our users’ expectations for how an enterprise app should look and feel. We want to make ones that can compete with intuitive consumer products they use every day, like Google, Twitter, and Facebook. Good communication is important to me because, at the end of the day, I can't reach that design standard unless I'm on the same page as my engineers. 

As Julie Zhuo, the director of product design at Facebook bluntly put it, “Own the product that goes out to users, not the mock on your computer.” I’m the person who ultimately owns the user interface and user experience of the products that I work on, products that our customers use every day to do their jobs. So while there are many reasons why a finished product might not look like my mock up, it’s my responsibility to spot those potholes, get into my engineers' workflows to avoid them, and ultimately, deliver good design.