Who Comes to the Wireframing Party?

Involving as many people as possible in the wireframing process is important, but who, exactly, should we include in the collaborative process? How should we define their roles and responsibilities? Who should be invited to participate, and who should be required to participate?

 

Last time, I wrote about the case for collaborative wireframing, and why it’s an essential part of producing a better product and capturing the true intent of the team that hopes to bring that product to life. If you haven’t read that, take a few minutes and do so now.

 

There are a few obvious answers to at least some of the questions above, beginning with the required participants. Regardless of the titles held by various participants, there has to be at least one user experience professional involved.

 

Let’s call her, “Alice”.

 

Alice is a UX (or an IA, or an Interaction Designer – roles and titles seem to differ widely between organizations), and she focuses at least part of her time on making sure that the interfaces with which people will interact are considerate of as wide a range of needs and preferences as possible. Alice has either conducted some kind of audience research, or at least spent a good deal of time reviewing it. And Alice has a very deep understanding of the tools being used in the collaborative wireframing process.

 

So let’s talk about who gets invited to the party now, other than Alice. There are lots of candidates, and each could make a case for the central importance of their input. Where do we begin?

 

Or rather, where do we end? It might make more sense to start with an upper limit, to define the maximum number of chefs in the kitchen, as it were. Recently, I was responsible for the UX of a product that had monthly team meetings with hundreds of people present, all working on the same project, all looking to provide their unique input and direction. Such massively parallel planning required very careful and deliberate organization and facilitation – someone needed to be “in charge”, not necessarily of the outcome, but rather of the process.

 

The upper limit on the number of people who can be actively involved in a collaborative wireframing exercise comes down to this: how many people can Alice facilitate a conversation with? There’s a rather individualized answer to that question, and once you have it, you also know how many collaborative sessions you need to conduct, if the number of collaborators exceeds Alice’s Facilitation Carrying Capacity.

 

With that upper limit set, we can focus on who should be involved in a given session (assuming there are more than one – a topic we’ll return to later.)

 

I’ll propose some suggestions, based on various kinds of projects, and the different constraints associated with each:

 

  • A visual designer – if Alice isn’t also playing that role – should at least be present to offer feedback on visual constraints and the overall aesthetic of the product.
  • A developer, programmer, or technical lead – someone who can offer feedback and suggestions on technical feasibility.
  • A project manager should be present to provide feedback on timing and budgetary constraints.
  • Certain members of the client team, if there is one, are also essential. “Client” in this case means: whomever ultimately approves a project. Who writes the check?


You might be tempted to include the senior-most representative from the client’s team, maybe even the CEO, but what you really want is the person who’s been given responsibility for bringing the product to market. Or, someone they’ve designated with the authority to make decisions about the project.

 

What about the most important collaborators of all: the customers, or end users? Here’s where it gets tricky: you absolutely want customer input as early as possible, but you want to have something to show them in order to help elicit useful feedback. If you don’t have something tangible to show them, then inviting them to a collaborative design session won’t necessarily produce any really useful insights. You will need, instead, to focus on empathy and discovery, which you can do in a similarly styled kind of session. But wireframing out a solution is probably not what you need to do at this point; you’re still in the problem definition phase.

 

There is one common thread tying together all of the necessary participants: they are the people who ultimately bear responsibility for the end product. Many others may have important ideas and opinions about what the product should look like, but usually, a relatively small group of people are tasked with bringing that product to life.

 

What if you do have a very, very large group of people who are responsible for a product? Returning to my earlier example: if your product is huge, and there are many dozens or hundreds of people involved in its creation, then your challenge is to split that product into workable, discrete chunks that smaller teams can take responsibility for.

 

Keep in mind the foundational purpose of a collaborative wireframing process: to unify and synchronize the intent of a team; your goal is to gather those responsible for a product so that when their collaboration bears fruit, it can be presented – to a larger team, to a client, or to a customer – as the embodiment of the entire team’s best ideas.

 

When collaborative wireframing

 

  • When deciding to invite people to participate in a collaborative wireframing session, choose those who bear responsibility for the final product.
  • When inviting members of a client’s team, focus on the people who are invested with decision-making authority.
  • End users/customers have important input to offer, but only if you are in the problem definition or solution validation phases of your work. Collaborative solution definition requires a set of skills which not everyone has. Focus your interactions with customers on understanding their problems and the context in which they live. Don’t expect customers to solve their own problems.

 


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.