Work Portfolio >


Niara was a network security startup focused on threat detection and incident response. The premise is that no matter how many layers of defense you put in place, you will eventually be hacked. The challenge is how quickly can you discover a security breach (not very quickly, it turns out), and how quickly you can respond. It was acquired by Hewlett Packard Enterprise in 2017.

As the first UI guy, my initial work was learning about the space, and how user tasks differed from my earlier experience with firewalls and VPNs. A major difference was that this was a tool in a security analyst’s toolbox. Configuration took a backseat in terms of priority.

The Product

By analyzing data from various network log sources, combined with behavioral analytics and 3rd party threat feeds, the Analyzer generated security alerts, and also computed a risk score for associated entities. “Entities” are things like:

  • User accounts
  • Device names
  • IP addresses

A user’s daily tasks might be:

  • Alert-driven: Investigating and resolving alerts
  • Entity-driven: Investigating and/or monitoring high-risk or high-value entities

The UI design provided for either workflow.

Starting Page

The initial page an analyst would see when logging in was user-configurable, and went through many design revisions. This was the design I liked best. It’s meant to be a starting point, and not intended for display on a big monitor in a security operations center.

Dashboard screen

Overview: The card on the left gives the analyst an overview, with counts of high-risk entities (by type), or alerts (by category). Clicking on any item here filtered the data shown in the cards on the right. This made the filtering relationship much easier to understand than some of the other designs we considered.

Cards: The cards on the right showed charts or lists, and could be configured and arranged to reflect a workflow that was primarily alert-driven or more focused on entities. Lists provided direct links to relevant detail screens, as well as a link to the full result list.

Detail Screens

Entity Details screen

Entity Details: Entity360™ presented a plethora of information about a particular entity (user, device, IP address), including a threat score over the selected time range). The screen also showed links to related entities, alerts, or conversations (all of which serve as pivot-points).

Alert Details screen

Alert Details: Similarly, an alert details screen shows info about an alert, as well as charts to show context, and links to related entities or conversations for pivoting or exploration.

Conversation Details (no screenshot): At the lowest level, this showed details about a network conversation (an episode of network traffic between a source and destination), with links to related alerts and entities. Additionally, analysts could retrieve packet capture data (pcaps) for study in a more focused application like Wireshark.


Investigation implies following leads, and the design provided rich cross-linking to support exploration and pivoting. False leads are a consequence of all that, and an ability to go back to a previous screen was important.

Navigation menu with MRU lists

Mega-menu Navigation: Of course, to go back, the Back button is always there. But the main navigation menu also provided lists of most-recent views and actions.


We anticipated needing a fairly sophisticated query syntax, like Splunk. But that would take time to implement, and an early UX goal was to make searching easy.

Simple search results

Simple text search: What could be easier than a simple text search in the header like Google Search or Apple’s Spotlight? This design provides a simple way to search across the various things for which a user can search:

  • Entities
  • Alerts (“events” here, because terminology changed)
  • Conversations (network flows)

Clicking a result would take user to a details screen, or a results screen with the appropriate filter set. This typical results list shows 2 other ways to avoid having to resort to advanced queries:

Conversations result screen

Tokenized input filters: More focused than the simple text search, these allow a user to do fairly sophisticated “who”, “what”, “where”, and “when” queries without having to write an actual query string. Values are implicitly OR'd within a row, and AND'd across rows. (We ended up discarding this part of the design.)

Facet filters: The sidebar shows hit counts for various fields of interest, allowing a user to get deeper insights about the current results, and filter accordingly.


As mentioned above, configuration UI was not a primary concern for design, partly because it’s not the main product focus, and partly because security analysts are often a completely different team from the folks who do the configuration.

Nonetheless, auto-generated UIs invariably suffer from poor usability and user experience. This eventually caught up with us. When we started adding more complexity for configuring data sources and rules for analytics, I did a complete survey of the existing config UI, discarded screens that were no longer relevant, and re-organized related functions and settings.

Configuration Overview screen

Information Scent: Besides describing a new information architecture for config, I added an overview page to provide visibility. From this screen, the user could:

  • get a high-level sense of what was configurable,
  • see what the current settings were, and
  • use deep links to each screen.