Wireframes are one of the earliest steps of the design process. At M|B, they fall into the Information Architecture part of our process. Once the architecture for the entire site is defined (in a site map), the next step is to design the architecture for key pages or templates. This is what a wireframe is used for.

A wireframe is kind of like the blueprints for a building. It shows all the elements of the page, suggests how they should be organized and begins to talk about interactions or states of the page. They do not show the “look & feel”–they are just a gray-scale representation of what makes up the page. For example, a wireframe will show primary navigation, but not what that navigation will look like (buttons, tabs, a colored bar, something else?); a wireframe will identify where a hero image will go and the type of message it will communicate, but not show the actual picture or final text.

To relay this information, at M|B we use gray-scale drawings of lines, boxes, shapes and words. We then overlay annotations that further define the meaning of elements and the thinking behind their purpose, location, interactions, content and any other details that will help communicate to designers, developers and writers.

Each template of a site should have at least one wireframe–sometimes more if a page has multiple states. Wireframes can also be used to show the major steps of a flow. These help define what form elements, buttons and actionable items make up each step of the flow.

Wireframes are the building blocks that identify the pieces of content that need to be written, the modules of a page that the CMS will need and the elements of the page that the visual designers must account for.

At M|B, we believe a wireframe:

• stipulates the elements of a page.
• stipulates the types of information on a page.
• creates a baseline for layout of elements on a page.
• creates a baseline for relationships of elements to one another on a page.
• recommends interactions of elements on a page.

A wireframe doesn’t:

• define the color scheme and visual design of the site.
• identify what images will be used.
• require how mark-up will be written.
• define what words will be used.

How is a wireframe different from a prototype?

While a wireframe is a static view of a page or template, a prototype has some interaction–it changes. Wireframes can be used as prototypes in some situations. For example, paper prototypes are often a series of wireframes, presented in a specific order. Generally when we build a prototype, though, we’re looking for more advanced definition of interaction and flow–a “clickable” prototype. In this case, a prototype is electronic (we like to use ProtoShare) and shows interactions as a user clicks (or touches) and navigates about the prototype.

For heavily informational sites, we generally tend towards wireframes. For applications or flow-oriented  sites, prototypes usually communicate better.

How is a wireframe for a mobile site different?

It’s not! While a mobile wireframe will generally have less real estate than a desktop wireframe for communicating ideas or presenting forms, the concepts stay the same. A mobile wireframe communicates all the same things that a normal wireframe does.

We often create mobile and desktop wireframes side-by-side. The desktop wireframe shows the priority of elements and the general organization for a desktop experience while the mobile wireframe shows how things change in the mobile experience. Sometimes the only difference is organization (particularly when working with responsive design). Other times, the entire navigation or purpose of the site might change for a mobile user. Regardless, the concepts of what a wireframe does all remain the same.

What does a wireframe look like?

Generic Wireframe (.pdf, 45kb)