$(function() { $('a[href*=#]:not([href=#])').click(function() { if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) { var target = $(this.hash); target = target.length ? target : $('[name=' + this.hash.slice(1) +']'); if (target.length) { $('html,body').animate({ scrollTop: target.offset().top }, 2000); return false; } } }); });


The product structure is set; now we fill it in with a final, polished look.

Main Deliverable

Screen comps

BOonus main Deliverable

Style guide

Other Deliverables

Build guide, Design direction, Iconography, Design production

Now we know the overall product strategy. We know what screens and repeating modules (e.g. hero images, headers, callouts, etc.) we need. We can now apply our earlier strategic learning to design the final, polished look-and-feel of our product.

Design is more important than technology in most consumer applications.
— Dave McClure

We lean on the work done in the Dive phase to get a sense of the users (e.g. Are they young or old? Urban or suburban?) and the competitors (e.g. Do competitors tend toward dense content or lots of whitespace? Organic or geometric imagery? Modern or outdated design standards?). From this, we begin to develop the aesthetic of the product.

We work in Photoshop or Sketch to hone the look and feel. We add specificity, address unique cases, and globalize standard elements. As always, we aim to work as efficiently as possible by starting broad. We like to start with a Design direction step before applying the agreed-upon design to the multitude of screens in the project.

Most generally, the design should:
› Enhance the brand
› Build trust in users
› Clarify the intended experience
› Be consistent, clear, precise, intentional

We carefully push the envelope, but we always keep in mind what is possible – and ideally straightforward – in HTML. Our design work is for naught if it can’t be faithfully realized.

To that end, we work as closely as possible with our developer partners. We want them to be a part of the design process. Great developers contribute heartily to the design, often suggesting treatments they’ve experimented with (or want to). They help us remain systematic and properly restrained, keeping us aware of the effort involved in building different design solutions.

The house metaphor

In the last phase, blueprints (in the world of construction) made a straightforward comparison to wireframes (in our world of digital production).

The comparison here is nearly as clear. A graphic designer figures out what a digital product will look like much like an interior designer figures out what a physical space will look like.

An interior designer works with the architect. Architecture decisions will constrain (or  inspire) the interior designer’s work, but she can do a lot within those constraints. For example, the arrangement of furniture in a room can alter the way people flow through it, or where their attention is drawn.

There are also, of course, the more superficial yet still vital and impactful decisions about things like materials (Wallpaper or paint? Wood or metal?), color, texture, and so on.

Main deliverable
Screen comps

In Draft we wireframed the screens and developed a high-level design direction with mood boards. We can now move into screen comps, wherein we'll apply that design direction to the screens we've wireframed. These screen comps show the screens in their final, full fidelity.

This is the first time we're seeing the screens the way users will see them. It's often tempting to start making changes to the screens, second-guessing foundational decisions made in earlier phases. This is extremely time-consuming at this point since we're now working at full fidelity. It's much faster to redo a sketch than a final painting; that's why we sketch first.

We should approach changes at this stage cautiously. Sometimes they're worth it, but often we're better served trusting our earlier choices and revisiting the decision post-launch (with data!).

Bonus main deliverable
Style guide

It is crucial that we deliver a detailed style guide made specifically for the developers and internal teams to follow when creating new pages and collateral.

In it, we address specific design tactics (color values, pixel sizing values, etc.). We also try to go further and explain their underlying strategies in color, typography, layout, button and form design, and more.

Without a style guide, developers won't know how to treat any element that wasn't explicitly designed. They also won't know the logic behind the treatment and placement of design elements. For instance, as a screen resizes they won't know how we intend its contents to reposition

Other deliverables

Build guide

A thorough style guide can massively improve the product's overall development efficiency. In some situations, the most streamlined approach is to provide the developers a limited set of wireframes along with a more thorough style guide, which we’d call a "build guide”.

This build guide explains how to treat the pages drafted in the wireframes. It gets into more detail about spacing, grid systems, placement logic, etc.

We like to also include a few fully designed screens, even in this streamlined approach. They illustrate how the build guide is applied. We’ll often “spec up” one or more of these examples to illustrate details.

Design direction

This is another tactic we use to try to improve efficiency and keep costs down.

For many projects, before designing a pile of screens or focusing on the nitty-gritty details of the design, we’ll do a quick, cursory exploration of 1-3 design directions. We choose one (or, rarely, two) representative screens and explore different applications of the design styles described in the Mood boards earlier. In the absence of Mood boards, we'll develop design directions now from scratch.

Seeing the designs applied to real screens can give them the necessary realism to help the team choose a single direction. Once we agree on a design direction, we'll refine it further before treating the multitude of individual screen templates outlined in the wireframe phase.


Icons are often used to support the design and communicate simple ideas to the user in a visual manner.

Iconography is – when done right – the Esperanto of the digital world. Icons serve as recognizable cross-cultural, language-agnostic signposts throughout your product.

They can concisely communicate a concept that might otherwise require many words (and therefore a lot of space and cognitive load). Users will often recognize icons from previous experience (e.g. a left arrow in the top-left corner means "go back to the previous screen"). They will quickly learn to recognize a small set of new icons specific to your application.

In an era of shrinking – and diverse – screens, icons can be a reliable way of communicating more in less space.

There's a lot to keep in mind as we develop an iconographic language for a particular application. It has to fit the aesthetic of the product and its target audience. We have to keep cultural norms in mind (Is a floppy disk still the best representation of "save"? Do these symbols mean to the people around the world what we assume here in the US?). Are the visual metaphors too obtuse? Are we sure that text wouldn't be better? Do the various icons work together as a family? Are they additive to the brand and experience?

We start by figuring out an aesthetic direction for our product’s iconography. Then, for most projects we’ll maximize our efficiency by using existing libraries to source individual icons, and then tailor the icons as needed to match the overall aesthetic of the site.

On the technical side, we want our treasured icons to look as beautiful as possible in your product, and reliably so. Depending on our platform, we might be able to use a vector format (SVG or icon fonts) to present the icons with ultimate clarity on any screen. Or we might resort to a set of rasterized assets (usually PNG).

Occasionally, a product will warrant the very significant effort involved in creating a custom icon set. This is a major effort. Each icon represents a concept to research. Then we go through many iterations to craft an image that is simple, recognizable, global, meaningful, and technically feasible.

Design production

When the design is complete (reviewed, iterated, and approved), we’re ready to hand it over to developers to build it. The style/build guide helps with this transition, and our continued presence fills the gaps.

We also generally break out the individual design assets necessary to build the design. These are elements like photos, icons, and shapes.

We’ll produce these assets in the appropriate format for the content and the platform. Icons generally work best as transparency-supporting PNGs, though web sites also support vector icon fonts or SVGs; iOS supports PDF but with issues, so we usually supply a variety of resolutions of PNGs. Photographic images generally compress best as JPGs.