Skip to content

2019 · Senior Product Designer · 12-person team · Shipped

Norton OPS: Security & Monitoring Platform

I owned end-to-end product design for Norton OPS as Senior Product Designer. I designed the security-monitoring interfaces that shipped, from the system overview to threat review, user access and configuration.

Security dashboard interfaceSystem overview · Threats · User access
Explore the shipped screens
Norton security monitoring platform
Project scope

PROJECT AT A GLANCE

The essentials.

My role
Senior Product Designer
Project
2019 · 12-person team · Shipped
Available screens
Overview · Threats · Access
Design scope
Security product UX/UI

See what the shipped design covers. Project record

Chapters Swipe or scroll for more

01 / CONTEXT

Finding the signal among the totals.

Project
Context

Norton OPS is a security-monitoring platform: a system overview, threat information, user-access records, reports, configuration and profile settings. The product has to serve two kinds of reading at once: aggregate system health and the individual records behind it.

My Role &
Ownership

In 2019, I owned end-to-end product design for Norton OPS as Senior Product Designer within a 12-person project team. The product shipped. This case study walks through the monitoring interfaces as they shipped, followed by a retrospective on how I would rework the overview hierarchy. The shipped screens shown here cover:

  • System overview
  • Threats
  • User access
  • Reports

Design
considerations

  • Four overview totals have similar visual weight.
  • The overview places a threat chart beside summary and table information.
  • Threat rows expose risk level and status.
  • User-access and configuration screens are separate from the overview.

02 / SCREEN REVIEW

Separate system status from threat review.

Screen
Observations

  • Summary totals and the chart provide aggregate context. Threat rows add risk and status at record level, so I treated them as a different review task.
  • Access records and configuration categories appear on separate screens. I kept them apart so access management and system setup do not compete with monitoring.
  • Looking back, I would lead the overview with an exception-first queue; that idea is covered in the retrospective below.

THE PRODUCT

See the signal. Understand the context.

Walk through the shipped screens below.

These are the monitoring screens as they shipped. The exception-first alternative later on the page is retrospective thinking, not part of the release.

Norton security overview dashboard
Norton threat overview
Norton user access screen
Norton reports screen
Norton configuration screen
Norton profile settings screen

Security overview

Review system totals, a threat chart and an incident table. Exception-first prioritization is discussed in the retrospective below.

01 / 06

FROM THE PROJECT FILES

Threats, access and configuration

Screens from the shipped product, titled as they appear in the UI. Counts, dates and identities are sample data.

Threat overview

Threat overview — Norton screen
Threat categories, top threats and recent threat rows share this view. Grouping them in one view lets a reviewer move from category to individual threat without changing screens. View full-size screen

User access

User access — Norton screen
Login activity, user status totals and an access table sit together, so account status and recent activity can be read side by side. View full-size screen

Configuration entry points

Configuration entry points — Norton screen
The screen groups settings, roles, policies, integrations, recovery and audit. Each category is a clear entry point, keeping administrative setup out of the monitoring views. View full-size screen

Screen
Coverage

How the shipped screens connect.

System overviewThreatsUser accessReportsConfigurationProfile settings

Pattern
review

Key structures in the shipped product:

  • Summary cards describe aggregate health; table rows describe individual records.
  • The threat and user-access views each combine summaries with record-level information.
  • Risk level and status sit in the threat row itself, next to the incident they describe.

DESIGN STRUCTURE

Overview, access and what I would change.

Two structural choices in the shipped dashboard, and one I would revisit.

01

Overview structure

Four totals, a chart and threat rows share the overview. The layout pairs aggregate context with record-level information on a single screen.

02

Separate access and configuration

Access records and configuration have their own screens, so administrative tasks stay out of the monitoring flow.

03

What I’d change next

Looking back, I would move exceptions ahead of aggregates. That ranking depends on an agreed severity policy, so it belongs in the retrospective rather than the release.

The first two notes describe what shipped; the third is retrospective.

03 / PROJECT RECORD

What the shipped design covers.

The scope of the release, and the questions I would take into the next iteration.

Project record

What shipped

End-to-end product design as Senior Product Designer in 2019, in a 12-person team; the product shipped. The release covers the system overview, threats, user access, reports, configuration and profile settings. The exception-first queue is retrospective thinking, not part of the release.

What the design makes clear

Aggregate health and individual threat records are visible together, each threat row carries its risk level and status, and access and configuration have dedicated screens.

04 / RETROSPECTIVE

An overview is not yet a triage decision.

The shipped dashboard puts summary totals, a threat chart and an incident table on one screen. Looking back, the question I would push further is which signal should lead someone toward the next investigation.

Shipped design and retrospective. The labels below mark what shipped and what I would change next.

Norton overview with totals, chart and security threat table
Shipped design · annotated. Numbers correspond to the notes alongside it.
  1. 01

    Four totals compete for attention

    Total threats, defended, failed and users share similar card weight. They describe the system well, but none of them signals which item needs action first.

  2. 02

    A chart needs interpretation

    The radar chart compares breached and at-risk signals across categories. It supports comparison, but leaves the reader to work out which incident to investigate.

  3. 03

    The table holds actionable context

    Risk level and status sit beside individual rows. This is where an overview can become an investigation, provided priority and the route into detail are explicit.

Threat table detail

Incident titles, risk level and status appear together so the next investigation has context.

Norton threat table with incident, risk and status columns
Shipped screen with sample data. Ranking these rows by priority would need an agreed severity policy. View full-size screen
Inspect dashboard details

Scroll across the enlarged screen. Keyboard users can focus the image area and use the arrow keys.

Security overview with summary cards and incident table
Alternatives and refinement rationale

WHAT I’D CHANGE NEXT

A / AS SHIPPED

Lead with aggregate health

Keep the shipped summary-led hierarchy. Useful for a broad status review; individual exceptions remain lower on the page.

B / PROPOSED DIRECTION

Lead with exceptions

Surface the highest-priority items first, then keep totals and comparison charts as supporting context. Ranking must follow an agreed severity policy.

Direction B is the triage-oriented alternative I would pursue. Direction A remains the right fit for a status-review audience. The choice depends on who owns the first action, which is the first thing I would confirm.

RETROSPECTIVE

Put exceptions before aggregates.

Prioritization helps only when the ranking is trustworthy. Keep the reason for each rank visible and preserve filters so an analyst can challenge the default order.

Retrospective schematic · not part of the shipped product.

RETROSPECTIVE / NOT SHIPPED

Exception-first overview

The hierarchy I would use next. Labels describe the structure, not security data.

First
Prioritized incident queue
Then
Risk, status and last activity
Supporting context
System totals and trends
Open selected incident
Retrospective: the information hierarchy I would use next.

What would decide it?

Give participants an incident-review task. Observe which item they choose first, whether they can explain its priority, and how they reach the relevant detail. Compare errors as well as task time.

These are the questions I would use to evaluate the next iteration.

The trade-off is status review versus incident triage. Aggregate health summarizes the system; an exception-first queue prioritizes investigation.

How I would validate the next iteration

Use equivalent incident scenarios and an agreed severity rubric. Ask reviewers to choose the incident that needs attention, explain why and reach its detail. Record missed critical incidents and incorrect choices alongside time; a faster choice alone does not mean better triage.

What I’d Change
Next

Which threat would a reviewer investigate first, and which visible risk or status field supports that choice? Answering that means agreeing a priority policy before redesigning the overview.