Bridging the Void Between Designers and Developers

Some say that in the world of web content, designers are from Mars, developers are from Venus and never the twain shall meet.

Image credit: Science Photo Library, Flickr

When it comes to content creation, ‘web designers’ are responsible for the visual aspect, which includes the layout, colouring and typography of a web page. Meanwhile, ‘web developers’ take care of the non-design aspects – usually markup and code. I’ve lost count of the number of times I’ve heard developers complain that a design has been ‘made for print and not for web’, and designers grumble that a developer has butchered their typography. If your web team is set up with such a clear divide, it is no surprise that such frictions occur.

So, how best to bridge the void? This has been said many times, but communication is key to successful collaboration. As one of the front end developers at Distilled, I’d like to outline how we work with our designers to ensure smooth handovers between design and development.

Starting communication early

Right from the point of ideation, the Distilled designers and developers start a conversation about how the piece could potentially work, what technologies would be involved and what (if any) restraints these would put on the design team.

While putting together the wireframes, the designers often consult the developers on how the piece will act with different screen sizes, browsers and devices. This doesn’t mean that they make an individual design for every possible width and device, but that both teams are aware of how the piece should respond.

Communication should continue throughout the build too. If it is possible to share a link to a work in progress then do so – that way designers can give feedback (once the developer is happy to start this process!).

Setting clear briefs

When the initial design stage is complete, the designer will have a handover briefing with the developer where they talk over the typography, the interactive elements, the responsive elements and any graphics that are featured. Included in this handover process is an Illustrator file and an annotated RealtimeBoard ( which shows the design at various screen widths.

Annotated RealTimeBoard

An example of a Realtime board with annotations from the designer for the developer

Specific elements that make the front end developer’s job easier at this point include:

  • A list of all the fonts used in the piece and where to download them.

  • A list of the hex codes for all the colours used in the piece with a name for each (eg primary, secondary). These names can be used by the developer in their stylesheets and also when discussing changes with the designer rather than their less memorable hex values!

  • Clear labelling of widths, heights, padding and margins. Measuring these elements not only takes time but is also fairly easy to get wrong; clear annotations will make the build go much more smoothly.

  • Annotations on font sizes for headings and paragraphs (at all screen sizes).

Outlining jobs to be done

Decide on who will be supplying graphics – will the designer provide separate files with images or will the developer pull them from the Illustrator file themselves? If a sprite sheet is necessary, who will be supplying that and in what format? Deciding on naming conventions for files at this point is also helpful as renaming multiple files is an unnecessary irritation.

Sharing knowledge

The more everyone understands the technologies and processes that their colleagues use, the smoother the web development process will run. If your designers understand even just the basics of HTML and CSS then their designs will be structured in a way that makes them simpler to code, and they will organise their Illustrator/Photoshop files to make it easier for the developer to pull out the necessary images. Inversely, if the developers are comfortable with design theory and practice, they will be able to make decisions on the responsive layout of the piece and will be able to create their own assets from the layouts provided by the designers.

One of the things that I love, as a developer, is when our designers find out the newest CSS attributes because they want the text to have a particular look. Their typography expertise keeps me up to date with the newest technologies. Similarly, whenever I find a beautifully implemented bit of web design or UI (user interface), I’ll share it with my designers so they can see what is possible with modern development techniques.

There are lots of exciting new technologies available to designers and developers to make websites look and feel visually stunning.

Some elements to bear in mind are:

Webfonts - The available list of webfonts is growing daily, and developers can even create new web fonts, from fonts that they own. The days of having to use only the limited number of ‘web safe fonts’ are quickly becoming a distant memory, thank goodness!

SCSS/LESS - These CSS preprocessors allow developers to structure their stylesheets in a way that is much more readable to non-developers, and make introducing universal changes to styles much simpler.

CSS shapes - It is now possible to wrap text around complex shapes. Websites can finally move away from boring rectangular layouts and start bringing the slick look and feel of magazine editorials into online articles.

Ligatures, opentype numerals, orphaned and widowed word control - Web support for these is becoming more widespread, meaning that designers can get some really great looking typography. With all new web technologies, remember to check for their browser support.

Optimal image formats - Make sure that whichever team is creating the assets for the piece is using the optimal image format for the type of image, and that the file size is optimised for the web.

Use your web browser development tools! - These let you edit and restyle the website inside the browser on the fly. They’re a really helpful tool for both developers and designers. You can change font sizes and styles, colours, add and remove images and copy, move elements about the page, and check out how other developers have put together their code. The developer tools even let you see how long your site takes to load.  I use Chrome DevTools and highly recommend this tutorial for beginners.

It is worth bearing in mind that getting a website to exactly reflect a design is time consuming and nigh on impossible in every browser. So make sure that ‘essential’ and ‘nice to have’ design elements are decided upon in advance. Understanding the limitations of design for the web versus design for print is essential.

Fostering respect and trust

Both designing and developing requires a lot of skill and neither job is more simple or straightforward. Mutual respect between design and development teams will make working together and skill sharing much more pleasant. Knowing that your colleagues can accomplish their work correctly, without your input, is also invaluable. When you trust the people that you work with, you can focus on finishing your own tasks, gaining their trust in return.

No project is without its mishaps, and there will be inevitable breakdowns in your designer-developer relationships. There can be bad feelings, misunderstandings and poor communication, but without each other we wouldn’t be able to create the amazing, inspiring pieces that we do! So before you embark upon your next web project, find your developer/designer and let them know how awesome they are.

And over to you, reader. Got any advice on designer-developer relationships you’d like to share? Or any questions for me? I await your comments in the box below!

Get blog posts via email