Building an inclusive approach
As organizations deepen their commitment to creating apps and services that consider the full range of human diversity, they realize that everyday design and research tools, processes, and behaviors need to change. They need to evolve in order to allow room for this expanded way of working. We created the Inclusive Design Sprint to give teams a structured way to learn in the context of doing their work–either on a practice project or on something they will ship to customers.
Most teams opt for a high-velocity one-week sprint to explore this new approach to make the most use of their workshop time. If the team delivery schedule allows for a measured approach, we recommend a longer time period, to allow more reflection and iteration.
All about the sprint
The gist of the one-week sprint is:
Day 1
First half: Review of inclusive design principles, dimensions of diversity, the impact of exclusion, and the business case for inclusion.
Second half: Introduction to inclusive research methods.
Day 2
First half: Apply inclusive research methods in the field by doing some actual research in real-time. The focus is field research of people with substantially-different lived experiences than the project team.
Second half: Evaluate findings from the research to uncover mismatches and identify opportunities to be more inclusive in apps and services offerings. Dig deep for insights that are not obvious by using the lens of exclusion.
Day 3
Learn how to expand typical ideation by understanding the spectrum of characteristics and exploring multi-sensory approaches to UI. Next, learn how to identify exclusion and bias risks for experiences which rely on machine learning or artificial intelligence. Then, review relevant accessibility standards to ensure familiarity. Finally, create a spectrum of characteristics for the specific project being tackled in the sprint.
Day 4
First part: Begin solution ideation, ensuring that mismatches are the focus and that the spectrum previously-developed is used to iterate.
Second part: Expand the ideation space by considering multi-sensory solutions. Then, iterate using different physical situations and context as framing.
Third part: Iterate solution ideas by integrating accessibility fundamentals, to continue to remove mismatches. Learn how to write guidelines and code samples to ensure consistent implementation.
Day 5
Examine personal and project bias, using reflection and a framework of types of biases, explore the uses and limits of simulation, and learn inclusive methods to get feedback on solution ideas. Finish the sprint with final presentations of the practice group project and reflection.
Transforming how we work
We have found that learning in situ is key to not only practicing the enhanced design and research methods, but to identifying tolls and processes that need to be altered. And, because the team is assembled in one place during the sprint, they can brainstorm solutions for the alterations in real time, try them out, and iterate–so that by the end of the sprint, they have tools and processes they can use with confidence going forward. This has proven to be very important because, once back on the job, the demands of delivering scenarios and features leaves very little time to invest in tools and processes.