# 3.2.2.1 Involve a diverse user group in the design

### **Involve diverse users in testing and feedback**

Ensure your user testing and feedback collection includes a diverse range of users. Include users with disabilities and those from various backgrounds and experiences. This approach helps identify potential accessibility and inclusivity issues that might be overlooked by individuals without these experiences.

[Inclusive Design Toolkit from Microsoft](https://www.microsoft.com/design/inclusive/)

### **Understand user capacity and identify barriers to access**

To create a service that caters to all users, you must understand their unique capacities. Consider factors like:

* Time available
* Financial situation
* Ease of access to an interface (device or person)
* Interface capability and confidence
* Service process-related confidence
* Awareness of the service, its purpose, and access options
* Ability to comprehend information
* Mental health/emotional capacity
* Trust in service robustness, security, reliability
* Ability to provide required information
* Willingness to use the service, at all or in the most cost-effective way

With this understanding, identify the potential barriers users might face when accessing and using the service. These barriers could be,

* Physical: Disabilities that affect a person's ability to interact with interfaces.
* Technological: Limited access to high-speed internet, up-to-date devices, or the latest software.
* Cognitive: Cognitive impairments, learning disabilities, or language barriers that make the service hard to understand or use.
* Economic: Economic limitations that restrict access to necessary technology or internet access.
* Geographical: Limited internet access in rural or remote areas, or cultural or language differences in different regions.
* Privacy and Security: Concerns about personal data usage or protection.

### **Design for inclusivity**

Having understood user capacity and potential barriers, you should design your service to be as inclusive as possible. This could involve simplifying processes, offering alternative access methods, or providing additional support where needed.

### **Consider non-digital alternatives**

While digital public services offer many benefits, they may not be suitable or preferred for all users. Some users may lack the necessary technology or digital literacy, while others may simply prefer traditional methods. In these cases, consider offering alternative mechanisms for accessing the service, such as phone support or physical locations.

### **Consider Gender Equality and Social Inclusion (GESI)**

In all aspects of your design process, ensure principles of Gender Equality and Social Inclusion (GESI) are adhered to. It means your service should be accessible and fair to all users, irrespective of their gender, age, ethnicity, disability status, income level, etc.

> **Example**
>
> In a public healthcare service, implementing GESI principles led to the development of a more inclusive appointment scheduling system.
>
> It was noticed that many women, especially from lower-income backgrounds, were unable to attend appointments during standard working hours due to their caregiving responsibilities. By extending service hours to evenings and weekends, and providing childcare services, the service became more accessible to this demographic, significantly increasing attendance rates.

**Further reading:**

* [GESI Qualitative Framework by Oxford Insights](https://www.oxfordinsights.com/gesiqualitativeframework)
* [Design Justice principles](https://designjustice.org/read-the-principles)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://specs.govstack.global/overview/23q4/govstack-ui-ux-guidelines/3-service-design-good-practice-guidelines/3.2-accessibility-and-inclusion/3.2.2.1-involve-a-diverse-user-group-in-the-design.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.