“We must design for the way people behave, not for how we would wish them to behave.” — Donald A. Norman, Living with Complexity
The U.S. military had a problem in the late 1940s. Pilots were crashing, and the causes were mysterious. The crashes weren’t mechanical failures, and the aviators were well-trained. Instead of blaming pilots, one young lieutenant had a counterintuitive theory. Neuroscientist Todd Rose documents what happened next in his book, The End of Average.
With a background in research, Lieutenant Gilbert Daniels believed the unexplained crashes were caused by errors in cockpit design. Each feature of the interior was designed in-place for the “average pilot”, with little or no adjustability. The philosophy was that an individual could physically adjust to fit a space designed for the average flier.
Gilbert analyzed hundreds of bodily measurements from thousands of pilots to establish the “average pilot,” which he defined as fitting within the middle 30% range for each measurement. From hundreds of parameters, he selected just 10 human dimensions to compare the individuals to the profile of the “average pilot.” Of the 4,063 pilots, how many fit all 10?
Not one.
From a pool of thousands, who had already been selected partially for their size, everyone had at least one measurement that fell outside the middle 30% range. Military leadership and Gilbert himself were stunned.
Because of Gilbertʼs research, a correlation between crashes and dysfunctional, “average pilot” cockpit design was so compelling that it spurred the creation of new design principles centered on individual fit. This led to innovations such as adjustable seat belts, adjustable seat heights, and adjustable positions of controls.
The change dramatically improved pilotsʼ safety and performance and significantly increased the number and diversity of candidates deemed qualified to be fighter pilots.
“[Gilbert] Danielsʼ findings were clear and incontrovertible. There was no such thing as an average pilot. If youʼve designed a cockpit to fit the average pilot, youʼve actually designed it to fit no one.” −The End of Average
The Limit of Our Assumptions
This research has urgent implications for todayʼs tech industry. Whether we are building enterprise dashboards or consumer apps, we are effectively designing digital cockpits.
Technologists are making decisions every day that affect who can access our solutions and how much effort is required of the people that use them.
Designing for a non-existent average user ignores the reality of multifaceted humans and the cost of exclusionary design. Designing for the average isn’t just an exclusion problem; it’s a quality problem.
We assume a standard level of tech-literacy, a standard internet connection speed, or a standard way of processing information. In doing so, we ignore the incredible diversity of human behavior and experience.
If we rely on a non-existent “average user” to guide our decisions, we build brittle software.
1. Inclusion Boosts Quality
Does designing inclusively just add unnecessary time to already constrained project deadlines, or does it tangibly improve what we make?
The team behind Microsoftʼs Visual Studio Intellicode put this question to the test. They wanted to create a feature that intelligently offered code suggestions. If successful, it would speed up development; if failed, it would be a focus-destroying nuisance.
They asked, how can our tool make suggestions to coders in a way that actually helps them?
Rather than testing with “average” developers, the team specifically sought out developers who struggled with focus—including those with ADHD. They discovered that for these users, having granular control over when suggestions appeared was essential.
Co-designing with the developers they recruited, the team integrated more options when intelligent suggestions surfaced.
The test results were clear. The usage of the feature immediately jumped, with a 3.5x increase in regular users.
By solving for the specific constraint ADHD/focus needs), they solved for a universal desire (concentration). They didn’t build a niche feature; they built a better product for everyone.
2. Assumed Ability Is False Confidence
Early in her career, Kat Holmes, a software designer, wanted to figure out what styles of design resulted in the most effective, useful solutions. She set out to formalize the principles behind her organization’s most successful innovations.
Based on years of shipping and testing solutions in collaboration with individuals who experienced the most exclusion from software solutions, Holmes documented the concept of ability biases.
Ability bias is the subconscious habit of using one’s own abilities as the baseline for a design. If the designer has perfect vision, a high-speed connection, and extensive domain knowledge, they tend to assume the user does, too.
As an alternative, Holmes proposed recognizing exclusion as the guide for improving products, viewing exclusion as a creative constraint.
- Accessibility is an attribute (is the code compliant?
- Inclusive Design is a method (who are we learning from?
In accessibility in tech, these ideas are often treated as interchangeable, but they are not. Holmes’ contributions created the principles behind the award-winning Microsoft Inclusive Design framework.
“Points of exclusion help us generate new ideas and inclusive designs. They highlight opportunities to create solutions with utility and elegance for many people.” − Microsoft Inclusive Guidebook
3. Untapped Opportunity: How We Move Past the Average
While there are many approaches, tech professionals can start to avoid the average-user trap by adopting two habits:
Prioritize the “Why” Qualitative Data
Metrics like clicks and time-on-page tell you what happened, but they mask why. Quantitative numbers average out users who, for example, might have expert technical skills but have low vision. Aggregating data that doesnʼt measure nuances hides pitfalls and broken interactions.
- The Fix: Supplement quantitative metrics with qualitative data like studies, surveys, and live testing. Watch a user struggle to navigate a menu. That frustration points to an opportunity.
Recognize the scale of the Persona Spectrum
We aren’t designing for a single individual’s specific biology; we are designing for a specific constraint that millions of people will experience at different times. The ‘one person’ is just the clearest signal of a need that extends to a much larger group.
- Permanent: A user with one arm.
- Temporary: A user with a broken arm.
- Situational: A new parent holding a baby.
- The Fix: When you design a one-handed navigation mode for the first user, you solve problems for all three.
Inclusion is the Foundation for Quality
In a business world defined by tight timelines and budget constraints, inclusion is often viewed as an extra step that can be tacked on at the end of a project. This approach misses opportunities for great design and for shaping the future of diversity and inclusion in tech.
As the Visual Studio example shows, strategically including people we design for in the development process is the fastest route to a superior product.
Creating a product that serves people across the spectrum of abilities should integrated into our long-term product development strategies. This is simply designing well. Essential business outcomes including adoption, customer satisfaction, and reduced technical debt, flow downstream from good design.
It starts with noticing the gaps. It continues by listening to a diversity of opinions and perspectives. And it concludes by realizing that when we design for the edges, the whole spectrum of users benefits.
Put another way, if we stop designing for the phantom pilot, we can avoid another crash and tangibly improve the lives of the people we serve.
“Designing for inclusivity not only opens up our products and experiences to more people with a wider range of abilities. It also reflects how people really are. All humans are growing, changing, and adapting to the world around them every day. We want our designs to reflect that diversity.”
− Microsoft Inclusive guidebook
You may also like
