Those “boring” black and white boxes are the base of your awesome website.
Through our experience designing and developing websites we have come up with a solid process that begins with the Information Architecture stage (you can read more what the whole process entails here). Wireframes are a key part of this process, but they always seem to be the most difficult piece to explain and translate to our clients. How could a black and white page with tons on boxes and no content possibly turn into a well designed and impactful website?
The simplest analogy is that of building a house. When you build a new house, you create a blueprint: you decide on a number of rooms, the locations of the bathrooms, and minutiae like the placement of the laundry hookup. All of the “bones” of the house need to be established before any construction can begin. The placement of the kitchen will effect the foundation, and plumbing needs to be mapped before you get to any of the pretty stuff like cabinets and countertops. The necessity of a blueprint and prior planning are well understood with regard to building a house, right? Well, same (to an analogous extent) goes for a website! We need all of the basic information and structure in place before we can start adding décor and style.
What, exactly, is a wireframe?
In a literal sense, wireframes are an arrangement of boxes and placeholder text that very accurately represent the general location and structure of a series of templates. In no way does the wireframe represent design, which is the phase in which a designer will take the wireframes (their structure and functionality) and create something visually appealing that speaks to a client’s aesthetic.
A final wireframe will typically consist of 5-10 custom templates. When a website is designed and built, we do not design each individual page; rather, we determine ahead of time via the sitemap (again, this article may be helpful). Then, we take the total number of separate designs (templates) needed to cover the pages that will be in the site, and we build their structure. A wireframe homepage example is here:
And these are the first few designs it became:
As you can see, the design is only structurally pulled from the wireframe – the end result looks totally different (and a whole lot prettier)!
What is the client’s role?
We need the client to think about all of the content that will go on each page so we can establish the templates for the site. This allows clients to continue to build content on their website once the project is finished and in their hands. One of our main goals is to build a site that is easy to use and that can allow the client to be self-sufficient in the future. That is a beauty of a content management system like WordPress!
Our designers will take the wireframes and use them as a base of their design. The decisions that are made in the wireframes effect the design and those decisions made in design effect the development and ultimately the end product. If the wireframe (or the foundation, to use the house analogy again) is not 100% approved and things change, the process can experience a ripple effect that can impact the end project.
Quick list of things to keep in mind when viewing a wireframe:
- Wireframes are not the design. The design will (likely) not entail boxes and a flat grey/black/white color schemes.
- Just because there are a lot of numbered modules doesn’t mean the page will be a super long scroll – again, this is structural, so the designer will keep the actual scroll length in mind (and believe me, we know that a long scroll is usually not the preference!).
- All text can change later in the process. We are primarily concerned with establishing each type of text (headline, subheadline, overview paragraph, and so on).
- The wireframe is a good indicator of the placement of one piece of content relative to the other pieces of content. That is, when we show a main content area on the left alongside a sidebar on the right, those two pieces of content cannot swap locations in design or development (content will remain left-justified, sidebars will remain left-justified – unless the approved wireframe says otherwise!).
In case you’re curious, this was the final design (and check out Taza’s website here):