Bridging the gap between web design & development

One of the biggest challenges we face in the design and development process is the translation of visual ideas, from something we can present to the client to something that can also form the technical design spec for a developer to build from.

When we are building out the front end of a website we don’t really want to be thinking about design decisions, they need to largely be resolved before a project build begins. Whether the designer is external or integrated in our team the challenges are the same.

Web designers don’t need to be developers but they really do need to think like developers and have an understanding of how things knit together on the web. All to often we’ve inherited lovely ideas from designers that just aren’t practically achievable within a clients budget.

So how do we align the differences between designers and developers?

We’ve been focusing on best practice within design files and their preparation to come up with a few essential tips to help the translation process.

If you’re using a grid then use the grid

If there’s one commonality between designer and developer then it’s the grid. Designing on a grid creates a uniform layout and puts some rules in place that a developer can immediately translate into code. But all to often we have seen design files where good intentions are set aside and things start to drift off grid. From a designers point of view, if something doesn’t look quite right on the grid then solve the problem within the constraints of the grid, don’t just position elements arbitrarily where they look best, otherwise you’re passing the problem on to the developer who is less equipped to make a design decision.

Of course there are times where the rule book just needs to be thrown out and we are all for fluid layouts, but be realistic and how time consuming it can be for a developer to build lots of elements off grid.

Keep styles consistent

The worst offender here is the Button. It seems quite a simple task to design a generic button style to be used globally but then there are exceptions. What if the button is on a dark background? Or a perhaps a different style for a “Read more” button? Oh and another style for a “Read more” button on a dark background. Before you know it you can end up with a dozen different buttons across a project but are they really necessary.

We’ve seen examples where every instance of a button is different and it’s hard for a developer to interpret whether differences are intentional. It’s the same with text styles. A heading on one page which is 32px then on another page it’s 30px. There might be a temptation for a designer to make slight adjustments to text styles on a page by page basis to make the layout work and impress the client but it’s really bad practice and just doesn’t translate well.

Depending what software you’re using there should be a way of defining a styles or symbols that are preset. Make the most of these as they will help to keep things consistent.

Consistent relational spacing

Try to keep the spacing around elements consistent. Given the nature of responsive design this applies much more to the Y axis as the X is determined by the browser window. Again there is a twofold benefit here: keeping the visual language consistent is great for the user and also practical for the developer to build.

We quite often work with around 3 or 4 spacing values and rarely have a need for any additional unique values. For example a large heading might have 120px of spacing above and below, then the following paragraph or picture might have 60px below before the next element. You might then have a 30px gutter between a grid of images and 15px of padding on the bottom of every paragraph. Key lines might then sit at 7.5px below a subheading (7px or 8px in reality to avoid sub-pixel rendering issues).

There is no shortage of articles discussing the golden ration and spatial relationships in design so that’s a bit off topic, but restricting yourself to a few simple values and measures will help everyone.

Annotations

Wherever possible give some added commentary to vague areas with hidden layers or text positioned off the artboard to give both the client and the developer a idea of what’s in your mind. Particularly relevant for interactive or animated elements. If you see something happening on a particular event then make sure it’s explicitly defined on the file.

It’s difficult to put all of your thoughts into a design file and can be impractical in terms of available time, in which case it needs talking through, but there is nothing stopping you clearly defining hover states for buttons, active states for menu items and other basic functionality. Don’t leave it to the developer to fill the gaps otherwise you may just end up with default behaviours.

Account for inconsistent content

So you’ve got a rock solid visual for a blog section with placeholder content and the client loves it. Then the client starts to add some real content into the CMS and all of a sudden headlines start running onto two lines and teaser or excerpt content has different lengths or maybe non existent. Portrait images are uploaded for use in a landscape format and so on.

We’ve seen it too many times where a designer thinks in terms of “ideal” content which is not always a luxury clients can afford. It should be the responsibility of an online editor to curate or create content effectively to fit with the structure of the website but more-so it’s the responsibility of the designer to account for varied content in a CMS.

When we produce layouts for presentation to a client we intentionally put in a variety of placeholder content. Yes, we could make it look artificially better by forcing line breaks and using the same number of characters across text fields but it’s not a reality for client managed content.

Summary

We focus on designing projects with development best practices in mind and equally we build websites with design best practice in mind. This gives us a fighting chance of covering the grey area between designers and developers.

To take this further we rationalise all of our design visuals from a development perspective before presenting anything to a client to make sure we are setting realistic expectations.

We’ve refined our approach and the tools we use to limit our exposure to unaccounted for development technicalities which ultimately end up costing someone and leading to designers and developers passing the buck.

We’ve dedicated Rifle Build to offer specific development services to designers and agencies who don’t have in-house development capabilities.

Enough waffle.

Show me the work