Skip to main content
Hero Background Image

Designer to Developer: How to Go from Paper to Style Guide

September 22, 2018

Ever wonder how websites go from initial design to code? What steps and tools are involved? What are the common pitfalls and how can you avoid them? In this blog post, I will recap the process our designers and front-end developers take to when creating a new website design for our clients. Hopefully, this will give you a little more insight into Mediacurrent’s methodology and in turn help you develop a more robust workflow of your own.

Build the Foundation

Before design even begins, there are a few key items to set the project up for success:

  • Track tasks
  • File sharing
  • Establish common nomenclature

Track Tasks

Choose tools to track progress on tasks. This is generally a task for the Project Manager, but it is important to set up a place for the whole team to track progress, share notes and alert other team members of potential issues. We primarily use JIRA for tracking progress on tasks.

File Sharing

Start a shared space where designers, front-end developers, and project managers can see the design, assets and updates. There are a number of tools like Dropbox or Google Drive that are ideal for this.

File structure is also important. In the shared space it might make sense to have subfolders for things like:

  • Sketches
  • Wireframes
  • Presentation docs
  • Design

Establish Common Nomenclature

Discovery is a great time to name things. A key part of communicating effectively as a team is to use the same terminology. Use agreed upon nomenclature the team and client can reference. The earlier in the process the better, especially when you are in discussions with the client.

Initial Design Phase

Effective design workflow during the initial design phase includes:

  • Open communication
  • Create component lists
  • Component breakpoints


Open Communication

It is important to name pages and components as early as possible, ideally during the wireframing stage - but often designs change, even after client approval. Be sure to have a way for everyone to know of the changes. We often use dates or version numbers on our files, to indicate which files are the most recent.

Create Component Lists

Keep a running list of assets and sizes for each component. It is easier to make this list during the design phase, then to have to go back and try and remember it all. Provide detailed specifications to the front-end developer up-front, so that they have something to work off of from day one.

Component Breakpoints

Wireframes can be an essential tool to further discussion about the behavior of each component at the different breakpoints you are targeting. If you have the time/budget, be sure to include designs not just wires. Even doing this for one or two pages can help the front-end developer tremendously.

Design Handoff

While working on the design there are a few things every designer needs to keep in mind:

  • Design specifications
  • Component features
  • Know your assignments

header demo

Design Specifications

Provide specifications that the front-end developer can use to build components. The more detail you provide to the front-end developer early on, the smoother the process will go and the fewer questions you will get later on. One thing to keep in mind is that your specifications may need to change at different breakpoints. Providing structure is great, but you need to be flexible as the design is translated into code.

Component Features

Communicate about the component features. One thing to consider when handing off design is that flat design files do not address everything. Be prepared to do a write-up or have a meeting to discuss the features of each component that might not be obvious from just the design files (ex. fixed site header section).

Know your Assignments

Know your assignments when it comes to asset creation. Who is responsible for creating the visual assets for the site? It could be the front-end developer or the designer. In some cases, especially with branded assets, the client may be responsible for deliverables. The important thing is to assign responsibility for these tasks up front.

Component Driven Development

Some key advantages of using a style guide as a design tool include:

  • Manageable components
  • Less development time
  • Easy to share

Component Driven Development

Manageable Components

Much like building a house out of legos, where you build the foundation first, then add walls, windows, and a roof, you use a style guide to build a website piece by piece. By thinking of the design as components (or pieces) it is less overwhelming when you are developing. With a style guide, you are essentially reverse engineering the design.

Less Development Time

Another great thing about style guides is they make the development process faster and easier. You can even recycle pieces of old components to help build new components.

As a bonus, when we build style guides for Drupal 8, the Twig templates can be used directly on the theme layer. The style guide markup essentially becomes a single source of truth for the final theme.

Easy to share

Clients love style guides because they get to see the design in action, not just theory. The style guide can be a useful tool for finding design issues, testing the responsiveness of a component, and identifying how all the components work together on the site.

Design Adjustments

While the initial design phase is complete, the job of a designer is not. This might mean reviewing the style guide build, answering a front-end developer’s questions as they arise or even identifying components that were not addressed in the design phase. Style guides are useful for design, in that they can be used for:

  • Quick changes
  • Testing responsive designs
  • Adding new features

Component Driven Development Page

Quick Changes

In website design, the designer cannot anticipate how a component or page will look in all scenarios on all devices. The more visibility the designer has into the components as they are being built, the better. There are always going to be gaps. Coding a design out in a style guide allows for quicker changes than on a live website.

Test Responsive Designs

In addition, responsive designs need to be tested in the real world. Since a style guide is actual code, the components can be tested in different browsers and across different devices before the website goes live.

Adding New Features

Further down the road, the client may request new features. Again, the style guide could prove handy to identify the building blocks that are needed to create the new feature, without disrupting the live version of the website.


  1. Build a Foundation - based on communication using tools like JIRA and google docs
  2. Initial Design Phase - Share designs and assets early and often, making sure all team members are on the same page. Try to predict development issues that may come up
  3. Design handoff - Establish rules, be flexible and communicate the design functionality
  4. Use Style Guides - break your design into manageable pieces that are flexible, reusable, and client friendly
  5. Design Adjustments - there will always be change! Changes happen as a site grows, so be flexible

Related Insights