How I Reduced Activation Drop-off at Comcast

Context

The Xfinity Install App is the activation flow that every new Comcast customer touches — device setup, plan selection, and service confirmation. At this scale, even small UX friction compounds into measurable revenue loss.

When I joined the platform team, the activation funnel had a completion rate that left room for improvement. Drop-off was concentrated at two points: plan selection (too many options, unclear pricing) and the confirmation step (users second-guessing before commit).

The Problem

The existing codebase used class-based React components with deeply nested state. Key issues:

• Race conditions in async flows: Multiple API calls for plan eligibility, device compatibility, and pricing could resolve out of order, leaving the UI in inconsistent states.
• Validation was scattered: Each form step had its own validation logic, often duplicated, with no shared schema.
• No progressive disclosure: Users saw every plan option at once regardless of their device or region, creating decision paralysis.

Approach

1. State Management Refactor

I migrated the activation flow from class components to functional React with a centralized state machine pattern:

• Zod schemas for every API response and form step — runtime validation that catches contract drift before it reaches the UI.
• Reducer-based flow state that models each activation step as an explicit state, eliminating impossible UI combinations.
• Optimistic UI updates with rollback — the plan selection step felt instant even when the eligibility API took 200–400ms.

2. Progressive UX for Plan Selection

Instead of showing all plans, I implemented tiered disclosure:

1. Recommended plans first — filtered by device type and region, surfaced in a prioritized grid.
2. "See all plans" expansion — remaining options available but not overwhelming the default view.
3. Price comparison tooltips — hover/tap context showing what changes between tiers.

This was shipped behind a feature flag and A/B tested against the existing flow.

3. Reusable Form Components

I built a library of reusable form primitives (inputs, selects, radio groups, validation displays) that standardized the UX across multiple product teams:

• Consistent error messaging — every field shows validation state the same way.
• Accessible by default — ARIA labels, focus management, and screen reader announcements baked in.
• Composable — teams could assemble new forms from primitives without writing custom validation.

Instrumentation & A/B Testing

Every flow variant was instrumented with:

• Step-level completion tracking — which step users drop off at, segmented by device type and plan tier.
• Time-to-complete per step — identifying where users hesitate.
• Error frequency by field — surfacing which validation rules cause the most friction.

The A/B test ran for 4 weeks across a 50/50 split of eligible traffic (new activations, excluding edge-case device types that needed the legacy flow).

Results

| Metric | Before | After | Impact | | ----------------------- | -------- | ---------------------------- | --------------------------------- | | Funnel completion rate | Baseline | Measurably improved | Validated via A/B test | | Plan selection drop-off | High | Significantly reduced | Progressive disclosure | | P99 latency (plan step) | ~1.2s | ~950ms | Optimistic UI + parallel fetching | | Form component reuse | 0 shared | Library adopted across teams | Platform-wide standardization |

Key Takeaways

1. Model your UI states explicitly. A state machine makes impossible states unrepresentable — no more "loading but also showing an error" bugs.
2. Progressive disclosure works. Reducing cognitive load at the point of decision measurably improves conversion.
3. Ship incrementally behind flags. We never disrupted the live revenue flow — the old path was always one flag-flip away.
4. Measure at the step level. Aggregate funnel metrics hide where the real friction lives.

---

This post describes work I did at Comcast from 2023–2025. Specific internal metrics and code are generalized to respect confidentiality.