BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course
BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course
BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course
BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course
BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course
BLOG · ARTICLE
The UX Maturity Model: Leading User Experience within the Organization
Written by: Daniela Suaza
Category: Leadership
UX maturity is an intentional evolution driven by scalable processes and strategic alignment. This article explores the stages of team development within an organization and examines how to lead user experience as a business-critical function. I break down the transition from tactical execution to organizational influence, providing a blueprint for leaders aiming to embed design intelligence into the corporate DNA.
I'll be honest about where this comes from. Everything I'm about to share is grounded in years of leading design teams firsthand - not as a consultant observing from the outside, but as someone who built processes from scratch, made the wrong hires, redesigned team structures mid-flight, and learned, sometimes the hard way, what it actually takes to make design work within an organization. This article is the distillation of that experience. Take what's useful. Push back on the rest.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
Not too long ago, the product designer lived in a place that was comfortable and uncomfortable at the same time: they were the ones who made the screens. They received the ticket, opened Figma, and delivered. If you were lucky, you got invited to the requirements meeting. If not, you found out about the changes in the sprint review.
That role still exists. But the world around it has changed completely.
Today, the most competitive organizations on the planet don't hire designers to make screens. They hire designers to solve business problems, anticipate user friction before it becomes technical debt, and translate corporate strategy into experiences people actually want to use. And for that to be possible, they need more than individual talent: they need infrastructure, structure, and leadership. They need DesignOps.
This article is for those who are building that bridge.
What Is DesignOps and Why Does It Matter Now
DesignOps — Design Operations — is the discipline concerned with how a design team works. Not what it designs, but how it does so: how it organizes itself, how it collaborates, how it communicates with the rest of the organization, how it measures its impact, and how it scales.
The Nielsen Norman Group, a global reference in UX, defines DesignOps as the set of practices that amplify the value of design by improving its efficiency, quality, and impact. It's not a single role or a separate department — it's a set of intentional decisions about how to operate. It spans areas like team organization, cross-functional collaboration, humanization of work processes, methodology standardization, inter-team harmonization, initiative prioritization, outcome measurement, and task automation.
In other words: DesignOps is what turns a group of talented designers into a team that can scale, demonstrate its value, and exert strategic influence.
Why does it matter now? Because the context demands it. Over the last decade, the role of design in technology and product organizations shifted from being an aesthetic discipline to a strategic function. Companies that once hired a single designer to "make things look good" now have multidisciplinary teams with UX Researchers, Content Designers, UX Writers, Design System Leads, and Design Strategists. That growth brought complexity. And complexity without structure becomes chaos disguised as agility.
DesignOps exists so chaos doesn't win.
How the Product Designer Role Has Changed
The product designer of 2015 and the one of 2025 share the same job title. That's where the resemblance ends.
For years, product design operated in an essentially reactive model: the business defined what to build, product management specified how, and design handled the interface. It was a functional model for small organizations, but fundamentally broken for any company that wanted to grow with intention.
The shift came from multiple directions at once. The mass adoption of Design Thinking as a corporate methodology elevated designers into earlier conversations. The rise of digital products as a primary revenue channel — not as support, but as the business itself — meant user experience stopped being a "nice to have" and became a direct competitive differentiator. And the professionalization of the field, with more academic programs, certifications, and communities of practice, produced a generation of designers capable of speaking the language of business without losing the language of the user.
The result is a profile now expected of the senior or lead designer: someone who doesn't just execute, but diagnoses, proposes, measures, aligns, and leads. Someone who understands that designing isn't making screens — it's making decisions.
And leading that requires more than design instinct. It requires the ability to build and sustain a team.
Why Building a Well-Structured Design Team Matters
A well-structured design team is not synonymous with a large team. It's a team with clarity across three dimensions: who does what, how it connects to the rest of the organization, and where it's going.
Research in UX team management is consistent: the quality of the team and the quality of its leadership are the two factors that most impact the return on design investment. Not the tools. Not the headcount. Not seniority. Structure and leadership.
A team without clear structure accumulates silent debt. The senior designer ends up doing junior work because there's no one else. Projects get duplicated because there's no shared visibility system. Design decisions get reversed during implementation because there was no early alignment with engineering. Reactive leadership fights fires instead of building processes that prevent them.
A well-structured team, on the other hand, can operate with less friction, produce with greater consistency, and demonstrate its impact measurably. That's not a luxury — it's what allows design to be taken seriously as a business function.
What Is UX Maturity and What Stage Is Your Organization At
UX maturity describes the level of evolution of an organization in its relationship with user-centered design. It's not a straight line, but it is a map.
The most widely referenced model in the industry, developed by Nielsen Norman Group, identifies eight stages. For practical purposes, we can group them into five major moments:
Stage 1 — Absent: Design doesn't formally exist. Someone with aesthetic sensibility handles "the visual part," and that gets called design.
Stage 2 — Present but reactive: There are one or two designers, but they operate in executor mode. They receive tickets and deliver screens. They have no voice in early decisions.
Stage 3 — Invested: The organization starts to believe in design. There are more resources, more budget, more invitations to strategic conversations. However, processes are still inconsistent and impact is hard to measure.
Stage 4 — Integrated: Design is part of the product process. Designers collaborate as equals with product and engineering. There's user research, design systems, and experience metrics.
Stage 5 — Embedded / Transformative: Design is a strategic function. It has influence over business direction, organizational culture, and the way the entire company makes decisions.
Where does the world stand today? Industry data suggests most organizations find themselves at stages 2 and 3. Only a small fraction has achieved genuine integration — and even fewer have reached the transformative level. Which means there is an enormous opportunity for those with the capacity to build that path.
The question every design leader must ask is honest and direct: what stage are we actually at — not what stage do we think we're at?
Team Structure: Who, How, and Why
A mature design team is not a group of people with the same profile multiplied by N. It's an intentional composition of complementary skills.
The most functional teams I've seen — and those that UX management literature supports — combine at least three types of competency:
Research and synthesis: The ability to talk to users, process qualitative and quantitative data, and convert findings into design decisions. Without this, the team designs with assumptions.
Interaction and visual design: The translation of needs into solutions. This includes information architecture, flows, prototyping, and the visual layer that makes the experience coherent and accessible.
Systems and operations: The infrastructure that scales. Reusable components, documentation, style guides, delivery processes. Without this, the team reinvents the wheel on every project.
In small teams, one person may cover several of these spaces. In mature teams, there is clear specialization. But in all cases, what defines whether the team works is not the org chart — it's role clarity and the quality of collaboration.
Skill Mapping: Knowing the Team You Have to Build the One You Need
Skill mapping is the process of charting the team's strengths, gaps, and aspirations in order to make informed decisions about hiring, development, and workload distribution.
It's not a performance review form. It's a strategic conversation with each team member about what they're good at today, what they want to develop, and what they need to do so. Crossed with the organization's current and projected needs, that map becomes a powerful leadership tool.
Skill mapping answers three questions: Where are we strong? Where are we vulnerable? How do we complement each other?
And from those answers, individual learning paths are built that make sense both for the person and for the team. Not generic courses assigned by HR, but intentional development aligned to the real needs of the work.
The Maturity Roadmap: Where to Go and How Long It Will Take
Once you have clarity on where your team is and what skills it needs to develop, the next question is directional: where do we want to go and in how long?
A UX maturity roadmap is not a wishlist document. It's a strategic plan with measurable milestones, anchored to the organization's business objectives.
The distinction matters. A roadmap that lives only in the design world — "we want to implement a design system and do more research" — is easily dismissible for a CFO or VP of Product. A roadmap that translates those initiatives into business impact — "the design system will reduce delivery time for new features by 30% and ensure consistency across all user touchpoints" — is a different conversation entirely.
The process of building that roadmap should include three steps: first, an honest diagnosis of the current state; second, a clear definition of the desired state over a 12-to-18-month horizon; and third, the alignment of each initiative with a concrete business objective.
When design speaks the language of the business, the business starts to listen.
Measuring Team Success
"What gets measured gets managed" is one of those clichés repeated in leadership meetings without anyone having thought carefully about what it means in a design context.
Measuring the impact of design is hard. But not impossible. And difficulty is not an excuse to skip it.
Design team metrics operate at two levels: those that measure the quality of the work and those that measure the efficiency of the processes.
At the first level, the most relevant metrics are tied to the user experience: task completion rates, time on task, NPS, CSAT, abandonment rate, retention. These metrics connect design to business outcomes directly.
At the second level, metrics like the cycle time of a deliverable, the number of iterations before approval, or the adoption rate of design system components speak to the operational health of the team.
Most importantly, those metrics should be shared regularly — at least monthly — with relevant stakeholders. Not as an activity report, but as a conversation about impact. Design that can't demonstrate its value will eventually lose the budget to produce it.
UX ROI: The Argument the Business Needs to Hear
The return on investment of design is one of the most researched and least communicated topics in the industry. We have the data. What many design teams lack is the habit of using it.
Forrester Research has documented that design-led companies outperform the S&P 500 in shareholder return. The IBM Design Thinking Study reported that for every dollar invested in UX, up to 100 are recovered. McKinsey, in its report The Business Value of Design, found that companies in the top quartile of design performance grow revenue at nearly double the rate of those in the bottom quartile.
These numbers aren't for a keynote slide to be forgotten. They're for building the argument that justifies investing in the team, the tools, the processes, and the time needed to do the work well.
UX ROI doesn't come just from making beautiful screens. It comes from reducing the friction that costs money: fewer late-stage redesigns, fewer support calls, fewer users abandoning a purchase flow because they didn't understand the next step. It comes from building products people actually want to use.
Design Systems and Automation: The Infrastructure That Scales
If skill mapping is the team's strategic conversation, the design system is its operational infrastructure. And in 2025, that infrastructure has to include automation.
A well-built design system is not a component library in Figma. It's a shared language between design and engineering — documented, versioned, and maintained. It's what allows a team of five designers to operate with the consistency and speed of a team of twenty.
Artificial intelligence is redefining what's possible in this space. Today, AI tools can generate component variants, detect design inconsistencies at scale, suggest accessibility corrections, automatically document usage patterns, and even translate design tokens into production-ready code.
But AI doesn't replace the design decision — it amplifies it. The design leader who understands how to integrate these capabilities into the team's workflow doesn't just increase productivity: they free up their designers' time for the work that genuinely requires human thinking.
The question worth asking isn't "should we adopt AI?" but "in which parts of our process does automation give us enough headroom to think better?"
Processes and Consistency: Figma Is Just the Beginning
One of the most common mistakes in growing design teams is confusing visual consistency with operational consistency. The design system ensures that buttons look the same throughout the application. But it doesn't guarantee that the team collaborates effectively, that design reviews generate real value, or that handoffs to engineering happen without information loss.
The consistency that matters for scaling doesn't live in Figma. It lives in agreements about how we work together.
That includes how files and layers are named. How design decisions and their rationale are documented. How feedback is given and received constructively. How coordination with product and engineering happens from the start of a project, not the end. How complexity scales without losing coherence.
Teams that have these agreements made explicit — not assumed, not inherited through habit, but deliberately defined — are the ones that maintain quality as they grow. Those that don't eventually fracture under their own weight.
Internal Education: The Quiet Key to Success
Building a mature design team isn't about hiring the right people and waiting for things to work out. It's about creating the conditions for those people to keep growing within the organization.
Internal education — continuous, intentional training contextualized to real work — is one of the factors that most differentiates high-performing teams from those that stagnate.
This doesn't mean organizing Figma workshops once a year. It means creating a culture of continuous learning: regular critique sessions where the team learns from each other, access to quality training resources, explicit space in the workload to experiment and learn from failures, and mentorships that connect junior designers with those who have already solved the problems they're now facing.
A design leader who invests in their team's growth isn't being generous. They're being strategic. A team that learns fast adapts fast. And in a field that changes as rapidly as ours, that capacity for adaptation is a real competitive advantage.
For organizations seeking design leaders who already have this mindset built in, Toptal's design leads network is one of the few places where the selection standard is on par with what these roles truly demand.
Evangelization: The Conversation Many Avoid Having
There is a persistent gap in many organizations between what the design team knows it can contribute and what executive leadership believes design is capable of. Closing that gap is the design leader's job. And that job is called evangelization.
Evangelizing design isn't convincing skeptical people that design matters. It's showing evidence of impact in the language the business understands and values.
Conversations with the board can't start with wireframes. They must start with business metrics: churn reduction, conversion increase, support cost reduction. Design needs to appear in that conversation as the lever that moved those numbers — not as the aesthetic process that accompanied them.
This requires preparation. It requires building an impact narrative with concrete data, success stories, and clear projections. It requires talking less about deliverables and more about outcomes.
Design leaders who master this skill don't just secure budget — they earn a seat at the table where the decisions that later arrive as tickets are actually made.
Evaluate and Keep Improving: The Value of the Leader Who Listens
There's something that distinguishes design leaders who build teams that last from those who build teams that collapse when they leave: the ability to listen to their own team as a primary source of information about what's working and what isn't.
The leader who believes their vision of how the team should operate is sufficient — without validating it with the people who live that operation every day — is designing in a vacuum. Exactly the mistake they would criticize in any product that doesn't do user research.
Iterating on team processes with the same mindset we apply to products — with observation, hypotheses, experiments, and a willingness to change direction when the data suggests it — is what keeps a team relevant and healthy as it grows.
A leader's value isn't in having all the answers. It's in creating the conditions for answers to emerge from the team, and in having the honesty and humility to implement them.
Conclusions
Building a design team that operates as a strategic function is not a project with a delivery date. It's a continuous process of intention, structure, and learning.
It requires understanding what maturity stage the organization is genuinely at — without self-deception. It requires mapping the team's strengths and gaps to make informed decisions. It requires building a roadmap that speaks the language of the business. It requires processes that guarantee consistency beyond Figma. It requires measuring impact honestly. It requires educating inward with consistency and evangelizing outward with evidence.
And above all, it requires a type of leadership that doesn't confuse authority with vision. That listens. That iterates. That understands that designing the team is itself an act of design.
The organizations making this transition — from viewing design as a production service to seeing it as a strategic capability — are the ones that will define the standard for the coming years. And the leaders building that path today are the ones who will be sitting at that table when the credit is distributed.
The time to build is now.
Further Reading & References
If you want to go deeper into the topics covered in this article, these are two of the resources that informed my thinking and that I'd recommend to anyone serious about building design maturity within their organization:
- Nielsen Norman Group — DesignOps Study Guide: A comprehensive guide to understanding Design Operations, its scope, and how to apply it in practice. Read it here
- Interaction Design Foundation — UX Management: Strategy & Tactics: The course that systematizes the principles of UX maturity, team leadership, and strategic alignment covered throughout this article. Explore the course