Achieving Alignment: Collaboration Versus Wireframes?

Ask UXmatters

Get expert answers

A column by Janet M. Six
February 24, 2014

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: [email protected].

Champion Advertisement
Continue Reading…

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; 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,” 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 essential for innovation.

“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

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.

“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

“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.”

“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.”

“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

“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.

“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.”

“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

“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.” 

Product Manager at Tom Sawyer Software

Dallas/Fort Worth, Texas, USA

Janet M. SixDr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research.  Read More

Other Columns by Janet M. Six

Other Articles on Communicating Design

New on UXmatters