posted by Matt Ward on Jul 19, 2011.
In this article, I will be drawing on my own recent experience to consider the topic of wireframes. Most specifically, I will be considering how wireframes are about more than just establishing the visual layout for a website and should not be created entirely in a vacuum, but rather with thoughtful consideration to structure and even HTML.
Over the past couple of days, I have been working on an initial concept/prototype for a new, interesting website. As I normally like to do whenever I am tackling a new project, I started by opening up a notebook and making a few really simple layout sketches for how I initially thought the page should be laid out (at this stage, I am just working the layout for a single type of page, with others following later). After discussing these initial concepts with members of the team I am working with, I very logically moved on to the creating more fully realized wireframes. For me, this meant printing of some grids and using a pen to draw and label content boxes.
The process, however, started me thinking about wireframes, their importance and the role(s) that they play in the design and development process. More specifically, it got me thinking about how wireframing— even in the rudimentary pencil on a paper grid method that I use—may be even more important and useful than it may initially appear, or than we like to give it credit for.
Any form of design—but especially web design (or anything else that actually requires a tangible user interface)—is about more than just what the product looks like. It also needs to consider its audience, its purpose and its media. On the web and in application development, this means questions of usability and user experience, interaction and information architecture, all of which are at least as important—and likely more so—than the what something looks like.
Yet, in the same way that “design” has a tendency to be understood merely as the creation of a unique (and often disconnected) visual aesthetic, so to can wireframing have a tendency to be relegated solely to the realm of layout, when it is, in fact a tool with a much broader scope.
It’s All About Structure
Often, many good designers will approach the question of layout from the perspective of arranging the elements on a page in such a way as to create something that is aesthetically pleasing to look at. Conversely, others will approach the layout as a matter of arranging elements in a logical, predictable and consistent fashion, which leads to improved usability and a better user experience.
Great designers do both, and I wouldn’t be at all surprise to learn that 9 times out of 10, this is generally reflected in their wireframing.
Earlier this year Nick Haas authored an excellent post on why wireframing is important and should not be glossed over in an effort to jump straight into the “real” design (and I use that term somewhat ironically) that determines a site’s appearance. In this article, Haas rightly points out that wireframing:
forces everyone to look objectively at a web site’s ease of use, conversion paths, naming of links, navigation placement and feature placement. Wireframes can point out flaws in your site architecture or how a specific feature may work.
From this perspective, wireframing is as much about the underlying structure of a site as it is about the visual dressing that we drape over that structure. It’s about planning the skeleton or framework on which the site will ultimately be built. And, while this skeleton will be reflected in a visual manner, with a number of sketched or grey boxes arranged in a particular fashion, that does not mean that the wireframes themselves are at all limited to the visual aspect of the site.
When done properly, those boxes tell us more than what kind of grid to use or how many CSS floats will be required. Through their positioning and interaction (and, ideally, accompanying notes), they bring a site’s underlying structure to the forefront. If that structure is solid and logical, then it will be easily be able to accept the aesthetic trappings that will eventually formulate its final apperance.
On the other side of the coin, if there are issues or flaws in that structure, those problems can be readily addressed (and hopefully fixed) at this early stage of the process. This certainly beats having nearly completed the entire design only to discover some fundamental structural flaw that forces you to tear everything apart, fix the problem and then try to put it all back together again.
Wireframing can help you catch these issues early, saving time and precious budget dollars.
Wireframing With HTML
There has been a lot of discussion at different points about the merits of designing in the browser, as opposed to creating flat mockups in an application like Photoshop. There are strong opinions on both sides of the fence. My own view is somewhat less concrete, in that I feel that approaching any new web design project is really a matter of context, and the tools and techniques that I chose to employ will depend on what I am looking to accomplish.
That being said, however, while I may not always start in the browser (or even get to it early), I do feel that it is vitaly important to always be designing with the browser in mind. In other words, to consciously design within the constraints and limitations of HTML and CSS. With new and emerging technologies, these constraints are certainly shrinking, but there remain certain things that we still can’t do (or things that we shouldn’t do).
Moreover, it is important to always keep in mind that when we are designing for the web in the traditional sense (apps, I believe, may be somewhat different in this regard), what we are actually doing is creating the visual skin that will be placed over our standard HTML.
We’ve already touched on how wireframing is very much a matter of creating the initial skeleton or structure for a site. In practice, the HTML that we craft becomes the tangible result of that structure. It the context of the document, it brings semantics and meaning to the content, while simultaneously providing the key hooks that will be required to wrap that same content in the visual layout that we have created.
For this reason, I believe that wireframing and HTML are (or at least should be) fundamentally connected, to the point where I am increasingly finding myself actually writing out simple HTML structures at the same time that I am creating my wireframes. In my experience this has a number of key benefits:
- It helps remind me that wireframing is about more than just the visual aesthetic of the site.
- It helps keep my mind “in the browser” so to speak.
- It helps me think of structure in a broader context. By constantly working out how the layout would need to be represented in HTML, I am better able to consider the placement of my wireframed boxes and make important decisions about the relationships between those boxes, both visually and structurally.
For me, these are all key components to my design and development process—components which help strengthen the quality of my work and ensure that the structure and layout are more than just a cool visual treatment. As such, I plan to continue to pair my traditional, rough pencil and paper wireframing with equally rough HTML structures, especially as I dive deeper and deeper into world of responsive design.
Of course, while the concept of wireframing generally serves the same basic purpose from designer to designer (or team to team), the techniques that are used in the process can be very different. As already noted, I like to work more traditionally with pencil and paper. Some designs will use simple grey boxes in Photoshop or Fireworks, while others will actually use applications and other tools that are specifically geared towards wireframing. Regardless of the technique that is used, I believe that the important relationship between these wireframes and HTML still exists and needs to be considered.
The only “exception” would be for those designers who wireframe by creating basic, lightly styled HTML documents right out of the gate. Of course, in these cases the exception is not that HTML should not be considered, but rather that it is no longer a matter of considering the relationship between two seemingly autonomous elements. Instead, the HTML is the wireframe, which only serves to further underscore the point that I’ve been driving at through the entire article: that a thorough consideration of HTML should be an integral part of any wireframing process.
How that manifests itself is up to you.
For those readers who may not be all that familiar with wireframing, feel free to check out Grace Smith’s “Get Wireframing: The All-In-One Guide” for a full complement of resource materials. There are all kinds of wicked resources to help get you started, or to help you dig deeper into the concept.
article photo my sonali sridharPost A Comment
Also from Echo Enduring Media: