I was recently watching a presentation where a deck of wireframes were introduced as:
Wireframes are intended to show navigation, user journeys and page content structure but do not imply exact layouts or any design approach.
I have a problem with this because it begins to make me question how useful a wireframe is. Wireframes came out of an older world when websites were more static than they are now and, if we’re honest, designs were less trend setting as well. Having worked over the last few years with some very good IA teams and some top notch planning and design ‘thinkers’, I have had the luxury of seeing how the pre-design process can work at its very best (and when it fails as well).
So lets address the statement in a little more detail. I agree with the first part, that wireframes should show navigation and user journeys. This is precisely the point of doing pre-design work. Wireframes, sketches, prototypes or whatever else you use, the point is to instill a level of thought about the end user needs before applying the ‘colouring in’. Similarly, planning out the user journey is paramount at this point because if it isn’t thought through properly at the start then you are potentially left with a site that isn’t optimal for the user groups. Therefore the wireframes / sketches should be mapping out the on page real-estate to reflect where content will be for the user, where the calls to action are and how the user will therefore interact with and move through the website. This is where the content structure starts to come in as well.
But this is the point at which I start to have a problem with the statement. One of the most annoying things for an Information Architect, UX Planner or anyone else in that pre-design role is when they spend a lot of time thinking through the page to then see a graphical designer produce something that has changed the layout of the page. I have seen this a few times and when questioning the designer about their motives often they have just said “I felt it would work better this way”. The problem with this is that the previous work has not just been thrown together on a whim, it has been heavily thought through, researched, user tested, and iterated with the client (or at least it should have been). All this could then be undone in one swift sweep of the Photoshop paintbrush. Now, to be pedantic, yes the layouts will not be pixel perfect, but the layouts should be almost exact, down to the positioning, the proportion of the screen that an element will use and indeed the general layout of that element in terms of the content.
Further to this, I also believe that this stage is the first stage of design. It might not apply the ‘sexy’ final design, but at sketch level (and I advocate sketches rather than wireframes – I will explain the difference in a minute) the styles that will be used should start to be applied because this is key in identifying prominence on the page and guiding users to certain areas before others. For example, a sketch can show how a background colour can be used to highlight one section, or how button styles can be applied across the site. It can show icons, possibly even the actual style of icons. It can show general typography approaches, and it can show colours. What happens after the sketching is that the designer then has a crystal clear brief for what they need to come up with. They can then take this and make it look amazing by refining it, tightening up the lines, making it pixel perfect for the grid system, applying the typography with actual fonts and colours and perfecting the imagery and icons.
The key to the sketch > design > development approach is that it is iterative and representative from the first step. And that is a key point. One of the things that often causes issues in a project is the client not being able to visualise what the final page will look like until a long way in to the process. Often this is caused because wireframes are too paired back, they don’t show enough of the styling approach and this then doesn’t resonate. It is also a problem if they have seen a wireframe and made assumptions about how this will be realised in a graphical design, only to be surprised and disappointed when a designer has come up with something quite different. It comes down to effective management of expectations, on both sides. The earlier you can understand what a client likes, holistically (design, layout, user journey) the better. This doesn’t for one minute limit the designers creative ability. In fact, it should help the designer as they don’t have to worry about the UX planning. I would incidentally always recommend that the designer is involved in the UX planning and sketching (if they aren’t the one doing it).
Ok, one final line to draw then. What is the difference between a wireframe and a sketch? Well, put quite simply, a sketch applies more styling than a wireframe. Whilst a wireframe will literally be a collection of black lines and boxes on a page, a sketch will apply more. It will have an element of design thought attached. It implies not only layout and journey but also iconography use, colour use, block level styling (e.g. background colours, lines, rounded corners vs square corners, etc.). And this is important because this is what your client starts to get excited about. A sketch starts to show how the page is actually going to look and means that they can actually visualise what they are going to get. It might even use example and representative content. It is truly iterative as it shows the first step of the design, meaning the graphical treatment should then be a logical step forward rather than a jolt. Wireframes just don’t provide this. They aren’t as useful, as warm and as fluffy. When it comes to it, wireframes simply don’t excite as much as sketches do!