Designers and Developers. The beating heart of any web project. So often at odds with each other yet working together to produce experiences on the web that impact us all day by day.
When a designer and a developer who understand each other, who can collaborate and work effectively together there are few forces in digital technology that are more powerful. They are like a military unit marching forward in lock step producing the work of their lives.
On the other hand, designer and developers who can’t communicate are doomed to failure and mediocrity. Fighting, ignoring each other’s feedback, dismissing concerns about functionality and purpose. Developers seeing designers as merely colouring in. Designers looking at developers as socially awkward and lazy for not getting their design exactly right.
This can only lead to mediocre work, wasted budgets and all but certain failure for a project.
No one wants to be mediocre, no one wants a project to fail. The fake walls and silos we’ve put up around our skill sets need to come down. Driven by a need to “manage” a project and control the process we produced the waterfall model of production and pitted the designers against the developers in a never ending battle of “this is pointless” and “that button is two pixels two small”.
Designer and Developers share so much of what they do and who they are. Both groups are creative, driven, passionate and want to make work they can be proud of. By making them fight like this we weaken relationships, build barriers, introduce stress and judgement while demoralising teams and teams of people.
Neither Side Can See Whole of A Project
The fact is that both of their perspectives are necessary for success.
A designers eye for detail and consistency can make a company look professional and trustworthy, a developer’s coding ability and experience is required to turn the ideas into software things that people can use every day.
To really solve a problem a designer needs to go and be immersed, to think through the consequences for users, for the business and for the world, of their design and the strategy they produce. They collaborate with the business owners, with user testers and with others to get the information they need to make decisions. They need developers to be collaboration partners, to give them the information needed to make smart decisions for the project in an aspect that they don’t understand and can’t get all the information.
Developers love to standardise, leave it to a developer and everyone would communicate in the single most efficient way possible but everything would look the same. Instead of celebrating the differences between projects that make them truly unique, everything would be standardised away and the differences treated like bugs. Bugs to be squashed. This isn’t to be harsh on developers, it is a generalisation, but the greatest techniques and structures in development projects is the abstraction of repetition and replication.
Both Sides Have Different Expectations
Designers, design. Developers Develop. They, primarily, work with people who do the same. They don’t know what to expect from each other. Its very easy to develop a set of expectations about what is normal to know in a field and what might even seem like beginner information when you’ve been working for a while. I assure you this isn’t the case. We go into every situation with a set of expectations that will either be exceeded or missed, collaboration is no different. How often do we hear “Why did they not do this?” “Why would they go against best practise?”, “How could you not know that?”, “Everyone knows that you’re supposed to do it this way…”
There is something key for both sides to accept.
They know something you don’t. You know something they don’t.
You are in this job or role because you are an expert! You know lots of stuff that isn’t necessarily obvious to everyone else. Also, that your collaborators are experts in what they do, they have a range of knowledge, skills and insights you do not
We cannot talk to each other expecting our full range of knowledge and experience to be shared. We all have different skills and accepting that we might have to take the time to work together, educate and communicate together to make amazing work is something that we all have to learn.
Keep Everyone in the loop
It’s easy to focus on frustration when working together if there is no clear purpose for half of the team. Development often come at the end of a long chain of events and the devs may not have been present at the kickoff or during any project planning. It is completely understandable for someone to be frustrated when working on a project if they dont fully understand what its for.
In the course of their work a developer is going to make hundreds of tiny decisions about how a site works under the hood, what is worth putting more time into to make extendable and follow all the best rules vs what can get less effort. This means that the development team can miss the total point of the project. Not because they are stupid or lazy, but, because no one told them
Imagine you have someone approach an agency for a web design project, their primary motivator is that they want the site to be fast, that’s why they want a new site. The designers design a lovely new site but it has a few elements that take a while to construct. When the end of the project comes along and the site is handed off the new site is slower than the old one and the client is, understandably, disappointed.
If the developer had been involved earlier and made aware of what the major motivating factor for the project was. They could have pushed back on the inclusion of those other features, had more time available for performance optimisation and pointed out some design elements that are causing the site to load slowly, like using 15 different fonts and font weights, not an obvious performance pitfall but a real one.
In the end, getting everyone on the same page about a project right at the start
Don’t focus on tools
Tools are important but they can’t help you here. I hope you see that this is a mindset change inside your teams and a revision of your processes to enable the information exchange needed to build this kind of collaboration.
Your tools are going to be talking, listening, opportunities to educate, pairing designers and developers together to work side by side on a project. There is no quick fix here.
By all means, look for software tools that help communication, process and collaboration but they are not silver bullets here.
What Designs Can Do to Help
Bring Developers in Early
Getting their ideas and concerns up front is a great idea – they have strategic insight into most areas of what goes into a website and can enhance your ideas with their own. They can also inspire you with theirs.
Learn To Code
But only a little. You don’t have be a back end pro producing complex systems but learning enough to give you an understanding and to be able to communicate will help immensely when the need comes up
Be Willing To Teach Design
Teach your developers to see the design, why all that white space is important, why that shade of blue has been chosen, why you have chosen the typefaces and the typography you have. Your goal is not to turn a developer into a design but to help them understand your decisions and why they matter in this context
Give good bug reports
“The text is wrong” helps no one. Give a screenshot, say what it is currently and what is should be. Communicate why the text is wrong rather than just the fact that it is.
Document Your work
Help a team out? Be specific about what your text sizes are, why your fonts are, what the spacing it. You may be able to look at a PSD and see that information but a developer, especially a back-end developer, may not. Document this information and stop the endless back-and-forth between Photoshop and a code window.
What Developers Can Do To Help
Not to be left out developers can help with this as well.
Learn To See Design.
You don’t know why the spacing between things is important, the colouring of things, the crop on that image. Learn to see it, learn why it’s important. It’s more than just aesthetic. It’s systematic and you will get better at your work because of it.
Appreciate that Software isn’t the goal.
Code doesn’t exist for its own sake – it’s a tool that helps us reach another goal. Learn to appreciate what it means and how you help in project.
Ask Questions
You don’t know everything. Don’t try to pretend you do. There is something on every project you won’t understand a decision or a break from tradition or best practise. Ask for an explanation. Get the designer to justify their decision to you, if they can’t then gently push back and ask how it supports the overall goals of the project, If the designer can’t justify it to you, how can they justify it to the client?
