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.

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

Make a simple application

Make a long application

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.