Designers and developers should work together. We know this. They should be partners in production. But they aren’t. Despite us knowing better, our designers and developers fail to work together. And it isn’t their fault.

Our design and development departments are not made to work together. Our design processes don’t allow for this level of teamwork.

We talk about changing our process, but we don’t change it. It’s too hard. We talk about changing the way we structure our teams. Instead of large functional teams, let’s have smaller product teams with mixed functions. Now back to functional teams. Now based around stories! This doesn’t work either.

The problem with a functional structure is that designers and developers don’t work together. On the flip side, with smaller teams, we see a splintering of the design language. Same with the development process and tool chain.

And this is the first time we mention the tool chain. The set of tools we have at our disposal to work with. We are so focused on the process, that we forget that process is useless when not followed. And people suck at following process. We are so focused on the structure of our teams that we forget how culture works. And what fragmenting of our teams do to culture. Hint; it will fragment the culture.

Neither process, nor structure, are good levers to turn on their own. Or even together. Because neither change makes it easier for people to do the right thing. What we expect of them. To work together. Only when our tools reflect our process is it easier for us to do the right thing.

Frameworks get a bad rap in the web community. They deserve it. Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.

The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.

Finding the right tool is not what I am advocating for. Making it is.

Your tools should feel right to work with. It should feel like your team. Like your product. Your brand. You shouldn’t have to persuade it to get what you want. Your tools should come from your work. Your “real” work and soon it will be where the “real” work happens.

Your tools should be a collaboration between the design and development teams. The design language should evolve there. The development tools should evolve there. It should be the ground bed of your work.

On the face of it, I’m talking about making a pattern library. Built from the same tools that you use to do the “real” work. But I’m not talking about just making a pattern library. Instead, cultivate a set of tools that you can nurture and evolve. A garden bed you can work in, not just present from. From which your real work thrives and grows. Not just a library which people can visit every now and then to peruse a button collection, but where the button is cultivated.

When your teams have easy access to the right tools. Tools that will make it easier for them to use the right button. To pick up the right font size. To inherit changes to your form design language. Then they will.

If this garden bed is an open place that everyone can work in. A community garden instead of a protected and isolated botanical garden. Then that is where they will work. Instead of cultivating their own little gardens. Where they try to match the latest bloom in the 2016 Botanical Garden catalogue. They will work in the community garden. Together.

Up Next: Not just pattern libraries

I made the case that custom tools leads to effective designer and developer collaboration. I also made the point that I’m not talking about just pattern libraries. Let me explain why »