Inclusive Design: Why Prototyping With Stakeholders Isn’t Optional

Introduction

For too long, the design process has followed a linear, top-down trajectory: ideation, design, development, and finally, testing. Often, the individuals who actually live with the disabilities or unique circumstances the product intends to serve aren’t invited to the table until the product is nearly finished. This “test-at-the-end” approach is not just a missed opportunity; it is a failure of logic. When you wait until the end of the development cycle to include diverse users, you are merely patching holes in a foundation that was poured incorrectly.

Inclusive design is not about creating a “special version” for a minority of users; it is about creating a better, more robust experience for everyone. By involving stakeholders—specifically those with lived experience—during the earliest prototyping stages, you stop designing for people and start designing with them. This article explores how to shift your workflow to ensure accessibility and inclusivity are baked into your product from day one.

Key Concepts

Inclusive design is often conflated with accessibility, but there is a distinction. Accessibility is an attribute—the result of a design being usable by people with disabilities. Inclusive design is a methodology. It is the process of acknowledging human diversity and designing solutions that accommodate the widest range of human capability, environment, and experience.

At its core, inclusive design relies on the concept of the curb-cut effect. When a sidewalk is cut to allow for a wheelchair, it also helps a person with a stroller, a traveler with a suitcase, and a delivery person with a cart. By solving for the most extreme edge cases during prototyping, you uncover usability improvements that benefit the entire user base.

Including stakeholders during prototyping means treating them as co-designers, not just test subjects. This involves shifting the power dynamic from “us testing on them” to “us building together.” It requires a commitment to radical transparency regarding what can be changed and a willingness to scrap a high-fidelity prototype if it fails the core accessibility requirements established in the initial discovery phase.

Step-by-Step Guide

1. Assemble a Diverse Advisory Board: Before you draw a single wireframe, identify stakeholders who represent a range of abilities, backgrounds, and technical proficiencies. This isn’t just about diversity in identity; it’s about diversity in cognitive and physical interaction with digital and physical tools.
2. Conduct Empathy Discovery Sessions: Instead of asking stakeholders what they want, observe how they navigate existing solutions. Identify the “friction points”—the specific moments where their current experience is hindered. Document these as core design requirements.
3. Prototype with Low-Fidelity Tools: Avoid high-fidelity software initially. Use paper sketches, cardboard mockups, or wireframes that allow for rapid iteration. It is much easier for a stakeholder to provide honest, critical feedback on a rough sketch than on a polished design that feels “complete.”
4. Establish Iteration Loops: Create a cadence of reviews. Present a prototype, gather specific feedback regarding usability and accessibility, revise, and return to the stakeholders. The goal is to close the loop in days, not months.
5. Document “Why” Not Just “What”: As you iterate, track the rationale behind inclusive choices. This creates a design language that can guide future development and serve as a reference for the broader engineering team who may not have been present for the initial sessions.

Examples or Case Studies

Consider the case of a major banking application redesigning its mobile check-deposit feature. Initially, the team focused on speed and aesthetic minimalism. However, during early prototyping with stakeholders who were blind or low-vision, it became clear that the standard camera-guidance tools were inadequate. The interface lacked haptic feedback and clear auditory cues to help the user align the check within the frame.

Because this feedback was gathered during the low-fidelity prototyping stage, the team was able to pivot. They added a “haptic-first” guidance system that vibrates the phone when the document edges align with the camera frame. This feature didn’t just solve the problem for the low-vision community; it became a preferred feature for all users, as it reduced the time spent trying to hold the phone steady and correctly aligned. The result was higher successful check-deposit rates across the entire user demographic.

The most successful designs are those that treat inclusive features as “power-user” features rather than “niche accessibility” requirements.

Common Mistakes

• The “One-Size-Fits-All” Stakeholder: Assuming one person with a disability represents the entire community. Different users with the same condition may have entirely different technical preferences or navigation strategies. Always aim for a heterogeneous group of advisors.
• Tokenism: Inviting stakeholders to participate but ignoring their feedback in favor of internal “best practices” or aesthetic preferences. If you aren’t prepared to change your prototype based on their input, you shouldn’t ask for it.
• Ignoring Cognitive Overload: Designing for physical accessibility while forgetting cognitive accessibility. Complex navigation, dense text, and flashing animations can create significant barriers for users with ADHD, dyslexia, or those prone to sensory overload.
• Budgeting for “End-of-Line” Testing: Many teams set aside money for late-stage usability testing but neglect the budget for sustained stakeholder engagement during the prototyping phase. Inclusive design must be a line item from the start.

Advanced Tips

To truly master inclusive design, you must move beyond the “user persona” and toward “user scenarios.” Personas can often become static, stereotypical archetypes. Scenarios, however, focus on the context of use. Ask: “How does a user navigate this prototype if they are in a high-stress, low-light environment with limited bandwidth?” This helps your team think about situational, permanent, and temporary disabilities.

Another advanced strategy is to utilize participatory design workshops. In these sessions, give stakeholders the tools to draw or map their own solutions. You might be surprised at the ingenious workarounds they have already developed for their own lives. These workarounds are often the seeds of your next big innovative feature.

Finally, track your Accessibility Debt just as you would track Technical Debt. If a feature is developed that doesn’t meet inclusive standards, document it as a “debt” that must be repaid in the next development cycle. By treating accessibility as a technical requirement rather than a “nice-to-have” add-on, you ensure the project maintains its integrity throughout the development lifecycle.

Conclusion

Inclusive design is not a charitable act; it is a strategic business advantage. When you bring stakeholders into the earliest prototyping stages, you eliminate assumptions, reduce the cost of late-stage rework, and build products that are resilient, intuitive, and truly universal.

The goal is to move past the era of “designing for the average user”—a user who, in reality, does not exist. By focusing on the margins and involving the people who live there, you naturally widen the center. Start small: find your advisory board, listen to their stories, and let their experiences dictate the shape of your product. Your design process will be more complex, but your end product will be infinitely more successful.