OpSec Smart Tabs (HUD) 
Single View to MultiView Smart (HUD) Heads Up Display

Problem - During data collection and the review of exit interviews, it was discovered that trust was a factor that customers leaving have been dealing with for extended periods of time. We decided to include trust in our Matrix of success. How do you measure trust? It's quite difficult to measure trust because well, it has to be qualitative in nature. Other issues like latency also arose during data collection. 

 

 

Solution - The system was originally designed for a single view experience. Meaning it was not possible to display multiple views at the same time.  I came up with the idea of leveraging the concept of a smart heads-up display. A heads-up display that would allow for the compensation of latency while looking at other work as the system was processing. Ostensibly the use of times. Smart tabs. Times that would communicate with each other as the analyst's work was chipped away over the. Of a day across too many of their custom views. For instance, from Amazon listings to eBay listings to listings on other major Global Market places such as China's Taobao. 

 

The idea of a heads-up display was specifically formulated to address the issue of trust. If customers could see that our system's custom views were talking to each other end updating throughout the workflow the belief was that it would then establish trust that the system was intelligent. In fact, in the background, lots of information like metadata was being utilized and stored. The decision to expose some of that metadata to establish the idea of a smart system was decided upon.

bulk.export.profile.png
Before: A single view module.
Tabs_Light_UI.png
After: A Multi View Smart HUD module.
Initial anatomy and UX/UI Recommendations
TAB ANATOMY.png
UI THEMEING.png
TAB HEIGHT.png
COMPLETE TABS.png
A Customizable HUD for different customer/user workflow needs.

A customizable Heads Up Display.

Depending on the need of the customer or analyst, the heads-up display can be customized in terms of adding different kinds of collapsible dashboards/bars. This tailored approach allows for efficiency gains across customer workflows and CMS’s access to data across many Personas Woday do day work. 

 

These features can decrease the number of clicks to access existing data within the system but at the same time deliver analytics helpful to the analysts/CSMs/Operations, during their workflows. These collapsible dashboards/bars can be assigned to Custom Views/Tabs.

 

Anatomy - HUD.png
Avoiding Grid Homogenization

Harvester Based Scan Scheduling

 

  1. Why is scan scheduling important? 
     

  2. Why do analysts need to understand when their scans are ready to review?

 

For listings to be ready for analysts to review, they must create a scan that the Harvester will process and get listings. Creating a scan is a small workflow consisting of filling for information specific to the brand, the product, its keywords, when the scan should run, what marketplace it should run, and other factors. Every 24 hours, harvester scans will run and return results for analysts across all global marketplaces. However, errors happen all the time. Scans need to be rerun. Understanding when scans will be finished is not a science.

 

Often there are delays and compromises. Analysts cannot start their work until their scans are ready to be reviewed. Therefore, having predictable scheduling is critical. The scan scheduling dashboard helps to solve that problem.

 

On average, most analysts run between 50 and 600 scans daily. A small percentage of those scans actually produces the largest amount of enforcement. However, numerous scans are running all of the time for all analysts.

Screen Shot 2021-04-23 at 5.05.45 PM.png
Light - Blue Theme.png
Scan scheduling dashboard (Light Theme)
Screen Shot 2021-04-23 at 4.38.28 PM.png
Screen Shot 2021-04-23 at 4.38.49 PM.png
Scan scheduling dashboard (Dark Theme)
Screen Shot 2021-04-23 at 4.41.03 PM.png
Screen Shot 2021-04-23 at 5.08.37 PM.png
Anatomy - Harvester scan scheduling dashboard

Data Grids for Scan Scheduling

 

Multiple data grids are composed and the primary view of the product. One of those data grids is for scan scheduling. To avoid the monotonous or homogenized impact of looking at multiple data grids that all look the same,  we've tried to make the scan scheduling grid very slim and composed of color and a high contrast environment.

Anatomy - Harvester scan scheduling dash
Anatomy - Harvester scan scheduling dash
Scan scheduling dashboard
Light - Blue Theme.png
Screen Shot 2021-04-23 at 12.39.22 PM.pn
UI Requirements for grid rows hover states, action-bars, and notifications.
Brand Protection - Grid row states & hov
Light theme grid rows, action bar, and notification cards.
Brand Protection - Grid row states & hov
Dark theme grid rows, action bar, and notification cards.
Accessibility readings for grid rows and hover states
Screen Shot 2021-04-18 at 5.52.47 PM.png
Use of Figma's Accessibility plugin.
UI Requirements for grid rows hover states, action bars, and notifications.

Prototype - Grid Row Selection

 

In this prototype, you'll be able to experience cooking on multiple grid Rose and deselecting them using the centralized right-click tool. Additionally, you'll also be able to select 500 rows at a time and  Classify them as enforcement. Once they're classified you'll notice the listing number or total will drop in the upper left-hand tab.

Prototype - Navigate to the completed scans grid.

 

In this prototype, you'll start off in a dark theme.  You'll then open the Sands scheduling dashboard by clicking on the carrots. You'll notice the dashboard will expand. Then click on the icon or look at the completed scans. This will open the completed scans grid. Reverse the order to go back.

Dat Tables - With 80% of the product viewport real estate data tables, they need to clean, be readable, and pass accessibility.

Data Grids for Scan Scheduling

 

In the early stage of this case study, around 2018, the majority of the data tables the company was using, more or less, were identical. Cut in between one data table to another from one module to another. You would never know you had actually changed from looking at 1 style of data to another unless you noticed the column headers change.

 

Homogenization of data was an obvious problem and clearly broke several heuristics of usability. Ultimately it was challenging for people to understand where they were in the system because of the degree of homogenization. Standardizing data tables to look subtly different for different aspects of the workflow and different data hierarchies based on row height is finally approved.

Accessibility standards of Triple-A (AAA) and Double-A (AA) were defined as accessible by the product team and the Figma plugin for accessibility was used to further Define and approve the standards of readability across the data tables.

https://www.w3.org/TR/WCAG20/#visual-audio-contrast

Anatomy - Grid row themes and UI requirm