Tag: Wireframe

It’s hard to imagine the work of information architect without use of wireframes and prototypes. Thanks to them we can see the final product before the graphic and web designers even start working.

Terms website wireframes and prototypes, are often used interchangeably, so you might ask there any differences between them?
Wireframes (and their more advanced form called mockups)are simply drawings of the interface and functionalities. Prototypes are interactive wireframes allowing to test user interaction and usually click through the website.

Hi-fi and lo-fi

Wireframes are traditionally divided into 2 groups, according to their detail level and fine-tuning.
On the “lo-fi” wireframes only basic and interaction compulsory elements are presented. Such project is examined from global perspective and focus is on crucial factors.
The more simplified the model is, the more imagination we use to describe it and it is best suited for preliminary stage of design. such a wireframe can be drawn using pen and paper and that’s how it’s usually done.
The “hi-fi” wireframes look a lot like final product, and are used more common in final phase of design. Here focus is on details of all used elements, rather than general representation. The most mature wireframe is a graphic design that should be created basing on previous wireframes (at least theoretically). Such wireframes can no longer be prepared manually, a software is required.
When do we consider model a “hi-fi? There’s no strict separation. Often, however, following situation may occur: we show the wireframe printout to an Director, President or other important person.
They will usually tell “Oh yes, very cool, fresh, I see progress, good job!” Then usually comes the sentence, which for the first time beats us off the track: “so where can I see this website on the Internet?”
If someone confuses prototype with real website, that is to say that the model is sufficiently “hi-fi.”

What are the common mistakes in the use of mock-ups?

1. Starting from drawing wireframes. This happens notoriously. I arrive at the client to discuss my idea for website mock-up (that I will design) and what do I see? A Beautifully drawn wireframe, or even worse – complete graphic design. You get a graphic designer and tell him: design a new page for us, because the old one is outdated and we need some refreshing. The designer does his job. In such case it is difficult to tell the client that first we should have started working on design. To Identify what’s wrong with present state of web service, how people use it, describe a vision for change, establish short and long term goals, prepare some scenarios, and only then draw it.
Drawing as such is not a bad way to brainstorm what we want to have on the new site. But it must be clear – it is not yet a mockup, it’s just a preliminary sketch.

2. “Joyfull drawing” neglecting the assumptions. When we start drawing, we suddenly bear down fantasy and forget about what we previously assumed. Than sometimes we forget about that couple different functions that should be implemented and … there’s no place for them anymore.
Quite an effective way to stick to the correct path is to make preliminary sketches, mock-ups for each user (role), that we previously designed. Separate role wireframe for main role and separate for each side role. In such case we draw for single user only, if that user does not use specific function it is not represented on the wireframe. This process is time consuming obviously, but it should be implemented for the major part of the product, e.g. for the home page.

3. Focusing on design. This is why it is important to know when we use the “lo-fi “and “hi-fi ” approach.If we start the design with selecting font size, color and background, then it’s to late to talk about the site layout or navigation scheme. Elements which are not in the wireframe are not discussed, so every time we feel like “beautifying” something, it is worth considering whether we want to discuss such details at this stage of design.

4. Using the advanced tools. Is this a mistake? Yes, if we create a “lo-fi” model, tools with multiple drawing and formatting functions (e.g. Photoshop, Corel) can only harm the project. The very characteristics of such a tool makes prototype look much better than we need at this particular stage.

5. Assuming that a good model is an almost finished product. Recently on Axure forum (a popular prototyping tool) I saw a delightful thread by someone who has created a prototype of an intranet for a company, and likes it so much that… it could stay like this. Creating a prototype and final product are two separate processes and cannot be combined without harm to the product.
Only exception I can imagine – we create a prototype in WYSIWYG tool for creating web pages or software – and in such case each prototype leads us closer to the final product. But the use of such tools within larger projects is limited, web sites consisting of only the interface, without the application backend are very rare.

6. Neglecting customers education. Customers should always know what is the purpose of prototypes, which are shown to them.
Cooperation with graphic designers, taught many decision-makers that what they see is “almost” the final product, therefore it contains more or less what the final product will have. What the client sees, and what’s in and not in it – are the basis, that somehow have to be communicated, before the first showing of any design (…).

This post was created by Robert Drózd. Here’s the original post, you can also visit Robert’s blog at www.webaudit.pl/blog/ (in Polish).
This article is available on Creative Commons 2.5 BY-NC-ND license: http://creativecommons.org/licenses/by-nc-nd/2.5/.