As management guru Ken Blanchard notes, “None of us is as smart as all of us.” Unfortunately, many teams operate in silos, where multidisciplinary collaboration and problem solving do not inform experience design. The cross‐functional collaboration play helps you dismantle these silos and ensure that the right internal partners share the right knowledge, processes, deliverables, and visibility at the right time. Breaking down these silos will reduce churn and increase productivity and ultimately ensure that sound decisions are made to achieve experience design goals.

Who Are the Key players in the Cross‐Functional Collaboration play?

ROLE	WHO’S INVOLVED	RESPONSIBILITIES
DRIVER	Experience strategist	Orchestrate collaboration across the organization
CONTRIBUTOR	Product manager, experience practitioners, engineering lead, and peer practitioners from other parts of the business (sales, marketing, customer support, etc.)	Provide necessary inputs, expertise, and perspectives for problem‐solving; Participate in cross‐functional discussions and workshops; Bring the necessary artifacts to the table.

THE HOW

To run an effective cross‐functional collaboration play, you need to be mindful of:

1. The EXPERIENCE VISION

The experience vision is always the north star for experience design. It encompasses an understanding of who your users are, knowledge of your business goals, and an understanding of your competition (Chapter 20: “Experience Vision Play”).

2. Relevant PARTNERS

Recent research has demonstrated that horizontal relationships actually are more important. This is why user experience design encompasses more than just product touchpoints: peer practitioners parallel to the design team need to be involved.

Identify peers from various departments who need to be aligned on the product and user goals, and who will have inputs into the processes and activities to achieve those goals.

At minimum, the collaboration trifecta of product manager, engineering lead, and experience practitioners must partner with one another. This core team should have a regular cadence to share knowledge and feedback.

However, true value will be driven when more representation is included from a wider team: other collaborators, influencers, and supporters such as peer practitioners (sales, marketing, customer support), CEO, executive leadership, and the board of directors. Establish a regular cadence with this wider team, as well.

3. A SHARED UNDERSTANDING of the User and Business Context

To achieve product innovation that is rooted in driving value for both your users and your business, ensure that your collaborators have a shared understanding of the following:

• Who your users are (Chapter 14: “User Empathy Play”);
• What the vision for the experience is (Chapter 20: “Experience Vision Play”);
• What your experience metrics are (Chapter 28: “Experience Metrics Play”);
• What the user and business goals are (Chapter 33: “Experience Design Brief Play”).

In a user‐first approach, organizations curate and disseminate a deep understanding of and empathy for their users and their experiences—before authorizing internal groups to make any product decisions. For example, shift the line of thinking from “I’m in finance; how does the user affect me?” to “I’m in finance; what can be done on my side that is part of creating a meaningful experience for the user?” Partners should be able to answer this question, as well as propagate information on the user, the vision, goals, and metrics within their own teams.

4. SHARED PROCESSES

To design and develop great end‐to‐end product experiences, identify the processes that partners need to be part of to ensure visibility and accuracy of information.

These processes include:

• Collaboration Planning: Create a product experience plan to bring the experience vision to life (Chapter 35: “Product Experience Planning Play”). Ensure collaboration is happening between product, user experience design, and engineering. Identify a driver that is accountable for the activity taking place and the outcomes being achieved.
• Take a cue from agile software development: It calls for multi disciplinary teams (“scrums”) to take an iterative approach and collaborate in the construct of “sprints”—a timeboxed duration given to complete a set amount of work.
• Communication at Large: Establish a communication channel or channels by which to engage and inform core and wider team members. For example, the core team may have a dedicated chat channel for day‐to‐day questions and updates, while the wider team may be best communicated to as a group through email.
• Feedback: Determine how to capture feedback from multiple disciplines during various stages of the product development process. For example, feedback can be given in live design reviews, as comments on artifacts, and/or as tickets on JIRA.
• Approvals: Determine how sign‐off from approvers is conveyed, how it can be traced, and how it moves from one team to another. For example, tracking approvals can be done by moving an item on a Kanban board or changing the status of a ticket.

5. SHARED ACTIVITIES

In the design and development process, define and plan the activities where it is vital to have multidisciplinary representation and inputs at the table. The intent of this is to break through information silos and get expertise input at the right time. These activities can include:

• Kick‐offs to launch new projects/sprints/phases of a project;
• Design reviews to elicit feedback from product management, engineering, SMEs, and other wider team members;
• Ideation workshops to effectively extract ideas and ward off tunnel vision;
• Design hand‐offs to the development team (Chapter 42: “Design System Play”);
• User research readouts to socialize research insights to the wider organization to build user empathy and keep others informed;
• Cross‐functional retrospectives to allow the multidisciplinary team to check in and course‐correct;
• Design QA to check the engineered build against the designs delivered (Chapter 43: “Design Quality Assurance (QA) Play”).

Track all shared activities in a deliberate manner by having an identified driver. This should be done with the help of a product experience plan (Chapter 35: “Product Experience Planning Play”).

True collaboration happens when relevant teams are given a stake in the product experience design process. Core team members should be involved, not just informed, and should hold each other accountable. Information should be registered, not just read. True collaboration becomes evident when:

• A common language starts being spoken;
• Everyone can rally for the vision and end goals;
• Multidisciplinary inputs are baked into deliverables/artifacts;
• The end result catches no one by surprise.

6. A SHARED REPOSITORY of Curated Artifacts

Finally, it is imperative that all partners have access to shared artifacts, whether they be research insights, requirements, roadmaps, design artifacts, meeting minutes, or documentation of processes.

Establish a repository of this information and communicate how it can be accessed. Set aside a few minutes each week to ensure it is updated.