“Is my new website going to look as sketchy?” I’m sure you’ve heard this kind of comment after presenting a wireframe to a client?
Wireframes can often lead to confusion, especially during usability tests with users who don’t know much about the project. But you can use a new agile methodology that will put everybody on the same page.
Wireframes VS user tests
In any IT project, usability tests are essential to get feedback on the overall user experience from random users. Unfortunately, most of them are not quite sure how to respond or interact with a wireframe. Often, they don´t know what they should be doing, and some don´t even realize they´re actually looking at a webpage. This lack of context adds cognitive troubles to every step of the process. In the end, this confusion means less relevant answers and opinions.
Most wireframe tests occur with good-willing, though unsophisticated users. They generously agree to test, figure, be puzzled and answer questions as best as they can. This cognitive gap is often due to blurry definitions on what they should or should not be focusing. “Look at the forms but don´t pay attention to images.” “forget about the design, tell me what you think of the layout” “check the font size but not font itself.” Anyone would get mixed up with such questions.
Design and visual impressions like colors, fonts and images are key to using a site, and these details are important to any usability test. Users won’t be able to use a page properly if they don’t see links or can’t read what you expect them to. Information architects, however, tend to stay away from these features so that they don´t step on designers’ shoes. After all, “a wireframe is no design”.
Design & wireframes
Or is it? The role of an information architect should really be focused on clarity, and getting the message across.
Originally a “wireframe” was a quickly rendered 3D model showing the model’s structure while engineers were still working on it. They were much faster to work with than the full rendering. Interestingly, they are not used anymore since modern tools and techniques are fast enough… that should give us a hint!
Why build wireframes and not straight final design?
Information architects don’t design final webpages, instead, they build wireframes instead of designing final pages. There are several reasons to this:
– Wireframes are faster to build and work on
– A wireframe forces the viewer to focus on the content and not on the visual design.
Unfortunately, all these tasks are geared for the project-team. Wireframes aren’t built for external audiences and this is why most users have a hard time grasping the essence of wireframes.
From wireframe to high-fidelity prototype
IT professionals are thus increasingly mixing wireframes with more functional HTML prototypes. These interactive prototypes are so close from the final output, in their design and interactivity, that it became a lot easier to carry on relevant user tests. These HTML prototypes can even integrate analytical tools like Google Analytics to carry out remote user tests. This use of wireframe and prototypes is changing the way IT project are carried out as it´s now possible to know what´s the best app to build for users before having even started the development process.
Projects can benefit a lot from this more agile methodology as it avoids long, time-consuming changes and cut rework drastically.