Design Branches –

Bridging the gap between designers and developers.

While working for various start ups, I’ve noticed a common theme amongst full stack developers. Very few of them are excited about CSS. I don’t really blame them. CSS can be finicky and developers generally have enough on their plate as it is. Having to replicate some wildly imaginative mockup that the designer created in a GUI is not always the holy grail of programming. For the small start-up, resources feel misspent when one of your highest paid developers wastes half a day messing around with CSS. Besides, shouldn’t the designer have control over the views? And in that case, shouldn’t the designer be willing to invest a little time into learning how to code?

“He’s the programmer, He knows all these complicated things about databases and stuff like that. He shouldn’t be wasting his time converting HTML into a template.” — Ryan Singer

In an interview from 2010, Ryan Singer talks about a fundamental point of change in the 37 Signals (now Basecamp) workflow. That change has to do with the way designers and developers work together at 37 Signals and the notion that segregating the two does not lead to optimal outcomes. As a product designer myself, I not only care about the visual and behavioural aspects of an implemented feature, I also care about the craftsmanship that went into it. I want to know if my design created any obstacles for the team. I want to empathize with my colleagues and ultimately improve and empower those around me.


Design branches have been part of my workflow for the past couple of years and are a strategy to help bridge the barriers of design and development. Simply put, design branches are a branch in version control that showcase both the aesthetics and interactions for a given feature. They differ from prototypes in the sense that they should always contain production ready HTML and CSS.

Let’s say Widget Corp wants to build feature X. A typical workflow for a designer might be as follows:

  1. Draw some low fidelity sketches to flush out some ideas.
  2. Start to think about the feature at a more granular level. Create higher fidelity mocks or maybe something interactive using a tool like InVision .
  3. Test and tweak designs if the feature requires it.
  4. Hand off your completed work to the developers.

Now that the designers job is done, the developer will eventually take over implementation of the feature. To fully understand the benefits of design branches, lets look at a familiar agile workflow in a ‘perfect world’ and compare that to what we more commonly see in the ‘real world’.

Figure 1. One Week Sprint ‘Perfect World’
Figure 2. One Week Sprint ‘Real World’

Realistically there could be many discrepancies between figure 1 and 2 but for now lets focus on two main differences.

Difference 1: In a perfect world, all user stories would be meticulously thought through by the design team. The requirements would be clear, the wireframes would be attached to the story and the developer might only have 1 or 2 questions before getting down to business. But In the real world, this is not always the case. Very often the developer finds an edge case or a user flow that has been over looked, which generally results in one of three scenarios:

  • The developer stops progress on the ticket and waits for the designer to come back with an updated solution.
  • The developer calls a designer over and they come up with an ad hoc solution.
  • The developer decides to implement a solution of their own.

All three scenarios result in some aspect of debt.

Difference 2: In a perfect world, developers would replicate mockups to pixel perfect precision. Again, this just isn’t the case. To the untrained eye, a lot of minor aesthetics go unnoticed. It’s not always easy to pick up on things like line height, white space, border size etc. Each minor design choice that goes unnoticed results in debt. These eventually begin to accumulate and influence the overall experience. Product Managers with a knack for design are generally pretty good at picking up on the details during UAT but many will still go unnoticed. As a designer, you generally won’t see the fruits of your labour until they reach staging or production. By that time, it’s too late to fix them.


It’s a tough pill to swallow as a designer knowing that the hard work you put into your mockups is not fully reflected in the application. So how do you as a designer make sure your overlooked work makes it into production? Well, there’s one surefire way and that involves building the designs yourself.

Instead of building high fidelity mockups let’s consider a new approach where the designer instead uses what I refer to as a design branch.

  1. Start with some low fidelity sketches to get a good understanding of the solution.
  2. Checkout a new Git branch. Try to follow the same naming conventions as the developers. A common naming convention includes the story type, description and ID. Replace the story type with “design”. For example if a story branch is “feature-2213-sharing-banner” your design branch would be “design-2213-sharing-banner”.
  3. Build all of your designs in code. Focus on writing production quality HTML & CSS. They key here is to not spend lots of time on things that will be built by developers. i.e. complex UI, models, controllers. It is however very important to show all of the interactions that are required in the ticket. If you need to use a special library or fake data to get your points across so be it.
  4. Push your code up. Try to do a good job of organizing your commits and squashing them when necessary. This will allow developers to cherry-pick the styles they need while leaving the poorly written dynamic stuff behind. If you’re not familiar with ‘squashing’ and ‘cherry-picking’ it’s not a big deal. Github does a pretty damn good job of showing diffs. Think of this as a nice to have.
  5. Instead of attaching wireframes and mockups to the story, simply add a reference to your branch. Do a good job of explaining any interactions that you may not have been able to replicate in code. For example, let’s say part of your design requires a dropdown. You’ve figured out how to toggle a single dropdown, but only one instance should be open at a time. That’s not a big deal. The important aspect is that you have provided the developer with all of the styles for the dropdown and maybe even the animations for how you would like it to enter and leave. You can now leave a comment on the story telling the dev that only one dropdown should be open at a time.


Design branches do a great job of getting designers and developers out of seclusion. Just as a design sprints aligns stakeholders and provide teams with a jumping off point, design branches do very much the same. By working in the same medium, I have seen improved code quality, shortened feedback loops and boosted dynamics within teams. Developers commonly have some of the best design suggestions. Collaborating through GitHub can prove to be even more beneficial than something like InVision.

When a developer checks out a design branch it is very clear as to what the interactions of the feature are intended to be. As a designer, building in code will make you think through all of the little edge cases that you might miss at a mockup level. Yes, fixing mistakes in code proves to be more costly but that’s why it’s important to heavily think through flows and interactions at low fidelity.

By continuing to design in code, you will become a better ‘design thinker’, trust me. Next time you go to design a new button, you will not only think about it’s appearance within the scope of the mockup but within the entirety of the application. How adding a new colour or font weight will affect other components. How it’s box shadow will appear on dark and light backgrounds. How it can be built in a reusable way.

Lastly, if I wasn’t convincing enough, a great article on the benefits of designing in code is ‘The fidelity curve’. A concept by Ryan Singer (can you tell I’m a fan-boy?). The fidelity curve is a comparison between confidence gained and time to build. In short, the realization is that for a straightforward UI, it doesn’t take much more time to build a feature in code then it does to build a high fidelity mockup.

The Fidelity Curve: How to weigh the costs and benefits of creating UI mockups – Signal v. Noise
The Fidelity Curve: How to weigh the costs and benefits of creating UI mockups Here at Basecamp we do a lot of paper…

Next Steps

Design branches are by no means full proof and are not required for every feature. Like everything, use your best judgement as to when to use them. Design branches really just boil down to a process for designing in the browser. With new frameworks coming out each day, sometimes writing production ready HTML & CSS is not always easy. ie React components. I plan on continuing to refine this process and writing a follow up with examples from my everyday work. Any feedback is much appreciated. Thank you Loki Meyburg for inspiring the concept.

Author: Lee Nelson

Collect by: