LogoLogo
Give FeedbackGovStack Home
Development
Development
  • GovStack
  • Contributing
  • Architecture and Nonfunctional Requirements
    • 2 Introduction
    • 3 GovStack Architecture
    • 4 Building Block Design Principles and Considerations
    • 5 Cross-Cutting Requirements
    • 6 Onboarding Products
    • 7 Standards
    • 8 UI Switching and Handover
    • 9 Other Resources
  • Security Requirements
    • 2 Description
    • 3 Terminology
    • 4 Security Management
    • 5 Cross-Cutting Requirements
    • 6 Standards
    • 7 Authorization Services
    • 8 Additional Security Modules
    • 9 Other Resources
  • Digital Sovereignty - Cloud Infrastructure
    • Abstract
    • Digital sovereign cloud technology
    • Digital Sovereignty considerations
    • Architectural graphics
  • GovStack UI/UX Guidelines
    • 1 Version History
    • 2 Description
    • 3 Service design good practice guidelines
      • 3.1 User-centred design
        • 3.1.1.1 Understand needs and requirements
        • 3.1.1.2 Involve others in the design process
        • 3.1.2.1 Test with users
        • 3.1.3.1 Share findings
        • 3.1.3.2 Monitor performance
          • 3.1.3.3 Set up analytics
      • 3.2 Accessibility and inclusion
        • 3.2.1.1 Test for accessibility
        • 3.2.2.1 Involve a diverse user group in the design
        • 3.2.2.2 Support multiple languages
        • 3.2.2.3 Foster a culture of inclusion
      • 3.3 Consistency
        • 3.3.1.1 Use simple language
        • 3.3.2.1 Implement a consistent style guide
        • 3.3.2.2 Use design patterns
        • 3.3.2.3 Use a frontend framework
        • 3.3.3.1 Interoperability
        • 3.3.3.2 Use integrations
        • 3.3.4.1 Work in the open
      • 3.4 Technology choices
        • 3.4.1.1 Choose the right level of security
        • 3.4.1.2 Design for privacy
        • 3.4.2.1 Optimise load times
        • 3.4.2.2 Account for connectivity issues
        • 3.4.3.1 Test across platforms
        • 3.4.3.2 Design cross-channel
    • 4 Design patterns
      • 4.1 Service patterns
      • 4.2 User flows
        • 4.2.1 Register
        • 4.2.2 Authenticate
        • 4.2.3 Asking users for feedback
        • 4.2.4 Find a service
        • 4.2.5 Check a users eligibility
        • 4.2.6 Make an application
      • 4.3 Page templates
        • 4.3.1 Feedback
        • 4.3.2 Perception survey
        • 4.3.3 Satisfaction
        • 4.3.4 Before you start
        • 4.3.5 Service sheet
        • 4.3.6 Asking users for consent
        • 4.3.7 Task list
        • 4.3.8 Asking users for information
        • 4.3.9 Check answers
        • 4.3.10 Outcome
    • 5 Use-case examples
    • 6 References
    • 7 Other Resources
  • Building Blocks
    • About Building Blocks
    • Consent
    • Digital Registries
    • E-Marketplace
    • E-Signature
    • Geographic Information System (GIS)
    • Identity
    • Information Mediation
    • Messaging
    • Payments
    • Registration
    • Scheduler
    • Workflow
  • Cloud Infrastructure
  • Use Cases
    • Reference Use Cases
  • Public Administration Ecosystem Reference Architecture (PAERA)
    • PAERA
  • Tools
    • Sandbox
  • Release Notes
    • 23Q4
Powered by GitBook

Apache-2.0 license

On this page
  • Involve diverse users in testing and feedback
  • Understand user capacity and identify barriers to access
  • Design for inclusivity
  • Consider non-digital alternatives
  • Consider Gender Equality and Social Inclusion (GESI)

Was this helpful?

  1. GovStack UI/UX Guidelines
  2. 3 Service design good practice guidelines
  3. 3.2 Accessibility and inclusion

3.2.2.1 Involve a diverse user group in the design

Previous3.2.1.1 Test for accessibilityNext3.2.2.2 Support multiple languages

Last updated 1 year ago

Was this helpful?

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.

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:

Inclusive Design Toolkit from Microsoft
GESI Qualitative Framework by Oxford Insights
Design Justice principles