Fog Creek

7 Tips for Better Developer-Designer Relations

Typical organizational groupings mean that designers and developers often find themselves in separate teams. Also, a common perception of the people in these roles are that they are different – developers are logical, analytical, left-brainers whilst designers are the creative, flexible, right-brainers. And whenever people are separated like this, it’s easy for the relationship to become adversarial. Pretty soon all you do is focus on the differences. They become those hippy-dippy designers with their strange and impossible requests. Or those vision-less, code monkeys. An ‘Us vs. Them’ mindset takes hold, leading to a break-down in communication, which gets borne out in poorer products.

But does it need to be like this? I mean, there’s a lot of common ground. Both have a keen eye for detail, solve problems in creative ways and often share a love of great tools and technology. What’s more, the theory around what you can do to overcome these issues is simple. You just improve communication, empathize with the other team, respect their contributions and build trust. Yet, actually achieving that can be tricky.

83 (1)

So, here’s seven practical things you can do to help designers and developers work better together:

1. Mind the Pet-Peeves

Developers:

  • Be Clear About What You Want

    Often it seems that designers are expected to be mind readers. The brief for designers can be little more than “go make this look good.” Just as a developer might ask for a requirements specification, a clear brief for a designer is also important. Be sure to provide examples of what you mean. These might just be links to how others have approached a similar thing or even a quick sketch.

  • Be Mindful of Design Constraints

    If you’re working with data, then supply real samples if possible. Knowing the data ranges you’re trapping in your code can be useful for designers to know too. Designers also need to know things like screen sizes and browser compatibility from the start.

  • Be Open About What’s Achievable

    Developers can be the gatekeepers of what gets implemented. A big idea can all too often be dismissed out of hand in the name of time or performance constraints. Often though there’s a compromise to be made, with some part of the original idea being possible. So staying open-minded and working with the designer to find that compromise is important.

    Designers:

  • Make Your Assets Easy to Work With

    Name different file versions so that the latest version or the one you want to be used is easily found. Maintain the layers in image assets, naming them usefully and grouping them whenever you can. Don’t forget to also remove any old and no longer needed layers and files. If possible, prepare the assets for use too – cut them up so that they can be used straight away.

  • List Out Key Details

    List out the names of fonts, text sizes and hex color codes used, along with the widths, heights, padding and margins you’re expecting. Doing this can be a real time-saver for developers.

With those pet peeves eradicated, you can start to focus on processes and ways of working.

2. Work Closely Together

This can be just having designers and developers sit next to or near each other. This helps encourage short, informal conversations that lead to more open and frequent communication. But this can also be applied remotely too with regular video chats and Instant Messenger or Group Chat. Either way, if you do this, then over time you’ll absorb knowledge about each others work.

3. Start Communication Early, Continue Regularly

64 (1) (1)
It’s best to start communication between the two teams as soon as possible into a project. If you build it into your process right from ideation, then there are no surprises that can cause problems later. So start off with designers and developers working together on how they can approach the project. Then continue the communication right throughout the build too. Look for opportunities to keep each other up to date on progress and developments. So, for example, when working on wireframes, designers can involve developers in deciding how to work with different screen sizes, devices, and browsers. Designers can share sketches, and likewise, developers can share links to works in progress. At all stages, bounce ideas off of each other, not just your own team, and break out onto white boards when you need to work through a problem.

4. Pair Designers and Developers

When the chance to work together doesn’t emerge itself, you should actively encourage it with designer-developer pairing. For example, as Cap Watkins recommended in our recent interview, designers and developers can work together on a design bug rotation. This is where designers and developers pair up to work through a list of design issues. This involves discussing the problems, deciding on solutions and fixing them together. By doing this, designers are given insight to the code and developers are exposed to design-related issues.

5. Open Up Design Critiques

Opening up design critiques to others is a great way of helping them to better understand design work. This is something we’ve started doing at Fog Creek. We’ve seen that by showing example work and then walking through the design rationale, non-designers can better appreciate design issues. What’s more, describing how you’ve considered implementation issues shows that you’re taking developer problems seriously.

6. Run Designer and Developer Placements

For example, Etsy runs an engineering placement program. This program aims to get employees with no technical knowledge to deploying simple code changes in a few hours. Spending time working with other teams, even for a short time, helps to foster cross-team communication. This can be taken further too, with embedded team members, so designers embedded in development teams and vice-versa. Trish Khoo explained how this works with embedded test specialists at Google, in an interview with us.

7. Learn about Design or Development

Knowing even a little about code will make you a better designer. It’ll help you to understand and resolve implementation issues that you would otherwise have run into later. Similarly, some understanding of the theory and processes involved in design work will enable you provide more useful feedback. Learning about design does not mean you have to be creating design assets. And the same goes for code too. But by at least knowing the terminology and key concepts, you’ll be able to have more meaningful conversations about design and code issues.

By thinking through and creating opportunities for designers and developers to work on issues together, you can encourage a closer and better working relationship.