We’ve noticed that some of our most exciting clients pursue inclusive design principles. But that’s where a problem comes in. Read more…
By “inclusive design”: I’m going to use the definition proposed by our client, Microsoft. They call it “design[ing] software with everyone in mind from the very beginning”.
We’re very lucky to work closely with Microsoft and I wish I could tell you more about our work. But in general, businesses which try to pursue inclusive design find that they have to deal with two challenges which need solving. We call them the glasses and the shoes problem.
You can skip to that, but let me tell you about inclusive design first.
Inclusive design is design for everyone. Some people use “everyone” to refer to groups most frequently forgotten by regular design processes or with specific product requirements – that might mean users who use screen readers, for example.
You can also use “inclusive” to refer to a cross-section of any other number of user categories. This is one reason that Pinterest houses accessibility, inclusivity, and localization in one place. There is also a distinction between a requirement and a preference, where some users might prefer your product to be in French in a way which makes a difference to commercial user behavior, but it’s not an absolute barrier to use.
There’s three categories of argument for why to design inclusively.
The first is economic. The nub of these arguments is that making your product better for more people will grow your product. The push for some kinds of inclusivity – for example, localizing your product – is nearly always economic, as 70% of the world’s internet users are non-English speakers. But it’s true of lots of groups of users: 44% of computer users use some kind of assistive technology, for example. One in six people worldwide have a significant disability according to the WHO.
And it’s bigger deeper than a bigger TAM: underrepresented probably means under-catered to, which may mean more lucrative depending on your niche. There’s a slow march of web and product accessibility laws; much of the investment in inclusivity you may have to make anyway.
The second is to do with vision or moral choices. Slack was the only business in our recent interview series which translated all their text for every language – others made the practical decision based on market size. Many businesses choose to go above the accessibility legal requirements because they want their inclusive values to be borne out in their product.
There’s a final argument, too – product quality. You can think of a non-inclusive product as a kind of technical debt. Many of the internationalization or accessibility initiatives businesses go through in middle life can be extremely painful; where sensible decisions taken from the beginning can make your product more robust for more users without slowing you down.
That’s why do it – but here’s why it’s difficult.
Designing inclusively creates two challenges, and it’s something we see all the time among businesses who first start out with GAT. We know them as the shoes problem and the need effect.
The shoes problem is the most obvious and important area in software design. It’s based on the “walk a mile in my shoes” expression. It’s not enough to ask users what they think, you have to experience what your users think and feel.
Take the advice of Paul Graham, the famous Y-combinator founder. He advises founders to “make something for yourself” because it’s an easy way of adhering to the foundry’s motto, “make something people want.”
Microsoft points out that there are two types of users of assistive technology. Those who need it, and those who “use it out of preference for a more comfortable or convenient computing experience”.
The “need effect” describes the product management processes whereby low-hanging fruit in terms of different user preferences is ignored.
When you have a “need”, a business will typically work forward from the user group (e.g. “deaf user requirements”) until the specification is complete (e.g. “we’re compatible with screen readers XYZ”).
In contrast, when you have a user “preference”, a business will typically work backwards from a business problem (“insufficient growth in Italy”) to identify an area of work they should do. (“Translate into Italian”).
All this is fine, except that it ignores some of the very best programming a business can do in terms of the return for user experience. Very often, just after a user’s “needs” are met, a product becomes technically usable but still frustrating. As those users join the platform, your NPS and other core metrics are likely to get worse. This is needless – by taking it a step further and working through their experiences up to their preferences, you can disproportionately affect their NPS and engagement.
Microsoft cited an example where deaf users were turning off toast [pop-up] notifications on their Xbox consoles. “When we asked actual deaf users about this, we learned that toast notifications were obscuring a section of closed captioning. The fix was to display the toast slightly higher on the screen. This was a simple solution that was not necessarily obvious from the telemetry data that initially revealed the behavior.”
The opposite approach – working backwards from a commercial incentive – can similarly fail to use the lens of different user “groups” to find the best possible development investments. I won’t retread some of the statistical challenges which make businesses miss bugs in their data here but in our view, both approaches are essential for an inclusive design approach.
Brian Chesky from Airbnb said:
“Once you get really successful, you stop becoming the customer. I can’t make products just for 41-year old tech founders. That’s not a really big market.”
(Well said, Brian.)
It’s time to put my cards on the table. I have heard large software businesses talk about the need effect and the shoes problem and several other problems for as long as I’ve been working in software testing, which is a long time.
Brian has done something extremely interesting which is that he’s rolled product management into product marketing, and in so doing, asked his product managers to think really deeply about the commercial propositions on which his business relies.
Here’s my list about how to solve the challenges in inclusive design:
This is it. This is the only answer. I was going to write a list, but there is only (1) thing on the list, and it’s the thing above. I will dig into it below, but the answer is above.
Here’s how and why:
Businesses do empathize with most user groups. They just do it very slowly. Research which involves focus groups, analysts, reports – anything where the timeline is months, could be too slow to inform your software development.
The reason for this is that iteration has shown to be the most effective way of building software, and you can’t iterate in months. You need to iterate in days, weeks at the most. Users are slow and frustrating, they identify different things than they really want, and they behave in unexpected ways. Continually showing users your software and seeing how they interact with it is a more effective route to better engagement than asking for a detailed specification.
Iteration should be as fast as you can get it done, and that’s why we emphasize speed above all else in our user research products. The difficulty – iterating very quickly for a very specific kind of user – that’s our specialism, and it’s one of the primary uses of crowdtesting technology. Routing to different time zones can get some kinds of test done overnight. Maintaining a large supply of testers means we can access a specified kind of tester very quickly. Incentivizing the best work means we can get faster and more accurate feedback than you can with traditional panels.
Faster also means earlier. Global App Testing allows you to test prototypes and design files to targeted demographic groups so that you can catch bugs and usability issues before they reach the hands of a developer. Speed unlocks a design process where you can route your software through multiple kinds of user in the pre-development process.
Early exposure to user feedback empowers businesses to make informed adjustments, ensuring that inclusivity concerns are addressed from the outset. Crowdtesting acts as a proactive measure that saves time, resources, and potential setbacks that might arise later in development.
We have powerful demographic controls which enable you to target different kinds of user. That could be by country (sometimes, region); device; OS; or users with specific kinds of software requirements.
We’re extremely proud to partner with Open Access to offer panels with users with real impairments, who can comment about their lived experiences; in addition to testing your features which relate to the WCAG guidelines to ensure you’re meeting internationally accepted standards for those kinds of users.
By offering audits which relate both to functional and usability issues, you can specify testing for both of those stages of the “need” to “preference” cycle for a specific kind of user, taking your product development into an area which will be improving
We can’t start retelling stories here, but it can sometimes surprise clients how much a bug which is affecting NPS, growth, or the bottom line can get. Different user profiles or needs are a very important lens to examine software through, and if it’s not something you do, it can be a very effective way to catch extremely-high ROI development you can undertake on behalf of that group of users.
Global App Testing runs both functional and non-functional tests for our clients. But for the most sophisticated ones, the distinction is much blurrier. Software is changing. It used to be about building a one-sized-fits-all interface which worked. But increasingly, generative AI will permit more personalized experiences in software which are cheaper to produce to a more granular level.
The answer to this is above; test earlier and faster to a diverse group of people and environments.