Beyond Checklists: Growing Our Inclusive Experience Mindset
By Nicole Windmann, VP of Accessibility and Inclusive Design at SAP
We know it by many names: Inclusive design, design for all, universal design. The inclination to create experiences that meet the needs of all people has been a topic in the software industry for decades. Now it represents a key pillar for SAP’s design strategy.
But what are the concrete steps we need to take to create an inclusive software experience for all? Whereas inclusive experiences are there to meet real virtual and physical needs, the “how” is often harder to describe. What are the aspects that have an impact on a person’s individual experience with a product? And when can we claim success?
Going beyond technical requirements
In the world of enterprise software, we are all familiar with the industry standards for technical accessibility requirements, ensuring that digital products are perceivable, operable, understandable, and robust for people with disabilities. The accessibility requirements covered by the Web Content Accessibility Guidelines (WCAG) are a great starting point. However, basing an inclusive design practice on accessibility standards alone does not account for the many nuances of the vast and varied human experience.
For starters, the WCAG aims for objective measurability of their recommendations, which is tremendously helpful to measure the accessibility compliance level of a product and to be able to reproduce test results. But it also misses out on the human factor in the experience: Joy, efficiency, intuitive usage. The current WCAG also do not cover recommendations to support the needs of all people with disabilities, including those with cognitive disabilities or those who identify as neurodivergent. But even just focusing solely on the term “disability,” which does not yet have a universally valid definition, is limiting. By this measure, we risk missing other, equally important intersectional aspects of inclusivity such as gender, sex, age, education, culture, legal requirements, sociopolitical, and even geographic environments.
In 2020, these inclusive considerations became very real for SAP when we were presented with an opportunity to design and develop an app to help Germans navigate the growing Coronavirus pandemic. The resulting Corona-Warn-App needed to be truly inclusive in order to succeed in its mission of helping to protect and inform all people in Germany. This pulled our design team into a much broader scope. While the app needed to be compliant with requirements around security, data protection, privacy, and accessibility, it also had to appeal to people coming from different educational backgrounds, language skills, abilities, disabilities, and cultural belongings. The app needed to serve many generations and support usage in changing environments. The design also needed to ensure high acceptance across the entire country. Because these inputs were present and necessary from the start, the team didn’t have to think about inclusive design as an afterthought — it was implicit in the process all along.
Designing inclusively from the start via deep change
Designing the Corona-Warn-App was a pivotal experience for our teams because it confirmed how important it is to make inclusive considerations from the start to come up with a user experience that fits a wide range of needs. We want everyone using our products to have a positive experience, to work to their highest capacity, and to feel valued and included in their physical and virtual environment. To do this, we need to ensure that our standard design and development processes account for the wide variety of needs arising from the variances amongst our users. Simple, user-centered, consistent, seamless, intuitive, data-driven, and inclusive are the paradigms that will guide us on our design evolution.
As part of this transformation, we are redefining the way we build our software to ensure the design and development process is inclusive from the start. The goal is not to create a separate “Inclusive Design Process” along the way. Instead, we will weave inclusion into the working routines of our teams, tools, frameworks, and thinking so that inclusivity becomes a core part of how we build products at SAP.
Here are some of the ways we are working to achieve this:
- We’re transforming our culture and working routines: As an organization, we need to reach out and learn from people whose backgrounds are different than ours–and we need to do that proactively by creating the spaces and opportunities to come together as a community. In doing this, it’s key to recognize that we may not always understand the needs of others or identify with others, but we need to listen and accept the differences. This means getting out of our comfort zone.
- Infusing inclusivity throughout the full software lifecycle: We are applying inclusive practices in all phases of the design and development process, including research, planning, designing, developing, validating and maintenance, with research being the practice spanning the full cycle.
- The Inclusive Research Playbook: Our research and inclusion teams recently piloted an “Inclusive Research Playbook” to support a more inclusive user research methodology across our design community. This guide provides tips on planning, organization, etiquette, and more. The latest evolutions to our design system are in fact based on outcomes from the inclusive user research feedback.
- Accessibility Annotations on Figma: We already have so much data at our disposal that we can learn from, and we are using it to steer our new direction. After analyzing hundreds of test reports, we found that many accessibility issues could be avoided at the development phase if design specifications were better annotated with accessibility assets. This is why we’re now making it a point to offer annotations, plug-ins, and links to supporting information where designers need it: directly in the Figma files. By enriching design specifications with accessibility annotations, we can ensure that accessibility aspects beyond the visuals are covered by the design and specified for developers. We will continuously enhance those assets as we evolve our expertise on broader inclusion aspects.
- Building upon a solid compliance foundation: At SAP, we also have a highly mature accessibility development policy in place that has evolved from mere compliance to a more user-focused approach over the past two decades. Our existing product accessibility processes ensure quality governance at scale and compliance transparency to our customers. This is a solid foundation on which to build upon as we open up our understanding of inclusive design to mean design without limits, design for all.
This list represents the beginning of our journey, with many more exciting developments around the corner to ensure that people remain at the center of everything we do. As we continue to cultivate an inclusive experience mindset, we should not forget that apart from all the tools and frameworks we could provide, true success is dependent on our people. A “product inclusion checklist” will only get us so far (even if it helps in the transition phase). Rather, we’re committing to building an inclusive culture that attracts diverse talent and where human-centered thinking permeates everything we do.
For over a decade, Nicole Windmann, VP Accessibility and Inclusive Design, has been channeling her passion for people, equity, inclusion and social justice into her Product Inclusion work at SAP. She is responsible for SAP’s Product Accessibility Policy and the processes and frameworks to make Inclusive Design happen across SAP’s products.
This article originally appears in SAP Community.
