Maintaining Harmony Between Designers and Developers

More and more we are beginning to see designers learning code and coders learning design. Creating a beautiful hybrid of designer / developer. However, discovering an individual with a passion and understanding of both design and code is rare. So, until the days arise where the hybrid take over, designers and developers need to learn to work together.

I am a designer at Code Wizards, and I am going to share some of my observations and experiences. I would like to take this opportunity to explain that I am the only designer and my colleagues (all techies) affectionately call me “Crayons” (I actually respond to this now and often sign my name as “Crayons”…but never actually in crayon…in case you were wondering) and they refer to my job as simply “colouring-in”. However, I shall rise above it and be nothing but professional and in no way shall I use this blog to take cheap shots at my treasured, techie colleagues.

 

Effectively Communicating with Nerds

I have discovered they do not appreciate being called nerds. Try and avoid this. Even if you witness a techie wafting around the office in a tailor-made blazer, with specially embossed patches on which represent the magic the gathering card game that they proudly play. Even in this extreme (and sadly, very true) scenario, show restraint. It will benefit your working relationship in the long term.

 

"Communicate in a way that both parties understand"

 

Techies, cut the jargon and simplify it. Only other techies understand you so please dumb it down. You don’t need to carry a set of glove puppets with you to assist your explanations (personally, that would get my undivided attention) but make sure you adapt accordingly to your colleagues.

Designers, cut the fluff. Techies don’t want to hear about the emotion you’re trying to convey or clever implementations of brand. Save that enthusiasm for the client. Sound out techies on your designs / prototypes prior to approaching clients and be open to their ideas and solutions.

Techies and Designers, demonstrate with examples where ever possible. It’s so much easier to show people how something looks or works rather than explain. This will really help ensure everyone is on the same page from the start.

When starting a new project, it’s vital to speak to developers and get their opinions on functionality. The design process is all about collaboration and developers have vast knowledge and valuable insight, making them integral to this process. So, it’s a win-win situation really, get the techies involved early on and build great relationships and a great product.

 

Don’t Create Stupid Designs

In the past I have been guilty of skipping off, hand-in-hand with clients to imagination land; a magical place where any design feature or function is probable and most definitely possible. Techies have then been burdened with the task of marching me back to harsh reality whilst verbally hitting me repeatedly with the technical constraints that my design exhibits. My advice here would be never wonder off in imagination land without being accompanied by a techie to guide you.

Getting a design signed off by a client and later discovering that technically it will function or look differently than intended reflects badly on the entire team. This is completely avoidable by ensuring the designer regularly updates their progress to the developer.

If regular communication between designer and developer is a problem (e.g. other work commitments, etc) then the absolute minimum the designer should be delivering is up-to-date annotation on their work which details exactly how they would expect their design to function. Don’t assume everyone will automatically know and waste their time.

 

The User is Always Right

Techies and non-techies interact with design very differently. Things that are obvious to a techie really aren’t to non-techies. So, requests to move text by a couple of pixels may seem tedious however, please trust our knowledge of how users will interact with the product.

 

"Techies and non-techies interact with design very differently"

 

Good design is intentional and typically adheres to restrictive company brand guidelines. So, there is reason why things appear the way they do, and they should not be considered minor or cosmetic. Developers should be open to user experience ideas from designers and not dismiss ideas with “users should know” or “users are stupid”. Ultimately, users will determine if the product is successful or not so understanding the human needs should always be paramount.

 

There’s no ‘I’ in Team

Never forget that we’ve got a shared goal, we are both solving problems; functionally and visually. Have respect for each other’s work (whether you understand it or not) and be considerate with each other’s time.

 

"Communication and empathy are key in building relationships and successful products"

 

• Take time to talk.

• Take time to help.

• Take time to mock – nerds are pure comedy gold!

 

I realise that by adding this final point that it contradicts the whole “have empathy” vibe this blog was going for. However, understanding what brings harmony to a workplace and actually doing what brings harmony to a workplace are two very different things!