Xfinity Call Guard
Designing clarity into a complex protection system
Xfinity Call Guard brought TNS's established call-protection capabilities into a new customer ecosystem. The product inherited a mature foundation from Verizon Call Filter, but the work was not a simple reskin. Xfinity introduced different product expectations, brand requirements, eligibility rules, platform behavior, and permission needs.
As design lead, I helped guide that adaptation while directly owning key parts of the experience, including onboarding and permissions across iOS and Android. I worked across interaction design, stakeholder reviews, shared IxD documentation, engineering collaboration, and implementation support. I later designed Call Guard's in-app feedback experience.
1. Adapting an established product
The project began with an existing Call Filter foundation. Early work involved translating that interaction model for Xfinity, identifying what could carry over, and documenting where Xfinity's requirements or technical environment demanded a different approach.
The design challenge was therefore one of adaptation and systems thinking: preserve proven protection patterns while creating an experience that made sense within Xfinity's product, brand, eligibility, and platform constraints.
2. Rethinking how customers get started
Onboarding became an early priority. Existing product data indicated meaningful drop-off at the beginning of setup, while Xfinity reviews raised broader questions: How should permissions be sequenced? What happens when someone leaves before finishing? Where should they return? What defines onboarding as complete?
The problem was larger than introducing features. Call Guard depended on OS-level permissions and roles that affected authentication and protection behavior, and those requirements differed across iOS and Android. The onboarding model had to explain why access mattered without making complete setup an unnecessary barrier.
3. Exploring the permission model
Early exploration tested different ways to expose permission requirements. One direction consolidated setup into a permission dashboard; another introduced permissions sequentially alongside the features they enabled.
The team worked through practical tradeoffs: bundled versus contextual requests, which permissions could wait, what happened when only one permission was missing, and how much setup should be required before a customer could enter Call Guard.
IMAGE PLACEHOLDER - HERO
Use direct UI exports - no device mockups. Recommended 3-screen composition: (1) Overview/landing with the purple App Feedback toast as the dominant anchor; (2) final Onboarding - Setup Permissions progress page; (3) a visually strong product screen such as Insights. Optional fourth screen: Custom Control / protection management. Use a clean 1-3 px border, restrained rounded corners, and staggered scale/cropping.
IMAGE PLACEHOLDER - PROCESS - FOUNDATION
Optional. Show one restrained Call Filter -> Call Guard comparison only if it clearly explains adaptation. Do not imply greenfield ownership. A single counterpart pair is enough; this should not become a before/after redesign section.
IMAGE PLACEHOLDER - PROCESS - EARLY FLOW
Use a dated Xfinity Onboarding WIP export from the October review period. Show the larger canvas to communicate scope, then use 1-2 readable crops. Keep review dates visible when useful. Caption explicitly as an early exploration / review artifact, not the final flow.
Xfinity Call Guard - case study blueprint v2 2
IMAGE PLACEHOLDER - PROCESS - PERMISSION APPROACHES
From the WIP Xfinity Onboarding / xf-ob materials, show the Permission Dashboard and Sequential Permissions per Feature concepts side by side. Annotate the tradeoff: consolidated completion vs. contextual explanation. Do not frame this as an A/B test or formal usability study.
IMAGE PLACEHOLDER - PROCESS - VISUAL EVOLUTION
Optional but useful if the progression is visually obvious. Use 2-3 tightly cropped xf-ob states to show movement from rough/placeholder content toward resolved Xfinity feature storytelling and permission UI. Keep this short; the case study is about product thinking, not a visual-design timeline.
4. Resolving one experience across two operating systems
The final interaction model preserved a shared setup concept while allowing iOS and Android to behave differently underneath it. Granted permissions could be recognized, ungranted permissions remained actionable, some OS dialogs could be triggered in succession, and settings-level permissions required explicit return paths from the operating system.
The final IxD also documents dynamic completion behavior: when all required permissions are enabled, the primary action changes to Continue and the secondary completion-later action disappears. This made setup responsive to the customer's actual state rather than treating onboarding as a fixed slideshow.
IMAGE PLACEHOLDER - FINAL - SETUP PERMISSIONS
Use final IxD/Figma states from the UC2.2 Onboarding - Setup Permissions & Roles progress page. Capture a clean default/partial state plus, if visually useful, the fully granted state that demonstrates the CTA change. This is final-solution imagery, not a WIP export.
IMAGE PLACEHOLDER - FINAL - IOS / ANDROID DIFFERENCE
Choose ONE meaningful OS difference from the final IxD: for example, an iOS instructional/settings-level permission path beside the corresponding Android permission behavior. Avoid duplicating whole flows. The point is shared experience + different OS mechanics.
5. Designing for incomplete setup
The resolved system did not treat onboarding as an all-or-nothing gate. Customers could reach the product without granting every permission, while Call Guard carried missing setup forward and surfaced recovery when the customer encountered a dependent feature.
That transformed onboarding into a larger state-management problem. The product had to understand what had been granted, what had been denied, whether the customer had returned from OS Settings, and which actions should remain available. In the final IxD, customers with denied notification access could still move through most of the product while specific dependent actions remained unavailable.
IMAGE PLACEHOLDER - FINAL - INCOMPLETE SETUP SEQUENCE
Build a compact real sequence from the final IxD: partial/denied setup -> Finish later or equivalent continuation -> Overview / contextual missing-permission UI -> recovery action -> return from OS Settings. Use 3-4 screens max. This should visually prove that setup continues into the product rather than ending at onboarding.
IMAGE PLACEHOLDER - FINAL - MISSING PERMISSION SYSTEM
Optional supporting crop from UC24.x showing how missing-permission behavior is reused across Overview, Recent Activity, filters, and other dependent surfaces. Prefer one annotated crop over a wall of tiny screens.
6. From flows to a living interaction system
As Call Guard moved toward implementation, the work became less about choosing a single flow and more about maintaining coherence as requirements changed. The shared IxD connected onboarding to Overview, Recent Activity, permissions, authentication, toasts, protection controls, and adjacent feature work.
Xfinity Call Guard - case study blueprint v2 3
Part of my role was carrying decisions across those surfaces: reviewing changes with the team and Xfinity, updating Figma and IxD documentation, clarifying behavior for development, and making sure new requirements did not introduce contradictions elsewhere.
When adjacent features such as Text Spam evolved, I supported their feature owners by integrating resulting onboarding, toast, and permission requirements into the broader Call Guard system. Text Spam itself was not my feature architecture.
7. When one platform constraint changes the whole system
A late-stage iOS constraint became a clear example of why onboarding had to be treated as a system. Apple rejected the notification permission ask at launch, forcing the team to revisit an assumption tied to authentication and setup.
The resulting work extended well beyond moving a permission prompt. The flow had to account for provisional notification behavior, remove the original hard stop, allow continued onboarding without full notification access, revise permission recovery, and constrain downstream actions that depended on full notification permission.
The final interaction model shows the downstream consequence directly: with provisional or no notification permission, iOS block-filter controls can become disabled and route the customer into a specific notification-permission recovery path. A single platform requirement therefore propagated across authentication, onboarding, Permissions settings, filtering, blocking, and recovery.
IMAGE PLACEHOLDER - FINAL / DELIVERY - IXD
Use one strategic crop from the final IxD that visibly demonstrates branching and cross-use-case references. Pair it with 2-3 enlarged callouts. Strong candidates: permission state -> OS Settings -> return state; contextual missing permissions; or a branch where downstream feature behavior depends on onboarding state.
IMAGE PLACEHOLDER - RECREATE - PLATFORM IMPACT DIAGRAM
This is the ONE recreated diagram strongly recommended. Draw: iOS notification constraint -> Authentication / Onboarding / Permissions settings / Filters + Blocking / Recovery states. Keep it simple and label it as a simplified retrospective view of system impact.
IMAGE PLACEHOLDER - FINAL - PLATFORM IMPACT EVIDENCE
Pair the recreated diagram with authentic final IxD evidence. Best candidate: the iOS Spam/Block Filter state where provisional/no notification permission disables the page and invokes the notification-permission flow. A second small crop can show the onboarding/provisional-notification branch.
8. Creating an in-app feedback loop
I later designed Call Guard's in-app feedback experience. The early problem was intentionally broad: where should feedback be requested, how intrusive should it be, how often should it appear, and when should product feedback lead into an App Store or Play Store review?
The final interaction model resolved that exploration into two entry points: feedback from Account and a Feedback component surfaced on Overview. For the Overview path, the request is triggered one week after first launch. Responding suppresses the request for that app version; dismissing it snoozes the request, and submitted responses and optional details are recorded for analysis.
The flow also distinguishes positive and negative responses. A positive response can continue to the app-store review path, while negative feedback can collect structured input and optional free text inside Call Guard. The interaction stays lightweight while still giving the product team actionable feedback.
IMAGE PLACEHOLDER - FINAL - APP FEEDBACK OVERVIEW
Use the Overview screen with the purple Feedback component. This is also the hero callback.
IMAGE PLACEHOLDER - FINAL - APP FEEDBACK FLOW
Use the actual UC29.x final flow, not a speculative trigger map. Recommended 3-4 state sequence: Overview Feedback component -> Yes/No response -> in-app feedback form for negative feedback OR review prompt/store path for positive feedback -> confirmation. Include Account entry only if it helps explain that feedback is also available on demand.
Xfinity Call Guard - case study blueprint v2 4
IMAGE PLACEHOLDER - PROCESS - APP FEEDBACK EXPLORATION
Optional. If the early Figma/notes produce a visually useful artifact, show one small exploration comparing possible entry points or modal vs. inline presentation. Caption as exploration. Do not recreate the old candidate-trigger diagram unless the authentic artifact is unusable.
9. Outcome and reflection
Call Guard demonstrates product-design work that can disappear behind polished final screens. The customer-facing experience needed to feel straightforward, but that simplicity depended on a larger system of permission states, platform differences, recovery paths, feature dependencies, stakeholder decisions, and implementation details.
My contribution was not to reinvent every part of an established product. It was to help make that system coherent for a new customer ecosystem - directly designing onboarding and permissions, maintaining the shared interaction model as the product evolved, supporting implementation, and later designing an in-app feedback loop.
Key takeaway: Good onboarding is not simply a sequence of welcome screens. It is the interface between what a customer wants to do and everything the product and operating system require to make it possible.