Inspiration

How Designers Should Work With Developers

We’re in this together! So, how can we work together?

Aerial view of hands working with computer laptop at the office by Rawpixel

Even though clients might have a hard time differentiating the roles of people working in the web industry, there’s often a chasm that forms between design and development teams. Sometimes compared to the relationship between architects and building engineers, web designers and developers can find it difficult to stay on the same page. Both parties might think that the other doesn’t understand where they’re coming from, that the developer isn’t paying attention to detail and that the designer is only caring about making things look pretty.

This became obvious to me when I moved from graphic design into web development a while back. After years of being frustrated with programmers constantly finding technical limitations that would block elements of my design, it was now me experiencing designers approving client ideas without checking with me to see if it was possible, first.

It made me furious, and I began to wonder if there was a way for us to work together from the start, rather than treating the design and development processes as completely separate parts of the process.

Communication

Two smiling friends sitting by the table in kitchen while drinking wine and looking at the tablet computer by vadymvdrobot

Surprise, surprise, there is. And it all starts with a bottle of wine, and a terms and conditions list.

The bottom line of collaborating on a website is to understand you need both designers and developers to build a website. You can’t create something great alone – you need each other.

Understanding this is the key to opening the door to a great relationship. And once you’ve established this shared thinking, you need to have a conversation to define what each site needs to get this project done.

Does the web developer need to have discussions with the clients directly from the start alongside the designer? What timeframe does each party need? What are the technical possibilities? Don’t be afraid to be upfront with each other or the client about if there are limitations, or if more research needs to be done in order for you to give an answer.

Developers often find that being honest with the client and designer about the fact that you actually don’t know everything about the web opens up the possibility of them giving you time for research and testing new things before you exclude their technical experimentations completely.

You want flying pigs on your website? Sure! I’ve never done that before but let me look into it.

Sometimes developers can get really immersed in their coding and forget about who they are actually developing the site for. It’s just so exciting to try out the latest CSS effects on the market and solve complex programming problems. This is why it’s important that they do get to meet the client and talk about their needs.

And the same goes for designers being unaware of the entire website build phase. This involves cross-browser and device testing, bug-fixing and problem solving. If you’re a designer and you haven’t heard of these terms before, it’s time to look them up.

Make sure that all of this is communicated early on so that time is set aside for both the testing and the discussions. Having covered all of these areas, there is less risk for the client changing the design when it’s been coded or the team having to tell the client that something can’t be done, only after you told them the opposite.

Happy Designer + Happy Developer = Happy Client

Preparing design files

Web Design Template Copy Space Concept by Rawpixel

Even if the design files are prepared by the web or UI designer, the developer also has a responsibility to make sure they meet the website expectations. In order to do so there are a few things to consider from both parties. The first is to discuss which program (photoshop, illustrator, etc) and format the designer prefers to use for the design stage as well as how to prepare the assets. The second is the style guide.

Style Guide

After working with the same designer for a few years, the teams developed a style guide that worked as a middle language between the design and development team. This particularly helped when it came to setting up the typographic aspects of the website. The following things were always included in the style guide:

Typography

Designers: it’s important to remember that the website is built on a maximum of six heading styles. Each typographic aspect of the site needs to fit these styles. For example, if you had a large bold heading on the front page with the size of 20px and 23px line spacing, this will become heading 1 and will most likely be used on other pages of the site as well. Make sure that all pages have similar styles for consistency and don’t create more than six different styles.

The same goes for the paragraph style. If there is a paragraph style on the website, double-check that it has the same size and line spacing on every page of the site. The developer will code the exact sizes that you have provided them with, despite what it might look like once it’s up on the web.


Developers: It is recommended to create all the heading and paragraph styles, displaying them on one page of the website and asking the designer if they are happy with the results before continuing with the rest of the site. I’ve had a lot of experiences of building a whole website based on the design only to realise that the designer wasn’t happy with the font styling once they saw it live.

Colors

Designers: you know when you hand over a style guide to a client for their identity system and they add new colours as well as ignore the spacing requirements for the logo? You don’t want that to happen with the developer as well. The best way to avoid it is to create a style guide with the exact colours that you want to use for the website and stick with them, just like you would for a print project. Then make sure you talk to the developer about the importance of only using the colours provided. This includes colours for smaller elements such as buttons, input fields and fonts.

Developers: If you’re creating your stylesheet in SASS or LESS, you can easily create variables for the recurring colours you want to use. Use this SASS guide or this LESS guide to name the colors properly.

If not, you can follow the designer recommendations above and stick to the colours you were provided with as well as checking with the designer that they are happy with the results during the early stages of the website development.

Margins & Padding

Designers: this is a simple reminder to keep the margins and paddings in mind but also to keep them consistent on each page of the site. If there is a header image on the front page but not on the other pages, using the same margins and paddings will make it easier for the user to recognize the positioning of the menu to navigate around the site.

Developers: create a reset CSS stylesheet based on the designer’s guidelines and make sure it matches up on each page. If the dimensions look odd once coded, discuss this with designers straight away before you continue the coding.

Extras

Designer: there are a few things that sometimes get left behind by the designer until the website is built and they realise that there is a lot more to it than just the ordinary website structure. These design elements should always be included in a website design:

  • Dropdown menus
  • Link/button hover states (colour and styling)
  • 404 page
  • Search page
  • Archive page
  • Tooltips
  • Form fields (name input, textarea, email input, button etc)
  • Responsive design of each page

Developer: your job is to remind the designer of these things in the beginning of the project and not to design them yourself at the end.

Remember that you are on the same team

Designer & Developer: Lastly, it’s really important to understand where the design changes are coming from and to not take it personally. Try to get as much work done as possible in the design phase to minimise the changes in the coding phase since it’s harder to change the code than the design. And remember, you’re in this together!

If you liked that, you'll love this


Nina Mujdzic

About the Author Nina Mujdzic

Nina Mujdzic is a front-end developer that writes about the latest trends on web design and development with a special interest in WordPress. You can follow her on Instagram @neendreams_.