Case Study: Balbix Dashboard

A central idea for Balbix is that you cannot defend what you cannot see. Beyond that, you need to know where to prioritize your cyber risk mitigations. Balbix' mission is to make cybersecurity risk visible to non-technical executives (to include the CISO, in some cases) so that they can stand confidently at the helm and direct cybersecurity operations.

A Product without a Feature

Balbix started as a jumble of data on spreadsheets and became a powerful inventory enumeration and assessment tool within a year. Companies were struggling to identify the assets on their network. Given that many were simply unable to identify what was connected in their environments, they could scarcely begin to speak of the amount of cybersecurity risk to which they were predisposed.

Making it Real

I had a bit of a personal mission coming to Balbix -- a low bar to clear -- but all the same, I wanted to make sure that the people using our product wouldn't grind their teeth when they went to log in. I had seen the boredom and disappointment of enterprise software users at my previous company, and I was not going to let that happen. When we got to creating UI, I was going to do this by bringing in a little bit of fantasy into the world of our cyber professionals.

But we had to start with the basics first of course, and build off of conventions and the few expectations of our would-be customers.


Creating a new product concept from scratch was a new experience for me. As a company we were building something that many people had never imagined. So when it came to getting started, It didn't feel like the right choice to leverage existing paradigms for expressing network layouts. The one's that existed were unimaginative and built more in line with technical limitations than with user's mental models. We also certainly couldn't leverage an existing paradigm for visualizing IT infrastructure risk, because it didn't exist.

Building the Dream

A lot of the features that were being phased for development were going to be "in the works" so to speak for years. The models and sensor observations informing the UI were all being conceptualized well in advance of their actual existence, but the value of our product depended on those observations.

We knew we were on the right track, we had begun the process taking the user into account from the beginning. Our UI was an extension of the User Story and Journey Maps we were creating, and we had a shared understanding of the who the CISO was.

Who is the CISO

This persona was something I hadn't experienced before. The CISO role is notoriously ambiguous, the career fields that funnel into this space are wildly diverse (Google's equivalent is a Marine biologist turned Medieval History buff, another I met was a Marine Corps band leader turned security pro), so nailing down the persona struck me as a stronger challenge than the personas I had worked with in the past. Nevertheless, I knew we needed a persona to at least focus our conversations.

CISO Persona

What did you say you do here?

Understanding what our future customers were currently doing to report on cybersecurity risk was also challenging. There are very few common practices among CISOs even today, let alone three years ago. The concept of Cybersecurity risk reporting is something I've only been seeing as a topic in popular blogs in the past half year.

Nevertheless, we had to deliver a product that we knew CISOs would need in the near future, even if many didn't think they needed it today. Since then the practice of CISOs reporting risk directly to executives has doubled

“According to a new study, data security is now on the agenda in most boardrooms. Yet only 14 percent of information security chiefs report to the CEO.”

Ian Barker, Beta News 2016

Click to view original article

“...25.4 percent say their CISOs report to CEOs...”

Andrew Morrison and Sandy Herrygers, FEI 2018

Click to view original article

Beginning the Interface Design

Probably everyone starts with a Design Thinking or The Design Sprint methodology and works it into the social dynamic they have been hired into. In my dreams, maybe like yours, I'm extremely rigid about how our company designs and I educate everyone perfectly on the benefits of a thorough and detailed process up front. The reality is that many people do not design products. And it's not because no on einvited them to try. They simply don't want to, or they have prioritized other things as more important.

Determining Customer Needs

With the level of buy-in that I had, knowing what to build seemed to be as simple and as difficult as understanding who we were building for, what they were currently doing, and what they would like to do. We started by understanding the person, to understand how they interact with the world around them, and where we could seamlessly fit our product into that world.

Who are they? -- Personas

You can imagine one product made for a soldier and one made for a ballet dancer would be different. The products would live in different worlds, and generally speaking there is a perception of quality that comes along with alignment to those worlds.

While our would-be customers were diverse, they had enough comonality to be able to deliver experiences based on the set of conventions they were commonly exposed to. Once we knew who we were building for, we had to know what to build.

What do they do? -- User Story Maps

This has been where I get the most value from the entire design process. Knowing what your customer's journey looks like. What they were doing before, during, and after the task in question, almost feels like cheating when it comes to design. Here we find the spot for the missing puzzle piece that our customer has been waiting for. User Story Maps (USM) are central to my design process. It is the tool that gives me a process I can look at, and that process answers many of the questions around what needs to be completed and when. I've found if you do at least this, you will have a usable product.

Develop Empathy

Journey Mapping is a technique we used to coordinate understanding and to enhance empathy around user workflows. In this case, talking through a user journey with product stakeholders helps the team align on which areas of the journey will be important to focus on from the User Experience perspective, and make the conversation around allocating resources to UX considerations a lot easier with the UX skeptics.

Journey mapping helped me think through and prioritize where to focus efforts related to enhancing usability and reducing pain.

User Interviews

The USM is best informed through direct customer contact. Customer interviews give us a chance to capture the details of the user's journey's that we can then bring into the USM. I would love to be able to watch customers go about their daily lives as one would an animal in a lab, but I have rarely had this chance. In most cases, the user interview is the closest I get to direct observation of the user's daily life.


This has been where I get the most value from the entire design process. Knowing what your customer's journey looks like. What they were doing before, during, and after the task in question, almost feels like cheating when it comes to design. Here we get a chance to sketch the missing puzzle piece that our customer has been waiting for.

User Story Map with the stories moved into phases to help guide deployment around usability considerations

Collaborating with Non-Designers

Without the buy-in of managers and executives, the design department can push out exceptional products all day long, but have them unopened in an executive's inbox for the rest of eternity. That is, if they haven't done the work to get buy-in, or "alignment" on the design process. As I said earlier, I tried everything I knew to get our stakeholders educated on UX Best Practices up front. At first it felt like a complete victory, then you realize that, as can happen without documented personas and mapped workflows, that while we spoke the same language, there was different meaning behind the words.

The conversation didn't degrade too badly, the UX maturity level of our organization fluctuated between a 2 and a 3, if you are familiar with the Nielson Norman Group scale, and in the end I was happy with how much we had accomplished, with so many intelligent, motivated and opinionated people.

Sketching and Mockups

I was taught to always start designing with pencil sketches. There is not freer method of getting ideas and options out of your head. They are the quickest way to iterate through ideas, to help others visualize what you are talking about and to help you determine the layout of your product across different form factors. We sketched together on white boards, on paper, and we used this to communicate rapidly. Without markers and pencils, we would have been talking our way in circles.

The Theme

This being a new product without legacy components and styling, I was really happy to take a chance with bringing some fantasy and magic into the lives of our customers. I started looking for a theme that spoke to a security practitioner's imagination. I borrowed ideas from popular movies' representations of hacking UI for this.

Because we had to communicate a rather complex concept such as IT infrastructure risk in a way that was actionable and easily prioritizable, it seemed natural that we should use gradients to do this. Red, yellow, green seemed like a natural choice. Of course, I was concerned with accessibility of these colors to those with color-vision impairments and proposed a single color gradient, and in some cases the use of icons to represent scoring differences, but this consideration was not brought into the product.

Accessible concept leveraging gradiants, shape and icons

The red, yellow, green palette we went with

Micro-interactions to Bolster
Perceived Quality

The back-end and machine learning algorithms had barely come together at the time the front-end was being rolled out. We knew what it would do, and we knew it would be powerful. Until then we had to give users a sense of quality and trust in the platform that they weren't going to be able to scrutinize in great detail initially.

With my initial intention to make our UI something the customer would be happy to come back to, and now the need to communicate quality in the absence of fully developed features, it was clear to me that micro-interactions, and well-tuned front-end interactions were of the utmost importance to build trust.


Enter the sunburst. Not only a fun way to navigate one's assets, but built on the understanding we gained from user interviews and card sorting, the sunburst allows users to dive into their networks with their "risk microscope," as our CEO would have it.

Sunburst interactions intended to bolster perception of quality as well as support navigability in an enjoyable way.

Risk Bubbles

Another way we increased delight in the product, and brought meaning to (at the time) difficult to organize risk measures, were the Risk Bubbles, which allow users to view their network by assets grouped by similar qualities and ailments. The idea is that the bigger and redder a bubble is, the more important. We allowed for reorganization of them allowing for a mapping to the user's infrastructure context.

Size and color used to rapidly assess value of assets and the dangers they face (Impact and Likelihood of Breach)


As I said, the UX maturity level of our organization fluctuated between a 2 and a 3, and it was difficult at times to communicate the advantages of testing with prospective customers and non-customers to an executive team that was protective of sales opportunities and intellectual property.


In the beginning, I was fortunate to have a team of former CISOs I could refer to, who were not involved in product development. I had opportunities to test them and capture observations of their mental models and their descriptions of workflows.

In situations where I knew they had encountered the concepts of the feature previously, I paid attention mostly to how quickly they seemed to comprehend and manipulate the afforded UI they needed to accomplish a task, paying less attention to their qualitative feedback.

Example of a test I administered


As time went on, I was given a chance to work with design partners and newly acquired customers and could review their interactions in similar tests to those I had administered internally.

We surveyed customers to capture their preference for features that user story maps had uncovered as valuable to their workflows, and used those to help prioritize our newer feature phasing.


While we never seem to get to perfection in the design process with all the stakeholders that take part in it, such is the nature of collaboration and working with others. The profound nature of this product and the nature of the company's goal to save the world from cyber risk was captured and came through in a better way than we anticipated. Today we have a number of customers who praise us for how we simplified this problem. We've taken complex formulas and statistics and turned them into something as easy as paint-by-numbers. We've made it simple for them to investigate, act on, and communicate what was once actually impossible.

<< Go back to Portfolio

Alex Sawsienowicz

UX Designer

Alex Sawsienowicz
500 Railway Ave. #303
Campbell, CA 95020
(408) 839-5430

Email Address