Li Zheng
Bay Area, CA
lz@lzheng.com

NortonLifeLock Alert Builder

  • Team

    Solo Project

  • Role

    Design, Develop

  • Duration

    Aug 2020 - Present

The Challenge

The NortonLifeLock Identity solution doesn’t require our customers to intensively interact with the product to gain benefits. Once the basic information has been set up, the Alert & Notification is almost the only communication method we rely on. 

We notify our customers about any activities we detected related to their financial assets, online accounts, personal information, credit, and much more. Therefore, we have to be very conscientious when sending out alerts or notifications to our users. They have to be accurate, glanceable, easy to digest, and actionable.

How to empower our designers, PMs, and copywriters to compose or update more than 150 types of alerts within the minimum design and engineering effort is the challenge I was facing.

  • Labor intensity: more than 150 types
  • Multi-platform discrepancy: iOS, Android, Web
  • Limited flexibility: fixed styles and structures

Scope & Constraints

With our frontend and backend teams’ support, I was granted the authority to rebuild the Alert’s data structure. There are several rules that we would like to follow: 

  1. Client-sides only display information with predefined styles.
  2. Visual elements should not be introduced into the API.
  3. The website and native apps consume exactly the same data.

Research

The old visual representation was restricted by bundling a title and a specific type of content style together. By doing this, the team was only able to use a fixed amount of styles to present hundreds of alerts.

  • Title + Paragraph
  • Title + Key value pair
  • Title + List of strings
  • Title + Unordered list

Existing Enhancement

In order to display more varied information, the team added “show” and “hide” property to the title and introduced an optional subtitle into the existing structure.

However, these adjustments increased the difficulties of design alignment between the app and web and also added complexity while converting the design into our API.

PMs

  • Provide feedback to all teams on alerts’ appearance and functions
  • Document revisions of any alerts with visual and plain text formats
  • Lose track of alerts revision history due to continuous content updates
  • Difficult to draft a copy of an alert without a proper design tool

Designers

  • Focus on designing information hierarchy and visual representations
  • Able to introduce new styles when necessary
  • Endless subtle copy revisions with mandatory mocks update
  • Reasonable information structure could not be achieved due to the constraint

Copywriters

  • View visual reflection on copy updates as soon as possible
  • Reorganize or propose different information structure when necessary
  • Overwhelmed by multi-platforms variations of the same piece of alert
  • Inconsistency due to the lack of an effective text retrieval system

Frontend

  • No additional or minimum work when a new alert is introduced
  • Take full control of the visual representation on the client-side
  • The rendered styles were disturbed by the HTML obtained from the API
  • The designs cannot be fully implemented with the existing data model

Backend

  • Smooth converting design to a certain data model without ambiguity
  • No data level discrepancy between the app and website design
  • Difficult to find a perfect model that can match the design
  • Struggle along with the combinations of limited existing styles

Legal

  • No need to review the same content twice for different platforms
  • Obtain a clear history of all the copy and design revision
  • Have to review and leave the same comments on both app and web designs
  • Get confused by too many variations of the same piece of alert

Ideation

There is a common need across all the teams that a centralized single source of truth. Currently, we use Zeplin to serve this need. However, only designers have the proper tool to upload new mocks. Developers have to convert the design in a certain data model judging by sight which is unreliable and could cause many misalignments.

As all client-sides consume precisely the same data from our API without special treatment, each piece of data is a building block. As long as the information structure is defined, the rendering should be determined as well. By handling these UI building work to automation, designers can focus on the information hierarchy and design new styles if needed instead of spending time on aligning UI components’ positions or styles.

Has to have

Alerts Preview

  • There must be a real-time visual preview feature to show the alerts rendering result on a website with width adjustments and on our native apps.

Content Editor

  • All team members can view and modify an alert via this editor. The outcome can be used as a source to auto-generate mocks and a precise reference to build data models.

Nice to have

Storage

  • A backend that serves all alerts in production, delivers any of them as needed for reference, and saves alerts with version information for future use.

API Integration

  • Real data can be pulled into this tool to provide realistic content during the alert designing stage and to test the feasibility of a design.

Solution

Develop a web app that allows text and layout editing with predefined styles, provides a real-time preview and supports data import and export. The exported data can be used as a copy source to generate Sketch mocks by using the Copy-Updater sketch plugin and can also be used as the final data model without any guessing job.

  • A web app with content editing
  • Responsive live preview
  • A flexible and scalable data model

Section 1: Header

The header contains an icon that can be selected from 4 options, a required primary title, and an optional secondary title. The layout is dynamic based on the content.

Editor: Header
Preview: Web & App

Section 2: Highlights

In order to provide glanceable alerts for users to grab the key information, we summarize the content and carefully pick the two most critical information as highlights.

Editor: Highlights
Preview: Web & App

Section 3 & 4: Body & Footer

The body and footer share the same data model. Both of them allow multiple blocks to be added, each block supports multiple sections and each section is a combination of different styled building blocks.

The section title is optional and can be controlled for a specific platform. For every single type of style, more than one piece of information can be stacked and mixed with other styles. The editor supports creating, inserting, reordering, and deleting.

Editor: Body & Details
Preview: Web & App

Section 5: Action

Either a single or a binary action button is supported within the editor aligning with our current alerts and notifications’ principle.

Editor: Action
Preview: Web & App

Section 6: JSON

For the MVP of this tool, I didn’t set up a backend for manipulating JSON. In order to compensate for this defect, I added a plain text editor here to display the generated JSON and to read outside JSON as a data source.

Editor: JSON
Preview: Web & App

Other Features: Link & Responsive View

Any plain text in the editor can be converted to a link by adding ${} around it. It allows users to preview the effect as close to the actual rendering result as possible.

The mobile and desktop web-view can be switched by a single toggle. Therefore there is no additional tool required to have a full spectrum of this alert’s visual representation on all platforms.

Editor: Link Support
Preview: Web & App

Impact

This tool has been beta tested by all the PMs, copywriters, designers, and several engineers. The generated JSON file has been used to generate Sketch files by utilizing the Copy-Updater sketch plugin.

This project was kept syncing up with all related team members along with its progress. By the time of posting this page, the director of development has assembled a dedicated engineering team to implement the proposed data model and styles within our alert and notification system.