UX Best Practices

As digital IDs gain adoption, organizations must design verification experiences that integrate emerging digital ID methods alongside existing IDV options. The goal is to enhance the experience for users who already have a digital ID, without disrupting those who rely on traditional verification. At Trinsic, we’ve helped customers launch these journeys, and this document summarizes the key UX lessons we’ve learned.

The first step in the verification process of a digital ID is selection. This is the critical point where users select the verification option to proceed with usually from a list of options surfaced in a few different ways.

Where Digital IDs Fit in the Flow

Digital IDs should typically be surfaced at the same decision point as document verification, not as a separate fork. We recommend introducing digital ID options on the “Choose verification method” screen, alongside “Scan government ID,” rather than earlier in the process.

Our Recommendations

  1. Don’t overwhelm people with choices. More providers doesn’t mean better UX. In practice, showing 2–3 good options converts much better than sharing a long list on the screen.
  2. Geography is the key input. Nearly all digital ID availability is location-dependent. The best experiences derive geography from signals you already have (phone number, IP, onboarding country) rather than forcing the user to choose upfront.
  3. Prioritize and filter based on relevance. Put the most likely option first and remove what doesn’t apply. If you already know the user’s device, geography, or prior selections, use that to surface the best method upfront. Don’t make users hunt, and don’t show options they can’t use.
  4. Always give people a fallback. Not everyone has a digital ID. Make sure there’s always a clear “Scan government ID” or upload path so users don’t hit a dead end.
  5. Build trust with correct branding. Always follow provider brand guidelines for logos, names, and icon usage. Familiar, official branding increases completion and reduces hesitation.
  6. Make it easy to go back. Users will sometimes pick the wrong provider, out of curiosity or because they think they have a digital ID and realize they don’t. Every flow should include a clear way to return to provider selection and choose a different option. Without this, users often drop instead of retrying.
  7. Monitor time-to-completion. Completion times as a primary KPI alongside conversion rates are great metrics for telling the story around digital IDs.

Most Common Implementation Patterns

Successful deployments fall into one of three approaches. Which one works best depends on how much you know about the user upfront, how many providers you plan to support at launch, and how your existing UX is structured.

1. Programmatic Orchestration (Recommended)

This is the cleanest option in most multi-provider environments. Instead of asking the user to pick from a long list, call Trinsic’s Recommendation API and we return the providers that actually make sense for that person on a per session basis.

How it works: You pass signals you already have; things like country/state, phone number, IP-derived location, or returning user context. The API returns providers grouped into:

  • Relevant: providers that Trinsic recommends based on location, sorted by adoption
  • Remainder: everything else, usually hidden behind “Show more” or search

We also recommend you provide progressive disclosure with "More options" for edge cases as an alternative where the recommendation may be incorrect.

💡

The goal here is simple: show the shortest list that covers most users, and keep the long tail out of the main UI. View a demo here.

2. Geography-First Selection (Country Picker)

A country picker works well when geography is the main driver of provider availability, especially if your flow already has a country selection step. This is common in global products where users expect to start with “where are you located?” before anything else. This can be combined with the programmatic orchestration model and offered as a fallback if the auto-detection fails to surface the correct providers for the user.

An important note: avoid hard-locking users into a region. Users may be traveling, using VPNs, or have mismatched signals (e.g. California resident abroad). Always allow an override or “Search for another country/provider.”

How it works: The user selects their country, you show the providers available there, and the chosen provider launches a Provider Session. You can also pre-fill country using IP or onboarding data, with an override if needed.

💡

Don’t show providers that don’t apply, and always keep a physical ID fallback available if no digital option fits.

3. Manual Button Selection

This is the simplest model: a fixed list of buttons. It works best when you only support a small number of geographies or if it's required for compliance-driven flows where only specific providers are allowed for a given market. We do not recommend this approach as a starting point since it is hard to scale when you want to add more geographies.

💡

If you do use this option, keep the list short, order it by expected usage, and include a clear fallback. Static lists get messy fast if they aren’t tightly scoped.

What to Avoid

It’s tempting to separate physical and digital ID verification flows early in the process, but we don’t recommend this approach. While digital IDs are widely adopted in some countries, not everyone has one. Instead of creating a bifurcated journey, digital IDs should be integrated seamlessly into your existing physical document verification flow.

When users are asked upfront to choose between “physical” and “digital,” many will select digital out of curiosity or assumption, only to become confused if they don’t actually have a digital ID. This pattern often leads to unnecessary friction and abandonment.

The following patterns consistently create suboptimal user experiences:

  • Showing every provider to every user
  • Trapping users in a provider journey without a clear way back
  • Asking for the same information twice
  • Letting static provider lists grow without user selection logic or programmatic orchestration

Selecting the Right Approach

The decision comes down to three questions:

  1. What signals do you already have about the user?
  2. How many providers need to be surfaced at once?
  3. Are you optimizing primarily for implementation simplicity or long-term conversion performance?

In most multi-region or multi-provider environments, some form of filtering (orchestration or geography-first) will perform materially better than static button lists.

Next Step: Launching the Provider Session

Once the user selects a provider, the next step is launching the Provider Session and handing off into that provider’s verification journey.

For implementation details, see our API Reference.