I am available for freelance work - HIRE ME

Wireframing is About More than Just Visual Layout

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:

  1. It helps remind me that wireframing is about more than just the visual aesthetic of the site.
  2. It helps keep my mind “in the browser” so to speak.
  3. 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 sridhar

Post A Comment

Also from Echo Enduring Media:

An Unfolding Tale

About the Author

Matt Ward is a digital artist who lances freely under the moniker of Echo Enduring Media, and specializes in graphics design, illustration and writing. He is also the Creative Director for Highland Marketing, a creative direct marketing company based out of Waterloo, Ontario. You can follow Matt on Twitter

Like this post? Help Promote it!

Comments

Jul 19, 2011

Jason Gross says:

Great to see you writing again Matt :)

I think you initial points of using wireframes to investigate structural flaws support the idea of creating wireframes in HTML. Especially in situations where project stakeholders that are not familiar with design software and code are going to be involved in the wireframe process, it can be helpful to create in HTML.

I do believe that HTML and image (or drawn) format are both valid ways to approach a wireframe. Not only does the type of project play a role as you mentioned but also the type of people. It can be helpful to take measure of whether your colleagues on a project gather concepts from static drawings or if they understand more being able to see the HTML version.

Jul 19, 2011

Liz Hunt says:

Thanks for this post, Matt!

I appreciate your points on the importance of wireframing, particularly that it’s more than just a way to layout content.

As someone who constantly jumps around with how I create wireframes, I’ve come to realize that no matter how I conceive the deliverable, it’s a fruitless effort unless I truly understand the constraints of back-end development.

At Go Media, WordPress is our go-to CMS for building small business websites. Whether you’re a fan of Matt Mullenweg or not, it’s common sense that working within the confines of a dependable framework can help streamline web project workflow and keep price points reasonable for clients.

In wireframing, understanding the different templates within a WordPress theme, for example, helps me evaluate the various parts and pieces our developer will be looking for when we reviews the document. This also is crucial for the designer to see and understand, as they’ll want to provide a style guide for the differences between a blog or category listing, a general page template, or a custom landing page.

Thanks again for your thoughts!

Jul 19, 2011

Ted Goas says:

You hit on one of the big thing wireframing helps with: consistent hierarchy. Depending on the site, HTML wireframes work quite well too.

With HTML wireframes, I’m currently wrestling with the idea of throw-away code. Comps like these are good but often change significantly, and some of the HTML containers and CSS classes start to look like one-off rules.

When the wireframe is done, it’s hard for me to tell how much of the existing code I can keep and what makes sense to throw away.

Some good stuff and a great topic!

Jul 19, 2011

Daquan Wright says:

After reading a particular article on alistapart, I became a big fan of wireframes and told myself I’d never make a website again without a wireframe.

Wireframing typically puts me in a frame of mind that right now, emphasis on information gathering/ui specifications are more important than pretty css and gradients. I focus on call to action paths, understanding client’s goals, and the task a user needs to take to reach point a to point b when wireframing.

I believe wireframing (for me) is the process of establishing an application’s layout, structure, and required functionality. It’s good to sketch, you can toy with ideas and mold them into whatever folds in your mind. It’s not costly, wireframes take minutes to create. Navigation and content areas are what I focus on most.

For how I work, I usually gather information and then wireframe toying with ideas on how the ui should look and function. I’ve done one particular wireframe where it ended up being a big pain in the ass to implement because I didn’t think about how easy it would adapt to markup! I can safely say that thinking about the connection between wireframing and html/css is important. I’m getting better all the time though, so I don’t mind making mistakes.

A sexy ui deserves a good foundation, so give it one! Just as an architect draws a blueprint before he makes a building, I believe web constructors should do the same (it’s cliche, I know, but still).


I also realize that architects don’t actually make the building, but that workers do. Just take note of that. xD

Jul 23, 2011

Shane says:

Nice post. I find this happens to me on a far too regular basis. I start with a Photoshop mockup, move into HTML, then i’m happy, then i’m not and i have to tear the site apart to put it back together again.

I tried using wireframing tools like Balsamiq but nothing compares to pencil and paper. Although it seems that i’m so precious with my Moleskine that refrain from going nuts and experimenting.

Aug 5, 2011

Missy says:

Great article!

I work in ecommerce design / development in a team of developers who are fantastic at coding but not so hot on the usability / ux front (no offence, guys!)

Depending on who needs to sign off a design change will determine how I produce a wireframe. If it’s senior management (Board level) then it tends to be full-on Photoshopped mockups; if it’s a UI change driven by marketing (who tend to fuss more about shades of red than good UX), I will rapid prototype using a hugely cut-down version of our platform. The prototypeing works better for the developers because they can find it difficult to interpret a static visual. When I hand over a pseudo-functional prototype they have a greater understanding of what they need to do to produce the right result programatically.

I think it depends on the environment in which you work, too. We’re Agile, so for most product iterations there’s no time for me to produce a pixel-perfect work of art – at best I might get a couple of hours in each 2-week development cycle to come up with a solution to a new business requirement.

Aug 5, 2011

Kara says:

Wireframes aren’t about the visual layout _at all_. They should be the output of the IA portion of the project and are about the structure and content hierarchy. Once that’s worked out, designers have the wireframes as important input and constraints to their portion of the work. If you’re a designer, put on your IA hat when you do wireframes. And if you’re using them for visual layout, that will always be a disappointment.

Aug 5, 2011

Chris says:

Personally wireframing is the last thing I do before actually laying out prototype designs. The structure of the site on general, flows, usability considerations and accessibility always come first in my book.

But, yes, I do find wireframing with one’s HTML hat on is the best way to do the final layout of the site as it gives a great opportunity to wring any flaws out of the layout phase.

Leave a Comment

Links

Top Commenters

Thanks so much to these awesome people for joining in on the discussion!

Copyright © Echo Enduring Media 2009-2014