When developing your product/service or concept, base it on the needs of your target group. The best way is to use real data and involve users in shaping the idea (see Steps 1–3).

If direct involvement isn’t possible, you should still think about inclusion. For example, in AI projects, make sure your data includes people of all genders, ages, and backgrounds. Check your development process for bias. For example, if you are creating synthetic data from real data, biases may occur in the process. If you are not sure about the inclusion factor in your case, please have a look at Step 1, do some research (e.g. on ethical AI) or do some interviews with experts in your field who also have experience in inclusion (see Step 2).

If personalisation seems difficult, look for alternative technologies – like 3D printing, which has helped customise prostheses in past projects.

Don’t develop your product all at once. It’s better to plan several testing and feedback rounds during development (this is called iterative testing).

You can use the following evaluation methods, either individually or in combination:

• User tests (e.g. with a thinking-aloud methodology, A/B Tests, usability test, Card Sorting, Walkthrough method)
• User diaries / pilot testing
• User shadowing in real-world scenarios
• Workshops & other group formats, such as Stakeholder workshops)
• Biofeedback (e.g. eye tracking, heart rate, or breathing rate)
• Many of the methods mentioned in Step 2 such as interviews, focus groups, observations, surveys, experiments
• And many more ...

Watch out for these issues:

• Inclusion: It is important not to reinforce existing stereotypes in the methods used, for example in personas, use cases and scenarios (e.g. a woman who likes everything pink and is unable to do basic handicrafts). It can help here to base personas on real data or use gender swapping. Consider the real-life circumstances of your target group. For example, think about how care responsibilities might affect scheduling. Please do some research on how this method can be applied in an inclusive way.
• Recruiting testers: Your test group should be as diverse as your survey sample but it can be hard to find a diverse group. See guidance in Step 2 on how to build an inclusive sample. Don’t rely only on tech-savvy users.
• Valuable feedback: Poor planning can lead to shallow results. Make sure you allow enough time, ask good questions, and design your test well. Analyse test results with an inclusion lens. You can follow the advice in Step 2 under 'Data Analysis' for support and external resources.

Here you find tools and resources for support

Tools & resources:

• The RESET project offers a Co-Design Starter Kit with a section on “Reflecting on and Evaluating Design”.
• The GILL Hub is a collaborative platform and community that provides tools, methods (also for testing, e.g. Empathy Map, gender-responsive walkthrough, EEASI Product Evaluation), services, and resources to support gender-responsive smart innovation and entrepreneurship.
• There is a useful handbook on Design Practices and stakeholder involvement: “Nothing about Us without Us”.
• Check out the guide “Usability Testing: A Practitioner's Guide to Evaluating the User Experience” by Morten Hertzum from the University of Copenhagen.
• If you want to deep dive into evaluation, have a look at the “Guidelines for Programme and Project Evaluations” by the Austrian Development Agency.

To make the test inclusive, they sent a short questionnaire to potential testers and selected a diverse group.

The plug-in was tested in two rounds. In both rounds, users participated in a fictitious online meeting, discussing two topics. Feature A was tested during the first topic and feature B during the second, meaning the user test followed an A/B testing logic. Afterwards, there was a discussion by the users with the team, in which the team collected feedback on:

What did they like? What did they not like? Did they have any suggestions for improvement? Based on this feedback, the tool was improved and tested again.

The guidelines for moderators were tested using user diaries. Moderators used the materials in their daily work for a few months, wrote down their experiences and gave feedback on the methods and recommendations. In a reflection workshop they also discussed the guidelines with the team. Their feedback helped improve the final version.