skip to primary navigation skip to content
 

Introduction

The Inclusive Design Wheel is an iterative process framework for designing inclusive products and services. This section explains how it can be applied to designing inclusive transport products and services. This page describes the process as a whole and its main phases: Manage, Explore, Create and Evaluate. The process is supported by a design log, which is a structured PowerPoint file to facilitate recording notes and findings from each of the activities.

On this page:

Introduction to the Inclusive Design Wheel

The Inclusive Design Wheel framework consists of four phases of activity:

  1. Manage: Review the evidence to decide ‘What should we do next?’
  2. Explore: Determine ‘What are the needs?’
  3. Create: Generate ideas to address ‘How can the needs be met?’
  4. Evaluate: Judge and test the design concepts to determine ‘How well are the needs met?’

The Explore, Create and Evaluate phases each contain a variety of suggested activities, as described in the relevant panels below. The nature of a design process is that it is highly iterative and hence the phases (and the activities therein) do NOT need to be carried out in strict order. Most real-world design processes will comprise of thousands of iterations, some large and many small, reflecting a gradual decrease in size as the project develops. However, the sequencing of these activities will be dependent on the decisions taken by the team reflected in the central Manage phase.

If a project team has an existing design process, they may find it helpful to check whether it already adequately covers the key phases and activities in the wheel, or whether there are other activities that can contribute to one or more of these phases.

Iteration and flexibility

A key principle of the Inclusive Design Wheel reflects that a design process is highly iterative. Thus successive cycles of the Explore, Create and Evaluate phases are used to generate a clearer understanding of the needs, better solutions to meet these needs and stronger evidence that the needs are met. The Manage phase guides the process by determining which activities should be performed, and when they should be performed. The iteration means that activities from all the phases are likely to be performed multiple times before the end of the project.

It is particularly important to include Evaluate activities in iterations, including early ones. This helps to ensure that the ideas and concepts are tested early enough that meaningful change is still possible. The design team can evaluate concept descriptions, storyboards, mock-ups or rough prototypes in these early iterations. The evaluation itself can take multiple different forms, as described in the Evaluate section.

The Inclusive Design Wheel is designed to be used flexibly so that it works in different contexts and can adapt to changes in projects and situations. As such, it is not necessary that all the activities within each phase are conducted in every iteration of the wheel. In fact, teams are encouraged to perform quick iterations, some of which can include just a few of the activities, in order to rapidly evaluate and refine ideas as they emerge and quickly respond to changes in the understanding of the needs.

The Inclusive Design Wheel is clearest and easiest to navigate when it is drawn as a single wheel, displaying all the activities in a single iteration. However, its use in practice is likely to be more like the example spiral shown opposite. All of the Inclusive Design Wheel activities are conducted at some point in the process. However, each individual iteration only involves a subset of the possible activities, ideally with at least some Explore, some Create and some Evaluate activities. The design process spirals inwards to reflect that as time and iterations are carried out, the solution becomes targeted at the problem and more refined.

Manage: What shall we do next?

The Manage phase determines which individual activities need to be performed, and in what order. Two key sources of information are used to do this:

  • The project proposition, which includes the project aims, objectives, risks, unknowns, project plan and costs.
  • The project summary, which includes the problem statement, the proposed solution(s), and the evidence gathered so far

Examining the project proposition and the project summary should help the team to identify the most appropriate 'next steps' activities that need to be completed in order to resolve the unknowns and progress the project. Each time a design activity is completed, the project proposition and the project summary should be checked or updated on the basis of the new information. This should inform the decision about which activities need to be conducted next.

The specific activities in the manage phase include:

  • Refine project proposition
  • Summarise & agree next steps

Each of these activities are described in more detail within the page about Manage.

Key principles to keep in mind during the Manage phase include:

  • Repeat to refine. Successive cycles of Explore, Create and Evaluate should improve the solutions and eventually deliver one lead concept.
  • Plan to be flexible. Make sure the plan can accommodate the 'game-changers' that are inevitably discovered during the process.

Explore: What are the needs?

Activities in the Explore phase provide a deeper understanding of the problem to be solved and the wider context in which the solution will operate. This is important because many design problems are poorly formulated with incomplete information and occur in situations where stakeholders have conflicting values and the existing behaviour of the system is poorly understood.

Exploration is needed to gain a clear understanding of the problem, considering the range of stakeholders involved and their wants and needs. Understanding the diverse range of end users is particularly important in inclusive design and the activities in the Explore phase can help reveal their needs, capabilities and current user behaviour.

The specific activities in the Explore phase include:

  • Explore stakeholders & context
  • Engage with users
  • Understand user diversity
  • Examine user journeys
  • Capture wants & needs

Each of these activities is described in more detail within the page about Explore.

Key principles to keep in mind during the Explore phase include:

  • It’s normal to be different. Remember that it’s normal for users to want different things and to do things in different ways. Understand the diversity amongst your end users, this will help identify which needs are going to be targeted by the proposition. Understanding capability and disability is only a part of this.
  • Consider the whole user journey. Satisfying user goals involves designing for end-to-end journeys that take place in real-world contexts.
  • Detail matters. Dig deeper to uncover and address the things that people actually do, want, and need. Observing users achieving their goals can elicit very powerful insights.
  • More than just users. Consider the needs of stakeholders such as local authorities, transport providers, regulators, manufacturers and maintainers.

Further information

The Explore phase described here corresponds to the Discover and Define phases of the Design Council’s Double Diamond design process model, in which many options are explored before the problem statement and design brief are agreed upon.

Create: How can the needs be met?

The activities in the Create phase help generate solutions to meet the needs identified in the Explore phase. These can range from producing initial fledgling ideas, to developing storyboards or prototypes with sufficient fidelity that they can be tested.

The specific activities within the Create phase are:

  1. Involve users
  2. Involve other stakeholders
  3. Stimulate ideas
  4. Develop & refine ideas
  5. Make storyboards or prototypes

Each of these activities are described in more detail within the page about Create.

Key principles to keep in mind during the Create phase include:

  • Strive for simplicity. Simplicity is powerful but elusive; it requires a clear and succinct vision of what the solution is about. Ask: 'can you do it with less?'
  • Challenge assumptions. It is easy to get stuck in thinking that the way things have been done is the only way they could be done. List your assumptions and ask 'why?'
  • Let ideas breathe. Give wacky ideas the chance to become great ideas. They may not be feasible now or in their current guise, but they may inspire a more feasible idea.

Evaluate: How well are the needs met?

The Evaluate phase is about examining the concepts from the Create phase to determine how well they meet the needs identified in the Explore phase. The first step in Evaluate is to agree the success criteria, which should be based on the wants & needs of users and other stakeholders from the Explore phase. These criteria are then used to inform the plan for gathering feedback from users and experts and to summarise the results.

The specific activities within the Evaluate phase are:

  • Agree success criteria
  • Gather user feedback
  • Gather expert feedback
  • Estimate exclusion
  • Identify strengths & weaknesses

These activities are described in more detail within the page about Evaluate.

Key principles to keep in mind during the Evaluate phase include:

  • Test early and test often. Perform quick tests with rough prototypes, early enough in the process that meaningful change is still possible.
  • Prove it. Complement opinions with evidence.
  • Consider different perspectives, such as the user experience, technical risk, resource efficiency and profitability.

Inclusive design log for transport

The Inclusive Design Wheel for transport is supported by a PowerPoint design log. The log contains sheets and templates for recording each of the activities, with example content for each of the activities drawn from the DIGNITY pilot projects. More information on the pilot projects can be found in DIGNITY Deliverable 3.3 (pdf).

The log is described in more detail in the page about the design log.