This is the second post in a series of blog posts we’re doing where we examine some of the processes and deliverables that we generate for our projects in an effort to gain some refreshing clarity into why we do them and to hopefully provide some insight to our clients.
One of the first design deliverables clients see for most digital products is a wireframe; that black and white thing that kinda feels like an ugly version of the website or app that’s familiar yet foreign enough that it’s sometimes a little confusing. So why is this one of the first things a client gets to see? Why not show them what the product will actually look like?
The term wireframing comes from the world of computer graphics. Before the final rendering of an animation is created, a process which requires a lot of time and processing time (like 29 hours per frame), a “wireframe” version is created. Rather than smooth, polished polygons, the only visible part of the objects are the lines or “wires” that make up the edges of the shapes that ultimately make up the object. These wireframes are quick to produce and edit while still giving the animator a close approximation of the motion of a character without the time needed to produce a final rendering. It allows them to animate freely and try different things without having to worry about getting bogged down by the time required to render.
Interestingly, the similarities between animation and digital products are quite similar. For websites and apps, wireframes are created so that designers can get a handle on the organization of information, navigation and the interface design without the overhead of having to worry about the aesthetics or the content. They can easily move sections, iterate, and refine without having to worry about the burden of keeping color, type, and imagery consistent. Working in black and white without photos or branded graphic elements allows one to focus on the foundations of the product rather than the look itself.
It’s this “familiar yet different” aspect of wireframes that can make them somewhat ambiguous to clients. Often, the feedback on wireframes is something like “looks great!” where you can totally hear the subtext of “Now, when can we see the site?!” not far behind. You can’t blame them! They hired you to build an app, not give them this kind of weird black and white app thing that doesn’t quite look or work like a site.
It’s important to stress what the wireframe is for. Have them look at it from the perspective of a visual organizer. Does it have all the pieces you’d expect from every page? Are they in a place that seems to make sense and if not, can the design team explain their decisions?
It’s sometimes helpful to provide an example of a past project’s wireframes and final design side by side so that they can get an idea of how they relate to one another. Additionally, when you present wireframes for the first time, it might be helpful to present a UI style guide or style tile along with them and explain that the wireframe serves as the canvas on which the style gets applied. We’ve even seen studios provide one page (such as Home) as a wireframe as well as with a preliminary style applied to it so that the client can get a glimpse of what the site is going to look like.
As for the creation of the wireframes themselves, we use Sketch to streamline our process. Previously, we were often building wireframes using Illustrator to allow for quick object creation and easy manipulation. However, that also meant basically “throwing out” the work that had been done in wireframing when it came time for design in Sketch of Photoshop.
Now that we’ve got a Sketch workflow, we can build the wireframes on the same layout grid we use for UI. While wireframes are getting approved, our design team is putting together the style guide for the site including color, texture, photos, and type. So once the wireframes are approved rather than having to recreate from scratch, we’re simply “painting in” the UI styling.
This is also possible because, as a studio, we tend to use a higher fidelity wireframes on most projects than you might find being generated by most shops. Rather than a simple square that says “Blog Post Block” we’ll drop in real headlines from their blog, a place for a tag and even the date or author. In our experience, this extra detail helps the client to see this as their site and have a better understanding of what we’re building. It also gives the designers a place to start when it comes to design (though they’re not beholden to it.)
Since we work on project after project we often forget that for many clients, this is the first time they’ve seen a wireframe in some time. For some, it’s the first time they’ve ever seen one at all. So a little bit of expectation setting and explanation goes a long way in this critical step in the design process.