Better Security Through UX Part 3: Responsiveness & Performance

This series explores how good UI design plays a key role in keeping users secure by making them more inclined to trust and use their cloud security systems. In Part 1 and Part 2, we examined the onboarding process and the visual design of Threat Stack’s Cloud Security Platform™. Here, in Part 3, we’ll look at an unsung hero of UX design — front-end performance — and its impact on the UI’s responsiveness to user interactions.

Responding at Human Speed

“Conversational UIs” are a hot topic right now in interaction design, and underlying the appeal of that concept is the reality that we have very high expectations for how quickly systems (and people) respond to us when we interact with them. Think about having a face-to-face conversation with a friend. When you say something, the natural rhythm of dialogue typically dictates that they respond within 1 second or less. We’re attuned to this timing on the millisecond level; if your friend is silent for 2… 3… 4 seconds, you start to wonder what they must be thinking. When a website fails to respond for that same interval, you wonder if it’s still working at all.

The margin for error is very low when designing for performance. Users expect pages to load in 2 seconds or less; after 3 seconds, frustration starts to set in. Responding quickly builds trust; failing to do so erodes any goodwill that the rest of the design may have gained.

As systems get complex and data sets grow huge, responding quickly becomes a major challenge. There are two ways we can address it: improving the system’s actual performance, and improving its perceived performance.

Speed and Scale

At Threat Stack, the concept of performance is inextricably linked to the concept of scale. Some of our customers are monitoring two servers. Others are monitoring thousands. But the experience of getting data in Threat Stack should feel the same either way. We provide our customers with a means to see what’s going on in their entire environment and feel confident about their security, and they should be able to feel in control of that experience, no matter what their scale.

Let’s take the Alerts page as an example. This is where most customers spend the most time in our product. So this is an area where our Engineering team has worked hard to make sure that whether you have 30 alerts or 3,000 alerts, the load time on this page is lighting fast.

BSTUX3_AlertsPageWithTabs.pngThreat Stack’s Alerts page UI

The Alerts page has tabs at the top for the most common views: Severity 1 alerts, Sev2, Sev3, etc., with Sev1 as the default selection. All the fine-tuning our engineers have done here relates to the critical rendering path — optimizing the progressive display of information to answer the single question that’s top-of-mind for our users: “How long before I can see my latest Sev1 alerts?”

To shave as many milliseconds as possible off our answer, we render the alerts on the Sev1 tab first thing, before many of the other components on the page have finished displaying. We sort those Sev1 alerts by when they were last triggered, to ensure that the most up-to-date information comes in first. In fact, we defer loading any data for the Sev2 and Sev3 tabs until Sev1 has finished rendering, to get as close as possible to the holy grail of loading what you need most in 1 second or less.

Beyond the initial render, other techniques are at work too, to ensure that the page stays responsive as you continue scrolling down through older and older data. But in the end, of course, no one should notice any of this complexity or effort: the UI “just works” — which is exactly what we’re going for.

Managing Perception

We try in every case to deliver the shortest data load times possible in our UI. But often there comes a point where the investment of effort into getting faster outweighs the marginal benefit. Fortunately, in these cases, we have other techniques available to improve the UI’s perceived performance.

Perceived performance is about setting expectations and bringing the user along with us in the sequence of getting from an action (e.g., button click) to a result (page load). As long as they’re confident that the system is getting to the result, and hasn’t failed or forgotten them, then we can avoid frustration and keep the experience moving along smoothly. Every interaction responds immediately with something, even if it’s not the full result; then we fill in the details progressively as they’re available, in the order of importance to the user. (For more on the foundational concepts of perceived performance, check out Ilya Grigorik’s High Performance Browser Networking.)

A good example of this is a type-to-complete selector control that we’re currently developing to support new functionality (coming soon!) for using server tags in Threat Stack.

BSTUX3_SelectorControlDiagram_Border.pngTag selector control (currently in development)

When you want to assign a tag to a server or to an alert rule, we want you to be able to immediately find the tag you’re looking for. And since a customer could have hundreds of existing tags, this UI expectation comes with a potential performance challenge. If we can’t show all the information the user needs instantly, the way we progressively display the result keeps perceived performance high.

When a user clicks into the selector control to select one or more tags, the very first thing they see is the appearance of the tag list container (a white box). This can be displayed instantly, but we also animate it (fading in and sliding down), which catches the user’s attention and distracts from any delay in loading the tag data — without any hindrance to perceived performance.

Next, we display the actual tag results inside the container — tag names, plus a badge showing what type of tag it is. This is enough for the user to begin typing to filter the list toward the results they want.

The last piece of information that we show is the count of servers using this tag; this is useful for helping users distinguish at a glance between frequently used and seldom-used tags, especially if the names are similar. We can load the blue badge itself immediately, but getting the actual number inside it is a separate data request and may come back more slowly than the rest. So to mitigate the potential delay, that blue badge shows a “loading” spinner at first, which is replaced by the actual number as soon as that data is available.

Once again, if we’ve done our job properly, all this complexity happens under the hood, and is essentially invisible to our users.

Back to the Benefits

As I’ve mentioned before, Threat Stack is a power tool in the hands of our users, and we want it to feel like one. Getting to that point has required the focused effort of our front-end engineers (among many others), aligned around a vision that’s central to our company: speed and scale are critical to success.

To meet or exceed our users’ high expectations, we engineer our UI to be as responsive as a well-built sports car, with feedback that feels as immediate as talking to a person face-to-face. This helps our users to feel, and to be, more productive, which encourages them to keep using Threat Stack — to keep doing the work of securing their organization.

References and Further Reading