In HubSpot’s early days, a lot of our designing was done by our engineers. Now, we’re fortunate enough to have a dedicated design organization, and with all due respect to our engineers, our designers have brought with them lots of improvements to the product.
This begs the question, does our design team need input from engineers at all? In a world where we have ever-increasing levels of specialization in our roles, it’s easy to think our jack-of-all-trades days are behind us. The designers are the experts in their own field, after all. Right?
Yes, and no.
At HubSpot, we place a really high value on autonomy. One reason we do so is because it gives people the freedom to do their best work. Another is that, because we work in small, autonomous teams, our job titles are closer to specializations, and we can leverage each others’ insights and feedback to achieve our goals.
So, should engineers have input into design?
To be clear, the designers are the experts. Not only are they much more clued into our customers’ needs, their bread and butter is taking those complex problems and designing software that’s easy to use. Engineers, on the other hand, can make things that look a little “headache-ey” if given too much free reign (sorry).
This isn’t to say that engineers shouldn’t be involved in the design process at all. On the contrary, the UX can be a lot worse off if engineers aren’t involved in the conversation. This won’t take the form of bugs, or even major UI issues, but often more subtle things:
- A UX that makes sense, but isn’t immediately intuitive
- A UX that works well for the most cases, but not for those edge cases that customers seem to keep bumping into
- A usable UX, but one that follows a different pattern than other parts of the app
- A small detail of a feature that will take a week to build, but doesn’t really provide that much value
These kinds of things aren’t really major issues when looked at in isolation. They aren’t bugs — customers might not ever complain about them — but they’ll be a constant source of pain for those experiencing them every day. Thankfully, all of them are things that engineers can move the needle on.
Enter the feedback loop. Feedback loops are the lifeblood of product teams at HubSpot, and they exist everywhere — from the small decisions we bounce off each other in our teams, right through to whole product lines that are born from user feedback.
One feedback loop we as engineers are very familiar with is pull requests. As with any feedback loop, pull requests are a forcing mechanism for the creator to be honest about any shortcomings of the work. Even the strongest engineers are prone to shipping lower-quality code, let alone mistakes, if they work in silo, and don’t have to explain their work to anyone. Not only that, but providing feedback here is a net-positive, whatever the feedback is; even if the feedback is ill-informed, the reviewer is learning something from the exchange. And if it’s not, that feedback can drive a plethora of improvements, such as:
- Pointing out mistakes
- Clearing a misunderstanding of requirements
- Providing context the creator might not have had
- Suggesting alternative approaches
For these reasons, reviewing pull requests is a win-win. Importantly though, none of these reasons are unique to pull requests. You guessed it — providing feedback to your designer can drive all of these improvements, and more.
At HubSpot, the customer is at the heart of everything we do. We also believe that we have maximum impact when we align our efforts around common goals. It follows that when engineers are invested in the customer’s needs, that’s our best chance of delivering the product they deserve.
Engineers can be a voice for the customer by providing design feedback. For the rest of this post, I’ll break this down into some specific ways that engineers can be better partners to our designers.
1. Have an opinion on designs
Having an opinion is possibly the most impactful way an engineer can improve design. As well as for all the reasons feedback improves quality, having an opinion signals your investment in the customer experience, and influences those around you to do the same.
It can be scary to start giving feedback if you haven’t before. Try to keep it as objective as possible, focus on the customers' needs, and remember it’s ok to be wrong; feedback is a win-win! If it helps, give feedback on the smaller things first — at least at HubSpot, smaller design decisions are often made in silo, and mistakes may have been made there.
2. Consider how long things will take to build vs. how valuable they’ll be
We all care about having impact, but we only have so many hours in the day. It’s important to consider the time something will take to do alongside the value it’ll have for the customer whenever you commit to build something, especially as designers often don’t have that insight. Often there’s a quicker way to achieve the same outcome, which means more time for building other features!
3. Push for patterns
Especially for bigger products, it becomes less and less likely that anyone will be familiar with every part of it. Without coordinated efforts to keep patterns consistent, small differences in UX can creep in between different parts of the app, which can become particularly painful for customers.
Engineers may be familiar with parts of the app the designer isn’t, and can be advocates for consistency by calling out when a pattern is or isn't used elsewhere.
4. Champion the details
The mocks will rarely cover every last detail. Things like edge cases, error states, and accessibility details are often up to the engineer to think about. It's important to make these as solid as the rest of the UX, as they will be experienced by your customers every day. Having great attention to detail will please customers and will often influence your teammates to do the same.
5. Hold your team to high standards
All of the above will only serve to improve your work. You can improve the UX of your app even more by holding your team to the same high standards.
If you’re looking for where to start, pull requests are the perfect place to do this. As well as reviewing the code, try testing out the UX too, and ask yourself if it is as intuitive, consistent, and easy as it can be. By providing this feedback, you’ll create a virtuous circle where the UX is talked about more and more.
Ultimately, what all of these tips boil down to is having empathy for the customer, having empathy for your teammates, and striving for the best quality you can. Though we might have unique job roles and individual responsibilities, a team can be more than the sum of its parts by fostering a culture of productive feedback, and by leaning on each other for ideas.
Does working on a team that values symbiosis between design and engineering sound good to you? Check out our open positions and apply.