Wireframes, you either love them or you hate them.

But regardless of your feelings towards the grey boxes of joy, if you work in web design in a professional environment, they will have been a common part of your existence for the past 15 years.

Process driven

They are a crucial part of any design process, giving the creator a logical thought process, allowing them to visually, and mentally, navigate through the proposed design. UI (User Interface) issues can be ironed out at this stage through the use of wireframes. By having this process in place, a design team can ensure they have the best solution to the brief. I am process driven for the most part, and always endeavor to follow a work flow similar to this handy diagram below.

Scalability

Of course, wireframes may not be required for small scale projects. Depending on the size of the solution, it is sometimes not necessary to wireframe the design at all, and the designer can go directly to producing visual mockups which accurately describe the final result. This can approach can generally only be taken if the clients expectations are successfully managed. As I have mentioned in a previous post, there are clear arguments, both for and against, presenting the client with full mock ups or wireframes.

Functional Vs Visual

There are two types of commonly used definitions of wireframes, functional and visual. Generally, functional wireframes are less common in todays design environment, and were used for primarily for large scale solutions, with hundreds of hyperlinked pages. Historically, this task would have usually been completed by the IA (Information Architect). Functional wireframes can be difficult to read, complex and overly annotated. They are ugly, and don’t inform the visual design. Getting a solution signed off on the basis of a functional wireframe can be risky, as it may not accurately reflect the visual mock, elements may move and other decisions may be changed during the design process.

A more accurate description of the final product is a visual wireframe. The designer can show actual content, fonts at correct sizes and use image placeholders. A visual wireframe is a mix of functional and mock up. It is something that combines the IA and design, into a document that everybody can read and feel comfortable with, including the client. Web design has evolved. It is now very much a modular process, as is coding. This argument is explained very well in this article by Isaac Pinnock over at Made by many.

Whose line is it anyway?

As I mentioned earlier, the job of creating wireframes 10 years ago almost certainly fell to the IA, which would then be passed to the designer to design. Today the the line between the Designer, IA and Developer is a blurry one. With Ajax and todays web design principles and technologies, the designer must ensure that their solution not only looks awesome, but works beautifully. Again, historically, this task fell to the developer, but today more commonly the UX (User Experience) is handled by the designer.

The best, and most successful solutions, are those which seamlessly combine the look (UI), experience (UX) and the Content, so the designers role in delivering these elements to the client is crucial. Wireframes will continue to remain a crucial part of this process, in whichever format best suits the solution.