Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Get started using design patterns
: use the to understand the key interactions in your service.
Map the user journey: Break down the user journey into phases like registration, information collection, appointments, feedback, and messaging. Identify the steps users take in each flow. .
Choose user flows: Identify the patterns (task-focused page types) needed for each part of your user journey.
Users
• Architect
Steps
Apply
Find the service > Register or authenticate > Submit application (including answering questions and uploading documents) > Receive the outcome of a decision >
If outcome is successful
Get notification for payment > Make payment > Give feedback
Patterns
Steps
Find through taxonomy
Service catalogue/homepage > Topic page > Service sheet > Service
Search for service
Service catalogue/homepage > Results page > Service sheet > Service Through search engine
Search engine > Service sheet > Service
Patterns
Service catalogue Service sheet Search results
Use this pattern to help users provide their personal and relevant information to create an account or profile in a system, platform or service.
Registration is useful when you need to give each user a unique identifier in a system or collect their information in one place. This allows users to access, apply for, or meet the requirements for a particular service.
Once a user has been registered, users can log in to their account using their chosen credentials to:
continue using the service,
apply for additional services,
see the services they have used in one place,
update their information, or
modify their account settings
Steps
Register to a create an account in a system
Service page > register > get notified of status
Registered user sign-in to access service
Sign-in > access service
Registered user sign-in to apply for service
Sign-in > eligibility check (if needed) > apply for service > feedback
Patterns
Use case example
Steps
From a service catalogue
Service catalogue pages > Perception survey
During a service
Service page > Feedback At the end point of a service
End page > Satisfaction page
Patterns
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.
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.
Creating and managing user accounts requires a significant amount of effort from both the user and the service provider. For the user, it's another set of credentials to remember. For the service provider, it's a matter of securely storing and managing that user data.
There are many situations where a service can be designed in such a way that a full account isn't necessary. Consider these alternatives:
One-Time GUID Links: If you need to provide users with a way to return to a specific state in a service (like a partially completed form), consider using one-time GUID (Globally Unique Identifier) links. These can be generated and provided to the user, allowing them to return to their session without needing an account.
Token-based Authentication: For some services, you can use token-based authentication. This could involve sending the user a unique token via email or SMS that they can use to access the service.
Third-Party Authentication: For services that require authentication, consider using third-party authentication services (like Google, Facebook, or Twitter login). This can make things easier for users, as they can use an existing account instead of creating a new one. However, be mindful of the potential privacy implications.
Guest Checkout: For e-commerce situations, consider offering a guest checkout option. This allows users to make a purchase without creating an account.
In all cases, the goal should be to make the user's interaction with the service as easy and smooth as possible, while still maintaining appropriate levels of security and privacy.
Steps
Log in with credentials
Login page > A: Service continues / B: Not authorised page
Log in through provider
Login page > Provider journey > A: Service continues / B: Not authorised page
Reset credentials
Log in page > Reset password > Send reset link > Reset password > Success
Patterns
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Session ID: If your system uses session IDs, collecting this can help you associate the feedback with a particular user session.
Suggestions for Improvement: Ask users what they think could improve their experience with the service catalogue.
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.
Steps
Task list > Question flow > Evidence (if required) > Check you answers > Outcome
Patterns
Uploading documents
Steps
If you need users to check eligibility before applying
Put eligibility screening questions up front
Summary of requirements > Eligibility questions > Upload evidence (if needed) > Check your answers > Outcome
If not eligible
Allows users to fail fast
Patterns
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.
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.
A series of simple eligibility questions
An understanding of what existing data you can integrate with
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.
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.
the system should automatically process the information provided and determine whether the user is eligible to access the feature or service.
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.
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.
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: .
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 may need to offer users an opportunity to review and correct data using the .
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.
