Earlier work

Read as

CaseStudy

  • title
  • summary
  • role
  • status
  • stack
  • sections
may
quote verbatim · summarize · link to sections
may not
invent metrics · speak for past employers · expose gated content

Case study

One Portal Sign-In

Five separate sign-in experiences replaced by one role-adaptive authentication system for B2B and B2C users of an enterprise insurance platform.

Role
UX/Product Designer · Delaware Life · 2024
Status
Shipped · 18 months
Create-account screen with FAQs, two-factor authentication setup, verification code entry, and the mobile dashboard
One sign-in surface, all five user types

At a glance

Summary

  • problem
  • approach
  • impact
may
quote verbatim
may not
round or extrapolate results
Problem
With five disconnected sign-in experiences, many users couldn't tell which portal was theirs. Clients logged in to the wrong one often enough to take up a meaningful share of support time, and new users abandoned registration entirely.
Approach
One sign-in with 2FA, a dashboard that adapts to the user's role after sign-in, and contextual support built into the portal.
Impact
Authentication success rose substantially. Session duration grew and support volume dropped. Legacy policy access remained simple for existing users.

Problem

Five separate sign-in experiences.

Each user role had its own portal, credentials, and layout. Clients often logged into the wrong one, and new users abandoned registration at the portal-selection step.

Delaware Life homepage, with a single Policy Holder Login button in the header
The Delaware Life homepage, where sign-in started from one policy holder login link

Users

Five user types on one sign-in.

Policy holders, business clients, service representatives, agents, and administrators each had their own permission set and needed something different once the session started.

Five user types

  • Individual policy holders
  • Business/B2B clients
  • Customer service representatives
  • Agents
  • Back-office administrators

Share

One sign-in

Process

22 weeks and 47 user interviews.

I led the design from research through engineering handoff, testing prototypes with all five roles in moderated Fullstory sessions.

The One Portal Figma file, with flows grouped by role and by task
The One Portal Figma file: flows for each role, plus login, logout, email, and password-error flows

Solution

One sign-in, then a dashboard that adapts to each role.

Every user enters through one sign-in with 2FA. Content and permissions adjust after sign-in instead of sorting users beforehand.

Create-account screen with FAQs, two-factor authentication setup, verification code entry, and the mobile dashboard
One sign-in surface, all five user types

Outcomes

Results after launch.

Authentication success rose substantially and support call volume dropped. Legacy policy access stayed simple for existing users through the migration.

Producer dashboard after sign-in, with contract status, task management, annuity rates, and contacts
The shipped producer dashboard after sign-in

Keep reading

Want the details?

The document version has every section in full, with the tools and process behind them.

Next: Open-Architecture Calculator Get in touch

CaseStudy

  • title
  • summary
  • role
  • status
  • stack
  • sections
may
quote verbatim · summarize · link to sections
may not
invent metrics · speak for past employers · expose gated content

One Portal Sign-In

Five separate sign-in experiences replaced by one role-adaptive authentication system for B2B and B2C users of an enterprise insurance platform.

Summary

  • problem
  • approach
  • impact
may
quote verbatim
may not
round or extrapolate results

At a glance

Problem
With five disconnected sign-in experiences, many users couldn't tell which portal was theirs. Clients logged in to the wrong one often enough to take up a meaningful share of support time, and new users abandoned registration entirely.
Approach
One sign-in with 2FA, a dashboard that adapts to the user's role after sign-in, and contextual support built into the portal.
Impact
Authentication success rose substantially. Session duration grew and support volume dropped. Legacy policy access remained simple for existing users.

Problem

Five separate sign-in experiences.

  1. Cognitive overload

    Multiple credentials per role, inconsistent interfaces, no single mental model.

  2. Wrong-portal logins

    A meaningful share of clients logged into the wrong portal every month, taking up a substantial share of support capacity.

  3. Abandonment

    New users abandoned registration entirely on the portal-selection step.

Delaware Life homepage, with a single Policy Holder Login button in the header
The Delaware Life homepage, where sign-in started from one policy holder login link

The organization operated five disconnected sign-in experiences across B2B and B2C touchpoints. Each user role had its own portal, credentials, and layout, so users struggled before they ever reached the product.

Users

Five user types on one sign-in.

Five user types

  • Individual policy holders
  • Business/B2B clients
  • Customer service representatives
  • Agents
  • Back-office administrators

Share

One sign-in

Each user type had its own permission set and needed something different as soon as the session started.

Process

22 weeks and 47 user interviews.

22 weeks

  1. Research6 weeks
  2. Information architecture4 weeks
  3. Visual design5 weeks
  4. User testing4 weeks
  5. Implementation3 weeks

Research included 47 user interviews across all five roles.

The One Portal Figma file, with flows grouped by role and by task
The One Portal Figma file: flows for each role, plus login, logout, email, and password-error flows

I led the design from start to finish: research, information architecture, visual design system, user testing, and engineering handoff.

  • research ecosystem mapping; 2FA integration specs.
  • information architecture journey mapping and flow work to find clear entry and exit points.
  • visual design a design system and high-fidelity prototypes for each role.
  • user testing moderated Fullstory sessions across all five roles with iterative refinement.
  • implementation spec docs, design reviews, and QA testing while engineering built it.

Solution

One sign-in, then a dashboard that adapts to each role.

  1. Single smart sign-in

    One entry point for every user, with 2FA.

  2. Role-adaptive dashboard

    Content and permissions adjust to the user after sign-in instead of sorting them beforehand.

  3. Contextual support

    In-portal help surfaced based on the current task.

  4. Unified business view

    Policy portfolio visibility with state-level filtering for multi-state operators.

Create-account screen with FAQs, two-factor authentication setup, verification code entry, and the mobile dashboard
One sign-in surface, all five user types
Sign-up role selection: financial professional or policy holder, then producer, assistant, or back office
Role selection during sign-up, which decides what each person sees after sign-in

Outcomes

Results after launch.

  1. Authentication success

    Rose substantially after the unification.

  2. Longer sessions

    Users stopped bouncing between the wrong portals.

  3. Less support

    Call volume dropped meaningfully, helped by contextual help and fewer wrong-portal logins.

  4. More feature use

    Grew across roles as the dashboard showed users features they hadn't known they had.

  5. Simple legacy access

    Existing users kept simple policy access through the migration.

Producer dashboard after sign-in, with contract status, task management, annuity rates, and contacts
The shipped producer dashboard after sign-in
Earlier work
View the full record for this page
{
  "@type": "CaseStudy",
  "id": "04.1 / one-portal",
  "title": "One Portal Sign-In",
  "summary": "Five separate sign-in experiences replaced by one role-adaptive authentication system for B2B and B2C users of an enterprise insurance platform.",
  "role": "UX/Product Designer · Delaware Life · 2024",
  "status": "Shipped · 18 months",
  "stack": [
    "User research (47 interviews)",
    "Fullstory user testing",
    "Information architecture",
    "Adaptive UX",
    "2FA / SSO design",
    "Figma"
  ],
  "tldr": {
    "problem": "With five disconnected sign-in experiences, many users couldn't tell which portal was theirs. Clients logged in to the wrong one often enough to take up a meaningful share of support time, and new users abandoned registration entirely.",
    "solution": "One sign-in with 2FA, a dashboard that adapts to the user's role after sign-in, and contextual support built into the portal.",
    "impact": "Authentication success rose substantially. Session duration grew and support volume dropped. Legacy policy access remained simple for existing users."
  },
  "sections": [
    {
      "label": "Problem",
      "title": "Five separate sign-in experiences.",
      "anchor": "#problem"
    },
    {
      "label": "Users",
      "title": "Five user types on one sign-in.",
      "anchor": "#users"
    },
    {
      "label": "Process",
      "title": "22 weeks and 47 user interviews.",
      "anchor": "#process"
    },
    {
      "label": "Solution",
      "title": "One sign-in, then a dashboard that adapts to each role.",
      "anchor": "#solution"
    },
    {
      "label": "Outcomes",
      "title": "Results after launch.",
      "anchor": "#outcomes"
    }
  ],
  "policy": {
    "agentMay": ["quote verbatim", "summarize", "link to sections"],
    "agentMayNot": ["invent metrics", "speak for past employers", "expose gated content"]
  }
}