What are Mockups?

An introduction to mockups and how to use them to bring your designs a step closer to reality

A mockup is just a sketch that represents the way the site will look:

It's meant to take the least effort to give you the most useful look at what you're going to be building.
We live in a world where we need to move quickly and iterate on our ideas as flexibly as possible. Building mockups strikes the ideal balance between true-life representation of the end product and ease of modification. You can build a site mockup in just a few minutes using tools like Balsamiq, which is barely more time than it takes to sketch it out by hand.

Mockups are useful both for the creative phase of the project -- for instance when you're trying to figure out your user flows or the proper visual hierarchy -- and the production phase when they will represent the target product.

Making mockups a part of your creative and development process allows you to quickly and easily ideate and iterate on your site before you've invested in the actual coding process. You'll have something tangible to show clients or a helpful reference to work from when you start moving forward.
A small investment of time up front to learn this skill will save multiples of that in the future.

Fidelity
Mockups aren't some industry standard that you need to memorize and stick to -- there are as many different ways of mocking up sites as there are designers and developers in the world. That said, a common way of identifying the "roughness" of your mockups is by using the term "fidelity".
Fidelity is the measure of how close your mockup is to the end product. A low fidelity mockup is basically just a simple sketch:
A high fidelity mockup, like those done in photoshop, are basically pixel-perfect representations of the final site:

In our case we'll be straddling the line between the two, striving to build mockups which are accurate enough to build from but simple enough to produce quickly.

Wireframes vs Mockups vs Prototypes
It's worth clearing up another common point of confusion. People often use "wireframe" and "mockup" and "prototype" interchangeably but they represent different things.
•    A wireframe is really meant to be a structural representation of your site.
•    A mockup fleshes out the static visual look of the site (e.g. with more of the image and color details as well)
•    A prototype is specifically meant to show the user's interactions with this design (so it's no longer really static anymore)

Note that these definitions actually aren't directly related to fidelity -- you could have a really low fidelity prototype that just specifies key user interactions or a high fidelity wireframe that contains every element of the page.

In our case, we'll be blurring the lines between mockups and prototypes a bit -- most of what we produce and use will be static representations of the final product (classic mockup case) but we'll also be specifying the user's interactions with our design, which starts to take it a bit more into "prototype" territory.
The point here is not to get lost in terminology, but just do what works. You'll pick up the differences as you spend more time in the industry.

How We Use Mockups
One of the most enjoyable parts of producing websites is taking the idea from your head and seeing it come alive in front of you during the creative phase. With mockups, you get to do that incredibly quickly and you can iterate on new designs or flows with just a few clicks (instead of needing to change substantial portions of the markup or code on a production site).
Once the creative process has settled to the production process, the mockup represents your goal. It's very helpful to have something to refer back to when you're mucking around in the back-end and barely remember what exactly you're building.
Our high-level process for building sites goes something like this:

1.    Identify the users and their goals
2.    Mock up the site that fulfills those goals
3.    Break the mockup into discrete pieces of work ("stories")
4.    For each story, start with the mockup of its end result (e.g. the specific feature) and build the data infrastructure, back end, and front end necessary to actually produce it.
5.    Validate, refactor, and deliver.

So not only does the mockup give us the overall site direction and scope, but we break it into pieces and use those pieces to guide our development process.