LogoLogo
Give FeedbackGovStack Home
25Q2
25Q2
  • 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 UX 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
  • 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
    • Cloud Infrastructure
    • Consent
    • Digital Registries
    • E-Marketplace
    • E-Signature
    • Geographic Information System (GIS)
    • Identity
    • Information Mediation
    • Messaging
    • Payments
    • Registration
    • Scheduler
    • Workflow
    • Wallet
  • 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
  • How it works
  • Service information sheet
  • A series of simple eligibility questions
  • Automatically check if a user is eligible
  • An outcome page
  • When to use this pattern

Was this helpful?

Export as PDF
  1. GovStack UI/UX Guidelines
  2. 4 Design patterns
  3. 4.2 User flows

4.2.5 Check a users eligibility

Use this pattern to help users check if they qualify for your service saving them time registering for a service they would not qualify for and redirecting them where possible.

Was this helpful?

How it works

To use this pattern you need to have:

  • A service information sheet

  • A series of simple eligibility questions

  • An understanding of what existing data you can integrate with

Service information sheet

Have a web page for your service where people can find the required information about the service. Such as requirements to access the service, actions and steps they need to start using your service. Check an example of a service information sheet.

Ensure to include general rules and information about whether the service can be used such as age limit.

A series of simple eligibility questions

Present the user with a series of simple questions that can determine their eligibility. Use questions when the eligibility criteria for the service is complex and require detailed information to determine if a user qualifies.

Ask the user to provide information such as their age, location, employment status, income level, or other relevant details to your service. Follow the question page pattern.

Automatically check if a user is eligible

the system should automatically process the information provided and determine whether the user is eligible to access the feature or service.

An outcome page

  • Eligibility outcome that clearly states whether the user is eligible or ineligible to access the service or feature.

  • Reason for eligibility determination such as a clear explanation if the user is found to be ineligible. This can include information such as incomplete or incorrect information provided in the form, not meeting certain age or income requirements, or other criteria.

  • Next steps depending on the outcome of the eligibility check. For example, if the user is found to be eligible, direct them to the next step which may be to register for the service. If they are found to be ineligible, direct them to another service or further guidance.

Here are some elements that can be included on the outcome page:

Present an outcome page to users to let them know the result of their eligibility check. The outcome page should provide a clear and concise summary of the user's eligibility status. If eligible, you should let the user know of the next steps to access the service. If the user is not eligible, let them know why and what they should do instead.

  • Eligibility outcome that clearly states whether the user is eligible or ineligible to access the service or feature.

  • Reason for eligibility determination such as a clear explanation if the user is found to be ineligible. This can include information such as incomplete or incorrect information provided in the form, not meeting certain age or income requirements, or other criteria.

  • Next steps depending on the outcome of the eligibility check. For example, if the user is found to be eligible, direct them to the next step which may be to register for the service. If they are found to be ineligible, direct them to another service or further guidance.

When to use this pattern

Services where eligibility criteria can be complex and may vary depending on the specific service or feature being accessed. By using the "check eligibility" pattern, users can quickly and easily determine whether they qualify for a particular service, without having to go through a lengthy application process or wait for manual approval.

Asking for eligibility flow diagram