The Case for Collaborative Wireframing

Imagine that you’re in front of a client presenting your wireframes. And about 1/2 way into the conversation you realize that their eyes are glazing over, or they’re nodding and smiling. But, no one is asking any questions.


You may suspect that this is because everyone simply agrees with you. But if you’ve been in this situation often enough, you may recognize that a lack of questions doesn’t always reflect agreement. More often than not, your audience simply doesn’t understand what you’re presenting, and has chosen not to point that out.


When you’re trying to communicate a concept at its very earliest stages, it’s essential that clients and teammates understand what you’re talking about. Often in those cases when there are no questions or suggestions, you leave the room thinking that you’ve got approval or signoff, and you go about the next step in your process. And then, when you come back to present designs, or something else that’s visually more compelling or complete, you find that there are a lot of questions which should have been resolved when you were presenting the wireframes.


And now, having worked for days or weeks defining and documenting the interactions for a very complex system, you have to spend just as much time explaining those interactions to other members of your design or development team, or other stakeholders. Or debating what you thought was settled. It’s as though all of your efforts spent producing a very detailed, in-depth set of documentation have been wasted!




Although you’ve taken the time to carefully walk your stakeholders through your thought process, and your well-reasoned approach, their input and feedback is coming late in the process. Although you’re collaborating, you’re doing so asynchronously. Each individual interprets the work in its current state, offers feedback or adjustments, and then waits for the next step in the process to offer more feedback.


Synchronous collaboration occurs when people are gathered in the same place at the same time during the creative process, conversing as much as they are contributing. The final output of this kind of exercise is an embodiment of the whole group’s intent, rather than an series of sequential interpretations and adjustments.


That’s what a wireframe should be: an embodiment of intent. It should capture what a group of people intend to bring to life. The more synchronous the collaborative process, the more likely that the intent is communicated with a shared understanding of its meaning.


Synchronising this collaborative process can raise important issues of ownership: We may ask, “who’s ultimately responsible for the wireframes?” But that’s not really the question we’re asking. Rather, it’s: who gets to decide? Who gets to decide what’s in, and what’s out? Who gets to decide what the right interaction is, or what the right label is? And when we talk about who gets to make the decision, it’s really kind of obvious that we’re talking about “who has the power?” Who has the power to enforce, ultimately, what may just be their opinion, regardless of how well informed it is?


Because synchronous collaboration happens in real time, that power accrues not to an individual, but to a group. You get the best decisions possible because more perspectives are taken into account. Granted it sometimes means that the loudest or most authoritative voice wins. But that tends to be less true in practice when there’s an actual physical product or visible artifact being created by a group.


To take a more concrete example: if we were all gathered around a set of building blocks trying to construct a tower, we could talk a lot about how it should be put together. We could discuss whether it made sense to start with the foundation, or the top – and some team members might have convincing arguments for each. But as we start to put the blocks in place, good ideas will tend to be recognized by the whole group right away because the tower gets taller and it doesn’t fall down. And if someone has an idea and it’s a bad one, it becomes obvious quickly because the tower falls, and we have to start over again.


When collaborative wireframing

When you’re collaborating in an environment where everyone’s contributions are visible in real time, it’s difficult to argue for a particular way of doing things, if you can’t show – then and there- why it makes sense. Does constructing a wireframe in real time, with everyone looking at the same artifact simultaneously resolve everything by itself? Of course not. But bringing a team together around the construction of a common vision will smooth the edges around an otherwise staggered process.
Rather than the best argument or the best set of assumptions winning out – or the final edits made by the last person who got to review the wireframes – the best idea in practice wins. Not only do you get a final embodiment of intent that everyone understands, it’s one that everyone agrees is the best possible solution.

  • When you present finished wireframes to stakeholders, ask: do they really understand what you’re showing them?
  • Collaboration requires more than just sequential input from different parties; it requires synchronous input.
  • Strive for collaboration that’s as close to real-time as possible, in order to capture a group’s true intent, and facilitate the filtering of the best ideas in practice.


Ben Levin

Ben Levin is a UX writer and content strategist at HotGloo. He’s been building and leading UX and Design teams for the last 15 years – including 2 long stints at interactive agencies.
You can find Ben on Twitter.


Author: Ben Levin

Ben is building and leading UX and Design teams for the last 15 years. Over the last 3 years he's been doing hands-on UX, user research, and collaborative design work with a great team at a large bank in Virgina, both in person and remote.