Co-Design for Inclusion in Software Development Design
Draw Your Process Tool
The Draw Your Process Tool is designed to support teams in reflecting on how inclusion is (and is not) embedded within their existing software development processes. The tool helps make inclusion visible not only in the final product, but throughout the decisions, handovers, and constraints that shape design and development work.
By starting from familiar development models and adapting them to reflect real practice, the tool encourages realistic conversations about where inclusive and participatory approaches can be meaningfully introduced, sustained, or strengthened. Its purpose is not to prescribe a single “inclusive process”, but to help teams identify practical, context-specific entry points for inclusion within the way they already work.
How does it work?
- Choose the process model that most closely resembles how you currently work.
- Draw your own version of that process, adapting it to reflect reality rather than theory.
- Reflect on where inclusion already happens and where it could realistically be strengthened.
- Compare your result with our findings to lear more about embedding inclusion in your process.
Step 1 - Download the empty that best reflect your process
Start by downloading the empty template that most closely matches your current way of working. These templates are intentionally simple and are meant to be adapted.
If you are unsure which model fits best, download more than one and choose after a quick review.
Step 2 - Draw Your Process
Using the template you selected, draw your process as it actually happens. This is not an exercise in correctness. The goal is mirroring your day to day processes as authentically as possible.
As you draw:
- Rename phases or steps to match the language used in your organisation.
- Add informal or implicit steps (handoffs, approvals, workarounds, support requests).
- Mark where decisions are really made, not only where they are supposed to be made.
- Indicate who is involved at each stage (e.g. developers, designers, product owners, users, co-designers, support staff).
- If parts of the diagram feel messy or unclear, leave them that way — this is often where important issues sit.
Use pen and paper, a tablet, or a digital file. What matters is that the process becomes visible.
Step 3 - Adding inclusion (realistically)
Once your process is drawn, look at it again with a different question in mind:
Where, in this process, do people risk being excluded?
Think beyond the final product and consider the process itself. Exclusion often happens through time pressure, unclear ownership, late-stage fixes, or assumptions about users.
Use the following prompts:
- Where could co-design or user involvement realistically happen?
- Where would a single, well-placed inclusive action make the biggest difference?
- Who would be responsible for inclusion at that point?
- What trade-offs would this require?
Mark possible inclusion points directly on your diagram. Avoid trying to include everything everywhere; focus on what is feasible and sustainable in your context.
Step 4 - What does your process look like now?
Take a moment to look at your final diagram and compare it to our results and reflections.
Waterfall
In Waterfall-style processes, inclusion is often the easiest to locate on paper, but also the easiest to postpone in practice. Because the process is organised into distinct phases, there is a strong temptation to treat inclusion as something that can be “checked” during testing or validation. When this happens, inclusion work tends to surface only once key decisions have already been made, at which point meaningful changes may be costly, constrained, or no longer feasible.
Inclusion is most effective in Waterfall when it is treated as a first-order requirement and design input, rather than as a corrective activity. Early engagement with users or co-designers can inform requirements, assumptions, and design choices before they solidify. This does not require continuous involvement, but it does require intentional early touchpoints. When inclusion is embedded at the requirements and design stages, testing becomes a confirmation of earlier decisions rather than an attempt to fix structural issues late in the process.
V-Model
The V-Model lends itself well to inclusive practices because of its emphasis on traceability between specification and validation. Inclusion can be meaningfully embedded when access needs and inclusive requirements are made explicit on the specification side and are clearly linked to corresponding verification and validation activities.
In practice, this means writing inclusion requirements in a way that can be verified and validated, rather than leaving them open to interpretation. Vague statements about accessibility or usability are difficult to test and easy to deprioritise. Clear criteria, mapped to specific validation activities, make inclusion visible throughout the lifecycle. Importantly, validation does not need to rely solely on technical testing; it can include structured involvement of users or co-designers as part of planned validation activities. This helps ensure that inclusion is not treated as a compliance checkbox, but as something that is assessed against real use.
Spiral
The Spiral model supports inclusion by framing development as a sequence of iterative cycles driven by risk assessment. Within this model, exclusion can be explicitly treated as a project risk: who might be excluded, how exclusion might occur, and what the consequences would be if it is not addressed.
This framing allows inclusion to be revisited regularly, rather than addressed once and assumed to be “solved.” Prototyping and evaluation stages provide natural opportunities to explore inclusive alternatives, test assumptions, and learn from feedback before committing to full implementations. Inclusion work can therefore progress incrementally, with each cycle refining both the product and the team’s understanding of users’ needs. The challenge is to ensure that insights from each cycle are carried forward, rather than reset or forgotten as the project moves on.
Scrum
In Scrum-based processes, inclusion often competes directly with time and delivery pressure. Short iterations, evolving requirements, and prioritisation driven by visible value can result in inclusion being postponed or fragmented if it is not made explicit. Without deliberate effort, inclusion risks becoming something that is “planned for later sprints” but never fully addressed.
Inclusion becomes more sustainable in Scrum when it is made visible in everyday artefacts and rituals. This can include writing inclusion-related backlog items and acceptance criteria, allocating time for inclusive research or testing within sprints, and embedding inclusion into the definition of done. Reviews and retrospectives provide opportunities to reflect not only on what was delivered, but on who may have been excluded and why. Rather than aiming for full inclusion in every sprint, teams often make more progress by agreeing on small, repeatable inclusion commitments that can be maintained over time.