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
  • When not to use these patterns
  • Consent page
  • Why we ask to share this data
  • About the data
  • Confirm or reject
  • Implied consent
  • Handling data beyond the transaction
  • Managing consent
  • Delegated consent
  • Additional details for information collection

Was this helpful?

Export as PDF
  1. GovStack UI/UX Guidelines
  2. 4 Design patterns
  3. 4.3 Page templates

4.3.6 Asking users for consent

Use these patterns to give users control over how you manage their data. These patterns align with the GovStack Consent Building Block.

Was this helpful?

Related Building Block: .

How it works

Consent covers all activities done for the same reason. If you use the data for more than one reason, get separate consent for each. For example, accessing data to check eligibility is separate from accessing data to make an application.

Use these patterns when you need to:

  • To access a user’s data.

  • To store, manage or share a user’s data.

  • Allow users to manage the data you hold on them.

When not to use these patterns

You do not need to ask for consent when:

  • the data is required for a government to perform a specific task or function set out in law, you do not need to ask for consent. For example, terms and conditions — these are required so you do not need to ask for consent.

  • a person is simply informed of the processing of the data by the organisation as part of the service provided under contract or by an authority.

  • consent does not have to be obtained in a situation where the entity does not identify or cannot identify people with reasonable effort.

Consent page

This pattern allows users to accept or reject a request to access or share data for the use of a service. For example, asking to access data from social insurance records in order to check eligibility for another service.

User journey considerations:

  • Consent should be grouped by purpose meaning you may need multiple consent pages.

  • You may need to ask for consent at the start of a service or throughout the user journey.

  • You should test your service with users to find the journey that works for them.

Why we ask to share this data

Explain what data you are requesting and the benefit to the user for sharing that data. For example, “Provide your location data so that we can tailor offers relevant to you”.

About the data

Be clear about:

  • Why you need it and the benefit to the user.

  • How the data will be used and for how long.

Confirm or reject

If you are handling a simple data set, present the data you are collecting followed by a checkbox to explicitly confirm consent.

If you are handling multiple data sets allow the user to choose which data is shared.

Implied consent

If you do not need to ask for consent but you are handling user data this should be specified in the privacy statement.

[Add guidance on when that should be presented to the user]

Handling data beyond the transaction

Managing consent

[Give details for how to manage data if the user changes their mind.]

Delegated consent

In cases where the person giving consent is doing so on behalf of someone else, as a guardian or carer.

[This pattern is in the backlog]

Additional details for information collection

When asking users information during a questions flow consider using progressive disclosure drop-downs or inline content to explain why you are asking for that information and how you will handle the data.

You may need to offer users an opportunity to review and correct data using the .

If the service will be accessing or sharing user data on an ongoing basis then you need to give users a method of managing consent. .

See point 6 of the future considerations of the Consent Building Block
GovStack Consent Building Block
check your answers pattern
*Note that images can be expanded by clicking on them.
A wireframe of consent for a single data set
A wireframe of conesnt for multiple data sets
Consent given example implementation
Consent withheld example implementation
A wireframe of an example progressive disclosure details pattern