Adaptive-Shield Ticketing

Client

Adaptive - Shield

Team

Avia Fucks - UX Team Lead
David Budznik - UI Designer
Myself - UX / UI Designer

Deliverables

- Wireframes
- Figma files for development
- Animated Prototype

Requirements

As part of the risk remediation process, we were asked to add a ticketing feature to security checks within the Adaptive Shield app. This will help users prioritize, assign, and manage security issues more efficiently without leaving the app.

Challenges

- Design a simple flow for creating a ticket in Jira through adaptive shield.
- Integrating ticketing feature with the current remediation process seamlessly.

Adaptive Shield Overview

Adaptive Shield is a Cybersecurity company that provides SaaS Security Posture Management (SSPM) services. Their services help security teams maintain a secure SaaS application stack by continuously monitoring SaaS apps, SaaS users, and their devices. They also identify misconfigurations, assess risks between different SaaS applications, and fix any weaknesses found.

Current Remediation Process

When a user accesses the security check page to investigate a specific security issue, a sidebar displays detailed information and remediation processes for both the security team to notify and the app owner to follow.

As part of this process, users can open a ticket through Jira to monitor the issue more efficiently. But there has been some problems with it.

Before Screen (UI): Security Checks sidebar / After user clicks on a security check

Problems & Pain Points

Through the use of a data matrix, interviews, and design partners, we have been able to identify the primary issues that users encounter with the current remediation process.

🔴

Manual Incident Reporting

Users are submitting incident reports via email and whatssup instead of opening tickets in Jira, causing delays and a lack of a systematic approach to resolving incidents.

🔴

Multiple Communication Channels

Incidents reported through various channels (email, chat, phone) result in a fragmented view, making it challenging to prioritize and resolve issues promptly.

🔴

Duplicate Incident Reports

Lack of visibility into reported incidents results in duplicate efforts, with multiple users reporting the same issue independently.

🔴

Incomplete Incident Information

Users provide incomplete information when reporting incidents, leading to a back-and-forth communication loop between support and users.

Research

The initial task was to provide a way for users to open a ticket directly through Adaptive-Shield's app instead of getting into Jira, enhancing the overall user experience.

We started our research by conducting a market analysis to understand current practices and trends in the domain of opening tickets.
Examining various products and platforms, we aimed to identify common patterns and pain points that could inform the design of our ticketing feature.

Creating a ticket in 'Jira'

Research Insights

We analyzed the "Open Ticket" feature and identified common characteristics that shape the subject of user-generated tickets. Although these products are distinct, our exploration revealed similarities in the fundamental elements of the ticketing process.

Consistent practices in providing contextual details ensure easy navigation and effective communication across platforms.

Common Ticket Patterns

🏷️

Context

🏷️

Subject

🏷️

Description

🏷️

Asignee

🏷️

Priority

Common Ticket Action

✏️

Edit

🗃️

Initial Solution

Before creating a ticket

We have collected all the necessary information regarding ticketing and user experience (UX) patterns. After analyzing the data, we began working on creating the ticket feature and how it will fit in with the existing flow.

By opening a ticket directly from the security checks sidebar after clicking on a specific security issue, we have found a logical and easy solution for users. It not only saves time, but also ensures that security issues are promptly addressed.

The sidebar’s current action bar presented an opportunity to open a ticket.

Open a ticket modal

After creating a ticket

We explored the best way to showcase ticket details After user created a ticket, and decided to consider either the Remediation or Journal tab.

We'll decided to use both - Remediation and Journal - to organize ticket information. Remediation will showcase main ticket details and status for quick access. Journal will provide comprehensive source for remaining ticket info.

Security Check Side-bar:Right - 'Remediation Tab' , left - 'Journal Tab'

Different actions for different tickets

Ticket statuses are designed to guide users through a logical workflow, aligning with the natural progression of issue resolution.

Each status corresponds to a specific phase in the lifecycle of an issue, and requiring corresponding user actions ensures that the system accurately reflects the status of ongoing work

Showing tickets on Security Check table

In the security checks table, displaying ticket statuses serves as a vital navigational aid and informational resource for users. By integrating ticket statuses directly within the table, users gain immediate insight into the progress and status of each security check without needing to navigate to separate screens or systems.

Visual cues such as color-coded indicators or icons alongside each ticket entry provide at-a-glance understanding, enhancing the user experience by reducing cognitive load and streamlining decision-making processes. For example, a green indicator may signify that a security check has been successfully completed, while a red indicator could indicate an unresolved issue requiring attention.

1 ticket per issue use case

2+ tickets per issue:
The last edited ticket will be on top of the tooltip, and the first to appear on the table

UX UI Case study

Adaptive Shield

Decreasing duplicate incident reports by 26%