[UX] First time user experience improvements in Security Analytics

[xeniatup]

Is your feature request related to a problem?
Based on the findings from the usability study on First time user experience with Security Analytics we propose a number of improvements to help users to onboard the plugin.
The definition of "onboard" is having a threat detector for a data source. User navigates to “Create detector” page from the Overview page or by using the plugin navigation menu (Detectors → Create detector).

1. The plugin landing page (Overview) doesn’t provide the guidance clear enough on how to proceed in order of priority.
2. The “Create detector” flow is very complex and users might not know what fields they are supposed to fill and how.
3. The “Field mappings” part is confusing.
4. It might be difficult to find the end of the flow and figure out the status of the detector that has been just created.

Update in User Experience

Overview page

1. We propose to improve the visibility of “Create detector” CTA on the page by adding it as a primary button to the header and to the empty state of the "Findings and alert count" section. (OuiPageHeader, OuiEmptyPrompt).
2. The content of the “Getting started” popover is updated to provide the hierarchy of the buttons and emphasize the “Create detector".

Create threat detector flow

Step 1 - Define detector

• We propose to refresh the layout by placing the sections of the flow on a single panel, which removes a lot of visual noise and makes the page cleaner.
• Define a clear hierarchy of the headings and organizing “Detection” section that covers Log type, Detection rules, and Field mappings.
• Addressing empty states for Detection rules and Field mappings
• Field mappings section:
  • communicate the hierarchy between mapped fields and available fields by adding tabs and opening the tabs in the right order
  • provide descriptions to explain the relationship of the fields with the detection rules
  • tone down the overwhelming number of callouts and replacing them with more neutral descriptions
  • update on the UX copy to clarify the terminology

Step 2 - Alert trigger

• Simplify the choice to skip creating alert trigger vs. adding one:
  • set “Create alert trigger” to default by pre-filling the trigger name for seamless experience
  • remove the “Skip” button, user can delete the default trigger instead to opt out of alerting
• Clean up the hierarchy of the accordions on the page:
  • One top level accordion for each trigger covering sub-sections in the nested accordions (Trigger condition+Name, Notification channels, Notification message)
  • When trigger conditions are changed, they are reflected in the description of the accordion
• To prompt user to select a notification channel, collapse the trigger details accordion and emphasize the Notification channel nested accordion
• Show empty prompt in “Notification channel” nested accordion (expanded by default) when there are no channels configured in the OpenSearch Dashboards instance.

Step 3 - Review detector

We propose to remove the review step for the detector to address the potential point for confusion and reduce complexity of the flow.

Messaging on detector creation

• After submitting the form user navigates to the “Detectors” page (list view) with a success toast message. The detector displays “Initializing” state.
• If the form submission results in an error, user stays on step 2 of the Create detector flow to address it.
• After the detector is transitioned from "Initializing" into "Active" status we show a success/error toast message.

[kgcreative]

@xeniatup -- do we have a target release for this? Can we link it to any ongoing PRs?

[xeniatup]

@kgcreative I believe we're targeting 2.11 with this.
Here is the corresponding PR: #738

[dblock]

Did this ship in 2.11? Can we close it?

Catch All Triage - 1 2 3 4 5

[xeniatup]

cc @amsiglan