All articles

4 Inclusive Design Mindsets That Actually Work

Four practical mindsets that shape everyday product decisions, research practices, and team dynamics.

Read
8 min
Topic
Research, Inclusive design
Who is inside the norm, who is outside

Inclusive design is often discussed at the level of values. Much less often is it treated as part of everyday product work, as something that directly shapes which decisions are made and whose experience ultimately becomes the foundation for those decisions.

In practice, inclusivity does not show up in declarations, but in details: in the questions a team asks during research, in who is considered a relevant participant in the process, in how discussions are structured within the team, and in which decisions are ultimately treated as "normal."

Most often, these decisions are based on the team's own experience. In itself, this is not a mistake. The problem arises when that experience quietly becomes the only point of reference. At that point, the product begins to reflect the team's internal logic rather than the diversity of user contexts and real-world scenarios.

Inclusive design helps teams notice this shift in time. It is not about creating a product "for everyone," but about awareness in decision-making: the ability to see a single but critical question. Whose experience are we treating as the norm right now, and who is left outside of it?

The approaches here have evolved at the intersection of human-centered design, participatory research, and inclusive design practices. One of the most widely known systematizations is the four-mindset model described by the IDEO U team. Below, these principles are examined as practical working models, with concrete steps teams can apply in everyday product work.

Build on what already exists

Working with content instead of researching "from scratch"

An inclusive designer does not start from a blank slate, but works within an existing context. In any product environment, there are already established decisions, hypotheses, and accumulated knowledge that need to be taken into account.

An informed partner clearly distinguishes between two different processes: their own onboarding into the product and generating new knowledge for the team. The goal is to focus on questions that truly remain open, rather than turning personal learning into the outcome of the research.

The opposite approach emerges when a designer comes in unprepared and treats familiar information as a new discovery. Participants are forced to re-explain basic context, and the research ends up repeating insights that were already known.

How this shows up in practice

  • Study the context in advanceBefore starting research, clarify what knowledge, conclusions, and decisions already exist.
  • Clearly define the research goalIdentify what new understanding should emerge as a result of the work.
  • Separate new insights from confirmationExplicitly distinguish where research generated new knowledge and where it merely validated existing conclusions.
  • Make the research contribution transparentShow what this work added and how it influences subsequent product decisions.

Best practice

A designer joins a project, reviews existing materials and discussions, and then focuses research only on questions where the team lacks clarity. As a result, the work extends shared understanding rather than repeating what has already been covered.

Why this mindset matters

The Informed Partner helps teams use research to move forward, not to revisit ground they have already covered.

A closed loop, not extraction

Partnership instead of data extraction

This mindset is based on a simple but fundamental shift: research participants are not data sources, but partners in the process. Their experience and understanding of context are treated not as raw material for analysis, but as part of a shared effort to arrive at better decisions.

In this approach, people's contributions matter beyond interviews or usability tests. They are considered during interpretation and influence downstream decisions. Research stops being an isolated activity and becomes part of an ongoing dialogue between the team and the people the product is built for.

The opposite approach reduces research to information extraction. Teams collect quotes and observations, then move on. Participants are left without understanding how their input was used, and research remains a one-off activity that does not build lasting relationships or shared understanding.

How this shows up in practice

  • Define the research focusClearly articulate the goal and key questions so participants understand why they were involved and what their input may influence.
  • Provide context to participantsExplain how feedback will be used and how it may shape future decisions.
  • Return with synthesized understandingAfter analysis, share the team's key takeaways without diving into implementation details.
  • Connect input to decision directionsShow which observations and comments influenced specific product directions.
  • Close the feedback loopCommunicate how the work concluded, even if certain suggestions were not implemented.

Best practice

At the start of an interview, the designer explains what problem the team is exploring and why participant experience matters. After analysis, they follow up with a brief summary of what became clearer and where the team is heading. Participants can see that their contribution had continuity.

Why this mindset matters

The Collaborative Relationship-Builder changes not the format of research, but the attitude toward it, helping teams make decisions grounded not only in data interpretation but also in trust, before those decisions become embedded in the product.

Notice the quiet voice

Balancing influence instead of defaulting to dominant experience

This mindset is rooted in the understanding that influence in product decisions is unevenly distributed. An inclusive designer does not treat the loudest or most familiar experience as universal, but actively works to ensure that different groups have comparable weight in decision-making.

Within teams and among users, some perspectives naturally surface more quickly and strongly. When these perspectives are treated as the "norm," products begin to reflect the interests of those who already have a voice, while systematically overlooking other scenarios.

The Conscientious Advocate mindset focuses on addressing this imbalance. It helps identify whose experience is missing and uses one's role in the process to bring those perspectives back into the decision space.

The opposite approach emerges when decisions are shaped around familiar viewpoints and the absence of other voices is neither noticed nor treated as a problem. Over time, this quietly reinforces existing biases.

How this shows up in practice

  • Monitor how influence is distributedTrack whose arguments shape decisions and which perspectives consistently fall outside the discussion.
  • Create multiple participation formatsRecognize that not everyone can or will participate actively in group discussions, and provide alternative ways to contribute.
  • Bring less-visible experience into the conversationUse your position to surface scenarios and constraints that would otherwise remain invisible.
  • Assess decision impactEvaluate which groups a decision simplifies the experience for, and which it creates barriers for.

Best practice

In team discussions, the most confident voices are often adopted quickly. The designer captures less-visible scenarios and reintroduces them into the conversation, so the final decision reflects real usage context rather than the loudest arguments.

Why this mindset matters

The Conscientious Advocate helps teams make decisions that reflect a more accurate picture of real user contexts, not just the most audible ones.

From the known into the open question

Exploring without predefined answers

This mindset begins with the recognition that designers never work in a vacuum. There are always existing decisions, hypotheses, constraints, and accumulated product knowledge. An inclusive designer works within this context rather than ignoring it.

The Curious Researcher separates personal onboarding from research outcomes. The goal is not to turn personal learning into research results, but to focus on questions that genuinely remain open and require exploration.

This shifts the focus of research. Context and decision history become the starting point, not something to be rebuilt. Questions are framed with existing knowledge in mind, and the work is aimed at expanding shared understanding rather than reproducing baseline insights.

The opposite approach appears when a designer arrives unprepared and treats familiar information as new. Participants are forced to restate basic context, and research collapses into repetition.

How this shows up in practice

  • Study existing context firstUnderstand what knowledge, conclusions, and decisions already exist.
  • Define a clear research goalIdentify what new understanding should emerge.
  • Distinguish discovery from validationClearly note where research added new insight versus confirmed existing assumptions.
  • Make the contribution explicitShow how the current work advances product decisions.

Best practice

A designer joins a project, reviews existing documentation and discussions, and focuses research only on unresolved questions. The result extends collective understanding rather than repeating prior work.

Why this mindset matters

The Curious Researcher helps teams distinguish new knowledge from what has already been learned, and use research to move forward instead of replaying context.

Different shapes, equal standing

Inclusive design is not a trend or an extra requirement placed on designers. It is a behavioral model that shapes how teams make decisions: which values are treated as meaningful, which experience is considered sufficient, and where responsibility lies. These mindsets only work when they are shared across the entire system, by designers, managers, researchers, and technical leaders alike.

When these best practices are not embedded into everyday work, risks accumulate over time. Teams lose time to repeated research and rework, the same assumptions are reinforced again and again, and parts of both user and internal experience consistently fall outside the conversation. Over time, this affects not only the quality of product decisions, but also the working environment itself: trust erodes, tension increases, and a sense of shared responsibility begins to blur.

That is why working with inclusive mindsets is not a one-off initiative, but part of a sustainable product practice, one that helps teams make more accurate, deliberate decisions over time.

The Most Important Design Decision Happens Before You Design Anything In progress
From Design Thinking to a Practical Design Process In progress
Best Practices for Designer–Developer Handoff In progress
The Art of Feedback: Conversations That Improve Decisions