Join us

Cross-Functional Teams

Your constantly-updated definition of Cross-Functional Teams and collection of videos and articles. Be a conversation starter: Share this page and inspire others!
88 shares

What are Cross-Functional Teams?

A cross-functional team includes members with different skills, expertise, and levels working towards a common goal. The team's diverse backgrounds contribute to a comprehensive understanding of problems, which enhances the likelihood of reaching optimal solutions.

Laura Klein, author of Build Better Products and UX for Lean Startups, explains how cross-functional teams work and how they differ from functional teams in this video:

Show Hide video transcript
  1. 00:00:00 --> 00:00:30

    Cross-functional teams, unlike silos, have all the people necessary to build a specific thing together. Let's look at an example. Imagine you're on a team that is supposed to build the onboarding flow for a new app that helps connect job applicants with jobs. You can't build the whole thing with just designers. Or with just engineers, for that matter. I mean, you probably could do it with just engineers, but it's a terrible idea.

  2. 00:00:30 --> 00:01:00

    A cross-functional team for this onboarding work might include a few engineers, perhaps some for the front end and some for the back end. Might include a designer, a researcher, a product owner or manager, maybe a content writer or a marketing person. In an ideal world, all of these folks would only work on this particular team. In the real world, where we actually live, sometimes folks are on a couple of different teams and some specialists may be brought in to consult. For example, if the team needed help from the legal department to explain some of the ramifications of a specific decision,

  3. 00:01:00 --> 00:01:32

    a cross-functional team would have a dedicated legal expert they could go to. But that legal expert might also work with lots of other teams. In agile environments, the cross-functional team generally sits together or if remote, has some sort of shared workspace. They all go to the required team meetings. They understand the goal of the team and the users. They're experts, or they soon become experts, on that onboarding flow. Contrast this to how it might be done in a siloed environment. In that case, you might have different people assigned to the team depending on need, which can seem really flexible.

  4. 00:01:32 --> 00:02:00

    Until you realize that you end up with five different designers working on the project all at different times and they all have to be brought up to speed and they don't really understand why the other designers made the decisions that they did. Same with the engineers. And do not get me started on legal. Silo teams tend to rely more on documentation that gets handed between groups. And this can lead to a waterfall project where project managers or product managers work on something for a while to create requirements, which they then hand off to designers who work on designs for a while

  5. 00:02:00 --> 00:02:29

    and then they pass the deliverables on to engineering, who immediately insists that none of this will work and demands to know why they weren't brought in earlier for consultation. You get it. By working in cross-functional teams instead, the people embedded on the project get comfortable with each other. They know how the team works and can make improvements to it. They come to deeply understand their particular users and their metrics. They actually bring engineering and even design and research into the decision making process early to avoid the scenario I described above.

Table of contents
  1. What are Cross-Functional Teams?
  2. How Do Cross-Functional Teams Differ from Traditional Team Structures?
  3. Advantages of Cross-Functional Teams in Design
  4. Challenges of Cross-Functional Teams
  5. How to Implement Cross-Functional Teams Effectively
  6. When Not to Implement Cross-Functional Teams
  7. Learn More about Cross-Functional Teams
  8. Questions about Cross-Functional Teams

How Do Cross-Functional Teams Differ from Traditional Team Structures?

Traditional team structures are usually functional, where team members share similar skills and expertise and perform similar functions. For example, a company might have a design team, an engineering team, a customer service team, etc.

A functional team has a manager who has a similar background and understands the team members’ roles and responsibilities.

Functional teams have a clear leadership structure. In large functional organizations, managers might assign team members to different projects, depending on their expertise and availability. Even if assigned to different projects, team members report to the departmental manager. This approach, however, can lead to a siloed organization where teams don’t interact with each other.

Cross-functional teams seek to break these silos and foster greater collaboration between teams. When people across different departments come together, the group gains multiple perspectives.

© Interaction Design Foundation, CC BY-SA 4.0

Functional and cross-functional teams have advantages and drawbacks that suit different organizations and projects. Here is a comparison between the two types of teams.

Functional Teams

Cross-Functional Teams

Composition

Team members share similar skills and expertise and perform similar functions.

Team members have different skills and expertise and perform different functions.

Alignment

Teams align themselves to the goals of the function or department.

Teams align themselves to the goals of a project.

Management

The manager usually shares similar skills as the team members. Teams have a clear leadership hierarchy, and members report to a single manager.

The team has a project manager who might be from a different department than most team members. The reporting structure is unclear, as team members might need to report to their departmental managers and the project manager.

Collaboration with Other Departments

The organization can become siloed, where one team doesn’t know what the others are doing.

Fosters deeper collaboration between people of different functions.

Communication

Since team members have a similar knowledge base, they share similar jargon and can communicate within the team easily.

Team members have different skills and expertise, use different terms, and have different work styles or approaches to problem-solving, which may cause friction and conflicts.

Scope of Work

Work within their domain or department and usually have a more specialized and narrow scope.

Work on projects or initiatives that span across multiple functions. Their scope is often broader and more strategic.

Flexibility and Innovation

Teams are focused and efficient in their specific area but might be rigid, thus reducing innovative thinking outside their field.

Often more adaptable and innovative. Team members’ diverse perspectives and expertise make such teams suitable for tasks that require creativity and interdisciplinary knowledge.

Duration

Often permanent and focuses on ongoing tasks and objectives within their functional area.

Frequently assembled for a specific project or initiative and may be temporary, disbanding once the project is complete.

Advantages of Cross-Functional Teams in Design

In this video, Frank Spillers, CEO of Experience Dynamics, dives into the importance of co-creation, especially in service design. He highlights how collaboration among cross-functional teams can drive innovation and success.

Show Hide video transcript
  1. 00:00:00 --> 00:00:31

    A lot of service design actually happens in workshops. And I think maybe it's the 'kiss' that service design has had with design thinking. And a lot of design thinking happens in workshops, in a workshop format. These are very interactive, lots of stakeholders, lots of sticky notes, affinity diagrams, personas, journey maps,

  2. 00:00:31 --> 00:01:03

    discussions, prioritization-weighting exercises, going through the business model canvas with your team, with your stakeholders – all really, really important. And they make up a huge part of service design. That's not enough – you have to follow through to execution. But let's spend some time on workshops and collaboration and what's called "co-creation" because there's a really important role here. So, co-creation is central.

  3. 00:01:03 --> 00:01:33

    Everything in service design is co-created. And what that means is that *you're doing this with stakeholders*. Just like with those two canvases, you want to use those with your stakeholders and teams to get the most leverage from the conversations, the discussions *and* the knowledge, the information, the contribution but also the problem solving of your team. People from different vantage points will bring

  4. 00:01:33 --> 00:02:00

    different *information*, different *solutions* and different *levels of ownership* to the problem. I mean, think about it – if your executives or someone who's a head of operations or support or whatever – if they're involved and they're listening to the customer pain points that you're introducing – those pains and gains – if they're part of the business model canvas discussions,

  5. 00:02:00 --> 00:02:30

    they're going to have a stake in how it gets delivered, and they're going to want to influence it, they're going to want to be part of that, as opposed to being on the side and being called in waterfall-style at the very end. So, it's important to do this work with your colleagues – that's co-creation. Of course, the other piece of co-creation is doing this ideation with your customers, and so, bringing your customers in and testing your service prototypes with your customers

  6. 00:02:30 --> 00:03:01

    becomes part of that. Understanding a service value proposition, the data, the processes, the procedures, the workflows and constraints – all that stuff is going to come out of your interaction with your stakeholders. What you're looking for from co-creation I think is not only the beauty of that cross-pollination but also the alignment that you get from that. Ultimately, I think what you're designing is a *culture of service design*

  7. 00:03:01 --> 00:03:30

    so that your delivery of a service is not just what happens outside to the customers, but it happens inside to the way the company thinks and makes decisions about products, about business models, about revenue streams, about the innovation that a design approach – you know – that divergent thinking – it's one of those things that with design thinking – which is a very popular tool used in service design – is just getting people to

  8. 00:03:30 --> 00:04:02

    do divergent thinking and not jump to solutioning; to actually spend time in the empathy of customer pain points can be a *huge* transformational shift. So, the other strategy or key is aligning your service design teams, especially if you have multiple service designers. For me, one of the keys with service design is *congruency in execution*. There are those of you who have different service designers working in different areas, bringing that into a cohesive strategy and cross-pollinating

  9. 00:04:02 --> 00:04:28

    is a huge challenge. It's not trivial. But it's one that comes down to how you design service design within – *within*. The other key is aligning agile to UX, especially if you have a digital delivery component. And, at the end of the day, you're going to introduce new ways of doing business. That's going to mean disruption. So, I really think a culture of service design is required.

  1. Diverse expertise: Cross-functional teams bring together members with a wide range of skills and knowledge from different functional areas of the organization. This diversity of expertise enables the team to tackle complex problems and challenges that require a multidisciplinary approach.

  2. Beginner’s mindset: Each team member has expertise in their domain, which might lead to blind spots and assumptions. When people from different backgrounds come together, they offer a fresh perspective and approach each other’s domains from a beginner’s point of view, thus challenging beliefs and assumptions.

  3. Fewer handoffs: In traditional teams, resources (such as a designer or researcher) might work on a project temporarily and then move to the next one. To help the next designer, the outgoing team member creates a handover, usually a document. These handovers sometimes can cause misunderstandings and confusion. A cross-functional team comes together for a specific project, which reduces the need for handoffs and potential confusion.

  4. Innovation and creativity: The design thinking methodology advocates for cross-functional teams. The combination of diverse perspectives fosters innovation and creativity. Team members can brainstorm ideas, challenge conventional thinking, and develop novel solutions that might not be possible in teams with a more limited focus. 

  5. Aligned with business goals: Unlike siloed departments, where teams might lose sight of the larger picture or move in different directions, cross-functional teams share a common vision.

  6. Comprehensive problem-solving: Cross-functional teams can consider all aspects of a problem, from technical and operational to marketing and customer-related concerns. This comprehensive approach often leads to more effective solutions.

  7. User-centric focus: When people from different teams come together, everyone can see how each department influences the customer journey and experience. This holistic approach leads to better products, services, and user experience.

    © Interaction Design Foundation, CC BY-SA 4.0

  8. Faster decision-making: Cross-functional teams can make decisions faster than traditional hierarchical structures. With all relevant expertise in one unit, there’s no need to wait for approvals or information from different departments. This is particularly relevant for agile teams.

  9. Flexibility and adaptability: Functional teams will likely have their priorities and may not be available at the same time for urgent scenarios. On the other hand, cross-functional teams don’t depend on multiple departments—they have all the required expertise within the team. Hence, they can adapt quickly to changing circumstances or market conditions. They can pivot their strategies and tactics more easily than siloed teams.

  10. Enhanced learning and development: Team members from different backgrounds can learn from each other, which leads to professional growth, skill development, and a broader understanding of the organization.

  11. Increased accountability: Team members are often more accountable for their contributions in cross-functional teams because their work is visible to the entire organization. This accountability can lead to higher-quality outcomes.

  12. Higher employee engagement: Working in cross-functional teams can enhance job satisfaction and engagement, as employees have a sense of ownership and impact on the outcomes of their collaborative efforts.

Challenges of Cross-Functional Teams

While cross-functional teams offer many advantages, they are not without their disadvantages. Organizations need to be aware of these potential drawbacks and address them effectively to ensure the success of such teams. Here are some disadvantages of cross-functional teams:

  1. Conflict and tension: Diverse perspectives, expertise, opinions, goals and working styles can sometimes lead to conflicts and tension within the team.

  2. Coordination and communication challenges: Coordinating activities and aligning goals across different functions can be complex. Effective communication can be difficult in cross-functional teams, especially if team members come from different backgrounds or have varying levels of technical expertise. Project managers may need more time and effort to ensure everyone is on the same page.

  3. Ownership issues: Team members might need help understanding who is responsible for what within a cross-functional team. Without clear roles and responsibilities, tasks may fall through the cracks, and accountability can be unclear.

  4. Resource allocation: The management of resources across functions can take time and effort. Cross-functional team members often belong to individual department heads as well. Department managers might want to assign other tasks. Team members might struggle to prioritize work, and managers might clash over resource allocation.

  5. Resistance to change: Employees from different functional areas might feel uncomfortable leaving traditional working styles. This resistance can hinder the team’s progress and success.

  6. Lack of domain expertise: Cross-functional teams may lack deep domain expertise in a specific area, making it difficult to effectively address highly specialized or technical issues.

  7. Time-consuming meetings: Collaboration and consensus-building can require frequent meetings and discussions, which may consume a significant amount of team members’ time and potentially lead to “meeting fatigue.”

  8. Decision-making delays: Achieving consensus among diverse team members may take longer than in more specialized teams and lead to delays.

  9. Groupthink: While diversity of thought is valuable, it can also lead to groupthink. In an effort to reach consensus, team members may conform to the dominant viewpoint and suppress other opinions.

  10. Difficulty in team formation: Project managers can struggle to identify the right mix of skills and personalities to build a high-performing cross-functional team.

  11. Training and development needs: Team members may require additional training or development to bridge gaps in knowledge or skills, which can add to the overall cost.

  12. Inconsistent performance: Cross-functional teams may find it difficult to perform consistently. Managers may also struggle to assess individual performance.

Many of these challenges stem from the team members’ diverse backgrounds. Cross-functional teams can invest in orientation programs, create clear communication channels and effective team management to ease many of these issues. If an organization promotes a culture of collaboration, then such challenges will ease out with every successive project.

How to Implement Cross-Functional Teams Effectively

Don Norman, the pioneer of UX design, emphasizes the need for cross-functional collaboration and urges designers to learn how to work with people from different disciplines. 

Show Hide video transcript
  1. 00:00:00 --> 00:00:33

    Let me talk about the issues in the 21st  century – the issues that are faced by designers. I've talked a lot about human-centered design, and we're starting to look at *complex socio-technical systems*. How do we teach? How do we instruct people? Well, there are several different answers. Well, one of the things that's going to be required is  *learning how to work with other disciplines*.

  2. 00:00:33 --> 00:01:05

    In fact, some of the very, very best schools I've seen have done that. They work together. In my own group at the University of California, San Diego, we are doing work in many parts of the United States. But the simplest part is simply within San Diego itself because within San Diego we can find the very rich and educated, and the very  poor and homeless without a good education. We can find all sorts of people. We're also located  on the border of Mexico with the city of Tijuana.

  3. 00:01:05 --> 00:01:30

    And so, that brings us an international flavor where we can start looking at the – first of all, there are really good software designers and other design skills in Tijuana, Mexico; and second, they have a very different outlook on life than we do, and combining that with what we do is wonderful. It enriches everyone. And so, we're working with other design schools in the city;

  4. 00:01:30 --> 00:02:03

    we're working with the city itself, with the mayor, with the Economic Development Corporation, and area governments, to try to look at what the major issues are inside of San Diego and how they can be addressed. And you can do the same. The people at the Royal College of Art in London told me they worked with the city to devise a scheme for new ambulances, new ways of taking care of injured and getting them to the hospital systems. There are lots of *local problems* that therefore allow you to *express your abilities*

  5. 00:02:03 --> 00:02:21

    and *work together with non-traditional groups*, like the city, like the politicians, like economists, like political scientists, like engineers, like businesspeople. That's how we change design, and you can do it all by yourself.

A single person or department isn’t enough to solve complex problems. Here’s how you can implement cross-functional teams effectively.

  1. Identify the right projects or initiatives: Choose projects or initiatives that benefit from a cross-functional approach. Not every project needs a cross-functional team. Ensure that the benefits of cross-functional teams outweigh the costs. Cross-functional teams are more suitable for complex challenges, strategic initiatives, or tasks that require diverse expertise.

  2. Define objectives and goals: Clearly articulate the objectives and goals you want to achieve through cross-functional teams. What specific problems or opportunities will these teams address? What are the expected outcomes? Define key performance indicators (KPIs) and metrics to measure the success of cross-functional teams. These should align with the project’s goals and objectives.

  3. Select the right team members: Identify individuals from different functional areas with the relevant project skills and knowledge. Consider a mix of backgrounds, experiences, and perspectives to ensure diversity within the team.

  4. Establish team roles and responsibilities: Clearly define the roles and responsibilities of each team member. Ensure everyone understands their contribution to the project’s success and how their role fits within the team.

  5. Provide training and support: Offer training or resources to team members to help bridge any knowledge or skill gaps. Clearly outline the benefits of the approach and provide cross-training sessions, workshops, or relevant tools and materials to ensure everyone is onboard.

  6. Designate a project manager: Appoint a project manager to guide the team’s activities, ensure that workshops have healthy discussions and help resolve conflicts or obstacles.

  7. Promote a collaborative culture: Foster a culture of collaboration and open communication within the organization. Encourage employees to share ideas, provide feedback, and work together across departments.

  8. Empower the team: Give the cross-functional team the autonomy to make decisions and take ownership of their work. Avoid micromanaging, but provide support and resources when necessary.

  9. Celebrate successes and learn from failures: Acknowledge and celebrate the team’s achievements and milestones. Encourage a culture where the team sees failures as learning opportunities and applies lessons to future projects.

  10. Evaluate and iterate: At the end of the project, conduct a thorough evaluation to assess what worked well and how the team can improve. Share best practices and lessons learned across teams and use these insights to refine future efforts.

When Not to Implement Cross-Functional Teams

Cross-functional teams are best suited to address complex problems or projects that benefit from diverse expertise and perspectives, for example, new product development and sustainability initiatives.

While cross-functional teams can be highly effective, there are certain types of problems for which a traditional team approach might work best. 

Here are some example scenarios:

  1. Routine or Simple Tasks: Individual specialists or small, specialized teams can often handle such tasks more efficiently than cross-functional teams.

  2. Urgent or Time-Sensitive Issues: Cross-functional teams may take time to form, and their collaborative nature can slow down decision-making. A hierarchical or specialized team approach may be more appropriate when quick decisions and immediate action are necessary.

  3. Confidential or Sensitive Matters: Problems or projects that involve highly confidential or sensitive information may not suit cross-functional teams; sharing sensitive data across multiple functions can increase security risks.

  4. Small-Scale Projects: For small-scale projects or initiatives, assembling a cross-functional team may be resource-intensive and unnecessary. A single department or a small group of specialists may be more suitable.

  5. Well-Defined and Narrowly Focused Tasks: If a problem or project has a well-defined scope and requires a narrow focus, a specialized team or individual experts within a single department may be more efficient and cost-effective.

  6. Low-Complexity Issues: Cross-functional teams are best suited for complex, multifaceted challenges. Problems with straightforward solutions may not require the diversity of expertise and perspectives that cross-functional teams offer.

  7. Highly Technical or Specialized Problems: Cross-functional teams may not be efficient to solve problems that require deep technical or specialized knowledge in a single domain. Rely on subject-matter experts within that specific field instead.

  8. Budget Constraints: In cases of tight budgets, other approaches may be more cost-effective.

Learn More about Cross-Functional Teams

The design thinking and agile methodologies emphasize the importance of interdisciplinary collaboration. To learn more about these methodologies, sign up for the following courses:

Design Thinking: The Ultimate Guide

Agile Methods for UX Design 

See this article from Asana for tips on Building a cross-functional team. 

Here’s a comprehensive piece on the Composition, Benefits, and Good Practices of Cross-Functional Teams.

To see how large companies like Amazon and Spotify use cross-functional teams, see What Are Cross-Functional Teams and How to Build One?

For more examples of cross-functional teams in action, see Cross-Functional Collaboration Overview + Examples.

Questions about Cross-Functional Teams

What is a cross-functional team in the context of design?

In design teams, a cross-functional team consists of individuals from various disciplines like design, development, marketing, and management, all collaborating on a project. This team structure integrates diverse perspectives and skills.

Key benefits of cross-functional teams include enhanced innovation, a more holistic understanding of projects, and faster problem-solving.

Cross-functional teams are the backbone of Google’s Design Sprint framework, which calls for a team with representatives from all relevant organizational functions and levels. Here is a short overview of the design sprint.

Show Hide video transcript
  1. 00:00:00 --> 00:00:32

    In this video, we'll teach you how to use  Google's design sprint process to create great design faster. In an age of tight resources, companies  are more reluctant than ever to commit  to big design projects without a thorough  understanding of their chances of success. Google has developed a method to make the design process fast and still offer valuable insight. The process developed by  Google Ventures is called a *design sprint*.

  2. 00:00:32 --> 00:01:00

    It focuses on getting insights into *critical  business questions* within a very short timeframe – just five days. The process is based on *design thinking*, so it attempts to gain those insights via *rapid design*, *prototype development* and *user testing*. The design sprint is a five-phase process. Each phase takes approximately one day or eight  hours to perform. So, a sprint can be done in five days. The five phases of Google's design sprint are *understand*,

  3. 00:01:00 --> 00:01:31

    *sketch*, *decide*, *prototype* and *validate*. The design sprint is a *linear process*, but you  are strongly encouraged to *make revisions* based on your first sprint and then *reiterate the prototype and validate phases*. You can also move further back to earlier phases and reiterate from there. In the following, we'll look at each step in more detail, but let's start by taking  a quick look at how to plan a design sprint. To ensure that the design sprint will be  successful, some *planning ahead* is required.

  4. 00:01:31 --> 00:02:04

    Before the sprint begins, here are some things you should consider. You should *write a brief* to state the sprint's goal and bring everyone on the same page. You might also need to collect or *conduct user research* to get insights that can inform the work you do during the sprint. *Consider who should be on the sprint team.* Google's sprint process is designed to be run by teams rather than individuals. That means getting everyone together and ensuring  that they're all aiming in the same direction. The ideal team would include representatives from  all relevant functions and at all levels in the organization.

  5. 00:02:04 --> 00:02:34

    You could also invite external people –  for instance, a representative user or stakeholder. You need a *suitable space* for the  sprint, typically somewhere bright, quiet, with lots of wall space and enough room  for people to move about will be suitable. You have to *gather supplies* for the sketching  and prototyping phases. Typically, you need office supplies like Post-its, blank sheets of paper, color markers, tape, and so on. Finally, you should choose a good *icebreaker exercise* to kick off your design sprint.

  6. 00:02:34 --> 00:03:00

    Some members of your team might not have worked together before, so it's good to start off with an activity to warm people up. Now, let's take a look at each stage in the  execution of the actual sprint. In the understand session, your goal is to *create shared knowledge* about the business problem you're working on. You bring everyone together and unpack all of your  team's knowledge about the problem.

  7. 00:03:00 --> 00:03:32

    *Lightning talks*, where knowledge experts use 10 to 15 minutes to share their knowledge about the problem, is an important part of the understand session. Typical topics for a lightning talk are *business goals*, *insights from user research*, an *overview of competitive products*, *technical opportunities*, and so on. As part of the lightning talk, it can be a good idea to have a presentation by someone from senior management outlining why the problem  you're working on is important to the business. Other typical activities of the understand phase are demonstrations of solutions that are already available,

  8. 00:03:32 --> 00:04:01

    a detailed walkthrough of any proposed  solution, creating user journeys and performing user research. In the understand session, it's also  a good idea to be *clear on the metrics of success*. And remember, your metrics should be  useful and not pulled out of thin air. When you do the understand session, it's  important to involve the whole team. Don't let an individual or group dominate the  proceedings. The idea is to ensure everyone is on the same page, and the only way to do that  is if everyone is heard from.

  9. 00:04:01 --> 00:04:30

    Once everyone is on the same page, it's time to split the team up and get them to start working on solutions. Sketch day is an *individual effort*. Everyone is tasked with coming up with a detailed solution to the problem. It's a good idea to do this on paper for two reasons. First, it's quick and it takes no time  to make changes. Second, everybody is able to sketch so they can participate even if they don't know any wireframing tools.

  10. 00:04:30 --> 00:05:05

    For particularly complex, large-scale problem solving, you might want to break up the problem into *manageable chunks* and assign people a chunk rather than the whole problem. The aim of sketch day is to get as many ideas down as possible. If your team is large and you generate a ton of ideas, you might want to allocate an hour at the end of the day to quickly *reduce the number of ideas* to a more manageable number before you go into the third day of the sprint. As you might expect, decide day is all about  *making a decision* about which idea

  11. 00:05:05 --> 00:05:33

    you're going to take to the prototype phase. But there's more to decide day than making a decision. It's also about working out how your solutions  might conflict with your objectives and abilities. You can start the day by quickly  listing any assumptions that you are making about things like budget, users, technology capacity and business drivers. Then it's time to review each idea and look at  the conflicts that it generates. You should have an objective in mind during your review.

  12. 00:05:33 --> 00:06:01

    Would you be looking to take a single great idea forward to prototyping? Or are you going to pick, say, a top  5 and take those forward? You should be looking to constantly *refine* your list and remove ideas that simply aren't feasible early in the process. The entire team takes part in the decision process  by participating in discussions and through voting for ideas. Once you have an idea or ideas you  want to prototype, the last part of decide day is to *create some storyboards for your ideas*.

  13. 00:06:01 --> 00:06:33

    The storyboard should show each interaction with the user in a step-by-step process, and they'll be your specification for your prototype. You might also want to define a *user story*  or two to help beef up the specification. As the title implies, on prototype day you have  a single day to *create a prototype* that your users can test on the final day. First of all, storyboard what you're going to build if you haven't already done that. To build a prototype, you can use any tool of your choice.

  14. 00:06:33 --> 00:07:00

    Just pick one that you master enough for  rapid prototyping. The important thing is, don't attempt to learn a new tool on this day. Just use *whatever you're most comfortable with*. Finally, remember to *leverage the whole team*. Assign tasks and get everyone building or helping with something. Prototyping isn't just for the engineers.  Get people to document, write, review, plan a user test – any activity that contributes towards your end goal.

  15. 00:07:00 --> 00:07:31

    On day 5, you *validate your idea*. The most important part of the validation  is to bring in a group of your end users to test your prototype. It's important that the entire team gets to *observe the users interact with the product* either directly  or through watching recordings of your test. A *cognitive walkthrough* or *brief usability  test* are great tools to use in this phase. Other good activities to validate your design –  to bring in experts and management stakeholders to review your idea.

  16. 00:07:31 --> 00:08:00

    Everyone on the team should make  notes and record what they feel they've learned. You want to take these notes and  summarize them at the end of the day. This should help you decide if  anything needs iterating and improving. At the end of the final day, take some time with  the whole team to reflect on your experience. As Google puts it, there can be three possible  outcomes to a sprint: an *efficient failure* – perhaps your ideas didn't work so well, but you learned a lot in the process

  17. 00:08:00 --> 00:08:30

    and saved your team a lot of time from going down the wrong path; a *flawed success* – perhaps some ideas worked nicely, while others didn't: this gives you insights on what  can be improved and what you could work on next; finally, an *epic win* – the ideas your team had have  shown great promise and seem to work really well. You're ready to move into a more serious  implementation phase. Either way, you can only win! Whether it's by avoiding failure, learning where more work needs to be put in

  18. 00:08:30 --> 00:09:04

    or generating a killer design, you can only emerge from the design *wiser and more experienced*. The added bonus is that the time you've sacrificed  for this is relatively *short*. Though this is a tried-and-tested method by Google, it's also a relatively new concept adapted from Agile methods. It might take a few tries within your organization  to keep the sprint to five days. That's OK. You can work towards delivering faster sprints as  you get more practice. Google design sprints should help you take a process that currently takes months and make it lean and efficient. 

  19. 00:09:04 --> 00:09:31

    It's not a substitute for all design processes,  especially not for very complex products, but it's one that lets you ideate and test  ideas incredibly fast. A highly productive design team working in sprints is more likely to add business value and be recognized for their work within the larger organization. Finally, we encourage you to take a look at Google's Design Sprint Kit to get more ideas and tools for how to run your own design sprint.

How do cross-functional teams benefit UI/UX and product design projects?

Cross-functional teams in UI/UX and product design offer a wide range of expertise in one place. UX designers, developers, product managers and marketers work together and apply their perspectives to ensure products meet user needs and market demands. Such teams facilitate faster, more efficient decision-making and bring innovative, user-centric solutions.

The design thinking methodology recommends working in cross-functional teams to balance desirability, feasibility and viability.

What are the key roles in a cross-functional design team?

A cross-functional design team’s composition depends on the type of project and its unique requirements. Generally, one can expect a cross-functional team to have a project manager who oversees the project and ensures everyone is on the same page. The team may include business stakeholders, product managers, designers, engineers, marketing personnel and other specialists suited to the project. For example, a banking-related project might involve legal or finance experts.

How do you effectively manage communication in cross-functional teams?

Cross-functional teams include people from different departments with different types and expertise levels. This increases the chances of misunderstanding since people might use different terms for the same concept. Onboarding and training programs and clear documentation can help minimize miscommunication.

Visual mapping tools such as customer journey maps and stakeholder maps help align the entire team. With time, as team members interact and learn more about each other’s roles and responsibilities, the team will overcome initial communication challenges and reap the benefits of cross-functional collaboration.

What challenges are commonly faced by cross-functional design teams, and how are they overcome?

The biggest challenge cross-functional teams face stems from the diversity of team members. With a range of expertise, team members might not understand who is responsible for what. Each member may have a different approach towards work and follow different processes, which might lead to conflicts and slower decision-making.

A good project manager can help ease these tensions. The project manager facilitates collaboration and ensures everyone understands the goals of the project, their roles, and how the team should function. Read the article, Three Steps to Facilitate Design Thinking in Your Team for a more detailed guideline.

How do cross-functional teams collaborate with stakeholders and clients?

Cross-functional teams are highly effective for strategic and complex projects. One of the best ways to collaborate with stakeholders and clients is to involve them in team meetings and workshops to keep them in the loop. With all relevant functional representatives in the room, such teams can run their findings, insights and ideas past clients, get timely feedback, and implement any changes or change course if needed. Documentation, prototype demonstrations, and regular status updates are other ways to collaborate with stakeholders.

Watch leadership coach Todd Zaki Warfel’s Master Class Webinar on How to Win Clients, Pitches & Approval: Present Your Designs Effectively to understand the mindset of stakeholders and how to communicate with them successfully.

What tools and technologies are recommended for cross-functional design teams?

Since cross-functional design teams involve people from different departments, the team must choose tools carefully. Specialized tools that need expertise will exclude several team members. The most common tools in such teams aim to optimize workflow and collaboration.

  • Project management tools such as Asana or Trello.

  • Remote communication tools such as Slack, Microsoft Teams, or Zoom.

  • Collaboration tools such as whiteboards (and virtual versions, such as Miro or Mural).

  • Document management and storage solutions such as Dropbox or Google Drive.

  • Design and prototyping tools such as Figma, Adobe XD or Sketch.

How do cross-functional teams impact the design thinking process?

Cross-functional teams foster creativity by encouraging a beginner’s mindset. When people from diverse backgrounds come together, they challenge assumptions and biases. They ask questions that people who are experts in the field may overlook. Moreover, such teams offer a holistic view of the problems and solutions, so ideas will likely be desirable, feasible and viable from the beginning.

Learn more about design thinking in IxDF’s comprehensive course, Design Thinking: The Ultimate Guide.

What are some highly cited scientific research about cross-functional teams?

  1. Nguyen, M., & Mougenot, C. (2022). A systematic review of empirical studies on multidisciplinary design collaboration: Findings, methods, and challenges. Design Studies, 81, 101120.
    This study systematically reviews empirical studies on multidisciplinary design collaboration, including cross-functional teams.

  2. Sethi, R., Smith, D. C., & Park, C. W. (2001). Cross-Functional Product Development Teams, Creativity, and the Innovativeness of New Consumer Products. Journal of Marketing Research, 38(1), 73-85.
    This study looks at 141 cross-functional teams and their impact on the creativity and innovativeness of new consumer products.

  3. McDonough, E. F. (2000). Investigation of Factors Contributing to the Success of Cross-Functional Teams. Journal of Product Innovation Management, 17(3), 221-235.
    In this article, the author analyzes the responses of 112 new product development professionals to determine which factors lead to project success.

What are some recommended books that cover cross-functional teams well?

  1. Finerty, S. Z. (2019). Cross Functional Influence: Getting Things Done Across the Organization. Two Harbors Press.
    This book gives you a practical model to navigate complex organizational landscapes and offers practical advice for successful cross-functional collaboration.

  2. Klein, L. (2019). Build Better Products: A Modern Approach to Building Successful User-Centered Products. Rosenfeld Media.
    This book offers practical advice on how to develop products and features that improve a business’s bottom line and dramatically improve customer experience. It includes how to build a better team to achieve this success.

Earn a Gift, Answer a Short Quiz!

  1. Question 1
  2. Question 2
  3. Question 3
  4. Get Your Gift

Question 1

What defines a cross-functional team?

1 point towards your gift

Literature on Cross-Functional Teams

Here's the entire UX literature on Cross-Functional Teams by the Interaction Design Foundation, collated in one place:

Learn more about Cross-Functional Teams

Take a deep dive into Cross-Functional Teams with our course Agile Methods for UX Design .

Agile, in one form or another, has taken over the software development world and is poised to move into almost every other industry. The problem is that a lot of teams and organizations that call themselves “agile” don’t seem to have much in common with each other. This can be extremely confusing to a new team member, especially if you’ve previously worked on an “agile” team that had an entirely different definition of “agility”!

Since the release of the Agile Manifesto in 2001, agile methodologies have become almost unrecognizable in many organizations, even as they have become wildly popular. 

To understand the real-world challenges and best practices to work under the constraints of agile teams, we spoke with hundreds of professionals with experience working in agile environments. This research led us to create Agile Methods for UX Design.

In this course, we aim to show you what true agility is and how closely agile methodologies can map to design. You will learn both the theory and the real-world implementation of agile, its different flavors, and how you can work with different versions of agile teams.

You will learn about the key principles of agile, examples of teams that perform all the agile “rituals” but aren’t actually agile, and examples of teams that skip the rituals but actually embody the spirit.

You’ll learn about agile-specific techniques for research and design, such as designing smaller things, practicing continuous discovery, refactoring designs, and iterating.

You will also walk away with practical advice for working better with your team and improving processes at your company so that you can get some of the benefits of real agility.

This course is aimed at people who already know how to design or research (or who want to work with designers and researchers) but who want to learn how to operate better within a specific environment. There are lots of tools designers use within an agile environment that are no different from tools they’d use anywhere else, and we won’t be covering how to use those tools generally, but we will talk about how agile deliverables can differ from those you’d find in a more traditional UX team. 

Your course instructor is product management and user experience design expert, Laura Klein. Laura is the author of Build Better Products and UX for Lean Startups and the co-host of the podcast What is Wrong with UX?

With over 20 years of experience in tech, Laura specializes in helping companies innovate responsibly and improve their product development process, and she especially enjoys working with lean startups and agile development teams.

In this course, you will also hear from industry experts Teresa Torres (Product Discovery Coach at Product Talk), Janna Bastow (CEO and Co-founder of ProdPad) and Adam Thomas (product management strategist and consultant).

All open-source articles on Cross-Functional Teams

Please check the value and try again.

Collaborating with Your Team for Research
Research on siloed teams is often the responsibility of a small number of people. On agile teams, we often involve more
  • 517 shares
  • 11 mths ago
Read article

Open Access—Link to us!

We believe in Open Access and the democratization of knowledge. Unfortunately, world-class educational materials such as this page are normally hidden behind paywalls or in expensive textbooks.

If you want this to change, , link to us, or join us to help us democratize design knowledge!

Share Knowledge, Get Respect!

Share on:

or copy link

Cite according to academic standards

Simply copy and paste the text below into your bibliographic reference list, onto your blog, or anywhere else. You can also just hyperlink to this page.

Interaction Design Foundation - IxDF. (2023, December 21). What are Cross-Functional Teams?. Interaction Design Foundation - IxDF.