Technology is often presented as a force that makes life easier. It automates processes, removes repetitive tasks, improves access to services and creates possibilities that would have seemed out of reach only a few years ago. Yet one question is still too often absent from the earliest stages of innovation:

Who are we designing for?

An application can work exactly as specified and still be difficult to use for someone with low vision. A speech-recognition system can perform well in testing but struggle with particular accents. An automated recruitment tool can improve efficiency while reproducing historical patterns that disadvantage some candidates. A sophisticated device can still require movements, visual abilities or digital skills that many intended users do not have.

None of these outcomes requires a deliberate intention to exclude. Exclusion can emerge from the assumptions built into research, product requirements, training data and testing. This matters as artificial intelligence, automation and digital services move into increasingly sensitive areas of daily life, including employment, education, healthcare, banking, mobility, commerce and access to public services.

The World Health Organization estimates that 1.3 billion people, or around 16% of the global population, experience significant disability. Demographic change is widening the issue further: by 2030, one in six people worldwide will be aged 60 or over. These are not exceptional needs affecting a small niche. They describe a substantial and growing share of the people who use products and services.

Inclusive innovation responds to that reality. It is not about adding accessibility features at the end of development simply to satisfy a checklist. It means considering different abilities, contexts and ways of interacting with technology while the problem is still being defined and while design choices can still change.

This approach supports social inclusion and regulatory readiness, but its business value is equally important. Products that work for more people can reach wider markets, reveal unmet needs and perform more reliably in the conditions in which they will actually be used.

Exclusion often begins before launch

When a company discovers an accessibility problem after development is complete, correcting it may require extensive change. Teams may need to redesign interfaces, reorganise information, alter the technical architecture, modify physical controls or collect new data. The problem did not suddenly appear at launch; it was simply detected late.

This is why inclusive design begins with different questions:

Who took part in defining the problem?
Which users are being treated as the reference point?
Who might struggle to use the solution?
What physical, sensory, cognitive or digital abilities are being assumed?
Would the product still work outside the environment in which it was developed?

These questions affect the direction of research and development. Many products exclude people because they were designed around an overly narrow idea of a ‘normal’ user. Once that imagined user becomes the standard, every difference is treated as an exception to be accommodated later. Inclusive innovation challenges that sequence. It treats human variation as a design condition from the beginning.

The average yser is a poor design standard

Product teams often create a representative persona and design around it. Personas can help teams focus, but they become risky when one profile is used as a proxy for everyone. People have different visual, auditory, motor and cognitive abilities. They use different devices, speak different languages and live in different cultural and economic contexts. Some have used digital tools for decades; others may be accessing a particular service for the first time.

Ability is not fixed throughout a person’s life. A limitation may be permanent, temporary or situational. Someone may be unable to hear a video in a noisy place, struggle to read a screen in direct sunlight or need to operate a device with one hand while completing another task. A person recovering from an injury may encounter the same interface barrier as someone with a long-term motor disability.

This helps explain why features developed for accessibility often benefit a much larger population. Captions are useful to Deaf and hard-of-hearing users, but also to people watching a video without sound. High-contrast displays improve access for people with low vision and remain useful in bright environments. Voice interfaces, predictive text and flexible input methods can help users across a wide range of situations.

The World Wide Web Consortium identifies this broader value in its business case for digital accessibility. Designing for varied ways of interacting can encourage innovation, improve user experience and extend market reach. Accessibility, viewed in this way, is not a final compliance test. It is a method for making products more flexible and resilient.

When data does not represent everyone

Artificial intelligence adds another layer to the issue. In a conventional product, an inaccessible design decision may create a visible barrier. In a data-driven system, exclusion can be harder to identify because it is embedded in patterns, classifications and probabilities.

AI systems learn from historical data, labelled examples and past decisions. If those inputs do not adequately represent the population on which the system will be used, performance can vary substantially between groups. This does not mean that every difference in model performance is automatically discriminatory. It does mean that representativeness, data quality and evaluation choices have material consequences.

The US National Institute of Standards and Technology has documented demographic differences in the performance of facial recognition algorithms. Its evaluations show that error rates can vary across demographic groups and that the composition and quality of image datasets influence measured performance. The same underlying concern extends well beyond facial recognition.

Consider a system developed primarily with data from one country and then deployed in another market. A language model may have limited exposure to certain languages, dialects or forms of expression. A health tool may be trained on a patient population that does not reflect the people who will eventually use it. A decision-support model may reproduce historical decisions made in a context where unequal treatment already existed.

Technology does not operate outside society, and data does not arrive without context. UNESCO warns that AI systems can embed or amplify bias and contribute to discrimination, inequality and digital exclusion when these risks are not addressed throughout the system lifecycle. The practical question for developers is therefore more specific than whether a model performs well overall: for whom does it perform well, and for whom does it perform worse?

Average accuracy can hide material risks

A model can achieve a strong overall accuracy score while producing significantly different outcomes for particular groups. A single average may conceal exactly the information a company needs to understand before deployment.

Evaluation should therefore examine who is represented in the data, whether performance differs between groups, whether smaller populations have enough examples for meaningful testing and how labels were assigned. Teams also need to understand what happens when a model fails and whether users have a clear route to challenge or correct an outcome.

The consequences of error matter as much as the error rate. An inaccurate entertainment recommendation may have limited impact. A mistake in a system used to assess credit, screen job candidates, support a diagnosis or verify identity can affect access to essential opportunities and services. In those settings, inclusive development is closely connected to technology risk management, governance and product quality.

Team diversity changes the questions

Data is not the only source of blind spots. The people who choose the research question, define success and test the product also shape what a technology can see.

No team can represent every possible user experience. Even so, teams that bring together different disciplines, backgrounds and lived experiences are more likely to question assumptions that might otherwise go unnoticed. This is especially important in R&D, where early decisions determine which problem will be studied, which hypotheses will be tested, who will participate in trials, which features will receive priority and which measures will define success.

Diversity in innovation should therefore be understood as more than a human-resources indicator. It can strengthen an organisation’s ability to identify needs. An engineer may see a technical limitation. A designer may notice a barrier in the user journey. A clinician may recognise that a solution does not fit real working conditions. A person who uses assistive technology may identify a problem that other testers never encounter. A commercial team may explain why a technically impressive feature is unlikely to be adopted.

These perspectives do not automatically produce a good product. They improve the quality of the questions, provided the organisation creates a process in which different views can influence decisions rather than simply being present in the room.

Designing with people rather than around them

Inclusive innovation also changes the role of users in development. Teams cannot reliably infer every need from inside an office. People with disabilities, older adults and other groups that have historically been underrepresented in design processes should not appear only at the end to validate a nearly finished solution.

Their experience can inform initial research, problem definition, prototyping and testing. Co-creation and continuous user research help teams find barriers while the product remains relatively easy to change. The World Health Organization recommends involving people with disabilities and their representative organisations in decisions about the policies and services that affect them. The same principle is directly relevant to technology development.

Participation must also be meaningful. Inviting one person to a final review does not make a process inclusive. Organisations need to recruit a relevant range of users, compensate their contribution appropriately, provide accessible ways to participate and show how their feedback affected the product. When users are involved early, accessibility can become a source of insight. When they are consulted only after launch, it is more likely to become a corrective exercise.

Ageing Populations Change the Market

The global demographic shift makes this work increasingly urgent. The World Health Organization projects that the population aged 60 and over will reach 1.4 billion in 2030 and 2.1 billion by 2050. Financial services, digital health, mobility, e-commerce, connected devices and communication tools will serve populations with a wider range of abilities and expectations.

Innovation for ageing populations does not necessarily require separate products labelled for older people. It may require existing products to become easier to understand and operate: reducing unnecessary steps, offering several ways to complete a task, avoiding interfaces that depend on precise gestures, allowing users to enlarge text, improving contrast and designing secure authentication that does not become an access barrier.

Language also matters. Clear instructions support users of every age, while oversimplified or patronising content can undermine trust and autonomy. An inclusive product recognises different needs without treating older users as incapable. This distinction affects adoption. A technically accessible product may still fail if the experience makes its intended users feel that it was designed for someone else.

From Regulatory obligation to product advantage

Regulation is increasing the pressure on companies to act. Since June 2025, the European Accessibility Act has applied common accessibility requirements across the European Union to specified products and services, including computers, smartphones, banking and payment services, e-commerce, electronic communications and certain transport-related services.

Compliance is an immediate reason to review products, but it is a limited starting point for innovation. If an organisation considers accessibility only when a legal obligation appears, the project will tend to aim for the minimum requirement. If accessibility is treated as a product criterion, the business asks a more useful question: how can more people use this product successfully?

That question can reveal underserved markets, inspire functions that improve the mainstream experience and reduce the risk of expensive redesign. The W3C’s business case links accessibility with innovation, market reach, brand value and improved user experience, as well as reduced legal exposure. The strongest business case will vary by organisation, but the underlying logic is consistent. A product that excludes fewer people has more opportunities to create value.

The cost of finding barriers late

Inclusion is easier to manage when it is part of the original specification. Adjusting contrast or navigation during early design may be straightforward. Reworking an established design system, architecture or physical product after deployment may be costly and slow.

Testing with diverse users requires time and budget. So does discovering after launch that part of the market cannot use the service, that customer-support demand has increased or that a product must be redesigned to meet a regulatory requirement. Early investment should be assessed against those downstream costs, not against a fictional process in which accessibility requires no work at all.

The same applies to AI. Reviewing data coverage, testing subgroup performance and establishing monitoring before deployment require resources. Correcting a model after it has been embedded in business decisions is usually more complex. Organisations may need to gather new data, retrain models, revise workflows, notify affected users and reassess previous outputs.

A final audit remains useful, but it cannot carry the entire responsibility for inclusion. Teams need checkpoints throughout research, design, development, procurement, testing, deployment and monitoring. Each checkpoint should have a clear owner, relevant evidence and authority to change the product when a material risk appears.

Five questions for more inclusive Innovation

Organisations do not need to solve every dimension of inclusion at once before they can improve. They can begin by incorporating five questions into R&D and innovation reviews:

Who might we be leaving out? Consider both the people who currently use the product and those who could use it if specific barriers were removed.
Do our data represent the population in which the solution will operate? This is essential for AI, advanced analytics and automated decision systems, particularly when moving into new countries or user groups.
Are we testing with people who differ from those who designed the solution? Internal teams know their own product too well. What seems obvious to a developer may remain confusing or inaccessible to another user.
Is accessibility included in the initial requirements? When a barrier is identified early, the team has more options to turn it into a useful design improvement.
Are we measuring access and experience as well as technical performance? A technology may meet its technical specification and still fail to work adequately for some intended users.

These questions do not replace technical standards, accessibility assessments or formal AI governance. They provide a practical way to change the conversations that shape innovation. They also create a record of assumptions that teams can revisit as the product, market and user population evolve.

Embedding Inclusion in practice

For inclusion to influence product decisions, it needs to be built into the way innovation projects are governed. Organisations can start by defining accessibility and inclusion criteria in the original project brief, rather than treating them as a late-stage review point. Those criteria should be connected to the users, markets and operating environments the solution is expected to serve.

Practical measures include mapping user groups and usage contexts during discovery, involving a relevant range of users in research and testing, and checking prototypes across different devices, input methods, assistive technologies and real-world conditions. For AI and automated systems, teams should review whether the data adequately represent the intended population, evaluate performance across relevant groups and define what happens when the system produces an incorrect or contested outcome.

Inclusive innovation also requires clear ownership. Accessibility, data representativeness and user participation should be reviewed at defined checkpoints across research, design, development, procurement, testing, deployment and monitoring. Teams should document the assumptions they are making, the evidence used to support those assumptions and the product changes made in response to user feedback. This creates a practical record that can be revisited as the technology, market and user base evolve.

Inclusive Innovation produces better evidence and better products

Accessibility has often been treated as a specialist review at the end of the process. A product was designed, developed and then checked to determine whether it was accessible. Inclusive innovation reverses that order. It considers human diversity while the problem is still being defined, reviews data before a model begins influencing decisions and involves intended users before the team assumes it understands how the technology will be used.

No product will respond in the same way to every possible need, and no single design can remove every barrier. That complexity is not a reason to postpone inclusion. It is a reason to treat it as a continuing part of research, development and product management.

For organisations, the opportunity extends beyond compliance.

Technology that works for more people can address a larger market.
Research that identifies a wider range of needs can produce more useful solutions.
AI evaluated across relevant populations gives decision-makers a more realistic picture of performance.
Teams that bring different perspectives into the development process can find risks and opportunities that competitors miss.

The central question is therefore larger than whether a product meets an accessibility standard. Organisations should also ask how many innovation opportunities they are losing because they continue to design around a limited group of users.

At FI GROUP by EPSA, we understand innovation as the process of turning knowledge and technology into practical impact. That impact will remain limited if some of the people who should benefit from a solution cannot use it. Incorporating inclusion, accessibility and diverse perspectives from the first stages of R&D expands the range of problems a company can solve and the number of people its innovation can serve.

Organisations can begin by reviewing one current innovation project against the five questions above. The answers will show whether inclusion is already influencing decisions or whether it appears only at the point of final validation. That distinction can determine whether accessibility becomes a late correction or a source of better product decisions from the outset.

Inclusive Innovation: Designing Technology for everyone

RelatedPosts

Business Intelligence: The Key to Smarter Decision-Making

AI Innovation Hubs and the future of Global R&D: King’s Cross and beyond

AI Regulation and Innovation: How compliance is becoming a funding driver?

FI Group Achieve ISO/IEC 42001 Certification.

How will AI shape the future of innovative companies?

No more Consultants VS Robots

Artificial Intelligence at FI Group

ChatGPT and the R&D behind it

Metaverses and Web 3.0

Industry 4.0: Unlocking the potential of digital twins

Companies Data: How to ensure security?

AI-Driven Innovation: How Artificial Intelligence Helps Us Maximize Efficiency

Mental Health at Work: People, Innovation and the Future of Work

New EU Tax Framework for R&D: What Innovative Companies Need to Know

Open Innovation: A Key Strategy for Business Expansion and Collaboration

FI Testimonials: Horse Aveiro

FI Testimonials: Leanbio

Horizon Europe in 2027: €500M budget increase, new calls, and changed deadlines

EAIC AGM 2026: How FI Group by EPSA is helping shape the future of EU Innovation Funding

European funds for businesses: the programmes available and how to access them

Strengthening R&D Tax incentive eligibility: Global trends, compliance strategies, and innovation advantages

A Global approach to Funding Innovation in 2026

Business Strategy: What to Expect from the 2026 Business Landscape?

Innovative Solutions for Sustainable Urban Mobility in Europe

STEM, Innovation and Opportunity as drivers for a smarter economy.

Space-Based Tech for Decarbonisation: Funding Roadmap for EU and UK SMEs

Europe Advances in Innovation: Analysis of the 2025 European Innovation Scoreboard

Protecting Innovation: The Strategic Role of Intellectual Property in R&D

From the Data Centre to the Factory Floor: Industrial IT as Innovation