Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Use this pattern to help users check if they are ready to start a service.
This helps people understand what your service does and whether they need to use it.
A list of things most users need to know: for example, what your service is, what will happen, what users will get or how much it'll cost. To keep the content concise, do not include details about anything that would be obvious to users.
There should be a clear call to action button to start the service, usually “Start now”. You should also include a link to “sign in” or “continue journey” if the user is able to continue an existing journey.
You should provide ways for people who can’t access the service online to get support, for example, by phone or text relay. You may also include details for support channels.
At the start of a service which involves the user inputting information in order to get something. For example, at the start of an application form.
At the end point of the user journey, prompt users to rate their experience. This should be a simple rating scale (1-5) or a binary satisfied/dissatisfied question.
Following the rating, provide a text field for users to share more details about their experience. Prompt users with an open-ended question like, "How could we improve your experience?"
Include a clear 'submit' button to finalise their feedback.
Display a success message after submission, thanking them for their feedback.
User Satisfaction Score: The user's response to the satisfaction rating question.
Feedback Text: The user's response to the open-ended feedback question.
Page URL: The URL of the page from which the feedback was submitted.
Session ID: Identifies the particular user session, for associating feedback with specific user journeys.
Consider adding questions to your satisfaction survey to gain deeper insights:
Did you accomplish what you intended to do in this session? Helps understand if the user journey was effective and efficient
Use this pattern at the end of a user journey to collect valuable feedback about user experiences. Be aware that user satisfaction is biased to users that reach an end-point of a service.
Use these patterns to give users control over how you manage their data. These patterns align with the GovStack Consent Building Block.
Related Building Block: GovStack Consent Building Block.
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.
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.
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.
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”.
Be clear about:
Why you need it and the benefit to the user.
How the data will be used and for how long.
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.
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]
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.
[Give details for how to manage data if the user changes their mind.]
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]
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.
In long complex forms and transactions that involve multiple steps and pages, help users understand the list of tasks involved and their progress as they move from one question to the next.
Use clear labels for each step and provide a visual indicator of their progress. Show the order in which the steps should be completed and mark completed tasks.
Group similar tasks together and use clear headings to explain what is involved or is needed to complete the task.
As users complete each step or task, show a label that describes their progress.
Use visual and written labels to indicate their progress. Avoid relying solely on visual indicators like progress bars or percentages, as they may pose accessibility challenges. Include a text display of progress as well.
Maintain a sense of hierarchy: If there is a specific order in which the steps should be completed, make it evident to the users. You can indicate the hierarchy by organising steps in a logical sequence or visually nesting them within each other.
If the form or transaction is long, provide a save feature that allows users to pause and continue later. When users resume the transaction, display the task list page as the first thing they see.
In a complex long form that involves multiple tasks, steps or pages.
Use this pattern to gather information from users using your service.
Clearly state why you need the information and how it will be used. For instance, you might need users' information so that you can provide a service, register them for a service, or tailor an experience to meet their needs.
Consider whether you need to ask for the information or whether you can use integrations to get that data from internal or external sources. Check whether you need to ask for to ask the questions.
You can use a to help you figure out what you need to ask. If you ask people for optional information, add ‘(optional)’ to the question. Do not mark mandatory questions with asterisks as these are not accessible.
Backlink
A question page should have a backlink to help users who may want to go back to the previous question to make any changes.
Question or question heading
When asking people for information, ask for one thing at a time. Helps users focus on one specific thing at a time and provide its answers without overwhelming them with too many demands at once.
This can be one question per page or group-related questions together, for example, contact details. Grouping related questions together can help users understand the context of each question and make it easier to provide accurate responses. When you group related questions together, you will have a ‘question heading’ that will help people understand what is needed for the set of questions.
Hint text
Provide clear instructions to help users understand what is expected of them on each question.
Question field
Use the appropriate question field for the different question types.
Other ways to provide information
Always provide other alternative mechanisms for users to identify themselves or provide their information so that they can access your service. Provide clear instructions on what to do if they encounter any problems.
This page focuses the user's attention on what they need to complete the service in one go. You might list the documents or evidence required or emphasise certain eligibility criteria (e.g., age).
When there is a risk that there is more information on a start page than users are likely to read you can break the 'before you start' information onto its own page.
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.
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.
Include a clear call-to-action button for submitting the survey. A label like "Submit survey" is straightforward and effective.
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.
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.
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.
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.
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.
You may need to offer users an opportunity to review and correct data using the .
Use this page to provide users with confirmation that they have successfully completed their intended task. It helps users know that their actions have been successfully processed.
Outcome page
How it Works
On this page include:
Details on what will happen next.
Contact details to provide users with further support.
Use this pattern to help users check, review and confirm their entered information before taking a significant final action, such as submitting.
By allowing users to review, make changes, or confirm their answers, this pattern helps prevent errors in data submission.
The long term benefits of this pattern are:
users will be confident while using your service as they can visually confirm that all their information has been accurately captured.
reducing incorrect and incomplete information will result in lower error rates in applications.
Use this pattern when you need to capture information from users on a form that spans multiple pages or steps.
Use a clear heading that clearly communicates the purpose of the page, such as "Check your answers before sending your application"
Show the summary of questions and answers given. Ensure the information is organised and easy to scan.
Consider the type of answers expected from users. For longer answers, utilize a full-width layout to accommodate the content. For shorter answers, a two-thirds layout may be appropriate to optimise space.
Break content into sections if needed. If there is a large number of questions or if it improves the clarity, divide the content into relevant sections.
Clearly indicate when a question has not been answered because it was optional. Make it evident to the user that the answer was not provided.
Provide navigation to edit answers. Offer users a straightforward way to navigate back to previous steps and edit their answers if needed. This can be achieved through direct links or buttons that allow users to easily access and modify specific questions.
Include a call to action button at the bottom of the page that helps the user take the final action such as submitting their application.
Throughout your service journey, prompt users to provide feedback.
This could be a dedicated page that opens in a new tab or a modal within the page. Provide a simple text area where users can input their thoughts and experiences. The prompt should be open-ended, such as "Tell us about your experience" or "How can we improve this page?"
Include a clear call to action button for submitting feedback. "Submit feedback" is an effective, straightforward choice.
After users submit their feedback, display a success message to let them know it was received successfully. This can be a simple statement like "Thank you, your feedback has been submitted."
Page URL: This shows the specific page where the user submitted feedback, giving you context about what their comments may be referring to.
Referrer URL: This indicates the page the user visited before the current one, which could be useful for understanding the user's journey.
Device Information: This includes data like the user's operating system, browser type, and screen resolution, which can be helpful for troubleshooting technical issues.
Timestamp: Recording the time and date of the feedback can help identify issues that occur at specific times.
Session ID: If your system uses session IDs, collecting this can help you associate the feedback with a particular user session.
You should aim to collect feedback whenever possible, it can be helpful in identifying issues or areas for improvement from the user's perspective.
At the end points of the user journey, you should use the satisfaction pattern.
Feedback
Perception survey
Satisfaction
Before you start
Service sheet
Asking users for consent
Task list
Asking users for information
Outcome
