I’ve read criticism recently describing wireframes as a crutch for teams that lack true collaboration. I’d argue, however, that sketching out wireframes should be a collaborative exercise, much like putting together a puzzle with friends. The wireframe debate is less about whether or not to use wireframes, and more about how to use them. No one argues the value of sketching out ideas before moving into code or production, so the discussion surrounding wireframes seems to be about three things:
- What are wireframes?
- How are wireframes created?
- When are wireframes finished?
What are Wireframes?
There has always been some confusion about what a wireframe is, and it’s obvious why: wireframes are always different. In fact, when all wireframes start looking and functioning in the same way, I think we’re in trouble. Wireframes should be as diverse as each team and each project. The fact of the matter is, wireframes are a collaboration tool.
One of the reasons we sketch out our ideas is to get a unified vision between several stakeholders. Putting together my first jigsaw puzzle as a child, I understood the importance of identifying the edges, and it’s often useful to demarcate different areas for navigation, content, and other functionalities—ensuring a collective vision by identifying the edges with the stakeholders in the room.
Adding detail to these sketches becomes more important the more distributed a team is. Typically a wireframe marks the first time a team is able to see how user, business, and technological requirements are being balanced in a project. The process of creating wireframes should be directed by an experienced professional, and should result in a collaborative concept, with input from the entire team.
How are Wireframes Created?
Every team dynamic is different, and different approaches for creating wireframes exist. Wireframes often start as sketches and evolve to include more and more fidelity, depending on how they are being used within a project.
For instance, initial sketches are often used to conduct user testing on paper prototypes before making any substantial decisions. The more decisions that are made with regards to design, functionality, information architecture, and usability, the more the fidelity of the wireframe increases.
When are Wireframes Finished?
As with most creations, it takes a true artist to determine when a wireframe is finished. Many things contribute to determining the fidelity a set of wireframes needs to have. Sometimes sketches are all that’s needed before prototyping in code can begin. Sometimes wireframes need to include every page and be pixel-perfect. Sometimes wireframes are presented in some form using a software emulator to illustrate what the experience would be in context. It’s important to trust that the team’s UX professional can determine what elements are most impactful to the user experience. This person will focus on fleshing out the most impactful elements, while leaving less impactful ones in low fidelity.
As with most creations, it takes a true artist to determine when a wireframe is finished
In the end, the team will decide if they feel comfortable moving forward with the project. If they do, the wireframes are done. The role the UX professional plays throughout the rest of the project will depend on the work that’s already been done. The more ambiguous a wireframe is, the more important it will be to include the UX professional as the project progresses.
Demarcation is the Art
Demarcation seems to be a common thread that runs through various types of art. Many forms of art begin to take shape through demarcation, and I believe demarcation is the art of creating wireframes. Like a jigsaw puzzle, a set of wireframes begins by identifying the edges, by distinguishing between different types of information and interfaces. As with most art, what may seem simple to say aloud is much more difficult to master. It’s relatively easy to put paint on a canvas, but creating a masterpiece can take a lifetime.
As with many forms of art, the products created by UX professionals are less important than their interpretation by an audience. Similarly, there are two traits that good artists and good UX professionals must possess: imagination and curiosity. Imagination gives us the ability to see problems from another perspective, and visualize solutions on the fly. Curiosity, specifically the passion to understand why people do and think what they do, drives us to develop solutions to meaningful problems.
We’ve been collaborating over drawings since we learned how to draw in the sand with sticks. Many people can more easily express and understand ideas presented visually than through words, and sketching and testing are always going to be a part of good product development. The question is: as new tools emerge to help us collaboratively design (and improve) products, will we still create wireframes? My guess is yes—we’ll still start with a demarcation exercise and add fidelity as we collaborate.
Image of puzzle courtesy Shuttershock
