Design tips for lowering front-end costs, part one: Deliverables

Here at Advomatic, we frequently get the chance to partner with really creative, disciplined, and talented design shops. Over the years, we’ve identified a few areas where we can be more helpful to them. We’ll try articulating the best ways to solve design problems which have an impact on the front-end development approach. Along with strategizing for design complexity early on, there’s always room for improvement on design deliverables. This week, let’s look at these common deliverables and what can make the front-end development process go smoother.

Style guide design deliverable exampleCreate a master style guide document that includes elements and design patterns that may appear

Having a master style guide or pattern library like Pattern Lab that shows all the baseline styles for HTML elements and other basic design patterns really helps front-enders hit the ground running. Developers won’t have to sift through a batch of comps and make decisions about which particular treatment is considered gospel.

At the minimum, a style guide should illustrate:

  • All common headers and text styles (showing the standardized font-size, font-weight, letter spacing, line height, etc…)
  • Form elements
  • Branding elements & colors
  • Buttons and other UI elements
  • Icons & categorization treatments
  • Navigation & menus (and how they appear differently at various screen sizes)

When is this document most useful?  If design work is happening concurrently while front-end work has already begun, having this document delivered first is best… even if it gets reworked and updated over the course of the design phase. Revised version(s) can be provided, and then the changes can be made on the front-end. When this document is delivered last, and front-end work has already begun, it is not nearly as useful. Try creating this document first, delivering to developers, and let it dictate page & component styles as the design phase proceeds.

Create as much vectorized art as possible

Logos, icons, and other graphic elements of the site (except photos, of course) should be vector so they look nice and crisp in our fancy high-resolution devices and screens! By delivering vector art and layers, we can export to SVG files that look great in browsers at any size or resolution.

Abide by a grid: keep major page elements aligned tightly to the columns, and be consistent

We request a grid be used for any design deliverables. It’s pretty much a standard practice in design shops we know and work with. Design that adheres to a grid allows front-enders to quickly build out areas of the page. Responsive front-end work can get tricky and time-intensive when things are positioned in odd places (that don’t align with grid columns). There are, of course, times you need to break free of the grid for design purposes. Keeping those situations to a bare minimum can help keep the complexity and cost of building down.

Deliver comps “mobile first”

A huge bonus is having mobile/small screen comps delivered before large/desktop screen comps. Because of the nature of writing responsive CSS with media queries, it helps to get all that mobile styling done first for many reasons. By doing that, many default aspects of the design (colors/typography) are already in place by the time we start tackling larger sizes/breakpoints of the site. This makes the process of scaling up the design go smoother.

Provide a document that describes non-comped behavior or effects

Sometimes we receive several comps that show various states, behavior, or functionality on a page. Simply “noting up” comps with descriptions of that stuff can save time for designer and front-enders. For example… hover states, how longer-than-comped text should wrap around an image, or how animated elements should behave. Even better, consider putting together a separate formal document that describes all edge cases and design-related functionality that happens on all pages and components of the site. This approach is usually more convenient than creating a bunch of extraneous comps that illustrate something that can be described through words.


Next week, we’ll continue with part 2 of this series, and take a look at ways to have the complexity of the site design limited in ways to bring improvements in your front-end workflow.