Get a credential

Help the user understand what the credential is, what it can be used for, and that they are responsible for keeping it.

Use this pattern when a service:

  • currently issues certificates, letters, or documents

  • creates proof that will be needed again (by this or other services)

  • completes a decision that confers rights or access

Steps

spinner

1. Understand the credential

The service explains what the credential is, what it can be used for, that the user is responsible for keeping it, and whether it can be reused for other services.

Clearly state who keeps the credential and what happens if it is lost or expires.

2. Confirm eligibility to receive the credential

This pattern assumes eligibility decisions have already been made in the service, if this is not the case, you may need to check a user's eligibility to get the credential.

Use the check eligibility pattern.

If a user is renewing a credential, you may need to match them to existing records before they can continue.

Use the matching step where needed.

3. Choose how the credential will be provided

The service should present available ways for the user to receive the credential and support them to choose one.

The user should be able to understand

  • the available routes (for example: digital wallet, paper, assisted)

  • what each route means in practice (deadlines, costs)

  • how long each route takes

  • whether it can be reused later

  • what happens if they lose it

Use single or multiple-choice questions.

4. Receive the credential

The credential is issued and made available via the chosen route. The service confirms successful issuance and provides the user with a usable representation or reference.

You should provide at least one credential representation and an alternative route. A credential representation is a user-facing way to access or present a credential (e.g., wallet entry, QR code, reference number, printable proof, physical document).

What the user may receive (one or more):

  • Added to wallet: the user is prompted to add/accept the credential in their wallet (or the service confirms it has been sent there)

  • QR code: a scannable code that allows the user to add/import the credential into a wallet

  • Reference number: a code the user can use later to retrieve or prove the credential through a service or assisted channel

  • Printable proof: a PDF or print view the user can download or print

  • Physical document: confirmation that a letter/card will be sent or is available for collection. Always indicate if this physical document should be kept by the user or is it merely a piece of information.

5. Understand what happens next

The service confirms the credential has been issued and explains what the user should do next using the outcome step.

The service should clearly show:

  • Who issued the credential

  • What the credential proves, in plain language

  • How long it is valid for, or when it expires (if applicable)

  • What the user can do now (use it, store it, present it later)

  • What happens if delivery fails (retry, alternative route, support)

  • What happens if credential is lost (esp. if it’s in physical form)

Use notification step if you need to communicate tousers about their credential issuance, delivery or collection.


Considerations

  • Do not assume the user has a wallet or smartphone

  • Introduce wallets in terms of benefit, not technology

  • Non-digital routes must provide an equivalent outcome

  • Services should not assume users understand that credentials are kept by them and can be reused. Patterns should explicitly support explaining ownership, reuse, and what happens if a credential is lost or expires.

Last updated

Was this helpful?