Considerations for choosing different patterns

Step-by-step guide to help you pick the right patterns for 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. Consider the technology choices available to you.

• Choose user flows: Identify the patterns (task-focused page types) needed for each part of your user journey.

• Select page templates: User flow patterns often include several page templates. Start with existing patterns for user flows. For unique requirements, you may need to mix and match individual templates.

User flows

How it works

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

Example service patterns

Apply for a construction permit

How it works

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 to use this pattern

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.

Make a simple application

Make a long application

When not to use this pattern

A principle of good user design is reducing friction and making processes as seamless as possible for the user. One way to do this is by avoiding the need for user accounts where possible.

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.

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.

How it Works

Prompt for Feedback

Throughout your service journey, prompt users to provide feedback.

Feedback Form

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?"

Submit Button

Include a clear call to action button for submitting feedback. "Submit feedback" is an effective, straightforward choice.

Success Confirmation

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."

Data you might collect

• 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.

When to use this pattern

You should aim to collect feedback whenever possible, it can be helpful in identifying issues or areas for improvement from the user's perspective.

When not to use this pattern

At the end points of the user journey, you should use the satisfaction pattern.

How it Works

Satisfaction Survey

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.

Open-ended Feedback

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?"

Submit Button

Include a clear 'submit' button to finalise their feedback.

Success Message

Display a success message after submission, thanking them for their feedback.

Data you might Collect

• 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.

Potential Questions for User Survey

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

When to use this pattern

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.