Wireframing – the fine line between design and development

The process of wireframing is one that brings up much debate in the web design and development community. Whilst they are a vital tool within some projects, they can also be seen to hinder the functional aspects of modern web layouts – it can be difficult to show functioning aspects of websites on a piece of paper.

Before delving into the debate of how important wireframing is, let’s look at the definition of wireframing:

“Wireframing – A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website.”

A typical process would be that most designers/developers would include wireframing near the beginning of a new project so that everyone has a better understanding of how a website is to be laid out, and the type of content included on each page. Coupled with a sitemap, wireframing can seem like a very important step when creating any website.

However, some would argue that this step can seem tedious and somewhat irrelevant based on the functioning parts of the website. Andy Clarke, in a recent interview with .NET magazine, makes some interesting points about how we approach web projects. We usually start by working on paper, or by opening Photoshop and starting to draw boxes with text inside to show that, “this is what goes in here”. A client then takes these plans, gives their opinion, changes are made if necessary (although not always necessary) and final plans are sent to client for approval. Andy argues that the client is already within the mindset that this is how the website will look, across all browsers and devices. No thought has been given to older browsers (graceful degradation) or the one fact that all web designers and developers must face:

Websites will never look identical across all browsers

How can we show our clients a wireframe, and then expect them accept this fact toward the end of a project?

Not only does this give headaches throughout the project, but it also leads the way for more time spent on project management in order to show our clients that they need to update their browsers in order to see all the stuff that we had envisioned in the original wireframes.

Personally, I think if we are clear from the beginning of a project that clients will not see an exact copy of a Photoshop file in their browser at the end of a project, then maybe we are creating wireframes incorrectly. Why not use HTML and CSS to build the wireframes, and let the client see how they are rendered in their browser – thus showing the client a better picture of what they are going to receive at the end of a project?

The website Quora asks the question, “Is it important to create wireframes before building your webapp? Why?” Russel Jurney answers with what I think is a thought-provoking response:

Absolutely not! HTML is a wireframe. Your prototype is your spec, and can be improved and iterated to become the final product. Spend that wireframe time iterating against analysis of real use of your prototype and you will build better stuff. Start with the smallest, most core functionality and get it going. Build out from there, one feature at a time. If you can scribble it on a napkin in 30 seconds, you can build a minimum viable version directly. Minimize assumptions, maximize experience and observation!

Do we need to create wireframes for every project we take on as web designers and developers? I think so, but the real question is in how we create these plans, and how they are presented to our clients in order to give a better understanding of the finished product.