Collaboration: The Most Underrated UX Skill No One Talks About

 

We often spotlight wireframes, research, or tools like Figma, but none of that moves the needle if we can’t collaborate well. Great UX doesn’t happen in isolation. It takes conversations with engineers, alignment with product, sales, and other stakeholders, as well as the ability to listen, adapt, and co-create. That’s where design becomes a team sport, and when your ability to capture the outcomes multiplies the UX impact.

When people talk about UX, it’s usually about the things they can see and interact with, like wireframes and prototypes, smart interactions, and design tools like Figma, Miro, or Maze. Some of the outputs are even glamorized, like design systems, research reports, and pixel-perfect UI designs. But here’s the truth I’ve seen again and again in over two decades of working in UX: none of that moves the needle if there is no collaboration.

Great UX doesn’t happen in isolation. It happens through conversations with engineers, product managers, customer-facing teams, and the customer support teams who manage support tickets. Amazing UX ideas come alive in messy Miro sessions, cross-functional workshops, and those online chats (e.g., Slack or Teams) where people align, adapt, and co-create.

Some of the most impactful moments in my career weren’t when I was “designing” in the traditional sense. They have been gaining incredible insights when discussing problems with teammates who have varied experiences, brainstorming, and coming up with ideas that I never could have come up with on my own. As I always say, ten minds in a room will come up with ten times as many ideas as one mind. Often, many ideas are the most useful outcome.

There have been times when a team has helped to reframe a problem in a workshop, taken vague and conflicting feedback, and clarified a path forward, or I’ve sat with a sales rep and heard the same user complaint show up in multiple conversations. This is when design becomes a team sport, and when your ability to capture the outcomes multiplies the UX impact.

Why This Article Matters Now

The reason collaboration feels so urgent now is that the way we work since COVID has changed, according to a study published by the US Department of Labor. Teams are more cross-functional, often remote, and increasingly complex. Silos are easier to fall into, due to distance or lack of face-to-face contact, and yet alignment has never been more important. We can’t afford to see collaboration as a “nice to have” anymore. It’s a core skill, especially in UX, where our work touches so many parts of an organisation.

Let’s break down what collaboration in UX really means, and why it deserves way more attention than it gets.

What Is Collaboration In UX, Really?

Let’s start by clearing up a misconception. Collaboration is not the same as cooperation.

• Cooperation: “You do your thing, I’ll do mine, and we’ll check in later.”
• Collaboration: “Let’s figure this out together and co-own the outcome.”

Collaboration, as defined in the book Communication Concepts, published by Deakin University, involves working with others to produce outputs and/or achieve shared goals. The outcome of collaboration is typically a tangible product or a measurable achievement, such as solving a problem or making a decision. Here’s an example from a recent project:

Recently, I worked on a fraud alert platform for a fintech business. It was a six-month project, and we had zero access to users, as the product had not yet hit the market. Also, the users were highly specialised in the B2B finance space and were difficult to find. Additionally, the team members I needed to collaborate with were based in Malaysia and Melbourne, while I am located in Sydney.

Instead of treating that as a dead end, we turned inward: collaborating with subject matter experts, professional services consultants, compliance specialists, and customer support team members who had deep knowledge of fraud patterns and customer pain points. Through bi-weekly workshops using a Miro board, iterative feedback loops, and sketching sessions, we worked on design solution options. I even asked them to present their own design version as part of the processAfter months of iterating on the fraud investigation platform through these collaboration sessions, I ended up with two different design frameworks for the investigator’s dashboard. Instead of just presenting the “best one” and hoping for buy-in, I ran a voting exercise with PMs, engineers, SMEs, and customer support. Everyone had a voice. The winning design was created and validated with the input of the team, resulting in an outcome that solved many problems for the end user and was owned by the entire team. That’s collaboration!

It is definitely one of the most satisfying projects of my career.

On the other hand, I recently caught up with an old colleague who now serves as a product owner. Her story was a cautionary tale: the design team had gone ahead with a major redesign of an app without looping her in until late in the game. Not surprisingly, the new design missed several key product constraints and business goals. It had to be scrapped and redone, with her now at the table. That experience reinforced what we all know deep down: your best work rarely happens in isolation.

As illustrated in my experience, true collaboration can span many roles. It’s not just between designers and PMs. It can also include QA testers who identify real-world issues, content strategists who ensure our language is clear and inclusive, sales representatives who interact with customers on a daily basis, marketers who understand the brand’s voice, and, of course, customer support agents who are often the first to hear when something goes wrong. The best outcomes arrive when we’re open to different perspectives and inputs.

Why Collaboration Is So Overlooked?

If collaboration is so powerful, why don’t we talk about it more?

In my experience, one reason is the myth of the “lone UX hero”. Many of us entered the field inspired by stories of design geniuses revolutionising products on their own. Our portfolios often reflect that as well. We showcase our solo work, our processes, and our wins. Job descriptions often reinforce the idea of the solo UX designer, listing tool proficiency and deliverables more than soft skills and team dynamics.

And then there’s the team culture within many organisations of “just get the work done”, which often leads to fewer meetings and tighter deadlines. As a result, a sense of collaboration is inefficient and wasted. I have also experienced working with some designers where perfectionism and territoriality creep in — “This is my design” — which kills the open, communal spirit that collaboration needs.

When Collaboration Is The User Research

In an ideal world, we’d always have direct access to users. But let’s be real. Sometimes that just doesn’t happen. Whether it’s due to budget constraints, time limitations, or layers of bureaucracy, talking to end users isn’t always possible. That’s where collaboration with team members becomes even more crucial.

The next best thing to talking to users? Talking to the people who talk to users. Sales teams, customer success reps, tech support, and field engineers. They’re all user researchers in disguise!

On another B2C project, the end users were having trouble completing the key task. My role was to redesign the onboarding experience for an online identity capture tool for end users. I was unable to schedule interviews with end users due to budget and time constraints, so I turned to the sales and tech support teams.

I conducted multiple mini-workshops to identify the most common onboarding issues they had heard directly from our customers. This led to a huge “aha” moment: most users dropped off before the document capture process. They may have been struggling with a lack of instruction, not knowing the required time, or not understanding the steps involved in completing the onboarding process.

That insight reframed my approach, and we ultimately redesigned the flow to prioritize orientation and clear instructions before proceeding to the setup steps. Below is an example of one of the screen designs, including some of the instructions we added.

This kind of collaboration is user research. It’s not a substitute for talking to users directly, but it’s a powerful proxy when you have limited options.

But What About Using AI?

Glad you asked! Even AI tools, which are increasingly being used for idea generation, pattern recognition, or rapid prototyping, don’t replace collaboration; they just change the shape of it.

AI can help you explore design patterns, draft user flows, or generate multiple variations of a layout in seconds. It’s fantastic for getting past creative blocks or pressure-testing your assumptions. But let’s be clear: these tools are accelerators, not oracles. As an innovation and strategy consultant Nathan Waterhouse points out, AI can point you in a direction, but it can’t tell you which direction is the right one in your specific context. That still requires human judgment, empathy, and an understanding of the messy realities of users and business goals.

You still need people, especially those closest to your users, to validate, challenge, and evolve any AI-generated idea. For instance, you might use ChatGPT to brainstorm onboarding flows for a SaaS tool, but if you’re not involving customer support reps who regularly hear “I didn’t know where to start” or “I couldn’t even log in,” you’re just working with assumptions. The same applies to engineers who know what is technically feasible or PMs who understand where the business is headed.

AI can generate ideas, but only collaboration turns those ideas into something usable, valuable, and real. Think of it as a powerful ingredient, but not the whole recipe.

“

How To Strengthen Your UX Collaboration Skills?

If collaboration doesn’t come naturally or hasn’t been a focus, that’s okay. Like any skill, it can be practiced and improved. Here are a few ways to level up:

1. Cultivate curiosity about your teammates.
   Ask engineers what keeps them up at night. Learn what metrics your PMs care about. Understand the types of tickets the support team handles most frequently. The more you care about their challenges, the more they’ll care about yours.
2. Get comfortable facilitating.
   You don’t need to be a certified Design Sprint master, but learning how to run a structured conversation, align stakeholders, or synthesize different points of view is hugely valuable. Even a simple “What’s working? What’s not?” retro can be an amazing starting point in identifying where you need to focus next.
3. Share early, share often.
   Don’t wait until your designs are polished to get input. Messy sketches and rough prototypes invite collaboration. When others feel like they’ve helped shape the work, they’re more invested in its success.
4. Practice active listening.
   When someone critiques your work, don’t immediately defend. Pause. Ask follow-up questions. Reframe the feedback. Collaboration isn’t about consensus; it’s about finding a shared direction that can honour multiple truths.
5. Co-own the outcome.
   Let go of your ego. The best UX work isn’t “your” work. It’s the result of many voices, skill sets, and conversations converging toward a solution that helps users. It’s not “I”, it’s “we” that will solve this problem together.

Conclusion: UX Is A Team Sport

Great design doesn’t emerge from a vacuum. It comes from open dialogue, cross-functional understanding, and a shared commitment to solving real problems for real people.

If there’s one thing I wish every early-career designer knew, it’s this:

Collaboration is not a side skill. It’s the engine behind every meaningful design outcome. And for seasoned professionals, it’s the superpower that turns good teams into great ones.

“

So next time you’re tempted to go heads-down and just “crank out a design,” pause to reflect. Ask who else should be in the room. And invite them in, not just to review your work, but to help create it.

Because in the end, the best UX isn’t just what you make. It’s what you make together.

 

The Core Model: Start FROM The Answer, Not WITH The Solution

 

The Core Model is a practical methodology that flips traditional digital development on its head. Instead of starting with solutions or structure, we begin with a hypothesis about what users need and follow a simple framework that brings diverse teams together to create more effective digital experiences. By asking six good questions in the right order, teams align around user tasks and business objectives, creating clarity that transcends organizational boundaries.

Ever sat in a meeting where everyone jumped straight to solutions? “We need a new app!” “Let’s redesign the homepage!” “AI will fix everything!” This solution-first thinking is endemic in digital development — and it’s why so many projects fail to deliver real value. As the creator of the Core Model methodology, I developed this approach to flip the script: instead of starting with solutions, we start FROM the answer.

What’s the difference? Starting with solutions means imposing our preconceived ideas. Starting FROM the answer to a user task means forming a hypothesis about what users need, then taking a step back to follow a simple structure that validates and refines that hypothesis.

Six Good Questions That Lead to Better Answers

At its heart, the Core Model is simply six good questions asked in the right order, with a seventh that drives action. It appeals to common sense — something often in short supply during complex digital projects.

When I introduced this approach to a large organization struggling with their website, their head of digital admitted: “We’ve been asking all these questions separately, but never in this structured way that connects them.”

These questions help teams pause, align around what matters, and create solutions that actually work:

1. Who are we trying to help, and what’s their situation?
2. What are they trying to accomplish?
3. What do we want to achieve?
4. How do they approach this need?
5. Where should they go next?
6. What’s the essential content or functionality they need?
7. What needs to be done to create this solution?

This simple framework creates clarity across team boundaries, bringing together content creators, designers, developers, customer service, subject matter experts, and leadership around a shared understanding.

Starting With a Hypothesis

The Core Model process typically begins before the workshop. The project lead or facilitator works with key stakeholders to:

1. Identify candidate cores based on organizational priorities and user needs.
2. Gather existing user insights and business objectives.
3. Form initial hypotheses about what these cores should accomplish.
4. Prepare relevant background materials for workshop participants.

This preparation ensures the workshop itself is focused and productive, with teams validating and refining hypotheses rather than starting from scratch.

The Core Model: Six Elements That Create Alignment 

Let’s explore each element of the Core Model in detail:

The Core Model framework with its six elements: Target Group, User Tasks, Business Objectives, Inward Paths, Forward Paths, and Core Content. (Large preview)

1. Target Group: Building Empathy First

Rather than detailed personas, the Core Model starts with quick proto-personas that build empathy for users in specific situations:

• A parent researching childcare options late at night after a long day.
• A small business owner trying to understand tax requirements between client meetings.
• A new resident navigating unfamiliar public services in their second language.

The key is to humanize users and understand their emotional and practical context before diving into solutions.

2. User Tasks: What People Are Actually Trying to Do

Beyond features or content, what are users actually trying to accomplish?

• Making an informed decision about a major purchase.
• Finding the right form to apply for a service.
• Understanding next steps in a complex process.
• Checking eligibility for a program or benefit.

These tasks should be based on user research and drive everything that follows. Top task methodology is a great approach to this.

3. Business Objectives: What Success Looks Like

Every digital initiative should connect to clear organizational goals:

• Increasing online self-service adoption.
• Reducing support costs.
• Improving satisfaction and loyalty.
• Meeting compliance requirements.
• Generating leads or sales.

These objectives provide the measurement framework for success. (If you work with OKRs, you can think of these as Key Results that connect to your overall Objective.)

4. Inward Paths: User Scenarios and Approaches

This element goes beyond just findability to include the user’s entire approach and mental model:

• What scenarios lead them to this need?
• What terminology do they use to describe their problem?
• How would the phrase their need to Google or an LLM?
• What emotions or urgency are they experiencing?
• What channels or touchpoints do they use?
• What existing knowledge do they bring?

Understanding these angles of different approaches ensures we meet users where they are.

5. Forward Paths: Guiding the Journey

What should users do after engaging with this core?

• Take a specific action to continue their task.
• Explore related information or options.
• Connect with appropriate support channels.
• Save or share their progress.

These paths create coherent journeys (core flows) rather than dead ends.

6. Core Content: The Essential Solution

Only after mapping the previous elements do we define the actual solution:

• What information must be included?
• What functionality is essential?
• What tone and language are appropriate?
• What format best serves the need?

This becomes our blueprint for what actually needs to be created.

Action Cards: From Insight to Implementation

The Core Model process culminates with action cards that answer the crucial seventh question: “What needs to be done to create this solution?”

These cards typically include:

• Specific actions required;
• Who is responsible;
• Timeline for completion;
• Resources needed;
• Dependencies and constraints.

Action cards transform insights into concrete next steps, ensuring the workshop leads to real improvements rather than just interesting discussions.

The Power of Core Pairs

A unique aspect of the Core Model methodology is working in core pairs—two people from different competencies or departments working together on the same core sheet. This approach creates several benefits:

• Cross-disciplinary insight
  Pairing someone with deep subject knowledge with someone who brings a fresh perspective.
• Built-in quality control
  Partners catch blind spots and challenge assumptions.
• Simplified communication
  One-to-one dialogue is more effective than group discussions.
• Shared ownership
  Both participants develop a commitment to the solution.
• Knowledge transfer
  Skills and insights flow naturally between disciplines.

The ideal pair combines different perspectives — content and design, business and technical, expert and novice — creating a balanced approach that neither could achieve alone.

Creating Alignment Within and Between Teams

The Core Model excels at creating two crucial types of alignment:

Within Cross-Functional Teams

Modern teams bring together diverse competencies:

• Content creators focus on messages and narrative.
• Designers think about user experience and interfaces.
• Developers consider technical implementation.
• Business stakeholders prioritize organizational needs.

The Core Model gives these specialists a common framework. Instead of the designer focusing only on interfaces or the developer only on code, everyone aligns around user tasks and business goals.

As one UX designer told me:

“The Core Model changed our team dynamic completely. Instead of handing off wireframes to developers who didn’t understand the ‘why’ behind design decisions, we now share a common understanding of what we’re trying to accomplish.”

Between Teams Across the Customer Journey

Users don’t experience your organization in silos — they move across touchpoints and teams. The Core Model helps connect these experiences:

• Marketing teams understand how their campaigns connect to service delivery.
• Product teams see how their features fit into larger user journeys.
• Support teams gain context on user pathways and common issues.
• Content teams create information that supports the entire journey.

By mapping connections between cores (core flows), organizations create coherent experiences rather than fragmented interactions.

Breaking Down Organizational Barriers 

The Core Model creates a neutral framework where various perspectives can contribute while maintaining a unified direction. This is particularly valuable in traditional organizational structures where content responsibility is distributed across departments.

The Workshop: Making It Happen

The Core Model workshop brings these elements together in a practical format that can be adapted to different contexts and needs.

Workshop Format and Timing

For complex projects with multiple stakeholders across organizational silos, the ideal format is a full-day (6–hour) workshop:

First Hour: Foundation and Context

• Introduction to the methodology (15 min).
• Sharing user insights and business context (15 min).
• Reviewing pre-workshop hypotheses (15 min).
• Initial discussion and questions (15 min).

Hours 2–4: Core Mapping

• Core pairs work on mapping elements (120 min).
• Sharing between core pairs and in plenary between elements.
• Facilitators provide guidance as needed.

Hours 5–6: Presentation, Discussion, and Action Planning

• Each core pair presents its findings (depending on the number of cores).
• Extensive group discussion and refinement.
• Creating action cards and next steps.

The format is highly flexible:

• Teams experienced with the methodology can conduct focused sessions in as little as 30 minutes.
• Smaller projects might need only 2–3 hours.
• Remote teams might split the workshop into multiple shorter sessions.

Workshop Environment

The Core Model workshop thrives in different environments:

• Analog: Traditional approach using paper core sheets.
• Digital: Virtual workshops using Miro, Mural, FigJam, or similar platforms.
• Hybrid: Digital canvas in physical workshop, combining in-person interaction with digital documentation.

Note: You can find all downloads and templates here.

Core Pairs: The Key to Success

The composition of core pairs is critical to success:

• One person should know the solution domain well (subject matter expert).
• The other brings a fresh perspective (and learns about a different domain).
• This combination ensures both depth of knowledge and fresh thinking.
• Cross-functional pairing creates natural knowledge transfer and breaks down silos.

Workshop Deliverables

Important to note: The workshop doesn’t produce final solutions.

Instead, it creates a comprehensive brief containing the following:

• Priorities and context for content development.
• Direction and ideas for design and user experience.
• Requirements and specifications for functionality.
• Action plan for implementation with clear ownership.

This brief becomes the foundation for subsequent development work, ensuring everyone builds toward the same goal while leaving room for specialist expertise during implementation.

Getting Started: Your First Core Model Implementation

Ready to apply the Core Model in your organization? Here’s how to begin:

1. Form Your Initial Hypothesis

Before bringing everyone together:

• Identify a core where users struggle and the business impact is clear.
• Gather available user insights and business objectives.
• Form a hypothesis about what this core should accomplish.
• Identify key stakeholders across relevant departments.

2. Bring Together the Right Core Pairs

Select participants who represent different perspectives:

• Content creators paired with designers.
• Business experts paired with technical specialists.
• Subject matter experts paired with user advocates.
• Veterans paired with fresh perspectives.

3. Follow the Seven Questions

Guide core pairs through the process:

• Who are we trying to help, and what’s their situation?
• What are they trying to accomplish?
• What do we want to achieve?
• How do they approach this need?
• Where should they go next?
• What’s the essential content or functionality?
• What needs to be done to create this solution?

4. Create an Action Plan

Transform insights into concrete actions:

• Document specific next steps on action cards.
• Assign clear ownership for each action.
• Establish timeline and milestones.
• Define how you’ll measure success.

In Conclusion: Common Sense In A Structured Framework

The Core Model works because it combines common sense with structure — asking the right questions in the right order to ensure we address what actually matters.

By starting FROM the answer, not WITH the solution, teams avoid premature problem-solving and create digital experiences that truly serve user needs while achieving organizational goals.

Whether you’re managing a traditional website, creating multi-channel content, or developing digital products, this methodology provides a framework for better collaboration, clearer priorities, and more effective outcomes.

Collaboration: The Most Underrated UX Skill No One Talks About

 

We often spotlight wireframes, research, or tools like Figma, but none of that moves the needle if we can’t collaborate well. Great UX doesn’t happen in isolation. It takes conversations with engineers, alignment with product, sales, and other stakeholders, as well as the ability to listen, adapt, and co-create. That’s where design becomes a team sport, and when your ability to capture the outcomes multiplies the UX impact.

When people talk about UX, it’s usually about the things they can see and interact with, like wireframes and prototypes, smart interactions, and design tools like Figma, Miro, or Maze. Some of the outputs are even glamorized, like design systems, research reports, and pixel-perfect UI designs. But here’s the truth I’ve seen again and again in over two decades of working in UX: none of that moves the needle if there is no collaboration.

Great UX doesn’t happen in isolation. It happens through conversations with engineers, product managers, customer-facing teams, and the customer support teams who manage support tickets. Amazing UX ideas come alive in messy Miro sessions, cross-functional workshops, and those online chats (e.g., Slack or Teams) where people align, adapt, and co-create.

Some of the most impactful moments in my career weren’t when I was “designing” in the traditional sense. They have been gaining incredible insights when discussing problems with teammates who have varied experiences, brainstorming, and coming up with ideas that I never could have come up with on my own. As I always say, ten minds in a room will come up with ten times as many ideas as one mind. Often, many ideas are the most useful outcome.

There have been times when a team has helped to reframe a problem in a workshop, taken vague and conflicting feedback, and clarified a path forward, or I’ve sat with a sales rep and heard the same user complaint show up in multiple conversations. This is when design becomes a team sport, and when your ability to capture the outcomes multiplies the UX impact.

Why This Article Matters Now

The reason collaboration feels so urgent now is that the way we work since COVID has changed, according to a study published by the US Department of Labor. Teams are more cross-functional, often remote, and increasingly complex. Silos are easier to fall into, due to distance or lack of face-to-face contact, and yet alignment has never been more important. We can’t afford to see collaboration as a “nice to have” anymore. It’s a core skill, especially in UX, where our work touches so many parts of an organisation.

Let’s break down what collaboration in UX really means, and why it deserves way more attention than it gets.

What Is Collaboration In UX, Really?

Let’s start by clearing up a misconception. Collaboration is not the same as cooperation.

• Cooperation: “You do your thing, I’ll do mine, and we’ll check in later.”
• Collaboration: “Let’s figure this out together and co-own the outcome.”

Collaboration, as defined in the book Communication Concepts, published by Deakin University, involves working with others to produce outputs and/or achieve shared goals. The outcome of collaboration is typically a tangible product or a measurable achievement, such as solving a problem or making a decision. Here’s an example from a recent project:

Recently, I worked on a fraud alert platform for a fintech business. It was a six-month project, and we had zero access to users, as the product had not yet hit the market. Also, the users were highly specialised in the B2B finance space and were difficult to find. Additionally, the team members I needed to collaborate with were based in Malaysia and Melbourne, while I am located in Sydney.

Instead of treating that as a dead end, we turned inward: collaborating with subject matter experts, professional services consultants, compliance specialists, and customer support team members who had deep knowledge of fraud patterns and customer pain points. Through bi-weekly workshops using a Miro board, iterative feedback loops, and sketching sessions, we worked on design solution options. I even asked them to present their own design version as part of the process.

After months of iterating on the fraud investigation platform through these collaboration sessions, I ended up with two different design frameworks for the investigator’s dashboard. Instead of just presenting the “best one” and hoping for buy-in, I ran a voting exercise with PMs, engineers, SMEs, and customer support. Everyone had a voice. The winning design was created and validated with the input of the team, resulting in an outcome that solved many problems for the end user and was owned by the entire team. That’s collaboration!

It is definitely one of the most satisfying projects of my career.

On the other hand, I recently caught up with an old colleague who now serves as a product owner. Her story was a cautionary tale: the design team had gone ahead with a major redesign of an app without looping her in until late in the game. Not surprisingly, the new design missed several key product constraints and business goals. It had to be scrapped and redone, with her now at the table. That experience reinforced what we all know deep down: your best work rarely happens in isolation.

As illustrated in my experience, true collaboration can span many roles. It’s not just between designers and PMs. It can also include QA testers who identify real-world issues, content strategists who ensure our language is clear and inclusive, sales representatives who interact with customers on a daily basis, marketers who understand the brand’s voice, and, of course, customer support agents who are often the first to hear when something goes wrong. The best outcomes arrive when we’re open to different perspectives and inputs.

Why Collaboration Is So Overlooked?

If collaboration is so powerful, why don’t we talk about it more?

In my experience, one reason is the myth of the “lone UX hero”. Many of us entered the field inspired by stories of design geniuses revolutionising products on their own. Our portfolios often reflect that as well. We showcase our solo work, our processes, and our wins. Job descriptions often reinforce the idea of the solo UX designer, listing tool proficiency and deliverables more than soft skills and team dynamics.

And then there’s the team culture within many organisations of “just get the work done”, which often leads to fewer meetings and tighter deadlines. As a result, a sense of collaboration is inefficient and wasted. I have also experienced working with some designers where perfectionism and territoriality creep in — “This is my design” — which kills the open, communal spirit that collaboration needs.

When Collaboration Is The User Research #

In an ideal world, we’d always have direct access to users. But let’s be real. Sometimes that just doesn’t happen. Whether it’s due to budget constraints, time limitations, or layers of bureaucracy, talking to end users isn’t always possible. That’s where collaboration with team members becomes even more crucial.

The next best thing to talking to users? Talking to the people who talk to users. Sales teams, customer success reps, tech support, and field engineers. They’re all user researchers in disguise!

On another B2C project, the end users were having trouble completing the key task. My role was to redesign the onboarding experience for an online identity capture tool for end users. I was unable to schedule interviews with end users due to budget and time constraints, so I turned to the sales and tech support teams.

I conducted multiple mini-workshops to identify the most common onboarding issues they had heard directly from our customers. This led to a huge “aha” moment: most users dropped off before the document capture process. They may have been struggling with a lack of instruction, not knowing the required time, or not understanding the steps involved in completing the onboarding process.

That insight reframed my approach, and we ultimately redesigned the flow to prioritize orientation and clear instructions before proceeding to the setup steps. Below is an example of one of the screen designs, including some of the instructions we added.

This kind of collaboration is user research. It’s not a substitute for talking to users directly, but it’s a powerful proxy when you have limited options.

But What About Using AI?

Glad you asked! Even AI tools, which are increasingly being used for idea generation, pattern recognition, or rapid prototyping, don’t replace collaboration; they just change the shape of it.

AI can help you explore design patterns, draft user flows, or generate multiple variations of a layout in seconds. It’s fantastic for getting past creative blocks or pressure-testing your assumptions. But let’s be clear: these tools are accelerators, not oracles. As an innovation and strategy consultant Nathan Waterhouse points out, AI can point you in a direction, but it can’t tell you which direction is the right one in your specific context. That still requires human judgment, empathy, and an understanding of the messy realities of users and business goals.

You still need people, especially those closest to your users, to validate, challenge, and evolve any AI-generated idea. For instance, you might use ChatGPT to brainstorm onboarding flows for a SaaS tool, but if you’re not involving customer support reps who regularly hear “I didn’t know where to start” or “I couldn’t even log in,” you’re just working with assumptions. The same applies to engineers who know what is technically feasible or PMs who understand where the business is headed.

AI can generate ideas, but only collaboration turns those ideas into something usable, valuable, and real. Think of it as a powerful ingredient, but not the whole recipe.

“

How To Strengthen Your UX Collaboration Skills?

If collaboration doesn’t come naturally or hasn’t been a focus, that’s okay. Like any skill, it can be practiced and improved. Here are a few ways to level up:

1. Cultivate curiosity about your teammates.
   Ask engineers what keeps them up at night. Learn what metrics your PMs care about. Understand the types of tickets the support team handles most frequently. The more you care about their challenges, the more they’ll care about yours.
2. Get comfortable facilitating.
   You don’t need to be a certified Design Sprint master, but learning how to run a structured conversation, align stakeholders, or synthesize different points of view is hugely valuable. Even a simple “What’s working? What’s not?” retro can be an amazing starting point in identifying where you need to focus next.
3. Share early, share often.
   Don’t wait until your designs are polished to get input. Messy sketches and rough prototypes invite collaboration. When others feel like they’ve helped shape the work, they’re more invested in its success.
4. Practice active listening.
   When someone critiques your work, don’t immediately defend. Pause. Ask follow-up questions. Reframe the feedback. Collaboration isn’t about consensus; it’s about finding a shared direction that can honour multiple truths.
5. Co-own the outcome.
   Let go of your ego. The best UX work isn’t “your” work. It’s the result of many voices, skill sets, and conversations converging toward a solution that helps users. It’s not “I”, it’s “we” that will solve this problem together.

Conclusion: UX Is A Team Sport

Great design doesn’t emerge from a vacuum. It comes from open dialogue, cross-functional understanding, and a shared commitment to solving real problems for real people.

If there’s one thing I wish every early-career designer knew, it’s this:

Collaboration is not a side skill. It’s the engine behind every meaningful design outcome. And for seasoned professionals, it’s the superpower that turns good teams into great ones.

“

So next time you’re tempted to go heads-down and just “crank out a design,” pause to reflect. Ask who else should be in the room. And invite them in, not just to review your work, but to help create it.

Because in the end, the best UX isn’t just what you make. It’s what you make together.

Rethinking The Role Of Your UX Teams And Move Beyond Firefighting

 Many UX professionals often find themselves working alone, and usually face more projects impacting user experience than they can handle. In this article, Paul Boag explains how UX teams can be transformed into a significant driver of customer-centric innovation within organizations.

In my experience of building and supporting UX teams, most of them are significantly under-resourced. In fact, the term “team” can often be a stretch, with many user experience professionals finding themselves alone in their roles.

Typically, there are way more projects that impact the user experience than the team can realistically work on. Consequently, most UX teams are in a constant state of firefighting and achieve relatively little in improving the overall experience.

We can complain about being under-resourced as much as we want, but the truth is that our teams are unlikely to grow to a size where we have sufficient staff to address every detail of the experience. Therefore, in this post, I want to step back and reconsider the role of user experience professionals and how UX teams can best improve the user experience of an organization.

What Is The Role Of A UX Professional? #

There is a danger that as UX professionals, we focus too much on the tools of our trade rather than the desired outcome.

In other words, we tend to think that our role involves activities such as:

• Prototyping
• User research
• Interface design
• Testing with users

But these are merely the means to an end, not the end goal itself. These activities are also time-consuming and resource-intensive, potentially monopolizing the attention of a small UX team.

Our true role is to improve the user experience as they interact with our organization’s digital channels.

The ultimate goal for a UX team should be to tangibly enhance the customer experience, rather than solely focusing on executing design artifacts.

“

This reframing of our role opens up new possibilities for how we can best serve our organizations and their customers. Instead of solely focusing on the tactical activities of UX, we must proactively identify the most impactful opportunities to enhance the overall customer experience.

Changing How We Approach Our Role #

If our goal is to elevate the customer experience, rather than solely executing UX activities, we need to change how we approach our role, especially in under-resourced teams.

To maximize our impact, we must shift from a tactical, project-based mindset to a more strategic, leadership-oriented one.

We need to become experience evangelists who can influence the broader organization and inspire others to prioritize and champion user experience improvements across the business.

“

As I help shape UX teams in organizations, I achieve this by focusing on four critical areas:

• The creation of shared resources,
• The provision of training,
• The offering of consultative services and
• The building of community.

Let’s explore these in turn.

The Creation Of Resources #

It is important for any UX team to demonstrate its value to the organization. One way to achieve this is by creating a set of tangible resources that can be utilized by others throughout the organization.

Therefore, when creating a new UX team, I initially focus on establishing a core set of resources that provide value and leave an impressive impression.

Some of the resources I typically focus on producing include:

• User Experience Playbook
  An online learning resource featuring articles, guides, and cheatsheets that cover topics ranging from conducting surveys to performing AB testing.
• Design System
  A set of user interface components that can be used by teams to quickly prototype ideas and fast-track their development projects.
• Recommended Supplier List
  A list of UX specialists that have been vetted by the team, so departments can be confident in hiring them if they want help improving the user experience.
• User Research Assets
  A collection of personas, journey maps, and data on user behavior for each of the most common audiences that the organization interacts with.

A service manual or digital playbook can serve as a powerful resource to assist and educate colleagues throughout your organization. (Large preview)

These resources need to be viewed as living services that your UX team supports and refines over time. Note as well that these resources include educational elements. The importance of education and training cannot be overstated.

The Provision Of Training #

By providing training and educational resources, your UX team can empower and upskill the broader organization, enabling them to better prioritize and champion user experience improvements. This approach effectively extends the team’s reach beyond its limited internal headcount, seeking to turn everybody into user experience practitioners.

This training provision should include a blend of ‘live’ learning and self-learning materials, with a greater focus on the latter since it can be created once and updated periodically.

Most of the self-learning content will be integrated into the playbook and will either be custom-created by your UX team (when specific to your organization) or purchased (when more generic).

Services like the Interaction Design Foundation offers a wide range of self-learning training materials that can be integrated into your training program. (Large preview)

In addition to this self-learning content, the team can also offer longer workshops, lunchtime inspirational presentations, and possibly even in-house conferences.

Of course, the devil can be in the details when it comes to the user experience, so colleagues across the organization will also need individual support.

The Offering Of Consultative Services #

Although your UX team may not have the capacity to work directly on every customer experience initiative, you can provide consultative services to guide and support other teams. This strategic approach enables your UX team to have a more significant impact by empowering and upskilling the broader organization, rather than solely concentrating on executing design artifacts.

Services I tend to offer include:

• UX reviews
  A chance for those running digital services to ask a UX professional to review their existing services and identify areas for improvement.
• UX discovery
  A chance for those considering developing a digital service to get it assessed based on whether there is a user need.
• Workshop facilitation
  Your UX team could offer a range of UX workshops to help colleagues understand user needs better or formulate project ideas through design thinking.
• Consultancy clinics
  Regular timeslots where those with questions about UX can “drop in” and talk with a UX expert.

But it is important that your UX team limits their involvement and resists the urge to get deeply involved in the execution of every project. Their role is to be an advisor, not an implementer.

Through the provision of these consultative services, your UX team will start identifying individuals across the organization who value user experience and recognize its importance to some degree. The ultimate goal is to transform these individuals into advocates for UX, a process that can be facilitated by establishing a UX community within your organization.

Building A UX Community #

Building a UX community within the organization can amplify the impact of your UX team’s efforts and create a cohesive culture focused on customer experience. This community can serve as a network of champions and advocates for user experience, helping spread awareness and best practices throughout the organization.

• 
  Leverage robust data-fetching and optimized bundle size with the KendoReact Server Data Grid
  Try now

Begin by creating a mailing list or a Teams/Slack channel. Using these platforms, your UX team can exchange best practices, tips, and success stories. Additionally, you can interact with the community by posing questions, creating challenges, and organizing group activities.

Utilize your community to assist in determining your organization’s design principles. This approach will not only involve the community but also lend greater authority to the design principles. (Large preview)

For example, your UX team could facilitate the creation of design principles by the community, which could then be promoted organization-wide. The team could also nurture a sense of friendly competition by encouraging community members to rate their digital services against the System Usability Scale or another metric.

The goal is to keep UX advocates engaged and advocating for UX within their teams, with a continual focus on growing the group and bringing more people into the fold.

Finally, this community can be rewarded for their contributions. For example, they could have priority access to services or early access to educational programs. Anything to make them feel like they are a part of something special.

An Approach Not Without Its Challenges #

I understand that many of my suggestions may seem unattainable. Undoubtedly, you are deeply immersed in day-to-day project tasks and troubleshooting. I acknowledge that it is much easier to establish this model when starting from a blank canvas. However, it is possible to transition an existing UX team from tactical project work to UX leadership.

The key to success lies in establishing a new, clear mandate for the group, rather than having it defined by past expectations. This new mandate needs to be supported by senior management, which means securing their buy-in and understanding of the broader value that user experience can provide to the organization.

I tend to approach this by suggesting that your UX team be redefined as a center of excellence (CoE). A CoE refers to a team or department that develops specialized expertise in a particular area and then disseminates that knowledge throughout the organization.

This term is familiar to management and helps shift management and colleague thinking away from viewing the team as UX implementors to a leadership role. Alongside this new definition, I also seek to establish new objectives and key performance indicators with management.

These new objectives should focus on education and empowerment, not implementation. When it comes to key performance indicators, they should revolve around the organization’s understanding of UX, overall user satisfaction, and productivity metrics, rather than the success or failure of individual projects.

It is not an easy shift to make, but if you do it successfully, your UX team can evolve into a powerful force for driving customer-centric innovation throughout the organization.

Building A User Segmentation Matrix To Foster Cross-Org Alignment

 Many organizations prioritize internal structures and services over customer-centricity, hindering effective decision-making. Through a case study, Talke Hoppmann-Walton advocates for a shift towards an outside-in perspective and proposes the use of a user segmentation matrix to foster alignment across departments and prioritize customer needs. If you are an experienced product or UX professional or a team leader dealing with stakeholder management to drive the organization as a whole forward, this article provides you with a canvas for better decision-making and focus.

Do you recognize this situation? The marketing and business teams talk about their customers, and each team thinks they have the same understanding of the problem and what needs to be done. Then, they’re including the Product and UX team in the conversation around how to best serve a particular customer group and where to invest in development and marketing efforts. They’ve done their initial ideation and are trying to prioritize, but this turns into a long discussion with the different teams favoring different areas to focus on. Suddenly, an executive highlights that instead of this customer segment, there should be a much higher focus on an entirely different segment — and the whole discussion starts again.

This situation often arises when there is no joint-up understanding of the different customer segments a company is serving historically and strategically. And there is no shared understanding beyond using the same high-level terms. To reach this understanding, you need to dig deeper into segment definitions, goals, pain points, and jobs-to-be-done (JTBD) so as to enable the organization to make evidence-based decisions instead of having to rely on top-down prioritization.

The hardest part about doing the right thing for your user or customers (please note I’m aware these terms aren’t technically the same, but I’m using them interchangeably in this article so as to be useful to a wider audience) often starts inside your own company and getting different teams with diverging goals and priorities to agree on where to focus and why.

But how do you get there — thinking user-first AND ensuring teams are aligned and have a shared mental model of primary and secondary customer segments?

Personas vs Segments

To explore that further, let’s take a brief look at the most commonly applied techniques to better understand customers and communicate this knowledge within organizations.

Two frequently employed tools are user personas and user segmentation.

Product/UX (or non-demographic) personas aim to represent the characteristics and needs of a certain type of customer, as well as their motivations and experience. The aim is to illustrate an ideal customer and allow teams to empathize and solve different use cases. Marketing (or demographic) personas, on the other hand, traditionally focus on age, socio-demographics, education, and geography but usually don’t include needs, motivations, or other contexts. So they’re good for targeting but not great for identifying new potential solutions or helping teams prioritize.

In contrast to personas, user segments illustrate groups of customers with shared needs, characteristics, and actions. They are relatively high-level classifications, deliberately looking at a whole group of needs without telling a detailed story. The aim is to gain a broader overview of the wider market’s wants and needs.

Tony Ulwick, creator of the “jobs-to-be-done” framework, for example, creates outcome-based segmentations, which are quite similar to what this article is proposing. Other types of segmentations include geographic, psychographic, demographic, or needs-based segmentations. What all segmentations, including the user segmentation matrix, have in common is that the segments are different from each other but don‘t need to be mutually exclusive.

As Simon Penny points out, personas and segments are tools for different purposes. While customer segments help us understand a marketplace or customer base, personas help us to understand more about the lived experience of a particular group of customers within that marketplace.

Both personas and segmentations have their applications, but this article argues that using a matrix will help you prioritize between the different segments. In addition, the key aspect here is the co-creation process that fosters understanding across departments and allows for more transparent decision-making. Instead of focusing only on the outcome, the process of getting there is what matters for alignment and collaboration across teams. Let’s dig deeper into how to achieve that.User Segmentation Matrix: 101

At its core, the idea of the user segmentation matrix is meant to create a shared mental model across teams and departments of an organization to enable better decision-making and collaboration.

And it does that by visualizing the relevance and differences between a company’s customer segments. Crucially, input into the matrix comes from across teams as the process of co-creation plays an essential part in getting to a shared understanding of the different segments and their relevance to the overall business challenge.

Additionally, this kind of matrix follows the principle of “just enough, not too much” to create meaning without going too deep into details or leading to confusion. It is about pulling together key elements from existing tools and methods, such as User Journeys or Jobs-to-be-done, and visualizing them in one place.

For a high-level first overview, see the matrix scaffolding below.

Visualization of the user segmentation matrix scaffolding. (Large preview)

Case Study: Getting To A Shared Mental Model Across Teams

Let’s look at the problem through a case study and see how building a user segmentation matrix helped a global data products organization gain a much clearer view of its customers and priorities.

Here is some context. The organization was partly driven by NGO principles like societal impact and partly by economic concerns like revenue and efficiencies. Its primary source of revenue was raw data and data products, and it was operating in a B2B setting. Despite operating for several decades already, its maturity level in terms of user experience and product knowledge was low, while the amount of different data outputs and services was high, with a whole bouquet of bespoke solutions for individual clients. The level of bespoke solutions that had to be maintained and had grown organically over time had surpassed the “featuritis” stage and turned utterly unsustainable.

And you probably guessed it: The business focus had traditionally been “What can we offer and sell?” instead of “What are our customers trying to solve?”

That means there were essentially two problems to figure out:

1. Help executives and department leaders from Marketing through Sales, Business, and Data Science see the value of customer-first product thinking.
2. Establish a shared mental model of the key customer segments to start prioritizing with focus and reduce the completely overgrown service offering.

For full disclosure, here’s a bit about my role in this context: I was there in a fractional product leader role at first, after running a discovery workshop, which then developed into product strategy work and eventually a full evaluation of the product portfolio according to user & business value.

Approach

So how did we get to that outcome? Basically, we spent an afternoon filling out a table with different customer segments, presented it to a couple of stakeholders, and everyone was happy — THE END. You can stop reading…

Or not, because from just a few initial conversations and trying to find out if there were any existing personas, user insights, or other customer data, it became clear that there was no shared mental model of the organization’s customer segments.

At the same time, the Business and Account management teams, especially, had a lot of contact with new and existing customers and knew the market and competition well. And the Marketing department had started on personas. However, they were not widely used and weren’t able to act as that shared mental model across different departments.

But How To Proceed Quickly While Taking People Along On The Journey?

Here’s the approach we took:

1. Gather All Existing Research

First, we gathered all user insights, customer feedback, and data from different parts of the organization and mapped them out on a big board (see below). Initially, we really tried to map out all existing documentation, including links to in-house documents and all previous attempts at separating different user groups, analytics data, revenue figures, and so on.

The key here was to speak to people in different departments to understand how they were currently thinking about their customers and to include the terms and documentation they thought most relevant without giving them a predefined framework. We used the dimensions of the matrix as a conversation guide, e.g., asking about their definitions for key user groups and what makes them distinctly different from others.

Discovery Board feeding into the User segmentation. (Large preview)

2. Start The Draft Scaffolding #

Secondly, we created the draft matrix with assumed segments and some core elements that have proven useful in different UX techniques.

In this step, we started to make sense of all the information we had collected and gave the segments “draft labels” and “draft definitions” based on input from the teams, but creating this first draft version within the small working group. The aim was to reduce complexity, settle on simple labels, and introduce primary vs secondary groups based on the input we received.

We then made sure to run this summarized draft version past the stakeholders for feedback and amends, always calling out the DRAFT status to ensure we had buy-in across teams before removing that label. In addition to interviews, we also provided direct access to the workboard for stakeholders to contribute asynchronously and in their own time and to give them the option to discuss with their own teams.

3. Refine

In the next step, we went through several rounds of “joint sense-making” with stakeholders from across different departments. At this stage, we started coloring in the scaffolding version of the matrix with more and more detail. We also asked stakeholders to review the matrix as a whole and comment on it to make sure the different business areas were on board and to see the different priorities between, e.g., primary and secondary user groups due to segment size, pain points, or revenue numbers.

4. Prompt 

We then promoted specifically for insights around segment definitions, pain points, goals, jobs to be done, and defining differences to other segments. Once the different labels and the sorting into primary versus secondary groups were clear, we tried to make sure that we had similar types of information per segment so that it would be easy to compare different aspects across the matrix.

5. Communicate

Finally, we made sure the core structure reached different levels of leadership. While we made sure to include senior stakeholders in the process throughout, this step was essential prior to circulating the matrix widely across the organization.

However, due to the previous steps, we had gone through, at this point, we were able to assure senior leadership that their teams had contributed and reviewed several times, so getting that final alignment was easy.

We did this in a team of two external consultants and three in-house colleagues, who conducted the interviews and information gathering exercises in tandem with us. Due to the size and global nature of the organization and various different time zones to manage, it took around 3 weeks of effort, but 3 months in time due to summer holidays and alignment activities. So we did this next to other work, which allowed us to be deeply plugged into the organization and avoid blind spots due to having both internal and external perspectives.

Building on in-house advocates with deep organizational knowledge and subject-matter expertise was a key factor and helped bring the organization along much better than purely external consultants could have done.

User Segmentation Matrix: Key Ingredients

So, what are the dimensions we included in this mapping out of primary and secondary user segments?

The dimensions we used were the following:

1. Segment definition
   Who is this group?
   Define it in a simple, straightforward way so everyone understands — NO acronyms or abbreviations. Further information to include that’s useful if you have it: the size of the segment and associated revenue.
2. Their main goals
   What are their main goals?
   Thinking outside-in and from this user groups perspective these would be at a higher level than the specific JTBD field, big picture and longer term.
3. What are their “Jobs-to-be-done”?
   Define the key things this group needs in order to get their own work done (whether that’s currently available in your service or not; if you don’t know this, it’s time for some discovery). Please note this is not a full JTBD mapping, but instead seeks to call out exemplary practical tasks.
4. How are they different from other segments?
   Segments should be clearly different in their needs. If they’re too similar, they might not be a separate group.
5. Main pain points
   What are the pain points for each segment? What issues are they currently experiencing with your service/product? Note the recurring themes.
6. Key contacts in the organization
   Who are the best people holding knowledge about this user segment?
   Usually, these would be the interview partners who contributed to the matrix, and it helps to not worry too much about ownership or levels here; it could be from any department, and often, the Business or Product org are good starting points.

This is an example of a user segmentation matrix:

Separating out primary & secondary user segments and providing key information in one space to share across the organization. (Large preview)

Outcomes & Learning #

What we found in this work is that seeing all user segments mapped out next to each other helped focus the conversation and create a shared mental model that switched the organization’s perspective to outside-in and customer-first.

Establishing the different user segment names and defining primary versus secondary segments created transparency, focus, and a shared understanding of priorities.

Building this matrix based on stakeholder interviews and existing user insights while keeping the labeling in DRAFT mode, we encouraged feedback and amends and helped everyone feel part of the process. So, rather than being a one-time set visualization, the key to creating value with this matrix is to encourage conversation and feedback loops between teams and departments.

In our case, we made sure that every stakeholder (at different levels within the organization, including several people from the executive team) had seen this matrix at least twice and had the chance to input. Once we then got to the final version, we were sure that we had an agreement on the terminology, issues, and priorities.

Below is the real case study example (with anonymized inputs):

Final version with anonymized inputs. (Large preview)

Takeaways And What To Watch Out For

So what did this approach help us achieve?

1. It created transparency and helped the Sales and Business teams understand how their asks would roughly be prioritized — seeing the other customer segments in comparison (especially knowing the difference between primary vs secondary segments).
2. It shifted the thinking to customer-first by providing an overview for the executive team (and everyone else) to start thinking about customers rather than business units and see new opportunities more clearly.
3. It highlighted the need to gather more customer insights and better performance data, such as revenue per segment, more detailed user tracking, and so on.

In terms of the challenges we faced when conducting and planning this work, there are a few things to watch out for:

We found that due to the size and global nature of the organization, it took several rounds of feedback to align with all stakeholders on the draft versions. So, the larger the size of your organization, the more buffer time to include (or the ability to change interview partners at short notice).

If you’re planning to do this in a startup or mid-sized organization, especially if they’ve got the relevant information available, you might need far less time, although it will still make sense to carefully select the contributors.

Having in-house advocates who actively contributed to the work and conducted interviews was a real benefit for alignment and getting buy-in across the organization, especially when things started getting political.

Gathering information from Marketing, Product, Business, Sales and Leadership and sticking with their terms and definitions initially was crucial, so everyone felt their inputs were heard and saw it reflected, even if amended, in the overall matrix.

And finally, a challenge that’s not to be underestimated is the selection of those asked to input — where it’s a tightrope walk between speed and inclusion.

We found that a “snowball system” worked well, where we initially worked with the C-level sponsor to define the crucial counterparts at the leadership level and have them name 3-4 leads in their organization, looking after different parts of the organization. These leaders were asked for their input and their team’s input in interviews and through asynchronous access to the joint workboard.

What’s In It For You? 

To summarize, the key benefits of creating a user segmentation matrix in your organization are the following:

• Thinking outside-in and user-first.
  Instead of thinking this is what you offer, your organization starts to think about solving real customer problems — the matrix is your GPS view of your market (but like any GPS system, don’t forget to update it occasionally).
• Clarity and a shared mental model.
  Everyone is starting to use the same language, and there’s more clarity about what you offer per customer segment. So, from Sales through to Business and Product, you’re speaking to users and their needs instead of talking about products and services (or even worse, your in-house org structure). Shared clarity drastically reduces meeting and decision time and allows you to do more impactful work.
• Focus, and more show than tell.
  Having a matrix helps differentiate between primary, secondary, and other customer segments and visualizes these differences for everyone.

When Not To Use It

If you already have a clearly defined set of customer segments that your organization is in agreement on and working towards — good for you; you won’t need this and can rely on your existing data.

Another case where you will likely not need this full overview is when you’re dealing with a very specific customer segment, and there is good alignment between the teams serving this group in terms of focus, priorities, and goals.

Organizations that will see the highest value in this exercise are those who are not yet thinking outside-in and customer-first and who still have a traditional approach, starting from their own services and dealing with conflicting priorities between departments.

Next Steps

And now? You’ve got your beautiful and fully aligned customer segmentation matrix ready and done. What’s next? In all honesty, this work is never done, and this is just the beginning.

If you have been struggling with creating an outside-in perspective in your organization, the key is to make sure that it gets communicated far and wide.

For example, make sure to get your executive sponsors to talk about it in their rounds, do a road show, or hold open office hours where you can present it to anyone interested and give them a chance to ask questions. Or even better, present it at the next company all-hands, with the suggestion to start building up an insights library per customer segment.

If this was really just the starting point to becoming more product-led, then the next logical step is to assess and evaluate the current product portfolio. The aim is to get clarity around which services or products are relevant for which customers. Especially in product portfolios plagued by “featuritis,” it makes sense to do a full audit, evaluate both user and business value, and clean out your product closet.

If you’ve seen gaps and blind spots in your matrix, another next step would be to do some deep dives, customer interviews, and discovery work to fill those. And as you continue on that journey towards more customer-centricity, other tools from the UX and product tool kit, like mapping out user journeys and establishing a good tracking system and KPIs, will be helpful so you can start measuring customer satisfaction and continue to test and learn.

Like a good map, it helps you navigate and create a shared understanding across departments. And this is its primary purpose: getting clarity and focus across teams to enable better decision-making. The process of co-creating a living document that visualizes customer segments is at least as important here as the final outcome.

Resolving Conflicts Between Designers And Engineers

 

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

• Successful Design Systems

• Prepare for today’s communication roles Northwestern’s MS in Information Design.
• Smart Interface Design Checklists

• Smart Interface Design Patterns, 8h-video course
• Start testing in minutes.
  Get axe DevTools

• Mastering The Design Process

In this article, Scott Himmer will go over some areas where you might find the design and engineering conflicts manifesting, what some of the contributing factors are, and strategies to work through the challenges.

In software development, UX designers and software engineers can get locked in verbal combat, which feels like a chess game of debate and wordplay. I’ve been there too many times and have the battle scars to prove it. If there has been anything I’ve learned from conflicts in the software development process, it’s that it’s not exclusively a cultural phenomenon, and obviously, it’s not productive.

The people involved in the conflicts generally react to a negative state of the world that no one wishes to be in. Sometimes it says more about a particular culture than us as individuals. Regardless of the reason, it’s not a good state for the organization or company to be in and will rob you of productivity, team cohesion, and focus on delivering customer value. Every company and department has its own challenges. In this article, we will go over some areas where you might find the challenges manifesting, what some of the contributing factors are, and strategies to work through the challenges.

I used to see the conflict between design and engineering in the software development process as annoying and an impediment to software design. When I began to see patterns in people and organizations involved in the conflicts mentioned above, I started to lean into the conflicts and see them more as an opportunity. I want to highlight some common contributing factors to design and engineering conflicts and lay out some strategies to work through them.

While engineers hold the keys to feasibility and how the technology works, designers hold the keys to the customer/market need and principles toward a delightful user experience.

“

If the two sides (design and engineering) don’t come together in perfect harmony, it could result in a functional feature that customers don’t enjoy or a good experience that’s not efficient and/or expensive to build. It’s not an either-or but an “and.” The design and the tech have to come together in harmony to balance the feasibility with aspects of a delightful experience.

I have found that, often, it’s easier for an engineer to see the aspects of a good user experience than for a designer to understand the technical aspects of how something functions, let alone how feasible it is. Regardless, the two sides work best when both lower their guards and reach across the aisle. Only then are your teams truly committed to delivering a great customer experience.

Assessing The Chasms #

There can be several contributors to the aforementioned dissension. From an organizational structure standpoint, contributors to the chasm could be boiled down to the following categories: culture, teams, roles, and individuals.

A review of the literature in saylor.org’s course lays these categories out in a bit more detail, and they note that “sometimes the structure of the organization itself can directly lead to conflict” whether that be based on the organizational structure or the authority provided within the structure.

I’ve seen these categories manifested in several ways. You may be able to relate to some of them. Let’s discuss them below.

Culture #

People do what they get rewarded for. If your organization incentivizes teams based on productivity, they will get good at cranking out widgets. Even if those widgets fall short of the customer expectations, the teams will become good at delivering what you asked for. Their focus becomes output over outcomes. This can cause teams to cut corners and produce “good-enough” solutions that miss the mark once released to customers. This is largely driven by the culture within the organization and can permeate the management hierarchy.

Teams #

Similar to what I mentioned regarding culture, a team, while aligned with the larger culture, typically has a team sub-culture. Sometimes a team culture can be seemingly at odds with the corporate culture. For example, a corporate culture that is collaborative and open can have teams that are hyper-focused on metrics and productivity that misconstrue the intent of the culture to meet productivity metrics. This is generally done to reduce uncertainty. I’ve worked with teams that became so hyper-focused on themselves that sizing a single user story practically took up an entire meeting.

Roles #

Staying in our lanes as designers and engineers. Personally, I couldn’t be more opposed to people staying in their lanes. I recognize that designers and engineers fulfill specific business needs, but we should be a unified body when it comes down to delivering outcomes. Engineers should have opinions on design, and designers should have opinions on the applied technical solution. The cross-pollination of views should support one another, which almost always leads to a better outcome.

Individuals #

I can be a contributor or a hindrance. I can become so focused on myself and my desires that I close myself off to others’ views. Rather than focusing on the outcome and the team, my views are forced on others, including the customer. I have seen this causes engineers to be entirely focused on output, “Just tell me what you want from me,” rather than collaborating on the outcome.

More after jump! Continue reading below ↓

Meet Smashing Email Newsletter with useful tips on front-end, design & UX. Subscribe and get “Smart Interface Design Checklists” — a free PDF deck with 150+ questions to ask yourself when designing and building almost anything.

Your (smashing) email

Once a week. Useful tips on front-end & UX. Trusted by 190.000 friendly folks.

United We Stand Or Divided We Fall #

Let me provide a few examples from my experience. I worked at one company where I tried several experiments to work more effectively with engineering. At a certain point, a prevailing schism was entrenched and a rather strong engineering-focused culture of “let us build it, get out of the way, and we’ll let you know what we need.” This tension had created an “us vs. them” mentality.

For this same company, I was brainstorming with a team for an upcoming project. As we started to get into sketching, I was met with blank stares followed by a litany of technical constraints. It was awkward, to say the least. Reflecting on it, I don’t think it went well because there wasn’t Product Owner buy-in, nor the proper context was set. I realized from that experience that when we are entrenched in a particular culture/team mindset focused on output for an extended period of time, it can be poisonous and entrench not only our behavior but also our mindset.

Last but not least, while working at a different company, I noticed a middle management cultural problem. The senior leadership spoke about collaboration, great design, and high quality. The agile teams executing on work agreed with this philosophy and were trying to work towards the leadership vision. However, middle management was making decisions that conflicted with senior leadership. The engineering manager would tell engineers to build things that completely excluded design. When designers tried to engage in the process, the engineers were just following orders. There were engineering building and shipping things with little to no Product Management or UX Design input, which showed in the product.

For an organization to be successful, they need to be united. We need to balance our thought processes and cross-pollinate our skills for our organizations to thrive.

“

It is wise to give the organization and teams the benefit of the doubt. Too often, we’re all just caught in the middle of what appears to be dysfunction. That dysfunction can be an opportunity for change if we learn to navigate the distraction that leads to conflicts.

Distractions #

Several studies have dug into this problem space of conflicts with teams, specifically UX designers and software engineers. A 2002 study by Dejana Tomasevic and Tea Pavicevic found that “tasks conflicts are the most common type of conflict. A 2019 study by Marissa Wilson also found that “100% of conflicts reported were task conflicts”.

After being in the trenches for a while, I’m not surprised by these studies, so I’d like to add some color to the study findings directly from the trenches. From my experience, most of the barriers to engineering and design collaboration are simply distractions. Although cultural issues can be barriers to collaboration, if people really want to bring about a positive change, they will find a way.

Let’s review some distractions that you’ll likely need to overcome:

• Timing
  Designers generally build up ideas (induction) while engineers break them down (deduction) to chunk out building the solution. While there is time to build up ideas and time to break down work, getting the timing right for either of these is important to avoid conflicts. Too often, we’re trying to build up ideas, and our partners are trying to break down the work.
• Miscommunications
  Designers and engineers have different skill sets and backgrounds. As a result, both groups come from different perspectives, speak different languages, and use different terms. This can lead to tremendous frustration, as Ari Joury points out in his article on designer and developer clashes.
• Mis-alignments
  If you don’t have the same frame of reference, you will have disagreements. It might be impossible to share every detail at every moment with everyone on the team, but there must be a shared understanding of the problem and the value the team is targeting. Misalignments can cause teams to pull in different directions.
• Role factions
  Sometimes teams get too focused on who’s responsible/owns what part of the solution. In a truly collaborative environment, the team owns the solution they’re working toward. Designers should get comfortable leaning into the engineering space, even if it’s to learn more about it. Same for engineers, lean into the design space and learn.
• Metrics
  Metrics help teams to be more focused on the outcome. They also help us be more incremental in our approach. You definitely want a healthy balance here because metrics on value delivery vs. metrics on team productivity can sometimes feel at odds. This can lead teams to focus on getting all the details right, which robs time away from delivering an outcome. Winston Churchill once said, “perfection is the enemy of progress.”

Though the list above is not exhaustive, there have been common themes in the various companies and teams I’ve worked with. The teams you work with within your company may be experiencing one or multiple of these distractions. Hopefully, not all of them! Regardless, designers and engineers will have conflicts if they work together. It’s our job as business partners to lean into them and work through them for teams to be successful.

• 
  A React Data Grid that makes a developer’s life easier? Yes, there is one: the KendoReact Grid
  Get a Data Grid!

Striving For Unity #

I think it’s crucial to understand that trust has to be the cornerstone of any team unity. In an article by Built In in 2021, they provide a variety of examples for uniting teams. In it, Jillian Priese, Engineering Manager at Granular tells us that for her teams, “When trust is present, it makes all the difference in the world.” And that without trust, it’s “easy for engineers and designers to question one another’s motivations and abilities.” Whatever the barrier, we must employ strategies to close the gaps and bring unity to the team.

Here are some tips that I’ve found to be effective:

• Discover together.
  While the design team is in the discovery phase of a project, make a point to include the engineers. In the research stage, they can be observers while hearing from actual users of their code. Don’t forget to include them in the ideation process as well. Give them room to fall in love with the problem space. As you discover, iterate, and refine, pull in engineers to get their input, particularly in areas where you want special interactions to take place. They can help you balance the approach to provide more value and be more feasible.
• Be curious.
  Try not to assume too much and be prepared to learn. Designers have a lot to learn from engineers, and engineers can learn a lot from designers. Cross-pollination of skills strengthens teams. You don’t have to be a designer or engineer, but you should spend some time learning a little about your partner’s role and their work. Exercise empathy and keep each other honest.
• Speak their language.
  As Ari Joury notes in his article, designers and engineers speak different languages. Designers and engineers sometimes assume they’re speaking the same language and using the same terms only to find that when the wires get crossed, they are talking about different things. Sometimes you will learn to slow down for clarity and shared understanding. Engineers need to be willing to patiently translate foreign technology to designers. Designers need to be ready to patiently sketch and use visuals to translate concepts to engineers sometimes.
• Be together.
  I literally mean that you sit with each other when you can. As a designer, I have learned a lot from sitting with or in near proximity to engineers about their work, each of them individually, about myself, and the need to modify my work behavior to be a better partner. If you happen to be remote, make a team commitment to be available whenever needed, and be sure you follow through on that commitment to help build trust.

It’s really powerful and rewarding when engineers are more aligned with UX designers because they can elevate good designs to be great designs when they’re fully engaged. I like to believe that engineers breathe life into UX designs through the power of technology.

Practical Examples #

As noted above, no company is the same, and different tactics should be used depending on your team’s challenges. Here are some practical examples of how I have put the tips above into practice.

Growing By Learning #

At one organization, I came in as the lone designer being dropped into an existing team. It was awkward because the culture had generally been tech-centric. I was the outsider and struggled to make headway. Over time, I realized that the team was open to more design collaboration but was a bit new to working with a designer. The team was in another country, so I petitioned to spend a few days working with them.

Part of my plan was to focus on our epic, which has a lot of frontend work; the other part of applying some design exercises. Since the team was new to design thinking, we did a lateral thinking exercise and UI pattern workshop. After that, things began to gel with us. The team became more user aware and empathetic, and the team started to come to me with UI defects and great ideas for solutions. I enjoyed working with that team.

Make Yourself Available #

At another smaller organization, the UX team was positioned with the Product Management (PM) department. The PM and Engineering departments were located on separate floors in the same building. It didn’t take long to realize that the barriers to collaboration while manifesting in several ways, were rooted in physical separation.

Image by Scott Himmer. (Large preview)

To start working to resolve this, I set up shop in the engineering space a few times per week. A sort of “UX Help Deck,” if you will. At first, I think they thought it was weird, but eventually, people began to open up. It facilitated many opportunities to better understand the team’s needs, educate them on the users’ needs, learn about their tech stack, and find in-roads with Product Owners and Engineering Managers. Fortunately, much of the engineering team appreciated it. So, we built great relationships and made a lot of progress in a short amount of time.

Playing To Their Tune #

At a much larger organization, I worked against a heavily entrenched engineering-centric culture. I made quite a few mistakes in that environment, such as not seeking more clarity on the authority of roles for the project, not pursuing more clarity in the project direction and priorities, and pushing back more against unreasonable hot-headed stakeholders.

I gained a lot of patience working with architects that had little experience working with UX designers. We were speaking different languages at different levels about different needs. They had a ton of domain knowledge from years of experience. So, they would pull these obscure edge cases out of thin air in conversations as a sort of trump card to any reasonable design recommendation. It was frustrating and humbling. To them, UX was all about “looking pretty” (the visceral aspects of the user interface). Sigh.

From my end, they saw UX as the lipstick they could just apply to the pigs they wanted to build. The in-road there was playing to their mindset. The architects fundamentally wanted to build a system that was robust, scalable, and easy to maintain quickly. The system being user-centered was the least important in their mind, and even that was generally boiled down to “looking nice,” which is not user-centered.

However, I believed we could build user-centered solutions and teach them along the way, but I had to think more modular and scalable. We needed to establish a frontend framework quickly and lay down some foundational guidelines we could build upon. We used that as building blocks that engineering could buy into. That helped them see UX as an ally to their goals rather than an adversary. We created a design system that helped us focus on user needs yet efficiently design at scale. While we got buy-in pretty quickly with engineers, we eventually began to see traction with the architects as the slow, grueling process slugged on.

Conclusion #

Finding the impediments that are preventing the unification of the clan is important. It’s essential for your organization, your customers, and your sanity. It does entail effort but is well worth it. Experiment with your teams to find what works for them. The same strategy might not work for every team. When you meet resistance, don’t pull away, but lean into it and be patient.

As a reminder of the things we covered:

• Assess the level at which you’re finding the biggest chasms;
• Identify the distractions you’re seeing in your teams and what might be contributing to them;
• Take action and experiment with different tactics to establish unity.

Challenge the status quo when appropriate. You may ruffle some feathers at first, but sometimes disruption is needed to get to a better state.

“

You may not make friends at first, but you will get respect. You may find that thirty percent of the people are on board with you. Another thirty percent are interested but not yet sold. The remaining percent of nay-sayers who want to continue with the status quo will eventually come along as the rest of the clan unites around them. Fight the good fight, my friends, and unite the clans!