Shipping code for designers, not just engineers

Great product teams are based around designers and engineers working closely together.

We’ve discussed before why this side-by-side partnership is important, but so is avoiding the curse of over-communication. There are many situations where designers can refine the product details themselves, without having to go to engineering for help.

Let’s imagine a scenario where a designer is doing a round of QA and notices that a button isn’t positioned correctly on a page. This could play out something like this:

• the designer spots the issue, and provides some improved CSS
• the designer opens an issue and assigns it to the engineering team
• the task is undertaken by an engineer (perhaps days or weeks later)
• there is a short conversation to clarify the work
• the change is made
• a quick desk-QA happens before the code is okayed
• the change is shipped to production

If you work on a product team, you’ll agree this workflow makes no sense. Simple changes are dragged out across several days or weeks, pulling in multiple people at the expense of other work. (Brooks’s Law specifically calls-out the explosion in communication overhead as more people are added to a project as a reason for delay.) Surely there’s a more efficient way to iterate on small changes? Thankfully, there is. Why shouldn’t designers ship code to production themselves?

This has two main benefits:

1. Designers feel like they’re empowered to take ownership over their own work. In many product teams, designers have to rely on engineering to make progress. This keeps designers in a subservient role, and makes engineering a bottleneck that can limit the entire team’s progress. It also means designers are never in full control of the final polish of their product – a less than ideal situation.

2. Engineers retain focus, which makes them more productive. Most engineers know that there are no small changes. Even something as trivial as changing a button color requires a number of small interactions and context-shifts that add up to much more work than it looks on paper.

Copyright Jason Heeris. Licensed under Creative Commons.

In short, having designers ship code to production themselves can benefit the entire product team. This requires a bit of work upfront, but pays back many times over once you’ve got the process nailed down. Here’s how we did it.

A simple way to teach designers to ship

Firstly, we don’t expect designers to be familiar with the JavaScript framework we use, the way we code or the way we layout CSS. Not all changes require that depth of knowledge, so we try to give designers just enough of the skills they need to have impact.

Secondly, we tried to remove the fear associated with shipping code to production. When we first spoke to designers about shipping it became clear they saw it as an arcane process exclusive to the engineering guild. Maybe they heard about how someone shipped a bug to production or maybe they had worked with engineers earlier in the careers who had warned them away from shipping. While it’s true that some code changes are far riskier than others, there are many low-risk tasks that can be done safely with a little support.

With both these principles in place, Julien, one of our product designers, organized a workshop for product designers to demystify the process of shipping code. We:

• made sure everyone had a working development environment on their laptops. When everyone could test out changes in a controlled environment, they were less likely to be crippled by fear when it came time to push to production.
• explained how our version control system works, and how code gets into our customers’ hands. This gave designers some more context on what happens after code hits production, and how changes are tracked in case anything goes wrong.
• explained what safety valves we have to protect us. Our infrastructure has been deliberately built to support failure (from engineers too ? ). This helped designers understand that everyone makes mistakes, and the damage limitation structures we have in place.

The impact of the workshop was immediate:

• It created a shared vocabulary between engineering and design. When engineers talk about changes that need to be made and shipping fixes to customers, the design team are no longer left scratching their heads.

• Everyone does code reviews. Designers now get hands-on when reviewing pull requests, requesting and reviewing screenshots/gifs and sitting with engineers to desk-review implementations. They’re now creating their own pull requests ?

So what are designers shipping?

There are a few rules of thumb we use to decide what designers should ship.

• Design-focused. Updating copy or tweaking CSS and animations is a good example here. Rewriting JavaScript to change the actions of a button is probably not.
• Simple or small. A large, complex PR laced with CSS changes could have knock-on effects that require a deeper understanding of the implementation. So keep it small and simple.
• Fast. If the change itself can’t be made quickly it’s probably not worth doing. Remember, the goal here is to reduce the overall cost of the work for everyone involved. If it would be quicker to hand-off to an engineer and take the hit of context switching then that’s always the right call.
• Confident. This is the golden rule. If there’s any doubt about how the code is implemented it’s not worth attempting. Changing the value of a CSS block is probably OK, introducing new classes might not be.

Let’s look at a nice example that Julien shipped recently.

He spotted an issue with the line height of buttons in our messenger, opened an issue, it was reviewed by an engineer on the team, and he made the change himself. It was all done in less time than writing instructions out for someone else to do it.

What could have been a change that dragged out over multiple days was fixed by a designer in less than one day.

From zero to shipping to production

If you work in a product team that ships multiple times a day, there are great opportunities to empower designers to ship themselves. It lets engineers focus on high-impact, focused work, while empowering designers to sweat the finer details of the product. We’re not advocating that every designer needs to become a rock star overnight. But if you work in a busy product team, it’s worth asking yourself what could be unlocked if everyone was empowered to ship?

If you’re interested in joining the R&D team to help build Intercom, check out our current openings here.