Nokia Internship | Winter 2026
Turning manual investigations into
30-second conversational insights.
INTRO
In the world of high-speed networking, a 5-minute delay in identifying a traffic anomaly can cost a Tier-1 provider (like AT&T or Rogers) hundreds of thousands of dollars in SLA penalties. Nokia Deepfield is a network defense system that stops these attacks in real time.
Over 12 weeks, this project gave me the opportunity to contribute to a SaaS solution that keeps the internet online for millions of people.
ROLE
Product Designer
TEAM
2 Design Mentors
Product Manager
3 Software Engineers
TYPE
Enterprise SaaS
AI Design
Design System
TOOLS
Problem
Current workflows risked massive financial penalty during cyberattacks.
Network data caused cognitive overload but couldn't be hidden.
Inconsistent UI patterns stalled engineering.
Solution
A chat feature connecting AI summaries with raw data logs.
Embedded interactive widgets to enable user action.
Scaled a conversational component library across the broader design system.
Results
Live testing proved a drastic reduction in anomaly response.
Delivered a validated blueprint for the upcoming engineering build.
Unblocked internal teams by establishing strict design guidelines.
Process
SETTING THE SCENE
The data was limitless.
Making sense of it was impossible.
If the internet was a massive highway, Nokia Deepfield is the high-tech traffic control center that detects car accidents (cyberattacks) in real-time.
Deepfield was already five years old when I joined, and its human element was missing. The product's core analytics engine was incredibly powerful, but extracting insights from massive amounts of data was a core user problem.
To understand why the data was so overwhelming, this is the client UI of a singular attack (bundled with hundreds).
UNDERSTANDING USERS
Every piece of data was important.
Deepfield is built for network operators at Tier-1 providers. These are deeply technical users who rely on granular data to perform IT and security services.
When I was onboarded, the overarching product demand and feature scope for Ask Deepfield were already finalized as capabilities were locked.
So I pivoted away from feature ideation and focused entirely on the visual hierarchy and conversational design. I discovered three core needs from user interviews.
IT specialists need speed under pressure.
Every minute of an attack risks costly SLA penalties.
Cross-referencing 5+ dashboards manually takes too long.
The UI must provide instant, actionable summaries.
Users need to trust the AI.
Blind trust is a risk in enterprise network security.
Network engineers won't deploy countermeasures on an AI's word alone.
Ask Deepfield must show its work and cite specific data sources.
Power users need progressive disclosure.
No legacy data can be removed; every metric matters.
The UI must start with a digestible, high-level overview.
Engineers need a seamless way to drill down into the granular logs.
FULL WORKFLOW
Research first, prototype second, pixels last.
Before touching design, I needed to know if Ask Deepfield's logic actually made sense to the people who'd be using it. Once that logic held up, I moved into Figma. Using its MCP,
I could hand that context straight to LLMs and prototype against real constraints.
My role here was mostly translation:
Turning research into concrete interaction states.
Catching edge cases before they became engineering problems.
Building live prototypes in code for user testing.
Iterations
CONSTRAINT #1
Keeping users in the loop.
Ask Deepfield cannot execute high-stakes commands autonomously. When the AI needs explicit user permission, open-ended text chat creates too much risk and cognitive load.
I created new AI-related components to our design system to fix long-standing UX issues; adding documented guidelines to have a progressive conversational UI (example below).
Dashlets with radio-button choices for standard approvals and nested text inputs for follow-ups.
CONSTRAINT #2
System Latency and Transparency
The success of high-latency queries needed to be proven as areas with no single “correct” solution that were causing inconsistency and unnecessary debate. Once we had a solid base of components, I focused on patterns.
I audited other design systems and products (via Mobbin) to define clear guidelines for recurring problems and established a design pattern in the AI outputs where it progressively communicates its reasoning and data sources in real time.
Solution
TARGET USE CASES
Analytics: Single vs. Multi Reports
Network attacks aren't uniform, so our user's experience wouldn't be either. I looked at how engineers make decisions under pressure as there's a difference between verifying a conclusion and triaging between parallel options.
Single reports are meant for verification, it provides a direct summary with collapsible key findings so engineers can validate the AI’s logic and act immediately.
Multi reports isolates concurrent entities into separate modules so engineers can scan top-level data and drill into the specific problem network.
Single Reports vs. Multi Reports
DESIGNING EDGE CASES
Simultaneous Context
Standard AI assistant UI is subject to a small portion of the platform's screen but our users can't afford to lose sight of the raw data.
To support these new workflows, I introduced a split-view layout where the conversation and data panels are independent but connected.
High-level summaries can be read while actively digging into network logs right next to it. Users can verify data without losing chat access.
DESIGNING EDGE CASES
Taking action during a network attack
Instead of forcing IT security professionals to switch between multiple dashboards, I brought controls directly into the chat.
I designed flows where the AI surfaces interactive widgets (components from design pattern library) to propose a fix. In this scenario where decision fatigue can cause financial loss, eliminating jarring context switches are high-priority.
Design System
SHARED COMPONENT LIBRARY
Scaling a unified design system
My component work extended far beyond Ask Deepfield, with new interactive patterns (including Dark Mode) added to the broader Network Infrastructure (NI) design system.
I worked with our Design Systems Manager to establish a single source of truth, scaling these components across four different enterprise products including Deepfield.
It eliminated the constant internal UI debates and gave the development teams a consistent foundation to ship faster across the entire suite.
Results
RESULTS
Securing stakeholder buy-in through proven UX
Since I was a contract designer on a massive enterprise project, my ultimate goal wasn't to ship the final product, it was to de-risk it.
My core objective was to validate the research and UX logic through user testing before engineering committed months to building it later in the year.
Our team campaigned for Ask Deepfield with results from testing and secured buy-in needed to officially commit engineering resources (super proud of this team!). I left the team with a fully validated prototype and a user-backed blueprint to develop from.
Validating interactions through client testing
Conducting internal audits pre and post research
LEARNINGS
Simplifying doesn't mean deleting
What looked like a visual clutter problem was actually a pacing problem. For Ask Deepfield, every single metric on the screen was necessary. I learned to give users digestible decisions first and let them drill into complex interactions only when needed.
Designing for friction
A seamless experience is actually dangerous when a false positive can cost hundreds of thousands of dollars. Having users to pause and verify the system's logic before executing a command isn't bad UX; it’s how you build genuine trust.
Prototyping with Cursor
This was my first time working in Cursor and it quickly became one of my most useful tools for exploring ideas. I learned that high fidelity can make a weak concept feel more resolved than it actually is. It was a great lesson in knowing when to push a prototype further and when rethink the core idea in the canvas.
