The right way to wireframe by Russ Unger. #rwtw

Additionally, sketching helps us change our ideas to make them more reasonable where they can become a reality, and gives us a general outline when we bring our design ideas to say, Photoshop.

Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. This helps us develop on our design idea, which actually helps us provide a better end result or product, than that of whom did not sketch the idea.

Therefore, eliminating sketching as a process of gaining experience is not a valid point as you are eliminating a crucial process in design that can sometimes make or break a project. To better prove the point on how sketching can strengthen your design ideas, we discuss several benefits to sketching out our designs before making them a reality.

Eliminates Time Wasted

One obvious factor or benefit of sketching your design ideas is that it eliminates time you could have wasted.

You may be wondering how sketching can eliminate wasted time while you could simply start right into Photoshop or Fireworks. You have a valid point; however, even the greatest ideas need refining. Sketching enables you to plan before actually starting to design. You can solve a lot of UX and design problems by sketching ideas on paper prior to firing up your preferred design software.

What this means is, spending the time to sketch your idea on paper will actually help you visualize your idea better than you would when you imagine it.

It allows you to get a better overlook on how it will turn out, and if you do not like how the design idea is turning out on paper, or the idea may not be reachable or feasible, you have not spent the time actually bringing it to life in Photoshop, but rather just a half hour throwing it on paper.

Therefore, a not so great idea will not waste hours out of your day just to realize that it will be heading straight to your trash bin.

Helps Expand on Our Ideas

Whenever we imagine ideas, they are usually the skeleton of what the end result can be.

However, when you take an idea directly to Photoshop, you do not quite have the brainstorming you would if you brought it to paper to expand on it, and thus great ideas are often suppressed and lost, making your great idea turn into an exceptional idea or design.

However, by bringing your designs from mind directly to paper, it gives you a completely new and different level of how you visualized it, allowing you to expand on your ideas for the design often bringing it from exceptional, to a mesmerizing drool-worthy design.

Therefore, it is definitely worth the time and effort to sketch your ideas out before making them a reality.

Helps with Group Feedback

Let’s face it, when we spend hours and days and weeks bringing an idea to life in Photoshop, we are generally not open to major feedback that will attempt to overhaul all the work, effort, and time we have put into it to bring it to life already.

We would just reject credible and excellent feedback if it means we need to change a huge chunk of our design such as a structural change, or we would be forced to perform these major changes by a design firm, which causes delays in the completion of the design project.

However, when you sketch your ideas on paper or on a whiteboard, your group can provide feedback allowing you to bring changes to the sketch in seconds helping make your design an excellent piece of work in the end.

In fact, many new great ideas whether design or not are structured by brainstorming on paper first with their group before going forth and bringing some sort of prototype to life.

Increases Creativity

By bringing your design directly to Photoshop you are limiting your creativity as you are trying to follow the idea you imagined to get some sort of prototype completed before actually changing a few things around.

A sketch on paper acts like your design prototype for your idea or ideas. This allows you to quickly expand on it by using your creativity before actually bringing it into Photoshop or to the browser for a graphical preview.

This also happens to save you time from manipulating your prototype in a graphic editing program rather than on paper which tends to only take several seconds rather than several hours.

Design Evolution

One great thing about sketching out your design ideas is that later on you can look back and see how your design has evolved, from sketch, to prototype, to the final product.

This not only is just for personal satisfactory, but it actually helps you improve on your final product months down the line.

When we design websites, we tend to design them specifically for the content we need for that website at that current point in time, however, our sketches often contain different content containers before we scratched them out.

By going back and looking at our sketches when we are looking for ideas or how our design or designs evolved, it will actually help us bring the containers we eliminated into our current design if we decided we needed such containers or elements later on.

GrindSmart Magazine on idea strengthening with the help of sketch notes and wireframes.

Documentation, of course, is critical to defining and confirming your client’s needs, and it’s critical for providing direction to your design and development teams.  As part of your documentation, wireframes provide visual conceptualization that cannot be captured in a text-only document.

At Urban Insight, when we kick off a new web development project the first document we produce is the formal Project Requirements Document. This starts as a working document and, in its final form provides the client-approved outline of project purpose, feature requirements, technical requirements and creative brief.

On the heels of the Project Requirements Document we begin development of the wireframes. Wireframes also begin as a working document, have two phases and serve two critical purposes.

1. To initially communicate basic content layout requirements to designers as input to the creative process
2. To subsequently provide specific detailed functional requirements to developers

Between these two phases of development, the wireframes will grow and evolve.

Input to the design process

As a major source of input to creative development, wireframes walk a fine line. They must illustrate content priority and content layout as it will best support the website’s business objectives, but beyond that they must not provide a specific sense of design. 

It's important your designer feels that within the creative process he or she has the freedom to rearrange content items while maintaining their relative importance within the presentation.  It's important that your client remains open to the various creative options that your designer presents. 

At the end of the first round of wireframe development, your client
should be happy that the site will effectively communicate what it needs
to communicate, and that it will lead the each website audience into
and through the site as required.

As a wireframe developer, if you have creative sensibilities, this may be a difficult impulse to control. The first round of wireframes, however, should be a technical illustration. Save your thoughts on design for your review you’ll have with your creative team on content layout and creative requirements.

Home page wireframe as input to design process

Home page mockup from wireframe input and creative brief

Input to the development process

Creative development, of course, is its own phase. Once design is signed-off, the wireframe document will subsequently expand to illustrate the requirements for content pages and any further design requirements for those pages, and they will become the document for detailed  page-by-page functional specifications and direction to the developers.

In the end, the newly launched website may not look a lot like the very first round of wireframes, but what’s important is that they trace the site’s evolution from content requirements to functional requirements and help to produce a website that is user-friendly, compelling and effective for the client.

Content page wireframe with functional specifications

Content page final implementation

Kurt Rademaekers on the importance if wireframes.

A year ago, I proposed the future of wireframes.

My proposal centered around relaxing the stranglehold wireframes have on layout decisions. Traditionally, the exact positioning of the different "boxes" of information has been in the information architect's domain. In other words, when a wireframe shows a featured article rotator above a sidebar of resource links, it is expected that the final site will have the featured article rotator above that sidebar of resource links. In fact, it is expected that all such boxes of information show up relative to each other as depicted in the wireframe.

There are several problems with this approach, but let's focus on the fundamental ones.

I Got 99 Problems

Despite how things turned out, nature intended the layout and the visual design of a site to go hand-in-hand. You pay a notable price when you decouple these two aspects of the design process: a price that generally manifests in the form of a design that's not very exciting.

In addition to the decoupling problem, there is the problem of lost opportunity cost. When members of a design team have cross-disciplinary skills—that is, when they are experienced generalists—you endure the opportunity cost of not maximizing the team potential if you decouple IA from the rest of the design process.

But finally, there's the question of responsive design: how does IA adapt to include responsive design?

I suspect that those who specialize in IA will argue for more wireframes: wireframes for every form factor. It may be a great way to inflate the project budget, but remember Biggie's infinite wisdom? In all seriousness, creating wireframes for the full responsive matrix isn't sustainable. It's counterproductive, and as Trent points out, it's unnecessary. It also compounds the decoupling and opportunity cost problems I mentioned earlier.

So, where does that leave us?

It turns out that the key to solving our dilemmas lies in our ability to address the source of all these issues: the issue of control.

Control Freak

For the most part, today's approach to IA is similar to architecture in the physical world: create an exact blueprint for what is to be built, and then build it.

This approach worked well when IA was emerging as a discipline in a time where designing for the Web was unchartered territory. It was a practical way to solve problems up front, control scope, and manage stakeholders. But times have changed, and while it's still necessary to know what you want to build up front, it isn't necessary to have it fully locked down. It isn't necessary for the IA to exert full control over it.

In fact, it's better to ease up on the control.

Fluid Information Architecture

As I proposed in The Future of Wireframes, information architects (or, whoever owns the wireframes for the project) can often improve the quality of a design drastically by relaxing their control on layout decisions. I introduced the concept of functional wireframes to illustrate this.

My proposal this year—something I'm calling "fluid information architecture" in the spirit of our times—is for wireframes to have less control over other aspects of information architecture, like responsive architecture for a site and functional copy decisions.

There are two major benefits to this approach. First, it allows responsive content choreography to happen downstream in a much better way. Secondly, due to the nature of the beast, it introduces a level of delightful unpredictability for our users. Remember, these are exactly the kinds of results we were hoping to gain.

However, the fluid IA approach brings an elephant into the room with it: if the information architect doesn't control the blueprint of the site, then why have the role?

This is worthwhile question, and I've found that the answer varies from project to project depending on scope and makeup of the design team. Sometimes, the answer is for the information architect to focus on other aspects of the process: identifying page-level information, determining relative priority of information (Allison House provides an excellent example), capturing page states, and so on.

But a perfectly reasonable answer is for the role of the IA to be combined with surrounding roles, like creative director, or front-end developer, as we did in the 10K project.

The 10K Apart Case Study

For those of you who haven't heard of the contest, the 10K challenges contestants to build the best application they can with no more than 10K (yes, kilobytes) of code. You can read about this year's contest here.

Among other things, I served as the information architect for 10K Apart. As you'll see, I drastically reduced the scope and influence of the IA role precisely due to the scope of the project, and who was on the design team.

I was fortunate enough to have the Paravel trio come on board to help design the site. This isn't a gratuitous plug. Paravel is on the top of their game in several areas of the design process—among other things, they create wonderfully laid out websites, and have cracked the responsive nut better than most. This helped me adapt the information architecture approach for the project, particularly in three areas:

1. Layout (zero control): I knew I could relax the control I exerted on layout in the wireframes. This is one of Paravel's major strengths, so I put layout in their able hands.
2. Copy (relaxed control): Copy, much like layout, can function as a focal point for the site aesthetic. I encouraged the Paravel team to experiment with copy in the context of the visual design.
3. Responsiveness (zero control): Paravel is pioneering responsive web experiences. It felt natural to leave the responsive architecture of the site up to them.

To fully illustrate my point, I'm making the functional wireframe deck for the project available for your perusal.

Download 10K Apart Wireframes → 1.4MB .PDF

As you can see, I mandated only one thing: page-level information. The rest was at Paravel's discretion.

Some things they chose to keep (like the entry form and the gallery layouts), while others they completely changed (the hero banner and layout of home page elements). The process was seamlessly fluid as becomes apparent in Reagan, Trent, and Dave's posts.

The resulting design—and I may be biased here—turned out to be functional and unpredictably delightful: http://10k.aneventapart.com.

Finally

It's widely accepted that the information architecture phase of a project can make or break the final experience. And this is true. But this belief rests on the assumption that control creates predictability. While this checks out in theory, we've seen how it quickly falls apart in practice.

Ironically, in practice it seems that creating predictably delightful designs isn't about exerting control. It's about judiciously giving it up. It's about identifying the right fluidity for the process and establishing the optimal flow.

Nishant Kothary wrote a follow up on his last years article "The Future Of Wireframes". This time he looks back to what he proposed last year and takes it even a step further.

How to Think About Website Prototypes (for Designers)

In the past, I often would describe a website prototype as a plan for how a website works, not how it looks. While, in a sense, I still think that's true, I've come to realize that it's actually pretty confusing, don't you think? Especially since we go on and on about how sitemaps and wireframes are inadequate website planning techniques because they can't be experienced interactively, like a website. But a very big part of the web experience is visual! Every aspect of a website's structure and functionality is represented in some visual way by its prototype. With that in mind, it's much easier to see how the distinction between prototyping and design is fuzzier than I'd thought.

So, to better describe what exactly a website prototype is, I'd like to start by drawing a pretty simple analogy: Just as architectural plans use a consistent visual language to describe buildings, prototypes use a consistent visual language to describe websites. In both cases, there are many good reasons for the consistency part. Architects are trained to read plans and discern critical specifications from them that are later translated into three-dimensional structures. Likewise, website developers are trained to interpret prototypes and translate their specifications into functional code. You could say that the use of conventions make the plans look very similar, but that doesn't stop the results from being quite distinct.

Here's an example (FYI, it's going to involve a bit of scrolling):

See what I mean?

For designers, rather than seeing the prototype as a document that imposes limitations, I think it makes more sense to see it as one that enables creative freedom. Believe me, I'm not trying to spin this. To milk my architecture analogy just a bit more, imagine if blueprints didn't exist. Without them, it would be amazing if buildings were built at all, but it would be even more incredible if the ones that did remained standing! In the same way, prototypes provide a structure that ensures a website is even possible. No matter how great a design might be, if it's not possible, it's useless.

Essentially, what I'm saying is that a good prototype wants to support good design, not step on its toes. But I realize I'm going to have to get a bit more into the details of how prototypes communicate in order to build my case, so bear with me...

The Language of Prototypes

The first priority of a prototype is to accurately represent the information a website will contain. That includes structural information—like the hierarchy of pages and sub-pages that make up a website—as well as content, which includes everything from the words and images displayed on pages to the logic behind content relationships and other functionality. In other words, a prototype has a big, big job: communicating a ton of technical information that will be understandable to everyone involved in the project—the technical and the non-technical—without using technical language (or for that matter, even working at all). Let me explain...

At the time of this writing, sunrise is expected about 15 hours from now. Maybe if I'm still up then (working on this article, of course), I'll stop for a break and watch the sun come up. Buuuut, probably not. The reason I bring up sunrise is that it's a perfect example of phenomenological language, which is exactly the kind of language a prototype uses. If you speak prototype—which I hope you will by the end of this article—you speak phenomenologically, which is to say, you speak in a way that describes experiences. We know that the sun doesn't actually rise, but from our subjective vantage point way down here on Earth, it looks like it does. The Earth would have to be much, much smaller in order for us to experience its day-long spin. So, despite our modern enlightenment, we still say "sunrise" because it's a whole lot clearer (and less pedantic) than saying "the time in the morning when we've spun around enough to see the Sun again."

Prototypes describe what it will be like to use a website—that's the phenomenological part—in a way that satisfactorily engages and prepares the client, without confusing anyone with overly technical jargon. But that leaves one question: if the prototype doesn't use technical language, how does a developer know what to build?

The first thing you probably noticed is that the prototype is mostly gray. We do this intentionally just to make sure that nobody gets sidetracked by any aesthetic hang-ups—at this point, we're not interested in whether the prototype is pretty, just whether it works. The second thing you may have noticed is that the prototype looks like a website...well, sort of. The page is certainly layed out like a website would be (and, were this an actual prototype, you could navigate from one page to another), but some things are specific while others are generic. For instance, the main navigation has what look like specific page names in it, but other parts of the page have generic titles like "Blog Post Title."

These are the brass tacks of the language of prototypes. In general, some aspects of the site will be very specific, and the way the prototype describes them will reflect that. So, from the example, the main pages (and their sub-pages) are named, and though that doesn't necessarily mean those names cannot be changed once the website is built, they're probably not likely to do so very often. On the other hand, the blog post that is featured on the homepage is likely to change very often. By using generic language, as opposed to prototyping a specific blog post title, the prototype is communicating to the developer that the site should be built in such a way that the end user can add new blog posts and name them whatever they wish. Just like "lorem ipsum" dummy text generally means "text will be here," generic titles stand in for types of content that are meant to be editable.

The Structure of Prototype Pages

Here is where I think most of the fuzziness between prototyping and design comes in to play. Because the prototype must communicate the website experience (that phenomenological language again), it has to work like a website—which means you need to be able to click from page to page. But in order to work like a website, it has to look like one, too. That's why sitemaps—they don't look or work like a website—and wireframes—they look (in a Flatland kind of way) like websites but don't work like them—fail to communicate anything useful about, well, using websites. Where I'm heading with this is that since prototypes need to look like websites, they can't look just any way. The honest truth is that building a prototype does involve a kind of design.

The kind of design I'm talking about has to do with communicating the priority of information on a page—or, for short, information design. The prototyping process involves returning to two core principles over and over again with every information design decision that the team makes:

1. What is the purpose of the website, and
2. For whom?

The answers to those questions should lead to very focused pages with a clear sense of priority. This is often manifested in visual decisions, such as the relative sizes and positions of elements on a page or typographical details if the volume of information on a page warrants it.

Let me unpack this with another example:

I created these simple mock designs for my example prototype in order to make a simple point: Though the prototyped homepage has a very deliberate layout in which the information on the page has been clearly and intentionally ordered, the spectrum of possibilities for what the final website can look like is still wide open.

Both examples take many liberties with elements of the page, but neither remove essential information nor disrupt the order of the information in a way that fundamentally changes the focus of the page. The interactive slideshow element, which occupies about 3/4 of the horizontal space at the top of the page, is still the most prominent visual element in both designs, even though Option 1 has changed its size. The sign-up form is not fundamentally affected by being relocated, nor has the choice to limit the number of blog posts on Option 2 significantly altered the overall priority of blog content on the page. Aside from these specific layout choices, Option 1 and Option 2 represent very different creative directions even though they share the same prototype.

There's so much more to say about the interplay between design and prototyping—much more than this post can handle, I'm afraid. I adapted this from a longer article I published a few months ago called Prototyping for Designers, which has many more examples of information architecture decisions and how they manifest in later designs, so if this has struck your fancy I recommend checking it out.

>EXTRA: For web design tips, pick up Patrick McNeil's book the Web Designer’s Idea Book, which provides inspirational examples of winning layout, color, and style directions.

Christopher Butlers interesting article on the role of design in website prototyping.

When building websites, I always recommend developing the home page last because the purpose of the homepage is to highlight content within the site. You need build out the site so you have something to highlight before you build the homepage. Over the past year, I have started to realize that the same advice holds true for design. In fact, I now feel even stronger about that rule for design. Here are four reasons why.

1. A homepage wireframe doesn’t tell a whole lot.

   Wireframes are helpful to express content structure and site functionality. When I look at a wireframe, I see a content model (what elements make up a particular type of content) and features (how the visitor interacts with the content — commenting, voting, sharing, related links, etc.). The home page is more of a summary. You don’t see that level of detail. The things that matter to a homepage (branding elements like font, imagery and palette) are not even captured in a wireframe. Talk about those things near the end of the project because you can make sweeping visual changes by editing a few lines of a style sheet.

2. The biggest functionality decisions are in the inner pages of the site.

   Although you may think you have scoped the project during your requirements phase, the devil is in the details. How the functionality works will have huge implications on project cost. The sooner you have those conversations, the sooner you will be able to adjust budget and scope so you can spend resources cost-effectively. Leave those decisions to the end and everyone gets surprised … in a bad way.

3. Internal audiences care more about the home page than external audiences do

   Let’s face it, if your site is like most sites, most of your traffic is coming from search engines and link sharing (Twitter, Facebook, etc.). If you have something worthy of your audience’s attention, Google is going to know about it and take your visitors directly there. The homepage doesn’t do much more than give a visitor something to look at when he doesn’t know where to go. The homepage is more about corporate vanity than serving audiences.

4. It is easy to get bogged down in political issues that have nothing to do with the functionality of the site.

   While there is very little functional substance on the homepage, that doesn’t mean people can’t argue about it. If the homepage is treated as a symbol for what is important to an organization (which it often is), a design session will quickly degrade into a turf battle. Your designer will try to mediate, but there is no way he will be able to settle such a fundamental argument. Don’t waste time arguing in the beginning of the project when there is so much productive work to be done.

Unfortunately, I regularly meet resistance from designers who habitually begin with the homepage. I understand the temptation. On the surface, a homepage wireframe seems easy and uncontroversial. It is just a bunch of blocks on the page that stakeholders can privately fill with their imagination; there are no assertions on how major site features behave. But, from a technical design perspective, we don’t learn anything from the homepage wireframe. We can’t start thinking about content structure and end-user functionality that will have major implications in scope and planning. The longer we delay that work, the greater project risk.

Interesting input from Seth Gottlieb on why you should start with other pages first and wireframe your homepage last.

Steve Cables talk from UX Bristol on how to make wireframes more useful.

Shawn Borsky for DesignM.ag wrote an article entitled A Practical Wireframe Primer.

Although Shawn hits the nail on the head with most of his writing, one area of serious error is the fact that Shawn states that wireframes are not design.

I wrote a response in the comments section yesterday at about 11AM and my comment was not approved. Websites like DesignM.ag will usually do this sort of thing when a comment contradicts what the writer is saying; but more importantly when it makes the writer appear to be wrong. This is not my intention- I like agree with 85% of the article, just not this statement. If I had wrote “Hey nice article Shawn”, it would have been approved within 20 minutes. This being said, I don’t even think Shawn is the one responsible for moderating the article.

Anyways, here is my response to Shawn’s post that was not published in the comments section.

Here we are again.
If I had a penny every time IA and/or wireframes were defined online, I’d be rich.

My only real issue with this article is point #1 under the subtitle “Wireframes are not” which states:
Wireframes are NOT designs
In fact, wireframes should be completely devoid of font choices, color, pictures, logos, etc. Most people think visually and it is extremely common to think that a wire-frame is a intended to convey design. It is extremely easy for a non-designer to think or act like wireframes reflect final designs or placements. Don’t confuse the function by putting visual distractions on your wireframes. Remind them: there is little visual fidelity, wire-frames are about working through functional issues and organizing information.

This is simply not true.
Wireframes are by their very definition design in the truest sense of the word. I think the author here is confusing the concept of art with design (or graphics with design.)

Websters dictionary defines design as seen here: http://www.merriam-webster.com/dictionary/design

Wireframes are design. (If they weren’t, what are we doing here?)
Wireframes are not just a bunch of boxes and arrows that are used to justify a graphical elements after the fact (like most ad agencies would have you think).
When we wireframe we are designing an intended- proposed direction on which we will be building our foundation on.

Design is:
“Conceiving, planning & constructing a proposed, intended element for a specific purpose.”

Examples:
1. A chair was “designed” to withhold a medium body weight that allows the user to sit down.
2. The car was “designed” to transport us from point A to point B over extended distances.
3. The pencil was “designed” in such a way that it allows us to ergonomically place our hands around in order to write something down.

 

It doesn’t matter what the chair, car or pencil looks like in terms of esthetics. That comes later when we want to add a graphical element to the finished product.

Dictionary.com has 13 definitions for the word “design” and only 3 of them (points 8, 10 and 11) refer to design in artistic expression: http://dictionary.reference.com/browse/design

Make no mistake, when we as design professionals craft our wireframes together, we are indeed designing. This is very important to understand and appreciate as many of our fellow co-workers view wireframing as sketches and just a simple step to overcome so we can move on with the project. Even more of the general viewing public do not know or appreciate the craftsmanship, intelligence and thought that goes in to designing wireframes.

Design is not artsy-fartsy feel good graphics. I believe this is where the disconnect is with many inexperienced work professionals as they do not have a proper understanding of the creative design process.

Two of the best and most popular examples of design is the story of the Wright brothers:http://en.wikipedia.org/wiki/Wright_brothers who designed an aircraft of sorts to fly.
All the while displaying key components of the design process: Creativity, thought leadership, sketching, planning, constructing, etc.,… all the while designing a proposed object with an intended purpose for a certain outcome.

This design process can also be witnessed with the inception of my second example, the automobile: http://en.wikipedia.org/wiki/Automobile#History
Ferdinand Verbiest, Karl Benz, Henry Ford and a few others all followed and practically reiterated the design process as well.
Again, the automobile was designed with an intended purpose for a certain task in mind. The steering wheel was designed to provide direction, the seats designed to allow drivers and passengers to sit, etc.,

In all of this, esthetics came later, and we all know that the graphical layer is simply the eye-catching icing on the cake to appeal to the buyer’s emotions in order to make the sale.

Not to harp on the author here, I luv other components of this article which are spot-on, but IA types had better wise up to their craft and what it is that they’re producing. If we as designers don’t appreciate or understand fully what it is that we’re doing, nobody else will.

We are not simple wire monkeys placing boxes and arrows together in the early stages of a project.

IA types should be cutting-edge, business oriented thought-leaders who craft and design proposed intelligent schematics for a certain demographic to accomplish a certain task for a certain purpose for a certain outcome.

Design is creation.

Brett Lutchman published a great article on his blog IAUXdesigner.com, elaborating why wireframes are indeed design.

Recently, I have been in a few meetings where we are working on developing a web site. In these meetings, it has been suggested that we skip the wireframe stage and roll right into what the site is going to look like, the design. This kind of thinking stemmed from the notion that the client would not understand what wireframes are and that jumping into design would get us one step closer to launch. This suggestion is a bad one.

First, let’s back up and talk about what a wireframe is. For those looking to build a web site of any size or shape, wireframes are the foundation on which to begin building. Wireframing usually comes after the site architecture has been determined by a site map or flow chart of the web-site’s pages and before the creative design phase.

There are 3 easy ways to describe a wireframe:

• Wireframes are simple black and white layouts that outline the specific size and placement of page elements, site features, conversion areas and navigation for your web site.
• They are devoid of color, font choices, logos or any real design elements that take away from purely focusing on a site’s structure. 
• We often say that they are much like a blue print to a home, where you can easily see the structural placement of your plumbing, electrical and other structural elements without any interior design treatments.

Here is an examples of what a wireframe looks like:

Simply overlooking this step in order to get to the look and feel is a huge mistake that would prove disastrous for any web site or any contractor building a home. To reinforce the importance of this phase in a web process, I have outlined seven extremely important reasons on why you need to wireframe.

1. Displays site architecture visually

A site map can be a bit abstract, especially ones that are very large. Taking the site map to wireframe starts the first real concrete visual process for a project. Wireframes turn the abstract nature of a flow chart into something real and tangible without distractions. This step ensures that all parties are on the same page.

2. Allows for clarification of web site features

In many instances, clients may not understand what you mean when you say “dynamic slide show,” “news feeds,” “google map integration,” “product filtering,” “light boxes” and hundreds of other types of features. Wire framing specific project features on a web site provides a clear communication to a client how these features will function, where they will live on the specific page and how useful they might actually be.

Sometimes you may decide to take out a feature once it is wireframed due to the fact that it just does’t work with what your site’s goals are. Seeing the features without any creative influence really allows a client to focus on other equally important aspects of the project and clarifies any expectations about how features will be executed.

3. Pushes usability to the forefront

This is the one of the most important points of the entire wire framing process. Creating wireframes pushes usability to the forefront in showcasing page layouts at their core. It 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. And this is a great thing.

4. Identifies ease of updates

For clients who purchase a content managed web site this point is especially important. A wireframe will immediately identify how well your site will handle content growth.  For example, if you only have ten products offered right now, but in six months you may have 100, you will want your web site to accommodate this growth without impact to the website design, site architecture or usability. Wireframes will identify these important areas of content growth.

5. Helps make the design process iterative.

Instead of trying to combine the functionality/layout and creative/branding aspects of the website in one step, wireframes ensure that these elements are taken in one at a time. This allows clients (and other team members) to provide feedback earlier in the process. Skipping wireframes delays this feedback and increases the costs of making changes because full design mock-ups must be reworked, not just simplified wireframes.

6. Saves time on the entire project

Wireframing saves time in a multitude of ways. Your designs are more calculated. Your development team understands what they are building.  Content creation becomes much clearer. You avoid hacks later on in the process. Everyone from the web team, the agency and client are all on the same page about what the web site is supposed to do and how it is supposed to function.

7. Experience shows it works

Building a web site is a process. Wireframing is one of those parts of the web process that should not be skipped, just as you wouldn’t build a house without a blueprint, or live in it without decoration. Each step has an important place in a larger process.

This week it's Nick Haas with 7 reasons why you should consider wireframing before designing/coding a website.

I'm a born planner. I take much more pleasure in creating a to do list than I do in actually completing the items I've painstakingly color-coded and arranged in order of importance. My downfall as a planner? I tend to get caught up in the small details before the bigger picture has been decided.

Every time we move, which has been a lot over the past two years, I immediately begin to envision the new space in my head as it would be in my dreams: repainted kitchen cabinets, warm colors and a collection of my favorite (yet to be purchased) framed prints in the place of stark, white walls, charming pieces of vintage furniture combined with some modern pieces to make my husband happy, a little orange teapot on the stove…yes, I envision the teapot. But before I've taken a step back to look at our new home- deciding what furniture will actually fit in the rooms and how it should be arranged to make the most of our space- or to look at my wish list- deciding whether it's worth the time and effort to achieve each item and creating a timeline for doing so- I'm off buying prints, performing daily searches on craigslist for vintage furniture, and spearheading a never-ending online pursuit for the perfect orange teapot...it's very elusive. After all, isn't the horse supposed to walk behind the cart, nudging it along down the street with it's snout?

Well I can tell you what that method has gotten me thus far: a stack of four vintage chairs in our attic waiting to be repainted and reupholstered, a kitchen sans cabinet doors (they're keeping the chairs company) and at least four unframed prints lying around without a home. And I can tell you that using the same method certainly won't lead to efficiency in web development projects either.

A much more effective method is our grayscreen prototyping process, established long before I crossed the Newfangled threshold as an employee (in fact, it has a good ten years on me). Consequently, there's already a wealth of information on our website about why we prototype and how we prototype, so there's not much to elaborate on there. However, within the process of the prototype lies nuances that can determine whether it's destined for greatness- a well planned, effective website that meets the client's expectations- or doomed to fail- a big ol' mess.

The goal of our prototypes is to thoroughly represent the architecture of the planned site- specifically the structure, content, and functionality. After all, not only will the developer and designer be using the prototype as a guide for their work in later stages, but the prototype is used to determine the scope of the project in functional, interactive terms as well. As a general rule, when it comes to functionality, the more specific the better. If the client wants forms that expand when the title is clicked, this should be represented in the prototype. If they're expecting a scroll feature that showcases their products, it needs to be represented in the prototype.

In one of our more complicated prototypes, clicking on a collection title resulted in the pop-up window shown above. With this prototype, it was important that the client be able to accurately see what the customer would experience as they navigated the site in order to make decisions about functionality. Of equal importance was specifying how those agreed upon pieces of functionality would work on the site so the developer and designer could do their jobs well.

To the extent that it is beneficial, we want the client to be able to click through the prototype and experience, as closely as possible, how the website will actually work once built. But, not only is it important for us to have this expectation ourselves, it's of equal importance for us to communicate this expectation to our clients and make sure they have it as well. They need to understand that when it comes to the prototype, design aside, what you see is what you get. Once the prototype is approved, any additions threaten not only the development schedule but the budget as well. The last thing a client wants to hear is, "Well, we could have included that on the website, but it wasn't specified in the prototype, so adding it means pushing back your important deadline" or worse "…it wasn't specified in the prototype, so we'll have to add it as an upgrade after go live at additional cost." However, there are aspects of a prototype that we intentionally make less specific.

While our prototypes will certainly fully represent the structure, content, and functionality of a website, they will not speak to elements such as color, graphics, or typography. It is precisely because we want clients to focus on the former that our prototypes are intentionally design-agnostic. In fact, if you look at the prototype expecting to be blown away by design, you'll probably be a little underwhelmed to say the least. I like gray as much as the next person, maybe more, but I wouldn't consider shades of gray to be a very exciting palette for a website. But the shades of gray allow us to draw the attention of our clients to the elements that matter during this phase - and keep their attention from those that don't. We use the same basic font across the board- only occasionally adjusting the size and weight to represent how items will relate to one another on the page when appropriate- shades of gray as the color palette as referenced earlier, and dummy text wherever allowable. Introducing stylized fonts or color at this phase may cause the client to get attached to certain aspects of how the prototype looks instead of focusing on how it works. Furthermore, being too specific with some of these elements can even be problematic when it comes to actually building the site.

I mentioned that we use dummy text wherever allowable, a sign to the developer that the client should ultimately have control over the actual content. Straying from this convention and entering specific text on prototype pages, such as actual page titles in lieu of something more generic like "Product Detail Page," may send the wrong message to the developer. Does the client want the titles to be hardcoded? Is this page different than a standard product page in some way? While these specific questions can be answered by a simple phone call, this may not always be the case. Regardless, the prototype is a means of communication between all involved parties- the client, the project manager, the developer, and the designer- so shouldn't we be trying to use it to enhance that conversation and not introduce more confusion?

Even a small detail like using more detailed page titles instead of generic ones can cause confusion. As a general rule, if there isn't a good reason for being specific with elements of the prototype, keep it generic.

It's important to note that there aren't necessarily hard and fast rules when it comes to developing a prototype. The way you choose to handle certain elements may be determined by the client rather than any set of rules as to when or when not to be specific. For instance, in our prototypes, areas designated as open content areas have a great deal of flexibility with regards to the formatting that's possible through our NewfangledCMS; images and files can be uploaded and bullet lists and hyperlinks can be created. Typically, we would write a small amount of "lorem ipsum" text with a note to the developer that a certain area is open content. However, some clients may get derailed by the length of text in these areas or the absence of bulleted lists if their content calls for them. In this case, it may be better to include some bulleted lists in the prototype so that the client is able to focus on more pertinent aspects of the prototype while keeping the note to the developer to prevent confusion.

"It's all about showing a client how things will work", claims Lauren Walstrum in her article and raises the overall question: How specific should a prototype be?