This morning I read a post about wireframes and when they are appropriate. Though I agree, audience is important, it is equally important to hand the correct items to the audience at the right times. This doesn’t mean you shouldn’t create wireframes.
There is an inherent problem with simply not creating wireframes before the design process begins. If the designer is handed a stack of content and a few images that represent what the stakeholders would like to see incorporated, the project can land, very quickly, in a swamp.
The designer won’t have user data to work with. The site may lack important flow and the information presented may become lost in a design which is appealing and hard to use. Wireframes do more than simply offer a low-fidelity idea of what the design is going to look like in the end.
When wireframes are carefully thought out and developed, they define the skeletal structure of the site as well as important user interaction. Wireframes reveal an underlying architecture that should become all but invisible once the final design is implemented.
User interaction with the information architecture should be transparent. This cannot be done with a pretty design alone. Functional specifications come from wireframes. Documentation comes from wireframes. Even code is defined from wireframes.
Let’s consider concerns regarding why people are building wireframes. If a designer decides to build wires for a project simply because they have heard or seen others doing it, they are definitely making wires for the wrong reasons. If the client, on the other hand, demands wireframes simply because they heard a new buzzword, they are asking for the wrong thing as well.
The important issue surrounding wireframes and audience is not whether they should be made or not. The issue is what the fidelity of the wires should be. At the beginning of the thinking process, hand-sketched wires are a great way to get ideas on the table with little time invested. These wires are typically not provided to the customer unless they were sketched at a client meeting.
Once the basic concept is sorted out, more formalized functional wires can be created and presented. These will typically be more fleshed out, accounting for the general states of the site they are intended for. Often times these frames will accompany a document detailing the information hierarchy and user flows. This set of documents is important for the developers and designers to aid in constructing a site that conforms to expected layout and behavior.
After the formal frames have been created, it is time to discuss appropriate fidelity of wireframes for presentation to the stakeholders. If project stakeholders are visionaries, capable of looking through low-fidelity wires to see a final product, then present what you have. Low fidelity is an acceptable choice here. If, on the other hand, you have users that are much more responsive to a final product, it may be time to beef up your wires with some graphics and real content. This is a high-fidelity presentation.
Speak to your client in their native tongue. If you are talking to bunch of engineers you may be able to simply hand them a spec for the views and the business logic and they will extrapolate the rest themselves. On the other hand, executives often don’t have time to review detailed documents. Instead, give execs a nicely presented, medium- to high-fidelity set of frames and comps which they can glance over and make a decision on. Knowing your stakeholders makes all the difference.
In response to the article mentioned early on, wireframes are an important part of the site development process. In order to provide the customer with an optimal product, wireframes should be an integral part of the development process.
The development team will know, immediately, if their work hit the mark when the stakeholders try to click on printed copies of the wireframes to see more information. Wires don’t define the graphical elements of the site, they define how the graphical elements drive the user to move. Wires don’t define how website function will interact with underlying code, they define how the user achieves their goals through using what the developers will build.
Wireframes are not an early version of something pretty, they are an interface tying visual appeal, function and user journey together. In the end, the question should not be, “do I make wireframes?” The question should be “what fidelity should my presentation be to have the greatest impact?” When presenting to stakeholders, consider their needs too.
As a designer, engineer, IxDA or any other element in a project, your users are your goal. Stakeholders are your clients. Build a better user journey. Think about presentation fidelity. Give the stakeholders something to believe in. Make the web a better place.