I’ve been a web developer for a few years now, mainly working at an agency, but with some freelance experience too. Generally this has meant the projects I work on will usually be alongside a designer, a situation which I’m sure many people are familiar with. This designer/developer relationship will therefore form the basis of their work together and I believe to produce great work you need a great working relationship. For me personally it’s been a bit of a love/hate experience and I’d like to share some of those experiences here and look at how it can be made into a much more enjoyable partnership for both roles.

From my experiences I’m yet to work with many designers who know that much, if anything, about coding. And for the most part I’m terrible at designing! However I’m not here to say that designers should learn code and developers should learn to design… In my opinion it’s each to their own. If you want to learn another discipline that’s great and no doubt it will help with your work and your understanding of the wider picture. I’ve worked on teams though, where people are either out-and-out designers or developers and they are still extremely successful, in that situation it’s been because of a strong collaboration between the pair that makes the team successful. Unfortunately that’s not always the case and sometimes there can be disagreement, conflict and ill feelings towards one another. I’d like to look at how we can prevent things like that from happening and create a relationship which leads to great work and a good feeling between both designer and developer.

I love my job

Put simply, I love my job! I’m a terrible designer, but when given a flat design I can turn that into a masterpiece of code – well I like to think so anyway – and I really enjoy it. I think if I were to design as well as code I wouldn’t be able to produce anything close to what I do now working alongside a designer. Having someone to work alongside and bounce ideas off is fantastic, as great as it feels to produce a brilliant piece of individual work, there no feeling like working with someone, being inspired by their ideas and having them respond excitedly to something you’re done.

And I love the challenge! If I were to design things for myself I don’t think I would be able to generate freedom from the code, I would design things knowing that I could code them easily or similar to something I’ve already seen. With a designer who doesn’t work with code they’re not bound as much by those contraints, they can design something which they think will look and work great and be as creative in that process as possible and it’s my job to work out how to turn that into code, and that’s where I get to have fun.

The not so good bits, and how easy they are to fix

Although the designer/developer relationship can be amazing and lead to some fantastic results, there are some things that can interrupt that creative process and cause the relationship to sour. There may be times where a designer or developer – whether internally or openly – believes that their discipline is superior and should be considered more important in the process, which is absolute rubbish. But I think Cassie McDaniel put this a little more eloquently in her post on the subject “Copy, art, typography — and technology — are the bones of a project, where design and development are the joints and skin that connect and hold together the parts.”

So putting aside egos, there are some common circumstances which we may come across through the course of a working relationship that are going to cause issues in the final outcome and maybe damage the relationship for further projects. One positive I mentioned earlier, that designers who aren’t that knowledgeable about code are more free from the constraints a developer might feel, can sometimes be a downside too. At times designers I’ve worked with at least – I’m sure that it’s not just me – have sold concepts to a client which, that when it comes time to build aren’t as simple as the designer thought and have either been under-sold or not given the necessary time to complete. This can be easily solved simply by communication, just speaking to the developer about the proposed solution before the client is sold the concept can mean it can be adjusted to work better for the clients budget or the client can be made aware of possible extra time/money needed for a solution which is best suited to them.

Developers can also be a pain when they choose to speak in too much technical detail about what they want to do or are doing on a project. Learn to talk more human language, just because you know exactly what you mean, it doesn’t mean the everyone else will – including the designer who needs to understand. Explain things clearly and easily and you’ll have a much better chance of getting the idea accross or comments on the design understood so something can actually be done about it.

Both parties need to stay up to date as well, developments in the industry, new ideas, tools and techniques. I probably don’t have to tell that to people reading this post or who saw this talk because clearly you’re already doing that. But what about the others in your office, is the developer you work with here as well, or are they back in the office because they couldn’t afford to come or don’t think they gain that much from conferences. If that’s the case it’s then your job to go back to them with all of these new fantastic ideas that you’ve picked up and expose them to it. After Reasons to be Creative I’m planning on going back into the office and doing a short talk to tell people about what I’ve learned there so they can take away some of the things I have.

Work more closely as a team

The biggest issue I think I have though is when a designer/developer relationship just isn’t that at all, when it turns into a conveyor belt process where things are just handed on from one person to the next and people have no involvement in anything outside their own discipline. This isn’t just bad practice but it’s extremely detrimental to the working relationship and can lead to people feeling completely removed from the project as a whole, resenting the work, and other members of the team. The most effective way to solve this is to include everyone in the process right from the start, having developers in meetings earlier and even with the client can lead to better results and sometimes more creative ideas, as developers know how to bend the technology to solve certain problems, something a designer might not have the technical know-how for. Throughout the process as well I think it’s important that both the designer and developer remain in touch with each other, talking about what’s going on both in design and development, it means we have to make ourselves available to each other and to willingly engage at all stages of the project. If there are problems discuss them openly and don’t be snarky, learn to give better critique and how to take criticism openly.

Another possible solution is to look at your process as a whole, a lot of people are still working to a waterfall like process where maybe now we could be thinking more agile. Working closely together to produce something quickly and iteratively. With the move into a more responsive web as well this can only be a good thing, otherwise it could lead to designers producing multiple versions of each page design when a conversation with a developer or working to create it in the browser as soon as possible would be much more appropriate. For an example you could take a look at Andy Clarke’s recent case study of the agile process he used when rebuilding the new responsive ISO website.

Why should we bother

Now what I’ve said is great in theory of course, but it may mean a lot of work for some companies, breaking their current process or some might think, it’s all well and good but when you’re trying to earn money there’s time to worry about relationships. So let me just give you a few reasons why I think this is important.

Getting a developer involved earlier in the process and working more closely as a team throughout the project can lead to people feeling more compassion for the project. A developer understanding why a design decision has been made because they’ve been involved in the meetings with the client that explained them. Or the designer having a developer there to help with a possible solution to give them technical advice they need at the right time may help them avoid going back over the design again after they’ve already put a lot of work into it.

If you think of the designer/developer relationship in terms of the partnership between driver and co-driver in a rally team. Both have their own speciality, both would be useless without the other. If they don’t have a good working relationship, communicate well and use each other to do the best job possible they’re not going to win anything. They have their individual jobs to do and they prepare and work on them a little separately I’m sure, but when it comes to the race, they’re side by side working together to get the best time.

And if they don’t work well together, there’s inevitably going to be a crash at some point!

Hug it out

The relationship between designer and developer can be irritating at times, there can be bad feelings, poor communication or none at all. But without each other we wouldn’t be able to create the amazing, inspiring websites we do and have fun in the process. We work best as a team when we complement each other and work towards a similar goal, so before you go into your next project, find the developer/designer you’re working with, and hug it out!