Designing a lifecycle-based identity & risk platform

Product Design | UX | UI
FrankieOne’s Portal evolved from a system built around a single onboarding and monitoring workflow into a platform supporting multiple workflows across identity verification, fraud, and transaction monitoring.

This introduced a fundamental challenge:

‍How do you represent the status of an entity when multiple workflows run independently, at different times, and produce conflicting outcomes?
Role: Product Design Lead
Team: Cross-squads

The problem

The issue first surfaced during some testing in preparation for a customer’s testing account.
An implementations team member flagged what looked like a bug — an entity showing “Passed” despite having an earlier workflow marked “Needs Attention”.

It wasn’t a bug. It was a consequence of how the system had been designed.

The original system assumed that each entity would have:

  • One onboarding workflow
  • One monitoring workflow
Entity status was simply the outcome of the latest workflow, and it was always assumed that monitoring would never run until onboarding was completely resolved.

As the platform evolved, customers began running multiple workflows per entity — for example:

  • Initial onboarding checks
  • Additional “step-up” verification flow
  • Monitoring workflows running parallel to standard workflows
However, the Portal continued to treat “entity status” as the result of the most recently run workflow, regardless of whether an earlier one was resolved.
This created a critical issue:
If an earlier workflow flagged “Needs Attention” and a later workflow returned “Passed”, the entity would appear as “Passed” in the main entities table.
‍
High-risk entities could be silently hidden. This broke the operator’s core question:“Is this entity safe, rejected, or does it need my attention?”

Insight

The problem was not just UI — it was a mismatch between system design and operator mental models.
Operators do not think in terms of workflows. They think in terms of:
  • Overall risk
  • Priority
  • What needs action
The system needed to shift from:
Workflow outputs → Entity-level risk

The system shift

We redefined “entity status” as a roll-up of all workflow outcomes, rather than the latest workflow result.
This required:
  • Aggregating multiple workflow states into a single, reliable signal
  • Introducing severity-based prioritisation
  • Separating onboarding workflows from monitoring behaviour
  • Making risk transparent without overwhelming the operator

Key design decisions

Roll-up logic for entity status

We introduced a severity hierarchy across workflow outcomes:
Needs Attention → Failed →
In Progress → Unchecked → Passed
Entity status is determined by the highest severity present across all workflows.
This ensures that risk is never hidden by subsequent “passed” results.

Separating onboarding and monitoring

Monitoring behaves fundamentally differently from onboarding.
  • Onboarding is a point-in-time check.
  • Monitoring is an ongoing event listener.
Treating them the same led to misleading states (e.g. “unchecked” despite active monitoring).

We redefined monitoring across two dimensions:
  • Coverage — is monitoring active?
  • Alerts — has risk been detected?

Making risk legible (progressive disclosure)

We surfaced a clear, aggregated entity status at the table level, while allowing operators to drill into workflow-level detail when needed.
  • Clarity at a glance
  • Transparency on demand

Reframing “entity status”

“Entity status” was being used as a label in the portal to represent Entity state (active, archived, etc.)
Operators considered "Entity status" to mean risk status (eg. Needs attention, Failed, Passed).
Instead, this risk status was represented by the label "Latest workflow status".
We separated and renamed these to align with operator expectations:
  • Entity status = Risk status (eg. Needs attention, Failed, Passed), higher priority
  • Entity state = State of the entity (eg. active, archived etc), lower priority

The redesigned system

To make the system change tangible, I built a rapid prototype simulating the new status model and workflow behaviour.
Using AI-assisted tools, I generated a working version of the redesigned Portal in a few hours.
This allowed me to:
  • Walk the team through the system shift
  • Validate assumptions early
  • Surface edge cases before implementation
The redesign reframed the Portal from workflow-centric outputs to a system-level view of risk.

Key changes

Entity status as a system-level signal

  • Onboarding is a point-in-time check.
  • Monitoring is an ongoing event listener.
Risk is visible immediately, without losing detail

Aligning language with operator mental models

  • Replaced “latest workflow status” with “Entity status”
  • Renamed system states (active, archived, etc.) to “Entity state”
Clear distinction between system state and risk

Separating monitoring from onboarding

  • Represented monitoring with coverage states (active, partial, inactive)
  • Introduced a dedicated monitoring view by category
Monitoring is understood as continuous, not a one-time check

Supporting flexible workflows at scale

  • Enabled visibility across multiple workflows per entity
  • Added table-level controls (e.g. column filtering)
Scales with customer complexity without breaking usability

Outcome

This work shifted the Portal from a workflow-driven interface into a system capable of handling real-world operational complexity, backing our core principle for an entity-first view.
  • Eliminated a critical risk where flagged entities could be hidden
  • Provided operators with a clear, reliable view of entity risk
  • Enabled support for multiple workflows without breaking usability
  • Established a scalable model for lifecycle-based identity and risk management