HIGHLIGHTS
Framed a loosely defined analytics problem into an investigation workflow
Used AI tools to move faster through domain learning and prototyping in code.
Designed shape language for network telcom tools
Overview
Overview
Overview
Overview
Overview
Context
Enabling AI-assisted network issue detection on scale
MY ROLE
Product design
TEAM
Analytics
TOOLS
Cursor, Claude, Nokia LLM
Context
In 2025, Nokia announced ANF, an autonomus network layer to think, sense and act.
I owned the end to end design of ANFs new analytics experience taking RAN engineers from scattered investigation across multiple tools to one place for them to understand the issue and act faster.
The first challenge was defining the product behaviour
I started with a broarder ask - make subscriber level RAN experience visible acorss 5G networks. The requirements gave a starting point but to design the right experience meant understanding how engineers investigate issues today, what data do users work with to access issues.
Conversation
Outcome
Conversation
Outcome
Insights
KPI health does not always equal subscriber experience
A cell or region can look acceptable in aggregate while individual subscribers are still experiencing poor service.
Investigation has to preserve context across time, location, session, and cell.
Engineers cannot diagnose the issue from one KPI alone. They need to see how signal, throughput, mobility, failures, device, and serving cell changed during the affected session.
3. AI guidance needed a strong investigation foundation first
Because AI-assisted diagnosis was planned for a later release, the first version had to organize the evidence clearly enough for engineers to make their own judgment. This meant designing the workflow as a foundation for future AI correlation, not as a separate dashboard.
The product needed to reduce correlation work.
The engineer’s real pain was not lack of data. It was manually connecting data across tools to understand the likely cause.
The key alignment was moving from “show more data” to “guide the investigation.”
Release one would help engineers move through the evidence manually but faster.
Release two could layer AI on top of that workflow to support correlation, guidance, and likely-cause investigation.
Product opportunity
Turn fragmented RAN data into a guided investigation flow
The goal was to help engineers move from: Something looks wrong to this subscriber was impacted here, during this session, with these supporting signals.
Explorations
The main tradeoff was where the investigation should start.
I explored three product models:
KPI-first
Good for monitoring, but still forced engineers to connect KPI changes to subscriber impact.
Map-first
Good for seeing spatial patterns, but too broad for complaint-driven investigation.
Subscriber/session-first
Best matched the real workflow: start with who was impacted, then inspect where, when, and why.
Decision: subscriber/session-first became the final direction.
Visual: 3 exploration screenshots side by side
Caption: The winning direction started from subscriber impact, not from raw network objects.
I built coded prototypes in Nokia’s design language using Cursor, Mapbox, Recharts, and production-like components.
This let PMs, engineers, and domain experts interact with the workflow, test map behavior, and give feedback on something closer to the real product.
Visual: prototype screenshot / close-up
Caption: Working prototypes helped the team evaluate product behavior earlier than static design reviews.
7. Final direction
A guided investigation workflow for subscriber observability
The shipped experience organized the investigation around impacted subscribers, sessions, cells, location, and correlated KPIs.
The first release did not automate likely cause. Instead, it gave RAN engineers the evidence they needed to make faster judgments around coverage, congestion, mobility, or device-related issues.
Visual: final large product screenshot
Caption: The final direction connected subscriber impact, session evidence, and network signals in one flow.
8. Impact
Shipped workflow, clearer product behavior
This work helped the team move from fragmented monitoring toward a shipped subscriber investigation experience.
It also established a repeatable investigation pattern:
Impacted subscriber/group → time & location → sessions → cell context → correlated KPIs → diagnosis support
This became the foundation for the next release, where AI-assisted correlation and likely-cause guidance could build on top.
Start from KPIs and ask engineers to find the problem.
This matched how legacy monitoring works, but it still forced engineers to manually connect KPI changes to subscriber impact.
This would require them to still manually check KPI's to get to the root of the problem.
Exploration 2: Region/site-first investigation
Start from geography and drill into impacted cells. Useful for locating network patterns, but still too broad for complaint-driven investigation.
The solution would require them to still manually check KPI's to get to the root of the problem
Exploration 3: Giving users indipendence to explore
What if we let users pick KPIs they want to investigate, they would be able to investigate freely.
The solution would require them to still manually check KPI's to get to the root of the problem
Final direction: a guided investigation flow for subscriber observability
The final direction gave engineers one place to move from impacted subscribers to sessions, KPIs, cell context, and location signals. Instead of asking them to manually correlate data across tools, the experience organized the investigation around the subscriber journey and helped surface likely causes such as coverage, congestion, mobility, or device-related issues.
Change the screenshot so its annotated sections showing what each part is doing and why
The final direction organized the experience around impacted subscribers, sessions, KPIs, and location so engineers could move from impact to evidence to likely cause.
Context
AI-assisted workflow
I used Claude, Cursor, and Nokia’s internal LLM to accelerate domain understanding, generate product hypotheses, and prototype interaction models. This helped me move faster through an ambiguous problem space and test different investigation flows before committing to the final direction