Network and subscriber observability for Telcom operators
Impact
Buyer readiness ↑ ~60%
Advisor clarification time ↓ ~20%
Deliverables
UX Design
Timeline
2 months
Team
Design manager
2 UX designers
UX research agency
About
In 2025, Nokia announced ANF, an intelligence layer for autonomous networks designed to help telecom networks sense, think, and act more autonomously.
To support this, I designed a network and subscriber observability experience that gave RAN engineers one place to investigate service quality issues, helping them reduce manual correlation, diagnose issues faster, and resolve customer-impacting problems before they escalated.
The product was broken into two releases: the first gave engineers visibility into network and subscriber experience, while the second would build on that foundation with AI-assisted correlation, explanation, and recommended actions.
Traditional monitoring is fragmented and slow
Picture this, customers are reporting slow data, dropped calls, or poor service. A RAN engineer now has to trace that complaint through maps, KPI reports, cell data, subscriber records, session details, and logs. The answer may be there, but it is scattered. To understand what happened, they have to manually connect where the issue occurred, who was affected, and what likely caused it.
This takes time, and the longer it takes, the harder it becomes to resolve the issue before it turns into more complaints, escalations, or service-impacting tickets.
Walking into the unknown
This was a new initiative and that meant product requirements were loosely defined.
some visual to support the idea of how I took ownership, collaborated with PM, Software Architectures, teams close to ANF & Nokia GPT to define the product clearly, define our persona and create a jira ticket that was broken down into 2 releases. (without and with AI)
Also reviewed exsisting nokia products and work that was being done in ANF
Key insight 1: Network teams had data, but not a clear investigation path.
Engineers could access KPIs, alarms, cell data, but those signals lived across different systems. This made investigation depend on manual correlation.
Key insight 2: KPIs only became useful when engineers could correlate them across context.
Each KPI, device model, subscriber group, session, and location each told part of the story. Engineers had to manually connect these signals to understand what kind of network issue were they dealing with quickly to prevent further compaints or escelation of the issue
Persona Detials
also share we created jira ticket in collaboration with sw architecture, pm and design
Reviewing existing nokia products & competitors
- sort of PMF to make sure my product fits within what Nokia makes..uses same sort of patterns
Problem
How do we enable RAN engineers to quickly identify why a subscriber or group of subscribers is having poor network experience, locate where and when it happened, understand the cause and take action before it becomes a larger service issue or repeated complaint.
How might we enable RAN engineers to quickly identify when, where, and why a subscriber or subscriber group is experiencing poor network performance, so they can understand the likely cause and act before it becomes a larger service issue or repeated complaint?
Exploration
Exploration 1: Giving users indipendence to explore
This solution would require them to still manually check KPI’s to get to the root of the problem
What if we let users pick KPIs they want to investigate, they would be able to investigate freely
Solution
Autonomy over investigation while being proactive
This early-stage experience helps first-time buyers understand whether a specific home fits their budget. It aligns buyers and advisors before their first meeting. Here's how it works.
Reflection
Context and the timing of when it is given are key to making an experience feel natural and empowering. The key here was to step in at the right time before buyers get advice from people around them and search online.