Fidelis Cybersecurity

Fidelis Cybersecurity was a massive product, with a complex tech stack and a very broad feature set. Its offering was spread across three distinct products: Network, Endpoint and Deception. The teams were geographically dispersed, each with their own set of engineers and product leadership, but dedicated design resources. The UI was built by frontend engineers using disparate out-of-the-box UI kits, resulting in three distinct visual languages for what was meant to be a cohesive set of products. Every page was an entirely new experience for the user, providing very little in the way of consistency or learnability.

My work as Fidelis’s sole product designer was cut out for me: I had to stand up a design system that could not only corral existing features and patterns, but provide a foundation of tokens, components and patterns to mitigate design drift moving forward. In addition, I wanted to take the opportunity to ensure the app’s UI synergized with other market-facing materials, including the website, social media, digital collateral, and Fidelis’s presence at trade shows.

I started by conducting interviews with stakeholders (CTO, VP of Engineering, Product leads, etc) to understand the “why” behind the current design, joining customer calls to observe their interactions with the product and get insights into any recurring friction points or learned dysfunctions, and collating the data to build behavioral archetypes. The discovery process at Fidelis was interesting. There was no such thing as a “casual user” – an analyst using Fidelis was always a power user. On top of that, because the UI surfaced data like emails, MAC addresses, IPs, etc, the majority of customers found themselves unable to share certain parts of their screen for information security reasons – especially if they were a government client. This meant that while I had some insights into customer behaviors and pain points, a good chunk of my work would be informed by heuristics, good Gestalt principles, and broader insights into user psychology.

Ideation took several months, and the eventual solution was a modular design approach. Because each analyst had their own preferred way of working, the modular approach would allow us to present experienced Fidelis users with the level of flexibility they craved, while newer users would be served out-of-the-box defaults oriented around common tasks. The core of most pages would be a tabbed, group-able table surfacing the core data set for that page. Selecting a row would yield a high-level summary, filled with plain-language explanations and easy-to-understand visualizations, serving as an inroad to further information depending on the user’s level of knowledge and willingness to explore further. The table would also be augmented by a slew of context-appropriate visualizations, which the user could reconfigure and save as pre-built dashboards to allow them to easily generate intuitive reports for any combination of data sets.

In order to “sell” the concept, I created a fully interactive prototype, leveraging fluid animation to showcase the flexibility this approach would offer. The prototypes were well-received by stakeholders and customers (engineers, of course, mourned the amount of work this would entail), giving us the green light to move forward.

0:00

Lo-fi, north star design was one thing: applying good design principles to net new features and pages in high fidelity was a whole different beast. As mentioned above, Fidelis was a massive, complex product, catering to experienced analysts in the network security space. As a designer, I leaned on the domain expertise around me to navigate the specifics, while keeping the larger user experience top of mind. In atomic design terms, the atom of the Fidelis information hierarchy was the alert - an event on a company's network, triggered by a specific ruleset. An alert could have any number of properties (equivalent to design tokens) attached. One of my projects was to redesign the alert details page. The previous design provided little in the way of information architecture: instead, it threw everything and the kitchen sink at the user, and expected them to find their own way around.

In my product design career, one of the recurring themes has always been workflows. How can we optimize the user’s workflow to align to their JTBD at that point in time, flattening the learning curve and reducing time to value? In conducting customer interviews and observing interactions with the existing alerts page, I observed that user behavior converged around three key themes: detection, analysis and response. Some users wanted to know what exactly led to the alert being triggered. Others were interested in the details (metadata) of the alert. And finally, other users wanted a way forward – how could they respond to the alert and mitigate similar activity in the future. This immediately pointed me to a workflow-first approach, coupled with a stronger visual hierarchy and the inclusion of visual anchors to augment (but not overwhelm) the experience.

The focal point of the page is, of course, the alert. To that end, I included a high-level alert summary in the upper-left corner, to align with a typical user’s Z-shaped eye trajectory, and included semantic coloring to quickly showcase the severity of the alert and add a splash of visual interest. I then dedicated the right-hand area to the three aforementioned workflows, separated by tabs, with content groups presented as drag-able cards. Finally, I made sure to not force users into the workflow mental model. In the upper-right, I offered a layout dropdown, allowing users to select from three presets based on their familiarity with the app.

0:00

Usability testing of the redesign page yielded very positive feedback: users appreciated the improved visual hierarchy, and the ability to hone in on specific JTBD related to alerts without being forced into a specific layout. Looking back, this redesign ticked a good number of boxes on my ‘successful redesign checklist’: design workflows-first, always include small delighters, introduce changes incrementally, and offer enough flexibility to not force existing customers into a new mode of thinking.

If you thought alerts were data-rich, wait until I tell you about metadata. In atomic design terms, metadata was (theoretically) the smallest unit of information hierarchy in the Fidelis app. Metadata presented itself as values (strings or digits) attached to transactions between a server and a client. Part of a network security analyst's day job is to observe metadata moving across a network and derive meaning from it. Unfortunately, metadata did not have a true place to call home in the Fidelis ecosystem, and it was my job to give it one.

In conducting customer interviews and understanding the archetypical analyst's interaction with metadata, it became clear that with such a broad data set, robust sorting, filtering and grouping would be needed. We could not predict which criterion an analyst would want to focus on, so we needed to present users with the most flexible solution possible. For me, this immediately meant a tabular presentation with a high degree of customization. One thing I did uncover was that criterion frequency and relevancy were important to analysts: to that end, I added two tabs, specifically around new, rare and frequent metadata. This would allow analysts to see all metadata by default, but provided them with a one-click solution to narrow down their search results if they so chose.

In the below design, notice the grouping structure of rows. As mentioned before, every transaction involves a client and a server: an origin and a destination. Each transaction is directional, but also has at least one sibling. In addition, notice the presence of toggle-able modules to the upper-right of the table. These are the toggle-able, customizable visualizations present in the new global design pattern.

0:00

The prototype was well-received, especially as it pertained to the discoverability of metadata. The time-based search, coupled with robust support for sorting and grouping, meant analysts could quickly hone in on relevant transactions and values. The grouping pattern had the added benefit to being scale-able to any table in the app.

In the animation, you can also observe one of my favorite prototyping/animation tricks – try to include a fake loader every so often. In real life, interactions and page changes are never instant, not matter how they are perceived. And with large data sets, page loads get pretty hefty. When building a clickable prototype, sprinkle in some loaders here and there for a touch of realism. I’ve presented plenty of prototypes where the client perceived them to be the actual app, largely due to the abundance of micro-interactions and the presence of loaders!

In order to scale, apps need to be designed systemically. This is the whole crux behind design systems, and specifically atomic design principles – define the smallest units, and build more complex units on top of an already solid foundation (the same principles apply for most other things in life). In practice, it’s much easier to stand up a design system for a new, green field product – for an older, more entrenched product, the notion of a design system becomes tightly coupled with a redesign, heralding an exponentially higher level of complexity. I learned this the hard way at Fidelis, and was able to use those learnings to my advantage at Ninety. The latter has its own dedicated case study (which you should definitely read as well), but this short story is about Fidelis.

When I came on board, the Fidelis app was messy. Consistency was lacking not only across the three main products, but across pages and features within a single product. Being a product that had been around for close to two decades, however, meant that customers were used to a certain experience, and my role wasn’t necessarily to upend all that. Parts of the app worked just fine. My role was to survey existing patterns and elements, find the “average”, refine the average, document it, then (re)deploy it to both legacy and net new pages. With a green field app, I have the luxury of looking forward – with a legacy app, I have to look both forward and backward.

Step 1: Survey Patterns and Elements

This step was probably the most laborious, but also one of the most important. It involved familiarizing myself with the legacy app across all three products. There was no easy way around it – it took a lot of clicking, screenshotting and note-taking. In some cases, when documentation wasn’t enough, I had to lean on other team members to understand what the heck a page was supposed to do.

Step 2: Find the Average

Everything’s got a middle. The nice thing was that Fidelis, like most webapps, used a fairly standard set of atoms – buttons, inputs, radios, the like. My job was to identify the larger units – organisms, molecules and layouts. I was able to reduce the app to five primary categories, which would form the basis of my modular design approach. These categories were higher-level nav, lower-level nav, main content (usually tabular), content details, and visualization widgets.

Step 3: Refine the Average

This step was, naturally, almost as laborious as the first – while some elements were pretty close to the ideal state, most needed a degree of refinement to get them into parity. The biggest chunk of this effort was taking hard-coded inconsistencies and refining them into variable-based tokens. This included things like colors, typography, spacing, radius, etc. I didn’t do this in a vacuum, but rather in the context of ongoing design work – seeing the tokens and components together helped me get a better sense of synergy between them.

Step 4: Document the Average

My software of choice at the time was Adobe XD (I have since seen the light). To document the refined design system, I created an interactive version in XD, allowing developers to move between styles, components and patterns in both light and dark mode, and quickly pull up mockups, variable names and values for anything they might need.

Step 5: Deploy

While working on the Adobe XD version of the design system, I also partnered with a developer to build an analog in Storybook. The latter is a great solution for housing and surfacing component libraries, and is flexible enough to grow into a full-fledged design system in its own right, coupled with brand imagery, robust plugins and ample documentation beyond engineering. This was a key piece of the puzzle in operationalizing the design system. Copying the mockup is one thing, but actually having the styles and components defined in Storybook (and in the codebase) makes a design system “real”.