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
  • Invitation for Feedback
  • Survey Form
  • Data you might collect
  • Potential Questions for User Survey
  • When to Use this Pattern
  • When Not to Use this Pattern

Was this helpful?

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

4.3.2 Perception survey

Was this helpful?

How it Works

Invitation for Feedback

Invite users to provide feedback about their overall experience with the service catalogue. This could be a dedicated page, a pop-up prompt, or an email sent after a certain period of usage.

Survey Form

Create a form to collect user perceptions about the entire service catalogue. Use a mix of open-ended questions and structured items (like ratings or multiple-choice questions) to gather comprehensive feedback.

Submit Button

Include a clear call-to-action button for submitting the survey. A label like "Submit survey" is straightforward and effective.

Success Confirmation

After users submit their survey responses, show a success message to confirm receipt. Something simple like "Thank you, your survey has been submitted" works well.

Data you might collect

In addition to feedback about specific services, consider collecting:

  • User ID: If the user is logged in, this can help provide context for the feedback.

  • Overall Satisfaction: Ask users to rate their overall satisfaction with the service catalogue.

  • Specific Services Used: Understanding which services a user has interacted with can provide context for their feedback.

  • Timestamp: Recording when the feedback was provided can help identify any time-related trends.

  • Suggestions for Improvement: Ask users what they think could improve their experience with the service catalogue.

Potential Questions for User Survey

To gain a deeper understanding of user experience with the government service catalogue, consider including these questions in your feedback form:

  • How did you find out about the government service catalogue? This can give insights into the effectiveness of your outreach and communication strategies.

  • Which services have you used? Knowing which specific services a user has interacted with can provide important context for their feedback.

  • How easy was it to find the services you needed? This can shed light on the effectiveness of your catalogue layout and search functionality.

  • How would you rate your overall experience with the services you used? This gives a high-level view of user satisfaction with your service offerings.

  • What improvements would you suggest for the services you used? This open-ended question allows users to provide specific feedback and suggestions for individual services.

  • What additional services or features would you like to see in the future? This can help guide your future development efforts based on user needs and wants.

When to Use this Pattern

This pattern is useful when you want to gather feedback on the overall service catalogue, rather than individual services or interactions. This can help identify strengths and weaknesses across your offerings and improve the user experience at the catalogue level.

When Not to Use this Pattern

Do not use this pattern as a substitute for gathering feedback on individual services or interactions. Users' experiences with specific services can be different from their overall impression of the service catalogue, so both types of feedback are valuable.

Wireframe showing feedback page