There’s been some discussion in the blogosphere recently about the importance of wireframes and how they should be handled within interactive agencies. Going by a recent post by Sarah Harrison and reiteration by Paul Boag of the Boagworld podcast, there seems to be a disconnect between information architects (IAs) and the designers that they work with in relation to the position of wireframes within the overall website development process. The basic caveat as introduced by Sarah is that wireframes, even if they are meant to be lo-fidelity representations of a final website that contain no true graphical direction, colors, or themes, still focus on physical information layout, something that is generally handled by designers in lieu of the IA (in a perfect world.) Sarah suggests a novel document known as the Page Description Diagram, as introduced by Dan Brown in his excellent work Communicating Design, as the perfect solution to this impasse. The Page Description Diagram  lists the elements of a page in a standard three-column format with the most important information featured in the left column with less important aspects listed in the center and right columns. The standard horizontal structure of the document keeps it layout-neutral in a design sense and leaves placement completely up to the designer.

At Rise the role of information architect and senior designer is a shared position, so the issues inherent with wireframe layout is not something we generally experience, although Sarah’s solution does make sense in a relevant setting. What I fail to understand, and as Sarah also mentions, is why some agencies utilize wireframes as nothing more than an internal instrument of development with the client only being exposed to functionality prototypes:

Why aren’t more people showing wireframes?

• Much of this work is internal, often confidential.
• Most people might consider the stark black and white renderings unappealing

I can’t think of any other good reasons for keeping these documents under wraps. The confidentiality reason is understandable, but I disagree that these documents are unappealing. I understand the thought that goes into these documents, and I want to see the results of this labor.

I believe wireframes should not be hidden from clients. At Rise we make it a defined point within our process to not only show the wireframe to our clients, but to also sit down with them to explain decisions and gain clarification on unclear points. There are several reasons why we do this:

1.) Creates a solid structure for website success.
The wireframe is like a sketch before a brilliant illustration is filled in — that brilliant illustration simply cannot exist without the structure of the sketch serving as its base. The sketch can be changed numerous times, but it always has to reach a point of finalization before the next phase of development can begin. The same is true of website development.

2.) Forces everyone to be on the same page.
Of course, changes will always occur no matter what phase of the project is being undertaken. However, fully considered wireframes can minimize surprise and massive functionality change by serving as a common point of reference for developers and clients. Keeping in constant communication can be difficult considering the realities of every day life and business, but the wireframe serves as  a constant that can be easily revisited, rethought, and altered.

3.) Makes functionality more obvious in usability testing.
Website prototypes constructed on paper or in an interactive medium such as Flash or Powerpoint may serve as excellent guides early on in a project, but they are less effective during initial usability testing where users are asked to interact with lo-fidelity versions of web projects. Having the website appear in a browser via a wireframe structure, alongside standard browser conventions, makes users feel more comfortable and apt to interact as they would with a fully realized website.

4.) Encourages clients to think through their content and calls-to-action.
We place a lot of emphasis on the wireframe, but not just on the functionality aspects it represents. Content is also plugged in and refined alongside the functionality to provide a view of the full user experience. This helps clients focus on the strategic nature of their content in the context of persuasion by limiting the distraction of graphical elements. The content portion of the wireframe is incredibly important not only because it refines the client’s message, but also helps define the direction of the site’s design. The designer can better understand the client’s needs if full content is available, which he or she can then take into account alongside vitally important user-centric design decisions.

5.) Saves time in the end.
While the wireframe process might seem to extend the development time to some, especially those who are excited to see graphics intertwined with their message, it, in fact, saves valuable time and resources. Without a defined wireframe and communication around it, a project can languish through numerous structural changes later in the development process where such changes can eat up hours upon hours of valuable time and resources. Wireframes are easier and quicker to change, and with their refinement comes a focussed push into site production that has already taken into account multiple contingencies.

At Rise we believe that wireframes are absolutely vital to a website or web application’s success and that they deserve as much time in the spotlight as the flashier cousin, graphic design. How do you approach complex web development projects?