Status Dashboard

My role

My role

Lead Product Designer, leading end-to-end UX/UI, research, and delivery.

The team

1 Designer (me), 1 Product Manager, 1 Customer Support Specialist, 2+ Engineers, 1 QA Specialist

The problem

After users purchase a new line or start a number transfer, they land on a dashboard that essentially says: “We’re working on it, please wait.” Without a clear timeline, progress, or next steps, the waiting period feels uncertain, especially when users temporarily lose signal and assume something went wrong.

Solution highlight

To make the waiting experience feel more predictable, I redesigned the status dashboard to clearly show what’s happening, with progress, expectations, and the right next step for each stage.

Impacts

Reduced confusion during the waiting period by replacing vague messaging with clear progress states.

Understanding what’s really happening

Before redesigning the dashboard, I mapped the experience from both the user and system side.

User side
I transferred my own number to US Mobile and documented the experience step by step. I also ran quick interviews with 5 people who had gone through either a number transfer or a new number setup. This helped me understand what users feel during the wait and what they need to stay confident while it’s in progress.

User side
I transferred my own number to US Mobile and documented the experience step by step. I also ran quick interviews with 5 people who had gone through either a number transfer or a new number setup. This helped me understand what users feel during the wait and what they need to stay confident while it’s in progress.

System side
I partnered with the PM to understand how the system handles line setup behind the scenes. I learned that the backend already has clear statuses and responses. I summarized them into a simplified flowchart to guide the dashboard design.

System side
I partnered with the PM to understand how the system handles line setup behind the scenes. I learned that the backend already has clear statuses and responses. I summarized them into a simplified flowchart to guide the dashboard design.

Designing the status experience

Exploring what “progress” could look like
With both user insights and the system flow in mind, I started by sketching and exploring multiple ways to visualize progress. The goal wasn’t to mirror backend steps directly, but to understand what “progress” could look like.

Defining a progress model users can trust
Based on the backend status logic and discussions with PM and engineering, we landed on a 3-step progress model: Submitted → Processing → Activating. This framework supported both number transfer and new number flows, keeping the experience consistent while reducing implementation complexity. Most importantly, it stayed simple enough for users to understand at a glance.

Crafting user-friendly status messaging
I partnered with the PM to define what users should see at each stage, translating backend terminology into clear, user-friendly language that reduces uncertainty during the wait.

Designing for the unhappy path

Grouping and categorizing error states
Errors happen, but showing 20+ error scenarios as unique states would overwhelm both users and the system. To keep the experience clear, I mapped each error to the next action users needed to take and grouped them into three consistent paths: Edit info, Contact carrier, Contact support.

Designing consistent error states
Based on the categorization, I defined a consistent structure and baseline message for each error type. We designed one representative state per category to validate tone, layout, and CTA patterns. The remaining error cases reused the same framework, with only the reason-specific details changing.

Helping users fix and resubmit
For errors that required updates to transfer details, I designed a clear edit-and-resubmit experience to guide users toward the next step with minimal friction.

I also redesigned the Transfer Details section to improve readability and hierarchy, making it easier for users to review their information before resubmitting.

Key takeaways

From system logic to user clarity
Good UX isn’t about mirroring backend logic. The system already had complex states and mappings, but users didn’t need to see all of it. My role was to understand how the backend worked, then simplify and restructure it into a clear, user-facing experience — especially during moments of uncertainty.

From system logic to user clarity
Good UX isn’t about mirroring backend logic. The system already had complex states and mappings, but users didn’t need to see all of it. My role was to understand how the backend worked, then simplify and restructure it into a clear, user-facing experience — especially during moments of uncertainty.

Designing scalable error patterns
With 20+ error cases, designing each one individually wasn’t sustainable. By grouping them based on the action users needed to take, I reduced the complexity into three consistent paths. This approach made edge cases easier to manage and more scalable across the system.

Designing scalable error patterns
With 20+ error cases, designing each one individually wasn’t sustainable. By grouping them based on the action users needed to take, I reduced the complexity into three consistent paths. This approach made edge cases easier to manage and more scalable across the system.

Knock knock.