Achieving Alignment: Collaboration Versus Wireframes?

By Janet M. Six

Published: February 24, 2014

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our experts discuss whether wireframes can sometimes be a crutch that product teams rely on too much when trying to achieve alignment rather than becoming aligned by truly collaborating.

In my monthly column Ask UXmatters, our UX experts provide answers to our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: ask.uxmatters@uxmatters.com.

The following experts have contributed answers to this edition of Ask UXmatters:

  • Dan Brown—Information Architect and Principal at EightShapes
  • Drew Davidson—VP of Design at ÄKTA
  • Nathaniel Davis—Director of Information Architecture at Prudential Financial; Founder and Curator of DSIA Research Initiative and DSIA Portal of Information Architecture; UXmatters columnist
  • Pabini Gabriel-Petit—Senior Director, User Experience and Design at Apttus; Publisher and Editor in Chief, UXmatters; Founding Director of Interaction Design Association (IxDA); UXmatters columnist
  • Steven Hoober—Mobile Interaction Designer and Owner at 4ourth Mobile; author of Designing Mobile Interfaces; UXmatters columnist
  • Robert Hotard—Lead eCommerce Web Design Architect at att.com; Technology & Production Chair at TEDxSanAntonio
  • Jordan Julien—Independent Experience Strategy Consultant
  • Baruch Sachs—Senior Director of Human Factors Design at Pegasystems; UXmatters columnist

Q: Are wireframes sometimes a crutch that product teams rely on to get aligned when true collaboration is lacking?—from a UXmatters reader

“Some product teams that lack the ability or the will to collaborate attempt to align themselves around design deliverables—whether wireframes, mockups, or UX design specifications.”—Pabini Gabriel-Petit

“Some product teams that lack the ability or the will to collaborate attempt to align themselves around design deliverables—whether wireframes, mockups, or UX design specifications,” answers Pabini. “In such cases, product teams are likely bypassing envisioning and ideation altogether, which is when collaboration should primarily occur. As a consequence, they are unlikely to achieve true alignment, which assumes team members’ having a mutual understanding of both product requirements and users’ needs. This often happens in immature product-development organizations that do not allow sufficient time for planning, requirements definition, or design and, as a consequence, do not make essential decisions until it is too late in a product development cycle to realize them. Such teams often sacrifice quality and slip their schedules.

“Over-relying on wireframes in this way is also antithetical to agile or lean development—both of which rightly discourage throwing deliverables over the walls that sometimes exist between disciplines and instead call for a collaborative approach. Collaborative, multidisciplinary teams always produce the best results. In fact, this type of team is absolutely essential for innovation.

“Great product teams engage in collaboration at every possible opportunity during the product development lifecycle.”—Pabini Gabriel-Petit

“In contrast to such high-functioning, collaborative teams, I’ve seen a Development team take an adversarial stance toward Product Management and User Experience and demand complete, high-fidelity design deliverables from User Experience as a passive-aggressive means of deflecting requests for collaboration and teamwork. Ultimately, they ignored the design deliverables that the UX team produced, saying that there wasn’t sufficient time to make changes to their implementation—or, at best, cherry-picked whatever aspects of the design they wanted to implement. This co-opting of responsibilities for which other team members were much better qualified arose from the developers’ misguided and destructive desire to retain control over the entire product development process—despite the cost to the organization that employs them. The end result of such behavior is invariably an inferior user experience.

“Great product teams engage in collaboration at every possible opportunity during the product development lifecycle. In a successful collaboration, great ideas may come from anyone on the team, and the best ideas make it into the product regardless of their source, ensuring everyone’s buy-in to the design solution. Each discipline contributes its unique strengths and abilities and is responsible for making certain types of decisions. (For more on this, see my article ‘Sharing Ownership of UX.’) The hallmark of a successful collaboration is a synthesis of the team’s best ideas into a coherent user experience. Responsibility for creating a holistic user experience rests with the UX team. Fortunately, throughout my long career, most of my experience has been working with great, collaborative product teams and only rarely with dysfunctional teams like the one I described earlier. If you have the misfortune of working with such a team, take heart. The odds are your next project will offer a better experience.”

The Right Context for Wireframing

“When you do wireframing at the right time—very early on, during ideation—it should be the culmination of true collaboration from all disciplines—creative, business, and technical.”—Robert Hotard

In answer to our reader’s question, Robert says, “I hope not. Otherwise, you may be wireframing at the wrong time in the UX design process—be it waterfall, agile, or some hybrid process. When you do wireframing at the right time—very early on, during ideation—it should be the culmination of true collaboration from all disciplines—creative, business, and technical. It starts with boxes and arrows, or flow diagramming, on a whiteboard or in virtual space, to make sure you have considered design, usability, stakeholder goals, and technical integration points. You almost can’t avoid wireframing in this collaborative environment. A team naturally wants to draw out their ideas—for example, that piece of a page that shows where to place the form fields or how to lay out the major content groups. From that point, once you’ve drawn those page concepts, it’s up to your company to determine what process to follow and how those early wires should evolve—whether low fidelity or high fidelity.

“Wireframes can become a crutch and, in fact, a barrier to true collaboration and iterative design. … Then you have the false alignment of teams that will gladly agree on a completed wireframe’s interactions instead of contributing to the creation of the overall solution.”—Robert Hotard

“On the other hand, if you are referring to teams that are working on maintenance updates or small, added components of functionality—as is common in agile scrums—then, yes, wireframes can become a crutch and, in fact, a barrier to true collaboration and iterative design. This can become what I call a folded-arms design mentality: ‘I’m not going to work on my comp till your wireframe of that new page is done…. I’m not going to write content, code the façade, or whatever.’ Then you have the false alignment of teams that will gladly agree on a completed wireframe’s interactions instead of contributing to the creation of the overall solution.

If this is the case on your team, take it upon yourself to reach out to the other team members and bring them into a collaborative design session. You can either wireframe on the fly—if you’re comfortable with that pressure—or have a few concepts ready to go beforehand. I’ve always found that, coming out of a collaboration session, I could have very rough drafts of wireframes that I could then refine before presenting them to the larger team. Now, everyone begins to have a stake in the solution, and alignment comes from true collaboration.”

Wireframing as a Tool for Collaboration

“Through collaboration, different members of a team contribute ideas, challenge each other, and move a project forward. Wireframes can help you to do that for certain design decisions.”—Dan Brown

“Wireframes are a design tool,” replies Dan. “In and of themselves, they are neither positive nor negative. Their value is in their use and application. Any design artifact—whether wireframes, mockups, personas, or prototypes—can be used as a crutch, but I’m unclear on how collaboration would be lacking as a consequence of wireframing. Lacking collaboration means a team isn’t engaging in discussions about design decisions. Through collaboration, different members of a team contribute ideas, challenge each other, and move a project forward. Wireframes can help you to do that for certain design decisions.

“The converse—project inertia—wouldn’t be the fault of the design artifact, but the fault of the project’s lead or manager. What slows a project down is avoiding discussion of decisions, wasting too much time on certain activities, or investing in artifacts that have no impact on project direction. When used appropriately, a good wireframe is a crutch, but in the sense of providing a support for the design process. Like any artifact—it’s a catalyst to the discussion about design decisions. Experienced UX designers and project managers know the limits of activities and artifacts, so they can determine where best to invest the team’s time.”

“Once you create and present a shell for a solution, it becomes hard to break free of that shell.”—Baruch Sachs

“While wireframes are not a crutch, they sometimes are a stalling tactic for development and UX people,” says Baruch. “If everything needs a wireframe, delivering a complete set of wireframes can become a huge sticking point on a project. Developers may say that they cannot do anything until they see a wireframe. Designers may want to talk around a wireframe instead of brainstorming new ideas. Once you create and present a shell for a solution, it becomes hard to break free of that shell. However, wireframes can also be a great focal point for an otherwise dysfunctional team. You have some tangible output from the design process and, if you have mature developers and designers who are truly collaborative, wireframes actually become a tool for collaboration.”

“The best collaboration occurs on cross-functional teams, working in the same physical location.”—Jordan Julien

“I’ve been searching for true collaboration for the past 15 years,” says Jordan. “I’ve found that the best collaboration occurs on cross-functional teams, working in the same physical location. But I’ve seen some really fantastic work come from distributed teams as well. I guess I’m suggesting that we should think of collaboration as a spectrum rather than a finite set of variables. I’ve seen fantastic collaboration on teams that created and utilized wireframes to unite the team. They weren’t a crutch; they were the product of collaboration. Why not jump right into prototyping as the product of collaboration? Not everyone on every team has the technical skills to produce a functioning prototype. But everyone has the ability to sketch something and write down some ideas. At their simplest, that’s all wireframes are—sketches and notes.”

Design Documentation’s Role in Collaboration

“Too often, wireframes are really just comps, or drawings with little or no explanation. These very often represent the antithesis of collaboration, with a design team locked away, creating pixel-perfect screen drawings.”—Steven Hoober

“I can imagine this happening, but I’ve never seen it,” proclaims Steven. “First, let’s talk about documentation methods. Wireframes are pretty non-specific. I create what I call UI Specifications and have worked with many, many others who do much the same. Creating design documents with copious annotations to explain and define a user interface and its interactions can help ensure that you think through a design and brings design onto the same footing as development. Quality Assurance can test against UI Specifications and open bugs to ensure Development’s compliance with the design.

“Too often, wireframes are really just comps, or drawings with little or no explanation. These very often represent the antithesis of collaboration, with a design team locked away, creating pixel-perfect screen drawings. Certain processes empower collaboration, but only one person at a time can do most steps of detailed design. That means you need a spirit of collaboration, engagement, questioning, and sharing. No design process, even drawing on a whiteboard or going straight to prototyping in code is automatically a collaborative process.

No design process, even drawing on a whiteboard or going straight to prototyping in code is automatically a collaborative process.”—Steven Hoober

“I always start by asking lots of questions and try to share my designs as early as possible,” continues Steven, “to ensure everyone is on the same page. When an organization is structured to keep team members apart and I have to explain a design, I spend more time explaining how it’s simpler than it appears than anything else. I strongly believe in design documentation. That coupled with a good design and development process can encourage collaboration and teamwork at least as much as any competing approach. If someone can get away with using any document—not just design documents like wireframes—to force compliance with decision making that occurs outside the team, that would seem to point out flaws in the organization instead of pitfalls in the document.”

“A wireframe is fundamentally a tool for collaboration. For UX designers who rely solely on creating wireframes because they are unable to apply the appropriate methods for stimulating alignment and collaboration, wireframes can be a crutch.”—Nate Davis

“In the design of user interfaces, complexity warrants documentation,” advises Nate. “Imagine having to design the architecture for a skyscraper. Since the person who designs the skyscraper surely won’t be the person who builds or maintains the building over time, a blueprint is essential. Likewise, when necessary, well-documented wireframes—which can be either static or dynamic—help content owners, designers, and developers to understand how to build and maintain user-interface attributes and behaviors.

“A wireframe is fundamentally a tool for collaboration. For UX designers who rely solely on creating wireframes because they are unable to apply the appropriate methods for stimulating alignment and collaboration, wireframes can be a crutch. Fortunately, gaining experience and having a desire to learn are still the best cures.”

Achieving Clarity Through Wireframing

“The discussions that follow the creation of wireframes are usually among the most fruitful and collaborative that I’ve experienced on projects because everyone now has a common frame of reference.”—Drew Davidson

“I’ve never experienced a situation where wireframes were a crutch for poor collaboration,” responds Drew. “Far more often, I see wireframes helping collaboration. Oftentimes, stakeholders think they’re collaborating on a concept and are in complete alignment, but when they see the wireframes, they realize that they were all thinking about the solution differently. The discussions that follow the creation of wireframes are usually among the most fruitful and collaborative that I’ve experienced on projects because everyone now has a common frame of reference.”

4 Comments

Any time you produce wireframes, whether a concept or as part of a detailed interaction design specification, you create a shared cognitive artifact for all team members to potentially interact with. By externalizing the designer’s cognition and intent, we are better able to reflect and react to it, and ideally make improvements to it. These improvements can come from heuristic evaluation, user feedback, or feasibility assessments, which are all much easier to do when you have a shared cognitive artifact. In addition, separating the thoughts and intents of the designer from the person themselves allows for critique and improvement without it being as personal as when ideas are only verbally discussed or, when the design artifact is so far along, it looks more baked than it is.

If there are serious collaboration problems in the culture, wireframes may or may not help. The rest of your design/development process needs to be considered with respect to solving that problem.

What I found very useful to facilitate discussion and knowledge transfer is to make use of a product backlog and a good tool.

We use Jira to facilitate the discussions in all phases of the design and development process. So when a feature is just an idea, we collect all information in a user story (Jira issue). When needed, we add wireframes to makes things clearer and also add design elements, if necessary. The whole team sees the stories, so development can give their input even when they’re not working on the project full time, as I do.

We use a concept of daily mini-design workshops—20- to 30-minute timeboxes—for the team to transfer knowledge and discuss possible solutions and estimate their impact on development. All findings are registered in Jira.

When the team thinks a user story is ready, the development team starts estimating. When needed, the story is split into more specific stories to get the story done. In my opinion, it really does not matter what technique you use, as long as you keep the conversation going.

Great discussion! Thanks!! Let’s keep the conversation going.

Good conversation here. I agree with the commenters that conversation, collaboration, communication, and coordination are all required—and the artifacts!

The artifacts are the hard part, I think, because they’re externalized and can be ignored. Nevertheless, they are essential and required because things cannot be overly wishy washy, pie in the sky, or personal.

For me, the essential artifacts of a successful development effort are A) well-written meeting notes, proving that people can talk and listen; B) wireframes, proving that there is a shared understanding of what the thing could actually look like; and C) use cases, demonstrating how the thing should behave and for whom.

Getting clear with the team on who the users are, their needs and motivations, their use cases, and how they’ll accomplish those through the screens is the story that needs to be told. Ultimately it’s about being good storytellers and working together as teams to get the necessary parties to understand and agree on the who, what, and why of the solution—and for some, they really need to know the how intimately.

Join the Discussion

Asterisks (*) indicate required information.