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