Cross-Functional Team Summary

Multiple moving parts and teams in a project can take the focus from a solution to confusion or worse, chaos. I discuss the work stream perceptions and how I, as an experience designer, drive focus to communication and alignment to move the team in a positive direction.

Key Points
  • I focus on transparency in information sharing to align teams
  • As the communication conduit, teams collaborate and work towards success better when UX is involved

Function or dysfunction?


I only know what I was asked to do but am not sure what others are doing; what are you doing? This is a question that comes up frequently from teams at the start or during a project. Teams are thrown into projects without an understanding of why their team was chosen for the project or what value they are expected to deliver. This lack of knowledge is exasperated by limited communication between work streams and no one really knowing why there are so many work streams on the project at once. Being part of a large project team can feel like many people working to deliver something with no requirements, direction or plan.

Limited focus on the direction toward the true goal of the project leads to chaos for work streams. Team members should remain aware of the other work streams and be mindful of how their work impacts others. This is not just applicable to project deliverables, but also to individual team members’ experience and their areas of expertise. Work stream alignment and collaborative communication build strong project teams. Building strong teams starts with a strong grasp on the attributes of the various work streams. In my experience, work streams usually fall in one of these general categories:

Example graphic of data points identified for cross functional teams.

Local delivery


Considered an “onshore team”, this work stream category represents the team that holds most of the domain knowledge for the technology solution being developed. The team member roles range from development, quality assurance, project/program management, and delivery support. In this range of experience, these team members have encountered changes in requirements, stakeholders, and project management. This can often lead them to be skeptical of new work streams and their ways of working or thinking.

With their depth and breadth of experience, some of the members of this team may be “set in their own habits” of working and delivering. They may also be resistant to engage in open conversations about the project goals and deliverables. If project does not succeed, the burden of supporting the technology will be left on their plate. These concerns can sometimes overshadow the hard work and diligence they possess in delivering quality projects for the company and team. Fear of scope creep from experience design teams can further add pressure.

Picture of whiteboard session discussing ownership in delivery process.

Long distant delivery


Generally dubbed “offshore”, this work stream category represents the team located furthest away from the stakeholders and the end users of the technology solution. The team makeup can consist of developers, quality assurance, project/program management, and delivery support. They tend to receive task directives, and not capability enablement direction. With cross-cultural and time zone considerations in place, they tend to be hesitant to provide insight beyond what is expected of their team.

Within a results-based relationship with local delivery teams, the focus is on accurately meeting requirements, and not on looking for accuracy in the requirements as they are written. These concerns take center stage in front of their desire to effectively deliver a steady stream of work that reduces roadblocks for other work streams. Changes from the experience team and risks raised by local delivery teams add to the confusion in this team’s direction.

Experience design


This team usually encompasses digital strategy, user experience research, user experience architecture, content strategy, visual design, and front end development competencies. They are considered the “user’s champion”, which attaches a perception that the team does not concern themselves with the details of how something will be done, but expects all of their wants and need-to-haves to be met. This perception is perpetuated by the occasional creative direction being “thrown over the fence” for the delivery teams to manage without any real guidance.

Additionally, a lack of a solid foundation in the technology being used to develop the solution is also common. Balancing these perceptions along side lofty, innovation expectations from users and stakeholders can make for a stressful team environment. When tensions run high close to deadlines or milestones, the experience design team tends to slink into a creative flow without regular feedback or check-ins with delivery teams.

Areas where experience design capabilities improve team delivery.

As an experience design team member, communication and alignment are high priorities for me. Communication enables us to align project goals amongst all work streams. Alignment can be achieved through persona development, annotated documentation, workshops, and other design artifacts. Associating a mockup with a set of requirements, for example, can bridge the understanding of the requirements to a positive user scenario. Communication can be further enhanced by tighter feedback loops that allow ideas and vague requirements to fail fast and rally the team to provide higher quality requirements. Transparent communication is facilitated among teams by sharing information and knowledge as it is gained.

Screenshot from slide deck I created to explain UX work to middle school students.

I prefer a shared vision of the scenarios we need to support for our user to be successful with the technology solution. I also like to give people a sense of awareness of their contribution within their team and their team’s contribution to the project. Knowing how to support your team and how your team supports other work streams can be a pivotal point of understanding in whether the project is successful or not. As a designer, I have the awesome opportunity to share different ways of communicating success to not only the user, but the teams working toward the success of the project and the user.