Project case study

AppScan Design System

Time: 2018-2022.
Role: UI Design lead / Design System owner

overview

HCL AppScan is a leading platform for Application Security Testing (Gartner, 2021). Their products help large-scale organizations to test their code for vulnerabilities and manage their risks.

Why a Design System was needed?

  • Efficiency: Enable a small and highly professional design team to support a full-scale offering of highly technical, large, and rather complex security tools.

  • Consistency: AppScan, as a whole solution, needed consistency across its different products and tools, each already mature in its own right.

  • Positioning: AppScan was newly acquired from IBM by HCL Technologies (2018), which required in-depth design changes, and flexible infrastructure to support it.

main challenges

Legacy management

Most AppScan products were already mature, familiar, and well-trusted within their niche. Changes had to be conducted with consideration.

Cross- Platform continuance

Different AppScan products provide different abilities of the technology through different contexts. From SaaS to Desktop (Windows native, Linux, Mac OS) to 3rd party IDE plugins (VSCode, JetBrains IDEA). Products needed to remain seamless with the user environment of choice, yet conform to its sibling AppScan products.

Acquisition

Support the new positioning of AppScan products by creating the right overlapping area between the new HCL brand guidelines and AppScan products’ business logic, content, and interaction.
The team of HCL COE were extremely helpful guides and partners.

Core Principles / general approach

Negative space:

Planning a Design System for slow adoption by mature, complex products, means knowingly planning to contain design gaps and differences within the offering for a transitional period, while gradually building UI consistency through them. I wrote about the Negative Space of Design Systems here.

environment before cross-product consistency:

Natural integration with the user's environment of choice (web, Desktop apps, IDE plugins) is prior to cross-product conventions.

Content Patterns before Interaction Patterns:

As UI patterns might differ in order to adapt to certain hosting environments, System content (security tests findings, data objects, etc) should retain consistent structure across different visual environments as key to cross-platform consistency. I wrote a bit about Content Patterns here.

Lean patterns library:

Highly selective about what is standardized into the Design System, including only guidelines, atomic/ molecular components, and core basic layout and interaction patterns.

Fully adopting products (by 2022):

AppScan Standard

AppScan Standard is a Leading industry tool for Dynamic Application Security Testing (DAST), used by pen-testers and security experts, designed to work specifically as a Microsoft Windows native application. 
The complexity of the product required a dedicated Desktop UI designer who worked through Windows Fluent Design System and crafted UI solutions that leveraged both AppScan’s strategy and the opportunities the Windows environment provided to create an optimal experience.

AppScan on Cloud

AppScan on Cloud is a cloud-based platform, provides organizations with rich monitoring, triage, and scanning capabilities.
While working on this product, we also laid the foundation of the UI guidelines, components, and design conventions at work throughout the overall AppScan's design principles, guidelines, and web-based products. 

AppScan CodeSweep

CodeSweep is a Security tool installed as a plugin within different IDEs, such as Jetbrains IDEA or Visual Studio Code, Allowing developers to test while coding.
We were applying our content patterns and basic design guidelines to keep the AppScan data recognizable and consistent with it's original representations, yet seamlessly integrated into the IDE environments.

Brand Values and Design Tokens

Brand Values and Design Tokens

Brand values and design tokens were sent downstream from the HCL COE team, mapped into essence within the AppScan context, and shared across all AppScan products.

Component management

Generaly, the already coded components were treated as SSOT, while the UI design tools were used for testing new concepts before coding them, and for documentation after implementation is done..

Component library

A lean component library was created, based on repeating interaction patterns and content patterns mapped across offering tools.
As the components were based on a web environment, gradually adopted by AppScan on Cloud, a shadow library was developed by the desktop team, based on Fluent Design System, leveraging on Windows 11 advantages to enhance the experience of AppScan Standard.

scheme and workflow

General reference for dynamics between Design and Code, loosely reflecting our approach

Storybook

SSoT. Current code implementation as a committing point of departure at every step.

Figma

Beyond design platform, serves as communication, design knowledge base, experimentations mudbox and documentation of designs already approved.

Documentation

Contextually located within Figma and Storybook, gradually materialized into an independent asset.

“Avin developed our product design system, which help us to revamp our products and have a better alignment across the offering. We have great synergy…And he was a part of the team's maturity. His availability to the team was outstanding even when we were in different time zones.”

— Itay Levin, Head of Design at AppScan