5 common inclusive design challenges (and how to solve them for better digital products)
.jpg)
Inclusive design. Accessibility-first. Designed for all. We’ve all heard the terms. They sound great on a slide deck and even better in a company values statement, but all too often, that’s where the conversation stops.
In many digital teams, inclusivity and accessibility in digital products are treated like buzzwords. Well-meaning, nice-to-have ideas that live at the bottom of the backlog. There's a persistent myth that digital accessibility is about checking legal boxes or doing the right thing if we have time. And inclusivity? That’s sometimes mistaken as simply using diverse stock photos or translating a page into another language.
But the reality is inclusive UX design isn’t a bolt-on. It’s a core ingredient of good digital products. True inclusive design starts at the beginning. It’s what makes digital products usable, sustainable, and future-ready.
As one of our panellists at our TechNExt 2024 fringe event ‘Accessibility Transformation: Ensuring Tech for All’ Ronise Nepomuceno, Digital Accessibility Lead at EE put it:
“The web was built to democratise information, not to leave anyone behind. We use the web to access essential services like healthcare, education, and employment and when access isn’t inclusive, people miss out on things they need to live, learn, and work.”
That idea isn’t just ethical, it’s practical. Because when you design for the margins, everyone benefits. Accessible digital products tend to be more robust, easier to navigate, faster to load, and simpler to maintain. They perform better across devices, bandwidths, and user contexts. In other words: inclusion drives reach, relevance, and ROI.
And here’s the important distinction:
Accessibility is about removing barriers so that people with disabilities can access and interact with digital content.
Inclusivity, on the other hand, is broader. It’s about designing with a wide range of users in mind from the start, including different backgrounds, contexts, abilities, and needs.
Inclusive design means recognising that not everyone experiences the world (or the web) the same way. As Ronise reminded us:
“Don’t try to control how people use the web. Give them flexibility. Let them use whatever font size, orientation, or device they need.”
Done well, designing for accessibility becomes a strategic advantage. It helps you meet more users where they are, adapt to emerging technologies, and build products that stand the test of time.
So, let’s move past the buzzwords and get into the real challenges that are holding teams back from building inclusive digital products. And more importantly, how to fix them.
One of the most common pitfalls in digital product design is that teams unintentionally build for people who look, think, and behave like them. Whether it’s the developers, designers, or stakeholders making the decisions, when everyone at the table shares similar experiences, backgrounds, and perspectives, it’s easy to assume the product will work for “everyone.”
Designing in an echo chamber creates blind spots. It bakes assumptions into the product about how people access information, what devices they use, what language they understand, and how they navigate the world. And it excludes the very people inclusive design aims to serve.
The problem isn’t a lack of good intentions, it’s a lack of awareness. Many teams simply don’t realise the diversity of user needs they’re overlooking. Without proactive research or input from underrepresented voices, it’s impossible to design for them, let alone with them.
And when feedback loops are limited to the loudest or most tech-savvy users, it reinforces the cycle. People who struggle silently, users with cognitive differences, older adults, people using screen readers, those with unreliable connectivity, are rarely the ones sending bug reports.
So, how do you break the echo chamber?
Inclusion starts behind the scenes. Recruit diverse perspectives into your teams, not just in terms of job roles, but lived experience. And when testing, seek out feedback from users with a wide range of abilities, backgrounds, and access needs.
Traditional user personas can unintentionally flatten or stereotype real experiences. Instead, use lived experience narratives to capture the complexity of how different people interact with technology. These narratives bring nuance and empathy to design decisions and help teams stay grounded in reality.
Don’t wait for quarterly reviews or big product launches. Make regular, small-scale user conversations part of your rhythm. Talk to people outside your core demo, those who might be underserved, excluded, or navigating the web differently. These conversations can uncover friction points you didn’t even know existed.
As Helen Robson, Head of Clinical Integration and Transformation at Connect Health reminded us during our TechNExt panel discussion:
“It’s about putting it front and centre, whether from a user design point of view or in development, accessibility by design, not as an afterthought.”
Designing for everyone doesn’t mean designing one-size-fits-all. It means creating with flexibility, empathy, and openness to difference. And that starts with breaking out of the echo chamber.
Too often, digital accessibility is treated as a final hurdle. A checklist to clear before release. Teams build a product, and only then do they ask: “Does it pass WCAG?” Accessibility becomes a tick-box exercise, not a meaningful part of the user experience.
But accessibility isn't something you slap on at the end. When it’s not baked in from the start, it leads to clunky, compromised fixes, workarounds that “technically” meet standards, but fall short in practice.
As James Lambert, Tech Lead at iamproperty explained during the panel:
“As soon as you start adding complexity into your applications, websites, or code, you move away from accessibility being the default.”
The root of this problem often lies in how accessibility is perceived within an organisation. Is it a shared responsibility across the product lifecycle or an optional extra handled by whoever’s keenest?
As Ronise put it:
“Accessibility is seen as a nice to have, an extra. It has this whole aura of volunteer work… and that has to change. If you're responsible for accessibility in your organisation one of the first things you have to do is think about how to change the culture so that accessibility is embraced, built into the process, and seen by leadership as something worth investing in.”
This cultural mindset creates structural issues. Accessibility is siloed, relegated to a few passionate individuals (often self-taught), with little time, support, or influence to drive meaningful change.
Ronise added:
“Most accessibility professionals started as champions, usually self-taught. But they’re often isolated, without mechanisms to change culture or measure progress.”
And without measurable progress, accessibility slips into the background. Fixes are reactive, rushed, and rarely maintained, until the cycle starts again.
So, how do we fix it?
Accessibility best practices should be part of your design DNA, not a bolt-on. Start with inclusive principles like clarity, flexibility, and user control and build them into every feature, component, and interaction from day one.
Make it easy for teams to do the right thing. Use your design system to set clear, accessible defaults for colours, contrast, font sizes, component behaviour, and interactivity. The more accessible your foundations, the fewer barriers you’ll build and the more accessible web design becomes the default.
Don’t leave accessibility to the final QA sweep. Include it in sprint planning, story grooming, design reviews, and code reviews. Accessibility needs to be owned collectively, not carried solo.
As Ronise explained:
“You can’t demand all this from accessibility champions without backing them up. Accessibility is a profession, it takes time, training, and cross-functional understanding.”
James added:
“It’s not just front end’s job to take care of it at the end. It should be everyone’s job to do a little bit of accessibility throughout the entire process.”
Accessibility doesn’t stop at design, it has to be carried through in code. That means using semantic HTML, ensuring all functionality is keyboard-accessible, supporting screen readers through ARIA where necessary, and avoiding patterns that create barriers (like modals without focus management or custom controls without native behaviours). Embed these practices into code reviews and engineering standards, so accessibility isn’t something retrofitted later but built into the DNA of your product.
It’s not just about WCAG compliance, it’s about creating elegant, usable, sustainable products that work for real people. When accessibility is part of the process, not a postscript, everyone benefits.
Modern digital design often aims for universality, build once, serve many. But that ambition can quickly backfire when teams assume that “universal” means designing for the average, ideal user: fast internet, latest phone, typical cognitive load, standard interaction patterns.
The result? Products that look great on a high-end device in perfect conditions but falter the moment someone deviates from that narrow path.
As Ronise reminded us on the panel:
“Don’t assume everyone has the best connection or the latest phone… think about people who won’t have that at all. They’ll have the minimum.”
Designing as if everyone engages with digital content the same way ignores the rich diversity of how people perceive, navigate, and interact with technology. It overlooks neurodivergent users who might struggle with visual clutter, users with motor impairments who can’t rely on a mouse, and users who rely on screen readers, voice commands, or keyboard navigation.
This “one-size-fits-all” approach also disregards cultural context, how language, visual cues, and interface expectations vary around the world. It creates friction instead of flow.
So, how do we design for reality, not ideal?
Responsive design adjusts layout for screen size, but inclusive design adapts experience. Can users adjust the font size? Does layout hold up when zoomed in? Can someone switch to high contrast or dark mode? Can the product function when animations are reduced?
Give people control. Let them change colours, contrast, input methods, or interaction modes. Support native device settings like system-level zoom or screen reader compatibility. Don’t lock users into one way of using your app or site. Ronise said:
“Don’t try to control how people use the web… Let them use whatever font size, orientation, or mode they want.”
While mobile-first design is widely embraced, not everyone interacts with mobile devices the same way. For some, a phone is their only device. For others, it's completely inaccessible without assistive tech. Designing “mobile first” should never mean “touchscreen only” or “gesture dependent.” Always consider alternative navigation, like keyboards, voice, or accessibility APIs.
Ultimately, inclusive design isn’t about serving the “average” user, it’s about serving real users, in all their variety. And that means building in flexibility, not just responsiveness.
When we talk about accessibility, it’s easy to focus on visible design elements, contrast ratios, keyboard navigation, alt text. But there’s another barrier that’s often overlooked: performance.
Slow-loading pages, bloated scripts, overly complex interactions, or data-heavy content can all lock users out, especially those on older devices, limited data plans, or unreliable internet connections.
We often design and test products in ideal conditions: strong Wi-Fi, new laptops, modern smartphones.
It’s easy to forget that performance is accessibility. A beautifully designed interface is meaningless if it doesn’t load in time or at all for the people who need it most.
What’s more, poor performance doesn’t just affect underrepresented users, it impacts everyone. Even in well-connected environments, sluggish experiences reduce engagement, increase bounce rates, and erode trust. Inclusive design means fast, efficient, and resilient by default.
So, how do we ensure performance doesn't become a barrier?
Start with the assumption that your users might be on 3G, or using data sparingly. Compress assets, limit large media files, lazy-load content, and avoid unnecessary animation or third-party bloat. Fast, efficient pages help everyone, especially those who need it most.
Simulate low-speed networks and test on older or less powerful devices. Consider accessibility testing tools that show how your app behaves in constrained environments. Try loading your product on a phone with battery-saver mode or system font scaling turned up.
Build your product in layers. If advanced features or enhanced visuals don’t load, the core experience should still work. Prioritise function over form, ensure people can complete the task even if the extras fail.
Inclusive design doesn’t just widen your reach, it safeguards your product against the unknowns of connectivity, devices, and user behaviour. When performance is treated as a baseline, not a bonus, you create something far more durable, adaptable, and inclusive.
A common accessibility pitfall is assuming that once a feature works on one platform, it’ll work everywhere. But accessibility APIs, interaction patterns, and even defaults vary significantly between web, iOS, and Android. Test across platforms and ensure consistency, not just in appearance, but in function and accessibility support.
Your design system can help here but only if components are truly platform-aware.
You can’t fix what you can’t see and if your feedback loop only captures insights from the most vocal, tech-savvy, or “typical” users, you’re missing the people who are struggling in silence.
That’s the heart of this final challenge: the absence of meaningful feedback from the margins. Users with disabilities, those navigating the web in their second language, those with low digital confidence, or those on outdated devices rarely show up in traditional feedback channels. They may not have the time, confidence, or trust that their input will be valued or even heard.
As Ronise noted in our panel discussion:
“You have to be close to the user group and recognise the diversity of people. Not everyone uses the web the same way and you can’t control that.”
Too often, the feedback that shapes product decisions come from those who are already well-served. The quieter the exclusion, the more dangerous it becomes because teams assume silence means success. Meanwhile, barriers persist, and frustration grows.
So, how do we listen better and design smarter?
Go beyond typical user testing pools. Recruit participants with a range of access needs, languages, and lived experiences. Test with screen reader users. Invite people from older age groups or rural areas. Seek out users with neurodivergent traits or limited literacy. Their insights will be some of the most valuable you’ll ever gather.
Don’t wait for users to raise their hands, many never will. Include accessible, low-friction ways to provide feedback anonymously, asynchronously, and in multiple languages. For example, allow screen reader users to report issues directly from the component they’re interacting with.
Try navigating your product as someone with one hand, no mouse, a slow connection, or colour blindness. How does the experience hold up? These kinds of stress tests can reveal surprising gaps, ones your average user would never notice, but that can be showstoppers for someone else.
Inclusive design requires inclusive feedback. When you actively seek out the voices on the margins, you not only find hidden problems, you uncover new opportunities to build better, more human-centred products for everyone.
Inclusive design isn’t a bonus feature. It’s not a box to tick at the end of a sprint, or a “nice-to-have” when time allows. It’s a mindset and a responsibility.
As we've explored in this blog, the real challenges to inclusivity aren't just technical. They're cultural, organisational, and deeply human. They show up when teams assume their own experiences are universal. When accessibility is passed off as a task for champions rather than a shared standard. When performance is optimised for the privileged few, and feedback loops exclude the people who need to be heard most.
But here’s the opportunity: inclusive design makes products better for everyone. It opens up your digital experiences to more users, in more contexts, with more trust. It creates broader market reach, stronger brand loyalty, and better, more resilient user experiences. That’s the business case.
And then there’s the human case: the person who can finally fill out a form on your site using assistive tech. The student who can access resources on a slow connection. The elderly user who feels confident navigating your service. These are not edge cases, they're people. And they’re too important to leave behind.
So, if you’re wondering where to start, keep it simple. Start with one change. One process. One user insight. One mindset shift. Then build momentum from there.
Because the moment you stop thinking of inclusivity as extra is the moment you start designing something that truly works for everyone.
Interested in more? Watch the full panel discussion from TechNExt on demand.
Inclusive design. Accessibility-first. Designed for all. We’ve all heard the terms. They sound great on a slide deck and even better in a company values statement, but all too often, that’s where the conversation stops.
In many digital teams, inclusivity and accessibility in digital products are treated like buzzwords. Well-meaning, nice-to-have ideas that live at the bottom of the backlog. There's a persistent myth that digital accessibility is about checking legal boxes or doing the right thing if we have time. And inclusivity? That’s sometimes mistaken as simply using diverse stock photos or translating a page into another language.
But the reality is inclusive UX design isn’t a bolt-on. It’s a core ingredient of good digital products. True inclusive design starts at the beginning. It’s what makes digital products usable, sustainable, and future-ready.
As one of our panellists at our TechNExt 2024 fringe event ‘Accessibility Transformation: Ensuring Tech for All’ Ronise Nepomuceno, Digital Accessibility Lead at EE put it:
“The web was built to democratise information, not to leave anyone behind. We use the web to access essential services like healthcare, education, and employment and when access isn’t inclusive, people miss out on things they need to live, learn, and work.”
That idea isn’t just ethical, it’s practical. Because when you design for the margins, everyone benefits. Accessible digital products tend to be more robust, easier to navigate, faster to load, and simpler to maintain. They perform better across devices, bandwidths, and user contexts. In other words: inclusion drives reach, relevance, and ROI.
And here’s the important distinction:
Accessibility is about removing barriers so that people with disabilities can access and interact with digital content.
Inclusivity, on the other hand, is broader. It’s about designing with a wide range of users in mind from the start, including different backgrounds, contexts, abilities, and needs.
Inclusive design means recognising that not everyone experiences the world (or the web) the same way. As Ronise reminded us:
“Don’t try to control how people use the web. Give them flexibility. Let them use whatever font size, orientation, or device they need.”
Done well, designing for accessibility becomes a strategic advantage. It helps you meet more users where they are, adapt to emerging technologies, and build products that stand the test of time.
So, let’s move past the buzzwords and get into the real challenges that are holding teams back from building inclusive digital products. And more importantly, how to fix them.
One of the most common pitfalls in digital product design is that teams unintentionally build for people who look, think, and behave like them. Whether it’s the developers, designers, or stakeholders making the decisions, when everyone at the table shares similar experiences, backgrounds, and perspectives, it’s easy to assume the product will work for “everyone.”
Designing in an echo chamber creates blind spots. It bakes assumptions into the product about how people access information, what devices they use, what language they understand, and how they navigate the world. And it excludes the very people inclusive design aims to serve.
The problem isn’t a lack of good intentions, it’s a lack of awareness. Many teams simply don’t realise the diversity of user needs they’re overlooking. Without proactive research or input from underrepresented voices, it’s impossible to design for them, let alone with them.
And when feedback loops are limited to the loudest or most tech-savvy users, it reinforces the cycle. People who struggle silently, users with cognitive differences, older adults, people using screen readers, those with unreliable connectivity, are rarely the ones sending bug reports.
So, how do you break the echo chamber?
Inclusion starts behind the scenes. Recruit diverse perspectives into your teams, not just in terms of job roles, but lived experience. And when testing, seek out feedback from users with a wide range of abilities, backgrounds, and access needs.
Traditional user personas can unintentionally flatten or stereotype real experiences. Instead, use lived experience narratives to capture the complexity of how different people interact with technology. These narratives bring nuance and empathy to design decisions and help teams stay grounded in reality.
Don’t wait for quarterly reviews or big product launches. Make regular, small-scale user conversations part of your rhythm. Talk to people outside your core demo, those who might be underserved, excluded, or navigating the web differently. These conversations can uncover friction points you didn’t even know existed.
As Helen Robson, Head of Clinical Integration and Transformation at Connect Health reminded us during our TechNExt panel discussion:
“It’s about putting it front and centre, whether from a user design point of view or in development, accessibility by design, not as an afterthought.”
Designing for everyone doesn’t mean designing one-size-fits-all. It means creating with flexibility, empathy, and openness to difference. And that starts with breaking out of the echo chamber.
Too often, digital accessibility is treated as a final hurdle. A checklist to clear before release. Teams build a product, and only then do they ask: “Does it pass WCAG?” Accessibility becomes a tick-box exercise, not a meaningful part of the user experience.
But accessibility isn't something you slap on at the end. When it’s not baked in from the start, it leads to clunky, compromised fixes, workarounds that “technically” meet standards, but fall short in practice.
As James Lambert, Tech Lead at iamproperty explained during the panel:
“As soon as you start adding complexity into your applications, websites, or code, you move away from accessibility being the default.”
The root of this problem often lies in how accessibility is perceived within an organisation. Is it a shared responsibility across the product lifecycle or an optional extra handled by whoever’s keenest?
As Ronise put it:
“Accessibility is seen as a nice to have, an extra. It has this whole aura of volunteer work… and that has to change. If you're responsible for accessibility in your organisation one of the first things you have to do is think about how to change the culture so that accessibility is embraced, built into the process, and seen by leadership as something worth investing in.”
This cultural mindset creates structural issues. Accessibility is siloed, relegated to a few passionate individuals (often self-taught), with little time, support, or influence to drive meaningful change.
Ronise added:
“Most accessibility professionals started as champions, usually self-taught. But they’re often isolated, without mechanisms to change culture or measure progress.”
And without measurable progress, accessibility slips into the background. Fixes are reactive, rushed, and rarely maintained, until the cycle starts again.
So, how do we fix it?
Accessibility best practices should be part of your design DNA, not a bolt-on. Start with inclusive principles like clarity, flexibility, and user control and build them into every feature, component, and interaction from day one.
Make it easy for teams to do the right thing. Use your design system to set clear, accessible defaults for colours, contrast, font sizes, component behaviour, and interactivity. The more accessible your foundations, the fewer barriers you’ll build and the more accessible web design becomes the default.
Don’t leave accessibility to the final QA sweep. Include it in sprint planning, story grooming, design reviews, and code reviews. Accessibility needs to be owned collectively, not carried solo.
As Ronise explained:
“You can’t demand all this from accessibility champions without backing them up. Accessibility is a profession, it takes time, training, and cross-functional understanding.”
James added:
“It’s not just front end’s job to take care of it at the end. It should be everyone’s job to do a little bit of accessibility throughout the entire process.”
Accessibility doesn’t stop at design, it has to be carried through in code. That means using semantic HTML, ensuring all functionality is keyboard-accessible, supporting screen readers through ARIA where necessary, and avoiding patterns that create barriers (like modals without focus management or custom controls without native behaviours). Embed these practices into code reviews and engineering standards, so accessibility isn’t something retrofitted later but built into the DNA of your product.
It’s not just about WCAG compliance, it’s about creating elegant, usable, sustainable products that work for real people. When accessibility is part of the process, not a postscript, everyone benefits.
Modern digital design often aims for universality, build once, serve many. But that ambition can quickly backfire when teams assume that “universal” means designing for the average, ideal user: fast internet, latest phone, typical cognitive load, standard interaction patterns.
The result? Products that look great on a high-end device in perfect conditions but falter the moment someone deviates from that narrow path.
As Ronise reminded us on the panel:
“Don’t assume everyone has the best connection or the latest phone… think about people who won’t have that at all. They’ll have the minimum.”
Designing as if everyone engages with digital content the same way ignores the rich diversity of how people perceive, navigate, and interact with technology. It overlooks neurodivergent users who might struggle with visual clutter, users with motor impairments who can’t rely on a mouse, and users who rely on screen readers, voice commands, or keyboard navigation.
This “one-size-fits-all” approach also disregards cultural context, how language, visual cues, and interface expectations vary around the world. It creates friction instead of flow.
So, how do we design for reality, not ideal?
Responsive design adjusts layout for screen size, but inclusive design adapts experience. Can users adjust the font size? Does layout hold up when zoomed in? Can someone switch to high contrast or dark mode? Can the product function when animations are reduced?
Give people control. Let them change colours, contrast, input methods, or interaction modes. Support native device settings like system-level zoom or screen reader compatibility. Don’t lock users into one way of using your app or site. Ronise said:
“Don’t try to control how people use the web… Let them use whatever font size, orientation, or mode they want.”
While mobile-first design is widely embraced, not everyone interacts with mobile devices the same way. For some, a phone is their only device. For others, it's completely inaccessible without assistive tech. Designing “mobile first” should never mean “touchscreen only” or “gesture dependent.” Always consider alternative navigation, like keyboards, voice, or accessibility APIs.
Ultimately, inclusive design isn’t about serving the “average” user, it’s about serving real users, in all their variety. And that means building in flexibility, not just responsiveness.
When we talk about accessibility, it’s easy to focus on visible design elements, contrast ratios, keyboard navigation, alt text. But there’s another barrier that’s often overlooked: performance.
Slow-loading pages, bloated scripts, overly complex interactions, or data-heavy content can all lock users out, especially those on older devices, limited data plans, or unreliable internet connections.
We often design and test products in ideal conditions: strong Wi-Fi, new laptops, modern smartphones.
It’s easy to forget that performance is accessibility. A beautifully designed interface is meaningless if it doesn’t load in time or at all for the people who need it most.
What’s more, poor performance doesn’t just affect underrepresented users, it impacts everyone. Even in well-connected environments, sluggish experiences reduce engagement, increase bounce rates, and erode trust. Inclusive design means fast, efficient, and resilient by default.
So, how do we ensure performance doesn't become a barrier?
Start with the assumption that your users might be on 3G, or using data sparingly. Compress assets, limit large media files, lazy-load content, and avoid unnecessary animation or third-party bloat. Fast, efficient pages help everyone, especially those who need it most.
Simulate low-speed networks and test on older or less powerful devices. Consider accessibility testing tools that show how your app behaves in constrained environments. Try loading your product on a phone with battery-saver mode or system font scaling turned up.
Build your product in layers. If advanced features or enhanced visuals don’t load, the core experience should still work. Prioritise function over form, ensure people can complete the task even if the extras fail.
Inclusive design doesn’t just widen your reach, it safeguards your product against the unknowns of connectivity, devices, and user behaviour. When performance is treated as a baseline, not a bonus, you create something far more durable, adaptable, and inclusive.
A common accessibility pitfall is assuming that once a feature works on one platform, it’ll work everywhere. But accessibility APIs, interaction patterns, and even defaults vary significantly between web, iOS, and Android. Test across platforms and ensure consistency, not just in appearance, but in function and accessibility support.
Your design system can help here but only if components are truly platform-aware.
You can’t fix what you can’t see and if your feedback loop only captures insights from the most vocal, tech-savvy, or “typical” users, you’re missing the people who are struggling in silence.
That’s the heart of this final challenge: the absence of meaningful feedback from the margins. Users with disabilities, those navigating the web in their second language, those with low digital confidence, or those on outdated devices rarely show up in traditional feedback channels. They may not have the time, confidence, or trust that their input will be valued or even heard.
As Ronise noted in our panel discussion:
“You have to be close to the user group and recognise the diversity of people. Not everyone uses the web the same way and you can’t control that.”
Too often, the feedback that shapes product decisions come from those who are already well-served. The quieter the exclusion, the more dangerous it becomes because teams assume silence means success. Meanwhile, barriers persist, and frustration grows.
So, how do we listen better and design smarter?
Go beyond typical user testing pools. Recruit participants with a range of access needs, languages, and lived experiences. Test with screen reader users. Invite people from older age groups or rural areas. Seek out users with neurodivergent traits or limited literacy. Their insights will be some of the most valuable you’ll ever gather.
Don’t wait for users to raise their hands, many never will. Include accessible, low-friction ways to provide feedback anonymously, asynchronously, and in multiple languages. For example, allow screen reader users to report issues directly from the component they’re interacting with.
Try navigating your product as someone with one hand, no mouse, a slow connection, or colour blindness. How does the experience hold up? These kinds of stress tests can reveal surprising gaps, ones your average user would never notice, but that can be showstoppers for someone else.
Inclusive design requires inclusive feedback. When you actively seek out the voices on the margins, you not only find hidden problems, you uncover new opportunities to build better, more human-centred products for everyone.
Inclusive design isn’t a bonus feature. It’s not a box to tick at the end of a sprint, or a “nice-to-have” when time allows. It’s a mindset and a responsibility.
As we've explored in this blog, the real challenges to inclusivity aren't just technical. They're cultural, organisational, and deeply human. They show up when teams assume their own experiences are universal. When accessibility is passed off as a task for champions rather than a shared standard. When performance is optimised for the privileged few, and feedback loops exclude the people who need to be heard most.
But here’s the opportunity: inclusive design makes products better for everyone. It opens up your digital experiences to more users, in more contexts, with more trust. It creates broader market reach, stronger brand loyalty, and better, more resilient user experiences. That’s the business case.
And then there’s the human case: the person who can finally fill out a form on your site using assistive tech. The student who can access resources on a slow connection. The elderly user who feels confident navigating your service. These are not edge cases, they're people. And they’re too important to leave behind.
So, if you’re wondering where to start, keep it simple. Start with one change. One process. One user insight. One mindset shift. Then build momentum from there.
Because the moment you stop thinking of inclusivity as extra is the moment you start designing something that truly works for everyone.
Interested in more? Watch the full panel discussion from TechNExt on demand.
Inclusive design. Accessibility-first. Designed for all. We’ve all heard the terms. They sound great on a slide deck and even better in a company values statement, but all too often, that’s where the conversation stops.
In many digital teams, inclusivity and accessibility in digital products are treated like buzzwords. Well-meaning, nice-to-have ideas that live at the bottom of the backlog. There's a persistent myth that digital accessibility is about checking legal boxes or doing the right thing if we have time. And inclusivity? That’s sometimes mistaken as simply using diverse stock photos or translating a page into another language.
But the reality is inclusive UX design isn’t a bolt-on. It’s a core ingredient of good digital products. True inclusive design starts at the beginning. It’s what makes digital products usable, sustainable, and future-ready.
As one of our panellists at our TechNExt 2024 fringe event ‘Accessibility Transformation: Ensuring Tech for All’ Ronise Nepomuceno, Digital Accessibility Lead at EE put it:
“The web was built to democratise information, not to leave anyone behind. We use the web to access essential services like healthcare, education, and employment and when access isn’t inclusive, people miss out on things they need to live, learn, and work.”
That idea isn’t just ethical, it’s practical. Because when you design for the margins, everyone benefits. Accessible digital products tend to be more robust, easier to navigate, faster to load, and simpler to maintain. They perform better across devices, bandwidths, and user contexts. In other words: inclusion drives reach, relevance, and ROI.
And here’s the important distinction:
Accessibility is about removing barriers so that people with disabilities can access and interact with digital content.
Inclusivity, on the other hand, is broader. It’s about designing with a wide range of users in mind from the start, including different backgrounds, contexts, abilities, and needs.
Inclusive design means recognising that not everyone experiences the world (or the web) the same way. As Ronise reminded us:
“Don’t try to control how people use the web. Give them flexibility. Let them use whatever font size, orientation, or device they need.”
Done well, designing for accessibility becomes a strategic advantage. It helps you meet more users where they are, adapt to emerging technologies, and build products that stand the test of time.
So, let’s move past the buzzwords and get into the real challenges that are holding teams back from building inclusive digital products. And more importantly, how to fix them.
One of the most common pitfalls in digital product design is that teams unintentionally build for people who look, think, and behave like them. Whether it’s the developers, designers, or stakeholders making the decisions, when everyone at the table shares similar experiences, backgrounds, and perspectives, it’s easy to assume the product will work for “everyone.”
Designing in an echo chamber creates blind spots. It bakes assumptions into the product about how people access information, what devices they use, what language they understand, and how they navigate the world. And it excludes the very people inclusive design aims to serve.
The problem isn’t a lack of good intentions, it’s a lack of awareness. Many teams simply don’t realise the diversity of user needs they’re overlooking. Without proactive research or input from underrepresented voices, it’s impossible to design for them, let alone with them.
And when feedback loops are limited to the loudest or most tech-savvy users, it reinforces the cycle. People who struggle silently, users with cognitive differences, older adults, people using screen readers, those with unreliable connectivity, are rarely the ones sending bug reports.
So, how do you break the echo chamber?
Inclusion starts behind the scenes. Recruit diverse perspectives into your teams, not just in terms of job roles, but lived experience. And when testing, seek out feedback from users with a wide range of abilities, backgrounds, and access needs.
Traditional user personas can unintentionally flatten or stereotype real experiences. Instead, use lived experience narratives to capture the complexity of how different people interact with technology. These narratives bring nuance and empathy to design decisions and help teams stay grounded in reality.
Don’t wait for quarterly reviews or big product launches. Make regular, small-scale user conversations part of your rhythm. Talk to people outside your core demo, those who might be underserved, excluded, or navigating the web differently. These conversations can uncover friction points you didn’t even know existed.
As Helen Robson, Head of Clinical Integration and Transformation at Connect Health reminded us during our TechNExt panel discussion:
“It’s about putting it front and centre, whether from a user design point of view or in development, accessibility by design, not as an afterthought.”
Designing for everyone doesn’t mean designing one-size-fits-all. It means creating with flexibility, empathy, and openness to difference. And that starts with breaking out of the echo chamber.
Too often, digital accessibility is treated as a final hurdle. A checklist to clear before release. Teams build a product, and only then do they ask: “Does it pass WCAG?” Accessibility becomes a tick-box exercise, not a meaningful part of the user experience.
But accessibility isn't something you slap on at the end. When it’s not baked in from the start, it leads to clunky, compromised fixes, workarounds that “technically” meet standards, but fall short in practice.
As James Lambert, Tech Lead at iamproperty explained during the panel:
“As soon as you start adding complexity into your applications, websites, or code, you move away from accessibility being the default.”
The root of this problem often lies in how accessibility is perceived within an organisation. Is it a shared responsibility across the product lifecycle or an optional extra handled by whoever’s keenest?
As Ronise put it:
“Accessibility is seen as a nice to have, an extra. It has this whole aura of volunteer work… and that has to change. If you're responsible for accessibility in your organisation one of the first things you have to do is think about how to change the culture so that accessibility is embraced, built into the process, and seen by leadership as something worth investing in.”
This cultural mindset creates structural issues. Accessibility is siloed, relegated to a few passionate individuals (often self-taught), with little time, support, or influence to drive meaningful change.
Ronise added:
“Most accessibility professionals started as champions, usually self-taught. But they’re often isolated, without mechanisms to change culture or measure progress.”
And without measurable progress, accessibility slips into the background. Fixes are reactive, rushed, and rarely maintained, until the cycle starts again.
So, how do we fix it?
Accessibility best practices should be part of your design DNA, not a bolt-on. Start with inclusive principles like clarity, flexibility, and user control and build them into every feature, component, and interaction from day one.
Make it easy for teams to do the right thing. Use your design system to set clear, accessible defaults for colours, contrast, font sizes, component behaviour, and interactivity. The more accessible your foundations, the fewer barriers you’ll build and the more accessible web design becomes the default.
Don’t leave accessibility to the final QA sweep. Include it in sprint planning, story grooming, design reviews, and code reviews. Accessibility needs to be owned collectively, not carried solo.
As Ronise explained:
“You can’t demand all this from accessibility champions without backing them up. Accessibility is a profession, it takes time, training, and cross-functional understanding.”
James added:
“It’s not just front end’s job to take care of it at the end. It should be everyone’s job to do a little bit of accessibility throughout the entire process.”
Accessibility doesn’t stop at design, it has to be carried through in code. That means using semantic HTML, ensuring all functionality is keyboard-accessible, supporting screen readers through ARIA where necessary, and avoiding patterns that create barriers (like modals without focus management or custom controls without native behaviours). Embed these practices into code reviews and engineering standards, so accessibility isn’t something retrofitted later but built into the DNA of your product.
It’s not just about WCAG compliance, it’s about creating elegant, usable, sustainable products that work for real people. When accessibility is part of the process, not a postscript, everyone benefits.
Modern digital design often aims for universality, build once, serve many. But that ambition can quickly backfire when teams assume that “universal” means designing for the average, ideal user: fast internet, latest phone, typical cognitive load, standard interaction patterns.
The result? Products that look great on a high-end device in perfect conditions but falter the moment someone deviates from that narrow path.
As Ronise reminded us on the panel:
“Don’t assume everyone has the best connection or the latest phone… think about people who won’t have that at all. They’ll have the minimum.”
Designing as if everyone engages with digital content the same way ignores the rich diversity of how people perceive, navigate, and interact with technology. It overlooks neurodivergent users who might struggle with visual clutter, users with motor impairments who can’t rely on a mouse, and users who rely on screen readers, voice commands, or keyboard navigation.
This “one-size-fits-all” approach also disregards cultural context, how language, visual cues, and interface expectations vary around the world. It creates friction instead of flow.
So, how do we design for reality, not ideal?
Responsive design adjusts layout for screen size, but inclusive design adapts experience. Can users adjust the font size? Does layout hold up when zoomed in? Can someone switch to high contrast or dark mode? Can the product function when animations are reduced?
Give people control. Let them change colours, contrast, input methods, or interaction modes. Support native device settings like system-level zoom or screen reader compatibility. Don’t lock users into one way of using your app or site. Ronise said:
“Don’t try to control how people use the web… Let them use whatever font size, orientation, or mode they want.”
While mobile-first design is widely embraced, not everyone interacts with mobile devices the same way. For some, a phone is their only device. For others, it's completely inaccessible without assistive tech. Designing “mobile first” should never mean “touchscreen only” or “gesture dependent.” Always consider alternative navigation, like keyboards, voice, or accessibility APIs.
Ultimately, inclusive design isn’t about serving the “average” user, it’s about serving real users, in all their variety. And that means building in flexibility, not just responsiveness.
When we talk about accessibility, it’s easy to focus on visible design elements, contrast ratios, keyboard navigation, alt text. But there’s another barrier that’s often overlooked: performance.
Slow-loading pages, bloated scripts, overly complex interactions, or data-heavy content can all lock users out, especially those on older devices, limited data plans, or unreliable internet connections.
We often design and test products in ideal conditions: strong Wi-Fi, new laptops, modern smartphones.
It’s easy to forget that performance is accessibility. A beautifully designed interface is meaningless if it doesn’t load in time or at all for the people who need it most.
What’s more, poor performance doesn’t just affect underrepresented users, it impacts everyone. Even in well-connected environments, sluggish experiences reduce engagement, increase bounce rates, and erode trust. Inclusive design means fast, efficient, and resilient by default.
So, how do we ensure performance doesn't become a barrier?
Start with the assumption that your users might be on 3G, or using data sparingly. Compress assets, limit large media files, lazy-load content, and avoid unnecessary animation or third-party bloat. Fast, efficient pages help everyone, especially those who need it most.
Simulate low-speed networks and test on older or less powerful devices. Consider accessibility testing tools that show how your app behaves in constrained environments. Try loading your product on a phone with battery-saver mode or system font scaling turned up.
Build your product in layers. If advanced features or enhanced visuals don’t load, the core experience should still work. Prioritise function over form, ensure people can complete the task even if the extras fail.
Inclusive design doesn’t just widen your reach, it safeguards your product against the unknowns of connectivity, devices, and user behaviour. When performance is treated as a baseline, not a bonus, you create something far more durable, adaptable, and inclusive.
A common accessibility pitfall is assuming that once a feature works on one platform, it’ll work everywhere. But accessibility APIs, interaction patterns, and even defaults vary significantly between web, iOS, and Android. Test across platforms and ensure consistency, not just in appearance, but in function and accessibility support.
Your design system can help here but only if components are truly platform-aware.
You can’t fix what you can’t see and if your feedback loop only captures insights from the most vocal, tech-savvy, or “typical” users, you’re missing the people who are struggling in silence.
That’s the heart of this final challenge: the absence of meaningful feedback from the margins. Users with disabilities, those navigating the web in their second language, those with low digital confidence, or those on outdated devices rarely show up in traditional feedback channels. They may not have the time, confidence, or trust that their input will be valued or even heard.
As Ronise noted in our panel discussion:
“You have to be close to the user group and recognise the diversity of people. Not everyone uses the web the same way and you can’t control that.”
Too often, the feedback that shapes product decisions come from those who are already well-served. The quieter the exclusion, the more dangerous it becomes because teams assume silence means success. Meanwhile, barriers persist, and frustration grows.
So, how do we listen better and design smarter?
Go beyond typical user testing pools. Recruit participants with a range of access needs, languages, and lived experiences. Test with screen reader users. Invite people from older age groups or rural areas. Seek out users with neurodivergent traits or limited literacy. Their insights will be some of the most valuable you’ll ever gather.
Don’t wait for users to raise their hands, many never will. Include accessible, low-friction ways to provide feedback anonymously, asynchronously, and in multiple languages. For example, allow screen reader users to report issues directly from the component they’re interacting with.
Try navigating your product as someone with one hand, no mouse, a slow connection, or colour blindness. How does the experience hold up? These kinds of stress tests can reveal surprising gaps, ones your average user would never notice, but that can be showstoppers for someone else.
Inclusive design requires inclusive feedback. When you actively seek out the voices on the margins, you not only find hidden problems, you uncover new opportunities to build better, more human-centred products for everyone.
Inclusive design isn’t a bonus feature. It’s not a box to tick at the end of a sprint, or a “nice-to-have” when time allows. It’s a mindset and a responsibility.
As we've explored in this blog, the real challenges to inclusivity aren't just technical. They're cultural, organisational, and deeply human. They show up when teams assume their own experiences are universal. When accessibility is passed off as a task for champions rather than a shared standard. When performance is optimised for the privileged few, and feedback loops exclude the people who need to be heard most.
But here’s the opportunity: inclusive design makes products better for everyone. It opens up your digital experiences to more users, in more contexts, with more trust. It creates broader market reach, stronger brand loyalty, and better, more resilient user experiences. That’s the business case.
And then there’s the human case: the person who can finally fill out a form on your site using assistive tech. The student who can access resources on a slow connection. The elderly user who feels confident navigating your service. These are not edge cases, they're people. And they’re too important to leave behind.
So, if you’re wondering where to start, keep it simple. Start with one change. One process. One user insight. One mindset shift. Then build momentum from there.
Because the moment you stop thinking of inclusivity as extra is the moment you start designing something that truly works for everyone.
Interested in more? Watch the full panel discussion from TechNExt on demand.
Inclusive design. Accessibility-first. Designed for all. We’ve all heard the terms. They sound great on a slide deck and even better in a company values statement, but all too often, that’s where the conversation stops.
In many digital teams, inclusivity and accessibility in digital products are treated like buzzwords. Well-meaning, nice-to-have ideas that live at the bottom of the backlog. There's a persistent myth that digital accessibility is about checking legal boxes or doing the right thing if we have time. And inclusivity? That’s sometimes mistaken as simply using diverse stock photos or translating a page into another language.
But the reality is inclusive UX design isn’t a bolt-on. It’s a core ingredient of good digital products. True inclusive design starts at the beginning. It’s what makes digital products usable, sustainable, and future-ready.
As one of our panellists at our TechNExt 2024 fringe event ‘Accessibility Transformation: Ensuring Tech for All’ Ronise Nepomuceno, Digital Accessibility Lead at EE put it:
“The web was built to democratise information, not to leave anyone behind. We use the web to access essential services like healthcare, education, and employment and when access isn’t inclusive, people miss out on things they need to live, learn, and work.”
That idea isn’t just ethical, it’s practical. Because when you design for the margins, everyone benefits. Accessible digital products tend to be more robust, easier to navigate, faster to load, and simpler to maintain. They perform better across devices, bandwidths, and user contexts. In other words: inclusion drives reach, relevance, and ROI.
And here’s the important distinction:
Accessibility is about removing barriers so that people with disabilities can access and interact with digital content.
Inclusivity, on the other hand, is broader. It’s about designing with a wide range of users in mind from the start, including different backgrounds, contexts, abilities, and needs.
Inclusive design means recognising that not everyone experiences the world (or the web) the same way. As Ronise reminded us:
“Don’t try to control how people use the web. Give them flexibility. Let them use whatever font size, orientation, or device they need.”
Done well, designing for accessibility becomes a strategic advantage. It helps you meet more users where they are, adapt to emerging technologies, and build products that stand the test of time.
So, let’s move past the buzzwords and get into the real challenges that are holding teams back from building inclusive digital products. And more importantly, how to fix them.
One of the most common pitfalls in digital product design is that teams unintentionally build for people who look, think, and behave like them. Whether it’s the developers, designers, or stakeholders making the decisions, when everyone at the table shares similar experiences, backgrounds, and perspectives, it’s easy to assume the product will work for “everyone.”
Designing in an echo chamber creates blind spots. It bakes assumptions into the product about how people access information, what devices they use, what language they understand, and how they navigate the world. And it excludes the very people inclusive design aims to serve.
The problem isn’t a lack of good intentions, it’s a lack of awareness. Many teams simply don’t realise the diversity of user needs they’re overlooking. Without proactive research or input from underrepresented voices, it’s impossible to design for them, let alone with them.
And when feedback loops are limited to the loudest or most tech-savvy users, it reinforces the cycle. People who struggle silently, users with cognitive differences, older adults, people using screen readers, those with unreliable connectivity, are rarely the ones sending bug reports.
So, how do you break the echo chamber?
Inclusion starts behind the scenes. Recruit diverse perspectives into your teams, not just in terms of job roles, but lived experience. And when testing, seek out feedback from users with a wide range of abilities, backgrounds, and access needs.
Traditional user personas can unintentionally flatten or stereotype real experiences. Instead, use lived experience narratives to capture the complexity of how different people interact with technology. These narratives bring nuance and empathy to design decisions and help teams stay grounded in reality.
Don’t wait for quarterly reviews or big product launches. Make regular, small-scale user conversations part of your rhythm. Talk to people outside your core demo, those who might be underserved, excluded, or navigating the web differently. These conversations can uncover friction points you didn’t even know existed.
As Helen Robson, Head of Clinical Integration and Transformation at Connect Health reminded us during our TechNExt panel discussion:
“It’s about putting it front and centre, whether from a user design point of view or in development, accessibility by design, not as an afterthought.”
Designing for everyone doesn’t mean designing one-size-fits-all. It means creating with flexibility, empathy, and openness to difference. And that starts with breaking out of the echo chamber.
Too often, digital accessibility is treated as a final hurdle. A checklist to clear before release. Teams build a product, and only then do they ask: “Does it pass WCAG?” Accessibility becomes a tick-box exercise, not a meaningful part of the user experience.
But accessibility isn't something you slap on at the end. When it’s not baked in from the start, it leads to clunky, compromised fixes, workarounds that “technically” meet standards, but fall short in practice.
As James Lambert, Tech Lead at iamproperty explained during the panel:
“As soon as you start adding complexity into your applications, websites, or code, you move away from accessibility being the default.”
The root of this problem often lies in how accessibility is perceived within an organisation. Is it a shared responsibility across the product lifecycle or an optional extra handled by whoever’s keenest?
As Ronise put it:
“Accessibility is seen as a nice to have, an extra. It has this whole aura of volunteer work… and that has to change. If you're responsible for accessibility in your organisation one of the first things you have to do is think about how to change the culture so that accessibility is embraced, built into the process, and seen by leadership as something worth investing in.”
This cultural mindset creates structural issues. Accessibility is siloed, relegated to a few passionate individuals (often self-taught), with little time, support, or influence to drive meaningful change.
Ronise added:
“Most accessibility professionals started as champions, usually self-taught. But they’re often isolated, without mechanisms to change culture or measure progress.”
And without measurable progress, accessibility slips into the background. Fixes are reactive, rushed, and rarely maintained, until the cycle starts again.
So, how do we fix it?
Accessibility best practices should be part of your design DNA, not a bolt-on. Start with inclusive principles like clarity, flexibility, and user control and build them into every feature, component, and interaction from day one.
Make it easy for teams to do the right thing. Use your design system to set clear, accessible defaults for colours, contrast, font sizes, component behaviour, and interactivity. The more accessible your foundations, the fewer barriers you’ll build and the more accessible web design becomes the default.
Don’t leave accessibility to the final QA sweep. Include it in sprint planning, story grooming, design reviews, and code reviews. Accessibility needs to be owned collectively, not carried solo.
As Ronise explained:
“You can’t demand all this from accessibility champions without backing them up. Accessibility is a profession, it takes time, training, and cross-functional understanding.”
James added:
“It’s not just front end’s job to take care of it at the end. It should be everyone’s job to do a little bit of accessibility throughout the entire process.”
Accessibility doesn’t stop at design, it has to be carried through in code. That means using semantic HTML, ensuring all functionality is keyboard-accessible, supporting screen readers through ARIA where necessary, and avoiding patterns that create barriers (like modals without focus management or custom controls without native behaviours). Embed these practices into code reviews and engineering standards, so accessibility isn’t something retrofitted later but built into the DNA of your product.
It’s not just about WCAG compliance, it’s about creating elegant, usable, sustainable products that work for real people. When accessibility is part of the process, not a postscript, everyone benefits.
Modern digital design often aims for universality, build once, serve many. But that ambition can quickly backfire when teams assume that “universal” means designing for the average, ideal user: fast internet, latest phone, typical cognitive load, standard interaction patterns.
The result? Products that look great on a high-end device in perfect conditions but falter the moment someone deviates from that narrow path.
As Ronise reminded us on the panel:
“Don’t assume everyone has the best connection or the latest phone… think about people who won’t have that at all. They’ll have the minimum.”
Designing as if everyone engages with digital content the same way ignores the rich diversity of how people perceive, navigate, and interact with technology. It overlooks neurodivergent users who might struggle with visual clutter, users with motor impairments who can’t rely on a mouse, and users who rely on screen readers, voice commands, or keyboard navigation.
This “one-size-fits-all” approach also disregards cultural context, how language, visual cues, and interface expectations vary around the world. It creates friction instead of flow.
So, how do we design for reality, not ideal?
Responsive design adjusts layout for screen size, but inclusive design adapts experience. Can users adjust the font size? Does layout hold up when zoomed in? Can someone switch to high contrast or dark mode? Can the product function when animations are reduced?
Give people control. Let them change colours, contrast, input methods, or interaction modes. Support native device settings like system-level zoom or screen reader compatibility. Don’t lock users into one way of using your app or site. Ronise said:
“Don’t try to control how people use the web… Let them use whatever font size, orientation, or mode they want.”
While mobile-first design is widely embraced, not everyone interacts with mobile devices the same way. For some, a phone is their only device. For others, it's completely inaccessible without assistive tech. Designing “mobile first” should never mean “touchscreen only” or “gesture dependent.” Always consider alternative navigation, like keyboards, voice, or accessibility APIs.
Ultimately, inclusive design isn’t about serving the “average” user, it’s about serving real users, in all their variety. And that means building in flexibility, not just responsiveness.
When we talk about accessibility, it’s easy to focus on visible design elements, contrast ratios, keyboard navigation, alt text. But there’s another barrier that’s often overlooked: performance.
Slow-loading pages, bloated scripts, overly complex interactions, or data-heavy content can all lock users out, especially those on older devices, limited data plans, or unreliable internet connections.
We often design and test products in ideal conditions: strong Wi-Fi, new laptops, modern smartphones.
It’s easy to forget that performance is accessibility. A beautifully designed interface is meaningless if it doesn’t load in time or at all for the people who need it most.
What’s more, poor performance doesn’t just affect underrepresented users, it impacts everyone. Even in well-connected environments, sluggish experiences reduce engagement, increase bounce rates, and erode trust. Inclusive design means fast, efficient, and resilient by default.
So, how do we ensure performance doesn't become a barrier?
Start with the assumption that your users might be on 3G, or using data sparingly. Compress assets, limit large media files, lazy-load content, and avoid unnecessary animation or third-party bloat. Fast, efficient pages help everyone, especially those who need it most.
Simulate low-speed networks and test on older or less powerful devices. Consider accessibility testing tools that show how your app behaves in constrained environments. Try loading your product on a phone with battery-saver mode or system font scaling turned up.
Build your product in layers. If advanced features or enhanced visuals don’t load, the core experience should still work. Prioritise function over form, ensure people can complete the task even if the extras fail.
Inclusive design doesn’t just widen your reach, it safeguards your product against the unknowns of connectivity, devices, and user behaviour. When performance is treated as a baseline, not a bonus, you create something far more durable, adaptable, and inclusive.
A common accessibility pitfall is assuming that once a feature works on one platform, it’ll work everywhere. But accessibility APIs, interaction patterns, and even defaults vary significantly between web, iOS, and Android. Test across platforms and ensure consistency, not just in appearance, but in function and accessibility support.
Your design system can help here but only if components are truly platform-aware.
You can’t fix what you can’t see and if your feedback loop only captures insights from the most vocal, tech-savvy, or “typical” users, you’re missing the people who are struggling in silence.
That’s the heart of this final challenge: the absence of meaningful feedback from the margins. Users with disabilities, those navigating the web in their second language, those with low digital confidence, or those on outdated devices rarely show up in traditional feedback channels. They may not have the time, confidence, or trust that their input will be valued or even heard.
As Ronise noted in our panel discussion:
“You have to be close to the user group and recognise the diversity of people. Not everyone uses the web the same way and you can’t control that.”
Too often, the feedback that shapes product decisions come from those who are already well-served. The quieter the exclusion, the more dangerous it becomes because teams assume silence means success. Meanwhile, barriers persist, and frustration grows.
So, how do we listen better and design smarter?
Go beyond typical user testing pools. Recruit participants with a range of access needs, languages, and lived experiences. Test with screen reader users. Invite people from older age groups or rural areas. Seek out users with neurodivergent traits or limited literacy. Their insights will be some of the most valuable you’ll ever gather.
Don’t wait for users to raise their hands, many never will. Include accessible, low-friction ways to provide feedback anonymously, asynchronously, and in multiple languages. For example, allow screen reader users to report issues directly from the component they’re interacting with.
Try navigating your product as someone with one hand, no mouse, a slow connection, or colour blindness. How does the experience hold up? These kinds of stress tests can reveal surprising gaps, ones your average user would never notice, but that can be showstoppers for someone else.
Inclusive design requires inclusive feedback. When you actively seek out the voices on the margins, you not only find hidden problems, you uncover new opportunities to build better, more human-centred products for everyone.
Inclusive design isn’t a bonus feature. It’s not a box to tick at the end of a sprint, or a “nice-to-have” when time allows. It’s a mindset and a responsibility.
As we've explored in this blog, the real challenges to inclusivity aren't just technical. They're cultural, organisational, and deeply human. They show up when teams assume their own experiences are universal. When accessibility is passed off as a task for champions rather than a shared standard. When performance is optimised for the privileged few, and feedback loops exclude the people who need to be heard most.
But here’s the opportunity: inclusive design makes products better for everyone. It opens up your digital experiences to more users, in more contexts, with more trust. It creates broader market reach, stronger brand loyalty, and better, more resilient user experiences. That’s the business case.
And then there’s the human case: the person who can finally fill out a form on your site using assistive tech. The student who can access resources on a slow connection. The elderly user who feels confident navigating your service. These are not edge cases, they're people. And they’re too important to leave behind.
So, if you’re wondering where to start, keep it simple. Start with one change. One process. One user insight. One mindset shift. Then build momentum from there.
Because the moment you stop thinking of inclusivity as extra is the moment you start designing something that truly works for everyone.
Interested in more? Watch the full panel discussion from TechNExt on demand.
