Inclusion is key for giving as many software users as possible a quality experience. Creating that experience, however, involves more than writing code. It also requires empathy to understand and anticipate user needs, whether those are visual, navigation, or language.
Companies that fail to foster empathy for customers will have a difficult time anticipating their needs and could fail to design interfaces and features that are usable for part of their potential market. That opens the door for competitors to create a product better designed to be inclusive for users with physical limitations and those who speak different languages or live in different cultures. Ultimately, customers are more likely to switch to the inclusive — and easier to use — software, costing the non-inclusive developer lost sales and likely damaging their reputation, too.
Inclusions and Empathy Explained
In simple terms, empathy is the ability to understand and respond to someone’s needs. Sympathy, in contrast, is the ability to recognize someone’s needs. For developers, that’s the difference between seeing someone is having trouble using their software (sympathy) versus recognizing the problem, understanding how it impacts users, and taking action to address it (empathy). Empathy is a skill we can learn and improve through experience.
Inclusion often includes accommodations for people with permanent or temporary vision, hearing, and mobility issues that limit their ability to successfully navigate and use the software. Developers typically think of inclusion in terms such as color contrast, font legibility, and button sizes, but to be truly inclusive, the software also needs to address language and culture.
Localization is Part of the Inclusion
Localization, or L10n, is the process of adapting software to fit a user’s language and cultural needs. That includes translating text for specific locales, as well as ensuring other content like number formats, addresses, currencies, and graphics conform to language and cultural needs. For users, localization makes the software feel like it was developed for them instead of seeming like a foreign tool they have to adapt to. In that sense, l10n is another element in inclusion and accessibility.
Developing with inclusion in mind for vision, hearing, mobility limitations, and l10n requires actively planning for the user’s needs. For developers, that means coding for accessibility, and in the case of localization, that means coding for internationalization. Briefly, internationalization (also known as i18n) is the process of coding software so it can be localized for any language and culture.
Developer tools for including accessibility features in software are available, along with resources like W3C’s list of web accessibility evaluation tools. For internationalization, Lingoport’s Globalyzer flags localization-related bugs for developers directly in their IDE. Coupled with Localyzer, the translation workflow is automated so developers and translators can work in tandem. It cuts out delays while waiting for completed translations, and lets developers see how those translations look in their software.
Giving developers the tools they need to support inclusion — for both accessibility and localization — should be part of the development cycle from the beginning. Coding for inclusion is more efficient and costs substantially less when it’s part of the development process instead of being addressed later or even after the product is released.
A good way to ensure your software is accessible is to follow the Web Content Accessibility Guidelines. For localization inclusion, use Globalyzer and Localyzer.
Research Helps Build Empathy
Knowing who your users are and how they’re using your software requires research. For accessibility, that can include learning how people who can’t see navigate software interfaces or what options are available for people with limited mobility.
With localization, companies need to learn about the cultures in the different locales their software will support. That also includes knowing what languages and local dialects are spoken.
Research builds knowledge, and knowledge helps foster empathy. With empathy, it’s much easier to design software that’s truly inclusive.
Testing Helps Build Empathy
Testing software helps uncover bugs and show where features can be improved. It’s also useful for helping foster empathy for users. Seeing and experiencing the same issues users face when using your software makes it much easier to appreciate why bugs and inclusivity problems need to be addressed and helps build a mindset where developers and designers are actively thinking about how to create more usable products in the future.
The data collected through software testing is critical because, without it, bugs that otherwise would have been caught before shipping become issues for users. Those bugs are also significantly more expensive to fix after the software ships. Data helps identify problems that can then be fixed, and you can’t fix problems you don’t know about.
Software testing, whether it’s for functionality, accessibility, or localization, needs to be an ongoing process. If it isn’t, software updates such as bug patches and feature updates can potentially introduce new problems that end up in public releases.
Developers use tools in their IDE platform to help find and track bugs. They can do the same with tools designed to test for accessibility-related issues, and tools such as Localyzer QA can test for and fix localization-related bugs.
Focus on User Needs
Quality software isn’t designed in a vacuum. In-house design and testing is an important element of the development process, but it’s only part of the equation. End users provide valuable feedback, too, because they’re using the software every day, and possibly in ways that weren’t considered during development.
While it’s sometimes frustrating, listening to user complaints reveals software bugs, issues with interface elements, and missing features. It’s about crafting software that everyone can use. This is a key place where empathy is critical because it’s a necessary element in moving beyond seeing a backlog of bug reports to understanding and solving user problems.
Designing inclusive software is more than just making sure the type is legible and that there’s enough contrast between colors. It’s also about making a conscious decision to help as many people as possible who use an app feel like it was designed for them. Understanding why inclusivity is important for users and actively working towards that goal needs empathy. The results will be software that’s easier to understand, users who are more loyal and less likely to switch to competing products, and a better reputation for your company.