07.12.2009: Wireframes Basics, the Ampli2de Way...

Category: tools     Posted by: cornelius     Discuss: view comments     Views: 315

The first mistake made out there is assuming that wireframes are primarily a design deliverable rather than an information architecture (IA) deliverable. The right interpretation should be self-explanatory. I personally use wireframes to demonstrate information, task flow and page flow rather than branding or graphics design. However, the notion of a wireframe has been expanded lately to include everything from physical hand-drawn paper screen mockups to high-fidelity, fully branded screen designs. This being said, my personal preference is somewhere in the middle as I prefer to use specialized applications to create them as a basis of discussion of content and overall structure rather than visual display.

If anyone's ever looked at a typical wireframe (and i say 'typical' very loosely as everyone personalizes the way they create them), you will notice that it consists of a collection of boxes, controls and annotations that make up the skeleton of an application screen. Each box may be an image, a section, a cell or a placeholder for application content.

When presenting screen design in the form of wireframes, application controls are also included. For example, in the case of a wireframe created for a web application, representations corresponding to HTML form controls will be added to the screen design in order to make the wireframe appear as an early drawing of the final product.

Bubbles or baloons are also overlapped over the wireframe elements in order to highlight additional information about the screen design. I use numbered baloons to highlight a couple of concepts. The first one is the importance of the screen component (I rank screen components as high, medium or low priority). The second one is a clickpath, a concept that allows the user to see what happens when clicking on select screen elements. Clickpaths are only shown when making major navigation decisions rather than adding bubbles or baloons for every link, button and event associated with screen components.

A new addition to my wireframe designs are multi-layer options. Rather than recreating the same wireframe multiple times to show changes within a layer (as a result of AJAX calls for example), I simply add the layer views as a separate page of the wireframe. That way, if the main wireframe elements change, I will not have to update every single page view option.

All of these wireframe elements will create a set of screens, however, when presenting them to a client I also like to include the task flow or the sitemap. In some instances (large clients) I have even printed out a large poster containing very small versions of each page so that the client can visually follow the flow and the wireframe at the same time. This is very tricky for large applications and is more useful once the flow and the wireframe structure is relatively stable.

» Share article on: