Designing an end-to-end annuity application lifecycle platform that replaced fragmented, multi-system workflows with a single source of truth for 10k+ users.

What we chose not to build (and why)

Early designs mapped all six operational stages: Can Sell, Application, Payment, Policy Activation, Commissions, and Post Activation. After reviewing with operations, marketing, and management, I advocated for cutting commissions from the MVP. The data showed agents didn’t make decisions based on commission status during the application lifecycle — it was relevant post-activation, not during. Including it would add cognitive load without driving action.

Similarly, agent eligibility verification (background checks) ran in parallel with application verification. Rather than give it a separate tile, we merged it into the Application stage. Two tiles that moved in sync created confusion; one tile with combined status was clearer and more honest about how the work actually flowed.

Design Process

From complex flow to three meaningful tiles

The design went through three distinct phases — each one driven by a specific problem that only became visible once we put something in front of stakeholders and users.

Step 1 — Map the full lifecycle

Before any wireframes, I worked with operations and product to map every stage an annuity application passed through. This produced stages: Application, Payment and funds, Policy Activation, Commissions, and Post Activation. Each had its own sub-processes, responsible teams, and potential blockers.

The critical insight from this exercise was that the lifecycle wasn’t linear. Applications could reach Policy Activation before all payments were received. Commissions could be processed in advance. Any design that implied a clean sequential flow would misrepresent how the work actually moved — and give agents false confidence about where things stood.

The full lifecycle. Mapping this was the foundation — it surfaced the parallelism that a simple tracker couldn’t handle, and gave us the scope of what the platform needed to represent.

Step 2 — First iteration: six-tile dashboard with SLA bar

The first design translated all six stages directly into tiles — one per stage — with a top-level SLA progress bar showing estimated vs. actual processing time. The logic was straightforward: give every stage equal visibility, and let agents and ops drill into whichever was relevant.

Stakeholder reviews revealed two problems with this approach. First, the six tiles created cognitive overload — agents didn’t need to act on all six stages simultaneously, so showing them all at once created noise. Second, the Commissions tile wasn’t relevant during the active application lifecycle; it only mattered post-activation, so it was drawing attention at the wrong moment. The dashboard was complete, but it wasn’t useful.

First iteration. All six stages visible as tiles, with a top-level SLA bar tracking overall processing time. Stakeholder feedback revealed this mirrored the old system’s complexity rather than reducing it.

Step 3 — Reduce to three tiles with tasks inside each

The key reframe was this: agents didn’t need to see every stage — they needed to know which stages required action from them. I advocated for collapsing to three tiles that mapped to the three points in the lifecycle where agents had something to do: Application, Premium, and Contract Activation. Commissions was removed from the MVP entirely.

The second structural change was moving tasks inside each tile rather than showing them separately. This meant agents could see at a glance whether a stage needed their attention, then expand to find the specific action required. The SLA bar was retained at the top but simplified to show stage-level estimates rather than an aggregate timeline.

Task states that create clarity, not noise

Each tile used five task states: Assigned, In Progress, Pending Review, Completed, and Cancelled. The key decision was making “Assigned” the trigger state — when a task lands in someone’s queue, the tile visually changes so neither agent nor ops team can miss it. This replaced the reliance on email notifications or manual check-ins.

DEFAULT STATE

ASSIGNED STATE

Communication built into context

Rather than routing conversations through email, I designed a messaging thread attached to each task. This kept communication contextual — anyone reviewing an application could see the full history of what was asked and resolved, without leaving the platform.

Task detail. Each task expands to show required actions, documents, and status — visible to both agent and ops team.

Contextual messaging. Conversations are attached to individual tasks, replacing the email chains that previously made coordination invisible.

SLA tracking as a trust signal

Estimated processing timelines (SLAs) were added to each stage. This served a dual purpose: internally, it gave ops teams a benchmark to measure against; externally, it gave agents a concrete answer to the question they were previously calling support to ask: “When will this be done?”

Stage-level SLA definitions. In collaboration with the operations team, we established estimated processing windows for each of the three tiles — something that hadn’t been formally documented before. This did two things: it gave ops a benchmark to identify when an application was running late, and it gave agents a concrete answer to the question they’d previously had to call support to get. Defining these numbers was as much a design decision as the UI that surfaced them.

The video below shows the dev environment stage of the project.

Post-Launch & Iteration

What the data revealed after shipping

We monitored the platform using FullStory session recordings and heatmaps in the weeks following launch. Two issues emerged early.

What the data revealed after shipping

Problem 1: Low task engagement despite high traffic

1,200 users were visiting DOT daily, but only ~300 were engaging with the task section. Session recordings revealed the issue: users weren’t connecting the status labels on the dashboard to the fact that they had action items waiting. The “Assigned” state wasn’t prominent enough at the entry point.

The fix was a contextual prompt on the dashboard landing page that surfaced assigned tasks directly — “You have X tasks assigned.” Within 30 days, task section visitors increased by 53.2% (from ~300 to 533 daily users).

Problem 2: Status chips were being clicked expecting interaction

Heatmap analysis showed status chips were the 3rd most-clicked element on the page — but they weren’t interactive. Rather than redesigning the chips (which would have delayed a fix), I added hover tooltips that explained each status stage. This gave users the information they were seeking and reduced frustration without a breaking change to the UI.

FullStory heatmap. Click density on the status chips (3rd most-clicked area on the page) revealed users expected them to be interactive filters. The fix — hover tooltips — resolved the frustration without a UI redesign.

Both fixes were small, but they illustrate how post-launch monitoring can uncover the gap between intended and actual user behavior — and how targeted interventions can move metrics without major rework.

Before vs After Metrics

Metric	Before	After
Processing Time	8-10 weeks	2.5 weeks
Application Visibility	Fragmented across Systems	Unified dashboard for all stages
Doc issue resolution	Weeks of back-and-forth	24–48 hour resolution time
Support dependency	High — agents called in for status	Reduced call centre volume
Platform adoption	No centralized tool	10,867 users; ~500 daily active

Reflections

What I’d do differently