Amanda Galvao

Work

About

Home

Self-Service Portal

OneID Self-Service portal is a standalone portal designed to simplify how businesses manage their customers' identity verification completed through OneID.

The goal of this project was to create a self-service interface that allows customers to configure and manage verification flows without requiring them to deploy engineering support, reducing onboarding friction and enabling scalable product adoption for smaller businesses.

Company

OneID®

Role

UX/UI Designer

Timeline

Jun-Jul 2025

The Problem

Businesses integrating OneID need developer support to configure verification flows and access results. This creates a few challenges:

  1. Onboarding depend on customers' engineering availability, often rare for smaller businesses.

  2. Non-technical customers struggled to understand integration requirements.

  3. Support requests for OneID were increasing as adoption grew.

These limitations slowed down product adoption and created operational overhead.

Framing the Approach

To help smaller businesses adopt our solution without overwhelming our internal team with ticket load, I designed a self-service portal where businesses could send verification requests, manage results and receive an understandable, PDF-exportable result for audit trail.

Process

To define the product direction, I worked through a structured discovery and design process. Key activities included:

1

Analyse support requests and internal workflows

2

Define MVP features and its flows

3

Explore interface patterns

Research

Research revealed that most onboarding friction occurred during configuration. Customers struggled to understand:

  • What verification flows were available

  • How to configure them

  • What data they needed to provide

This suggested the portal should prioritise clarity and progressive configuration rather than complex settings upfront.

Research revealed that most onboarding friction occurred during configuration. Customers struggled to understand:

  • What verification flows were available

  • How to configure them

  • What data they needed to provide

This suggested the portal should prioritise clarity and progressive configuration rather than complex settings upfront.

Define

For a first release, the Product team and I decided to focus on Right to Work and Right to Rent checks. Both required the same verification method (document scanning) and were the use cases who most often requested a no-code solution.

The Head of Product and I collaborated to define what were the minimum needed features and MVP flows to launch and be able to test the proof of concept.

For a first release, the Product team and I decided to focus on Right to Work and Right to Rent checks. Both required the same verification method (document scanning) and were the use cases who most often requested a no-code solution.

The Head of Product and I collaborated to define what were the minimum needed features and MVP flows to launch and be able to test the proof of concept.

Configuration

Since MVP would be a proof of concept, we decided not to enable a configurable verification process but to start with Right to Work and Right to Rent solutions, both require the same verification method (document scanning). Those were also the use cases that most requested a no-code solution.

Scalable structure

The structure and interfaces needed to allow for multiple provider types in the future, as we knew some potential customers were interested in document scanning, bank checks and credit reference agencies silent checks.

Security

Since OneID is a Government-certified identity provider with several no-document, low-friction ID checks available, it made quickly verify new portal users' identity. After all, this portal would display extensive sensitive end-user data.

Design

With the user flows and MVP requirements defined, I now started to design what this Self Service Portal could look like. This was an initial UI intended for testing and stakeholder collaboration rather than a final handoff. Most elements were already in the design system I've created for OneID, with some minor improvements, new icons and tagging components.

As the product grew, cost and scale became much harder to ignore. By this point, weekly journeys had increased 300×, reaching around 800k per week, so even small inefficiencies in the model started to matter.

OneID delivered a great first-time experience, but every verification had a per-check cost. As users began returning more frequently, we were effectively paying again for something we had already verified. Meanwhile, competitors with app-based models accepted a clunkier first run, but benefited from near-instant, low-cost reuse after that.

That was the shift for me. Reuse couldn’t just be a UX improvement. We moved away from the “we don’t store anything” mindset and introduced OneID Accounts: a secure reuse, allowing users to save verified results and skip repeated checks, with encryption ensuring only they could unlock their data via a passkey.

It wasn’t only about speed. At this scale, reuse changed the economics of OneID.

Validate

I collaborated with Sales to run prototype walkthroughs with two customers who had previously asked for a self-service portal. While broader usability testing would have been ideal, priorities later shifted toward larger enterprise clients integrating via API. As a result, this phase focused on exploratory interviews with the two customers who were specifically interested in a no-code portal. Key feedback included:

As the product grew, cost and scale became much harder to ignore. By this point, weekly journeys had increased 300×, reaching around 800k per week, so even small inefficiencies in the model started to matter.

OneID delivered a great first-time experience, but every verification had a per-check cost. As users began returning more frequently, we were effectively paying again for something we had already verified. Meanwhile, competitors with app-based models accepted a clunkier first run, but benefited from near-instant, low-cost reuse after that.

That was the shift for me. Reuse couldn’t just be a UX improvement. We moved away from the “we don’t store anything” mindset and introduced OneID Accounts: a secure reuse, allowing users to save verified results and skip repeated checks, with encryption ensuring only they could unlock their data via a passkey.

It wasn’t only about speed. At this scale, reuse changed the economics of OneID.

Excel exports

  • While PDFs were considered useful, it was mentioned Excel files are easier fed into other platforms they may use.

Activity status

  • Every activity was marked as 'To-Do' vs 'Closed'. That was confusing for both customers, proving we needed to think further how this could behave making easy for teams to understand results that haven't been actioned yet.

Email notifications

  • One customer suggested email notifications sent to the user who requested the verification so they don't risk delaying any required actioned.

AI Refinement

At this stage, Figma had just launched Figma Make. I was looking forward to try it and this was a great opportunity to explore its capabilities.

First, I've asked Make to replicate my exact design and create the interactions.

On another file, I gave it a prompt including the same structure and guidelines, but no design. I wanted to see a different vision for the portal's UI, and listed what aspects of Figma Make's design made sense keep and what should be avoided:

As the product grew, cost and scale became much harder to ignore. By this point, weekly journeys had increased 300×, reaching around 800k per week, so even small inefficiencies in the model started to matter.

OneID delivered a great first-time experience, but every verification had a per-check cost. As users began returning more frequently, we were effectively paying again for something we had already verified. Meanwhile, competitors with app-based models accepted a clunkier first run, but benefited from near-instant, low-cost reuse after that.

That was the shift for me. Reuse couldn’t just be a UX improvement. We moved away from the “we don’t store anything” mindset and introduced OneID Accounts: a secure reuse, allowing users to save verified results and skip repeated checks, with encryption ensuring only they could unlock their data via a passkey.

It wasn’t only about speed. At this scale, reuse changed the economics of OneID.

Adopt

  • Dashboard scannable layout Overview>Action>Details

  • Activity filtering within the list frame, so it doesn't conflict with future new sections

  • Action is clearer displayed as text instead icon

  • Insert logo (configuration) format

Avoid

  • Dashboard was turned in a metric-first analytic tool, initial design was task-driven

  • Action update directly from the Activity list view can lead to user error

  • Identity Report was heavily simplified, skipping essential requirements

Check out the full prototype

Check out the full prototype

Open prototype

PoC Launch

To validate the portal concept, I built a full proof-of-concept prototype using Figma Make and shared it with internal teams.

The prototype allowed stakeholders to explore:

  • user management

  • verification management

  • home/dashboard

This helped align engineering, product, and commercial teams around the initial portal direction.

However, with a change in leadership in September 2025, OneID decided to focus on large enterprises and paused any effort directed to small business. While a self service portal is still on the pipeline, it's been de-prioritise for now. While its upsetting not see the portal live, growing and being iterated with user feedback and analysis, this gave us more space to review product running costs reviews and focus on scalability for large customers instead.

As the product grew, cost and scale became much harder to ignore. By this point, weekly journeys had increased 300×, reaching around 800k per week, so even small inefficiencies in the model started to matter.

OneID delivered a great first-time experience, but every verification had a per-check cost. As users began returning more frequently, we were effectively paying again for something we had already verified. Meanwhile, competitors with app-based models accepted a clunkier first run, but benefited from near-instant, low-cost reuse after that.

That was the shift for me. Reuse couldn’t just be a UX improvement. We moved away from the “we don’t store anything” mindset and introduced OneID Accounts: a secure reuse, allowing users to save verified results and skip repeated checks, with encryption ensuring only they could unlock their data via a passkey.

It wasn’t only about speed. At this scale, reuse changed the economics of OneID.

Impact

KPIs & Expected Impact

Reduced tickets

Reduced tickets

Customers should be able to manage verification flows independently.

Faster onboarding

Self-service configuration should reduce the time required to integrate OneID.


Self-service configuration should reduce the time required to integrate OneID.

Increased adoption

Lower integration barriers should enable more customers to start using the platform.


Lower integration barriers should enable more customers to start using the platform.

Operational scalability

The portal should allow the product team to support more customers without increasing manual support.

Reflection

To validate the portal concept, I built a full proof-of-concept prototype using Figma Make and shared it with internal teams.

The prototype allowed stakeholders to explore key areas of the experience, including user management, verification management, and the dashboard overview. This helped align engineering, product, and commercial teams around how a self-service portal could work in practice.

Shortly after this phase, a shift in company strategy led OneID to prioritise larger enterprise customers and API integrations. As a result, work on the small-business self-service portal was paused. While the concept remains part of the longer-term roadmap, it was deprioritised in favour of initiatives focused on scalability and enterprise adoption.

Even though the portal has not yet been launched, the prototype helped clarify the operational requirements for self-serve verification, align internal teams around a potential future product direction, and create a foundation that could be revisited if the small-business segment becomes a strategic priority again.

Get in touch

Email

a.galvao@outlook.com

Linkedin

linkedin.com/in/amanda-galv/

@2026 London

Next Project →