“Effective collaboration is essential to creative teamwork—especially for multidisciplinary teams,” advises Pabini. “In a two-part series for my Leadership Matters column, ‘Overcoming Common Barriers to Collaboration,’ I discuss how to overcome the following common barriers to collaboration:
- A lack of respect and trust
- Different mindsets
- Poor listening skills
- Knowledge deficits
- A lack of alignment around goals
- Internal competitiveness
- Information hoarding
- Organizational silos
- Physical separation
“Only by eliminating these counterproductive cultural barriers can an organization foster alignment, collaboration, and information sharing.”
“Effective communication is the #1 principle to ensure team success—whether within your own team or across departments or projects,” replies Carol. “Being an effective communicator means being strategic about how much and how often you connect with team members or colleagues. No one wants to be inundated with emails or messages. At the same time, no one wants to be left out of the loop for need-to-know information.
“Striking the right balance is critical. For each message you send out, start by planning what you want to communicate. Make sure your main ideas are at the start of a message. Then follow up with details that message recipients might or might not need. Organize your communications, using effective writing techniques. Include headings, bulleted lists, and images where appropriate. If you’re responding to a long email thread, change the subject line to match the current content.
“Choose the right communication channel,” continues Carol. “Does your team prefer handling communications on a Slack channel, a project-management tool such as Trello, or an email group? Whatever channel you choose, provide the chance for people to opt out, depending on their interest in a particular project. Do not assume that everyone wants to be included in every project.
“For interdepartmental projects, reach out to stakeholders to inform them about your project work and determine their level of interest in the communications you and your team members generate. It might be that they would want direct involvement or, in contrast, no involvement. Reaching out to them at the start of a project lets you determine how and whether you should communicate with them about that project. But, for your next project, don’t assume that you understand their interests. Instead, reach out again, so you can learn about their level of interest in your new project.”
At Ax-Stream, we have long recognized that one of the big problems in the software-development lifecycle (SDLC) is communication—particularly between different groups and departments and especially between UX design and development,” says Ritch.
“There are two principles that are key to addressing communications: The first relates to tools. Reduce the number of tools a team uses on a project, particularly when interfacing between groups. For example, we do all our UX design work within an Axure team project, then our development teams use that very same team project as the sole source of specifications from which to develop working code. This increases our SDLC efficiency by massively reducing the development team’s interpretation errors.
“The second principle is to use multiskilled leads—people who have experience working downstream of the group they are leading. For example, all of our UX design leads also have experience in development. Therefore, we advocate that all disciplines get involved much earlier in the SDLC than is normally the case. For example, early in the design process, lead developers validate the technical viability of design concepts, preventing UX designers from wasting time detailing infeasible designs. They also help optimize designs by recommending standard user-interface controls and patterns. This principle is part of a broader philosophy that we call left-shift, which means doing everything as early as possible when it is cheaper to fix problems!
Ritch suggests, “My UXmatters article ‘(Why) Is UXD the Blocker in Your Agile UCD Environment?’ has some relevance here—particularly in relation to working within a UX group.”
“So much of working well together depends on the ability to maintain consistent, open communication between team members,” suggests Amanda. “It is helpful for everyone to be together, get along, and have biweekly design critiques that align everyone on decisions and foster better communication. These design critiques ensure that we’re all in the loop on what each of us is working on and spark discussions that would not otherwise have surfaced. The ability to share information with interdepartmental or outside teams is important. I have found that teams are more effective when upper management supports cross-team collaboration.”
Aligning on Goals and Solutions
“Each organization works differently from other organizations,” acknowledges Andrew. “So you’ll need your own company-wide and department-level principles and practices. Teams that are working toward the same goals, following the same principles, inherently work better together. One of the most helpful resources I’ve found on this topic recently is the podcast Intercom on Product: ‘The Principles Behind How We Build.’”
“One risk of a lack of collaboration and alignment on project goals is that stakeholders might reject a design solution that a UX designer has created unilaterally,” warns Pabini. “Such a design could fail to meet business requirements or might not be implementable by the development team—for example, because the solution is incompatible with a development framework the developers are using or because it’s not possible to implement the design within the necessary timeframe.”
“Having UX designs rejected implies that the designs were tossed over the wall to the powers that be, who review it on their own, then come back with a yes or no decision,” replies Cory. “That’s not the way things should be. Rather, UX design should be collaborative, involve stakeholders as much as possible in initial design decisions, and ensure their continued involvement every step of the way.
“Sure, stakeholders might want to make some changes to designs if there have been miscommunications—or just incorrect assumptions—or they encounter unforeseen politics. However, these should not result in a design’s rejection, but simply suggested revisions as you iterate and improve the design. Then, hopefully, you’ll test the design with representative or actual product users.”
“The root cause of a flat-out rejection of a UX design is likely a process that needs more communication and collaboration,” suggests Andrew. “When you work closely with product managers, engineers, and other stakeholders, the project team marches forward in unison toward an outcome.
“For more tips on improving communications, presenting designs, and achieving agreement, I suggest that you read Tom Greever’s Articulating Design Decisions. You can read a sample chapter on UXmatters.”