It seems like designers fall into two camps — either they think wireframes are really important OR they say they think wireframes are really important but don’t. At all. In fact, it has been my experience that those who fall into the latter group actually think that following the wireframes too closely makes them look lazy or non-innovative — that they are just coloring them in without actually doing any designing at all.
How I think these designers view wireframes:
As stated by Dan Brown in his 2007 book Communicating Design wireframes are, “A simplified view of what content will appear on each screen of the final product, usually devoid of color, typographical styles, and images.” In this broad view, wireframes are essentially any design rendering that does not highlight the look and feel. Instead, things such as overall site architecture and content layout, labels for navigation and basic functionality are often the focus. They can be rendered as sketches or drawings, created in a wireframing software program such as Axure, or even as clickable prototypes.
At their best, wireframes represent the upfront work done to ensure what is being built, who it’s being built for, and how best to build it for those users. They are a culmination of stakeholder goals, user needs, engineering capability, timeline and budget considerations, and (of course) usability best practices. If done the right way, wireframes are researched, created, vetted, tested, and edited (repeat as necessary). Yes, it is typically the UX designer who pulls together the renderings, but the process is hardly a one-person job. Virtually everyone (or representatives for everyone) on the project team needs to be involved during this process to make sure that the wireframes represent a well thought out and feasible design.
Despite the fact that it is widely agreed that wireframes are flexible in definition, representative of up-front work, and subject to change, there still seems to be some question of how useful wireframes are during the design process…
Of course, most of us realize that one solution can’t solve all problems and one person’s opinion is rarely all encompassing. However, since wireframes have entered into the processes of virtually all digital teams, it is worth taking a look at these questions: how useful are wireframes? How much should they be followed? How do we get the team (including designers) to invest in the work they represent?
Are They Useful?
Yes. Next quest… ok, I’ll elaborate.
Wireframes in and of themselves are not an outcome. They are representative of an outcome. They are an artifact – a way to communicate the work that has been done up to this point. Without some way of documenting how all of this up front work has influenced the design, it would be all too easy to completely forget how this work impacted the direction of the project.
Given that the wireframes are simply an artifact, it is reasonable then that the form and complexity that artifact takes might vary to meet the needs of a project or team. It’s possible that for a larger redesign project, it might make sense to create formal wireframes that can be archived, edited and shared, in order to keep track of all of the design decisions. However, for a smaller one-page refresh, a rough pencil sketch may be enough to get the designer started (if the developer cannot be involved during this process, I recommend annotating the comps to ensure functionality decisions are not lost). Or, perhaps for a new product design a prototype would help to visualize new functionality and support user testing.
No matter what decision is made, it is important not to resort to a default action. This can cause confusion, the loss of key decisions, or simply waste time.
How concrete are they?
How concrete is any deliverable? Ok, some are pretty concrete. Wireframes, though, are absolutely subject to change — just hopefully not with the wind. As stated before, wireframes represent a lot of up-front strategic work – research, analytics, business decisions, technical constraints, etc. So if a major functionality change is proposed in design, there should be a really good reason for it. That isn’t to say that really good reasons don’t come up, but the person proposing this change should be aware of (or find out) the implications to the project and be prepared to explain why the change is worth any setback it may incur before just popping the change into the comps.
Is that too much to ask? Sometimes it is, especially when a designer is on a really tight timeline and has to make some quick decisions at 2 AM in order to make something work for a comp review at 9 AM that morning. That’s where I find collaboration can be a really handy way to make sure everyone is on the same page early on. Get the designer involved during wireframing so that when they do need to make those decisions in a silo, they won’t ignore those good reasons why a decision was made (or can’t even if they sometimes really want to…a lot).
Of course, not all design limitations (or tech constraints for that matter) can be assessed during the wireframe review, so things will still come up later. But we can try, can’t we? Let’s try.
Does anyone care?
Somebody cares, right? I mean, I have a job so that says something right there. But when wireframes are seemingly ignored it can feel as though wireframes are built for the benefit of no one (well, I do like playing with Axure. I feel like I’m coding without that pesky ‘learning how to code’ nonsense).
People care. They really do. However, a lack of understanding of what they are or should be looking at can have a profound impact on how engaged people are when looking at a wireframe. This is another argument for why it’s important to take a look at the form the wireframes are taking, per the people and project involved.
One thing we’ve recently begun to explore are the idea of wireflows – wireframes arranged into a user flow or site map.
Wireflow example:
Team members (or clients) who may be getting too granular when looking at wireframes, can benefit from being able to see how the pages, transitions and interactions play into the larger whole. Communicating design clearly will increase people’s willingness to engage and provide meaningful feedback. Of course, no one can make someone care about their job (or yours) if they don’t. But hopefully that is a rare problem. And if it isn’t, well, that is an entirely different post for a different day.
Just remember, when wireframing a design: Choose form wisely, communicate purpose clearly, and collaborate with your team.
