As someone who worked for a company whose logo was itself red, I spent years cajoling some unhappy marketing people to create a black version of our logo for our products to use on screen. For the people whose job is to respond to red things, filling the top fifth of the screen with red corporate branding can slow their response time. They could overlook the alert entirely. Often by the time a critical alert pops up on your screen, it\u2019s too late. The horse has left the barn, and the barn is on fire. Still, acting within minutes could mean the difference between a quiet afternoon and a corporation-altering disaster, as we will see.<\/p>\n
Context switching<\/h3>\n
UX problems also arise when designers burden users with unnecessary context-switching. Researchers at the University of Notre Dame ran a study<\/a> where people stood at a table on one side of a long room and arranged some elements. Then they walked across the room to complete the task at another table. They did well until the researchers partitioned the room, leaving a doorway between. After that, completion rates plummeted.<\/p>\n The study invoked that common human experience of walking to another room to get something and forgetting what it was upon arrival. You didn\u2019t lose your mind; you gained a partition, and an additional context to inhabit.<\/p>\n The researchers proposed that our physical location defines the larger context in which our minds operate. As we change locations, our minds dehydrate our previous context to focus instead on our new context. You leave your living room to make popcorn, and the moment you cross the kitchen\u2019s threshold you forget why you\u2019d gone in there. Walk back to the living room and your mind rehydrates that context, and you remember, popcorn!<\/p>\n Here\u2019s where it gets weird. The researchers repeated the study but had subjects sit in front of computers controlling a human figure on screen. In a long virtual room with a table at each end, people did okay, but when the researchers placed a virtual partition in the virtual space, completion rates tanked again.<\/p>\n A cybersecurity system with a rich range of functionality can certainly look complicated; often they\u2019re designed from a simplistic perspective, with one table on each screen\u2014essentially one view for a table of settings, another for a table of security events. Although this approach may make a developer\u2019s life easier and appear efficient, navigating these individual contexts with a virtual wall between them takes a serious toll on the minds of cybersecurity professionals. Reviewing those security events and repeatedly checking them against the bundle of settings is like walking from kitchen to living room, trying to remember the popcorn. And assume you\u2019d have to drill down into yet another view to see the details of each event.<\/p>\n Unfortunately, the designer I managed would see the results of that problem first-hand. I sent him off to a large customer site to sit among those awash in monitor light. What he learned was crucial to his grasping cognition and context.<\/p>\n He spent two days shadowing a senior cybersecurity analyst, an older man with a lot of experience. The first day he toured the facilities, and saw the massive amount of networking hardware, with cybersecurity appliances from various vendors racked and stacked alongside the machines that ran the business.<\/p>\n The next day he sat near the senior analyst\u2019s workstation, peppering him with questions about workflow and priorities. After a long silence, the analyst waved to get the designer\u2019s attention.<\/p>\n \u201cYou know what really bothers me? This.\u201d He pointed at what looked like a dense spreadsheet but was actually one of our user interfaces. \u201cThis right here, and this.\u201d He pointed to a different display, at a different user interface\u2014newly one of ours from a recent acquisition. \u201cThese things use different words for the same thing.\u201d The customer\u2014the kind of seasoned analyst who\u2019s basically a muse for cybersecurity products\u2014was pointing out failures of consistency. These rob people of cognition because they force the user to keep switching models and contexts.<\/p>\n Even worse, he went on, it wasn\u2019t just that the words are different\u2014the taxonomy wasn\u2019t the same. Something as simple as \u2018source\u2019 and \u2018target\u2019 weren\u2019t always consistent.<\/p>\n \u201cIf my computer connects to Google, then I\u2019m the source<\/em> of the connection. But in this other product of yours, if I download something bad from my inbox on Google, then I\u2019m the target<\/em> of the event.\u201d<\/p>\n Although his understanding of the many products from the various vendors was deep, he still had to click down into little pockets through to other views to verify things. \u201cSome days are easier than others, but sometimes it\u2019s too much,\u201d he said with exasperation.<\/p>\n He pointed at each display. \u201cAll I know is that between this event over here and this other one over there, I feel like I\u2019m missing something.\u201d His user experience was like walking through a house with too many rooms.<\/p>\n The designer then told me the analyst had been right: the two events had been reporting on different facets of the same dark crystal. By the time the analyst caught it, the barn was on fire.<\/p>\n In just a few days, the whole corporation was offline. A group known to be associated with a malicious nation-state would dump corporate email, sensitive documents and other intellectual property for all the world to see. They had to build a brand new network infrastructure, parallel but separate from what already existed\u2014everything new from service providers and routers to firewalls and switches, email and file servers\u2014as well as every computing device used by everyone across the company. I have no idea what that cost. I wonder if they knew\u2014forget about time and materials; what were the opportunities lost?<\/p>\n Many things could have prevented this or stopped the attackers as they infiltrated the network, or as they exfiltrated terabytes of data\u2014which was what I believe the analyst had spotted in a twist of taxonomy. A shocking amount had begun to move in the wrong direction\u2014all because we, as human beings, have only small bits of brain power to focus on any one problem at a time.<\/p>\n Our most precious cybersecurity resource is our own cognition. Our own brains flatter us, and work hard to maintain the illusion of greater intelligence. But the cybersecurity tools which were supposed to secure that company robbed that man of his cognition, slicing it up into so many different silos that he could no longer track across them. He even knew it was happening, and articulated it clearly.<\/p>\n The typical way I\u2019ve seen Enterprise-scale products designed is to begin with a simple visual design, an idea for the presentation they\u2019ll ask their developers to target. Then people refine the presentation,<\/em> often to make the experience more efficient<\/em>. Early customers ask for more information or additional views and context<\/em> is added\u2014until finally, the end-user\u2019s goals<\/em> are more fully understood. New workflows are imagined with new controls<\/em> imagined to support them as the product evolves over time.<\/p>\n There\u2019s a lot in favour of this approach, in that the experience employs a presentation<\/em> to be efficient<\/em> in relating contexts<\/em> in which controls<\/em>, once fiddled, satisfy a user\u2019s goals. <\/em><\/p>\n I propose, though, that it would be cheaper and more effective to turn this process around.<\/p>\n First, understand the end users\u2019 Goals<\/em>, and the Controls<\/em> needed to complete them;<\/p>\n then define the Contexts<\/em> needed to inform and direct the use of controls;<\/p>\n add Efficiencies<\/em>, protecting the user\u2019s time and attention.<\/p>\n Only then should you settle on a Presentation<\/em>, containing and supporting all the work done previously, directing the eye and keeping the mind clear.<\/p>\n Most cybersecurity products satisfy the goals set for them, though these are rarely informed by the end-users\u2019 goals except in broad strokes. The classic cybersecurity products promise to deliver on abstract goals like \u201cgreater protection,\u201d stopping issues before they become problems, or \u201cgreater visibility,\u201d by no longer allowing some issues to fly under the radar. These sound like things anyone should want. But what if someone spent all their time chasing alerts when a better goal might produce better results?<\/p>\n What do you do when you have too many alerts? I know a large, international bank which signed a very dear contract to fill a warehouse in the Netherlands with around 100 young technical people, rotating in and out on 8-hour shifts, keen eyes focused on each new threat. It became a problem when higher-level management realised the contractors were billing by the number of threats, a number contractors could control by tweaking the policy for evaluating network traffic. The goal of chasing threats suddenly began to feel like a dead end, in addition to being dead expensive.<\/p>\n After getting to know our own customers, I proposed we flip our flagship product\u2019s dashboard in favor of a compliance-based approach: namely, are you running the most recent version of your security software? That\u2019s how some of our most successful customers got ahead of the torrent of alerts without cheating: first, make sure that all your endpoints\u2014the devices on your network, from fat servers to wafer-thin laptops\u2014run the most current threat software with the most recent threat models. For various reasons, a vendor\u2019s updating processes can get gummed up for months if no one\u2019s paying attention, which can result in machines being exposed to and exploited by threats to which their peers were essentially invulnerable. By prioritizing software compliance, threats that you do see should be real, actionable threats, and there should be vastly fewer of them.<\/p>\n Very quickly\u2014by our definition; around half a year\u2014we reimagined the user experience of our flagship product for compliance alongside threat-monitoring, while providing automatic enforcement tools for both. As our other security offerings integrated into our platform\u2019s new model, we shifted from many tens of different contexts across four or more different logins, each with their own UX, to one login on one console and two contexts: a summary view and a drill-down into details. The detail view would encourage admins to push deployments of the newest security packages, bringing the host into compliance. The most important function required no effort from the user at all: automatic isolation of endpoints that may have been exploited, preventing the threat\u2019s lateral spread to other internal hosts.<\/p>\n The result: many fewer threat events, and more time and attention to focus on the ones that weren\u2019t automatically blocked. The best part: our new UX solution required little in the way of new engineering at any kind of scale. These grand new capabilities were things our system could already do if you knew how to pull the right levers. We were curious and humble enough to learn from our most successful customers and roll their strategies out to everyone else.<\/p>\n Ultimately, an experience must meet its intended goals. But you must choose the proper goals. We were lucky, in this case. The cost to have your product\u2019s UX fulfill its purpose by way of reimagined goals will generally add up to a sum greater than any sane executive would pay. We had a richly flexible platform on which nimble engineers could build, as well as unusually risk-tolerant executives whose top-down support made all the difference.<\/p>\n Context, in its most basic form\u2014the \u201cwhat\u201d and \u201cwhy\u201d of an issue\u2014is crucial to a human making the call between \u201cignore this\u201d and \u201cjump on this now.\u201d<\/p>\n A top-level dashboard for one popular product had a pie chart showing the total number of events for the day, by criticality. Most of it was green, with a hefty wedge of yellow for unclassified security events and a sliver of red. Because the red changed so little from one day to another, one customer assumed all was well. They overlooked a huge spike in malicious (red) events because the outbreak also caused an enormous spike in innocuous (green) events, keeping ratios between the two the same.<\/p>\n The best kind of context takes something moderately functional and makes it fascinating. I took hundreds of screens from our most popular product\u2019s policy editor and origami\u2019ed it into One Screen to Rule Them All, in terms of that one specific class of policy. When I showed the design proposal to customers, they nodded quietly and asked how soon it would ship.<\/p>\n There are many ways to make workflows more efficient, though I tend to focus on the larger labels of Assistance and Protection.<\/p>\n Assist the user in understanding why something has happened, then boost their overall efficiency by letting them close a loop in a workflow without leaving the current context.<\/p>\n If some annoying false-positive events are spamming your security console\u2019s dashboard, you\u2019d want to dial them down to make it more likely you\u2019ll more quickly see events of real interest. But when you have to fumble through a series of menus to get to the setting that needs editing, you may no longer be confident about what exactly needs to change in order to silence those errant alerts. It would be super efficient to let people call up the view for the spammy event\u2019s settings without leaving the dashboard. Then your eye simply needs to dart between two panels side-by-side in order to confidently make the right change.<\/p>\n Don\u2019t prioritise screen tidiness by hiding \u201cgarbage\u201d or \u201cnot human-readable\u201d fields if customers depend on them. Let the drive for efficiency prioritise the work to present relevant information and controls in the same larger context.<\/p>\n It should be an easy sell to protect users by respecting their time\u2014and one of the most impactful ways to do that is by respecting their cognition. Protection from unnecessary context switching is one of the most straightforward and valuable uplifts you can provide.<\/p>\n The presentation of an experience is usually considered to cover styles, branding, and other aesthetic concerns. All too often, the product owners already have some idea of what information they\u2019d like to present from the start of the project, and simply want a designer to take some examples of the data they already intend to present, rendering it out in a way that can be implemented quickly.<\/p>\n While those are important drivers, they\u2019re often best served by establishing a clear visual hierarchy. The viewer\u2019s eye should be drawn from one area or element on the screen to another in order of importance. Importance to what? Early in the process, it\u2019s hard to know for sure. That\u2019s why holding off on major presentation decisions until now can pay off.<\/p>\n For example: Consider carefully how you sprinkle red and other colors or tones around your screens. It should make users more efficient in grasping the message delivered in your presentation design.<\/p>\n Every view on screen or on paper comes with a visual hierarchy, whether it was intentionally designed to have one or not. Users will take something from it, even it\u2019s not what was intended.<\/p>\n Inverting the usual direction in which these products are designed is the only way to break out of the negative feedback loop in which many product industries unwittingly find themselves. Driving the process from this perspective puts the focus on what truly makes users successful, increasing the odds of an organization\u2019s success.<\/p>\n If we do not, cybersecurity products will continue to be more than simply expensive. They are likely to cost all of us dearly, in many different ways.<\/p>\nA UX solution\u2014the other way around<\/h2>\n
Goals and Controls<\/h3>\n
![\"old-poroduct-reviseed\"](\"https:\/\/blog.container-solutions.com\/hs-fs\/hubfs\/WTF%20blog%20diagrams\/old-poroduct-reviseed.jpg?width=1920&name=old-poroduct-reviseed.jpg\")
![\"image003\"](\"https:\/\/blog.container-solutions.com\/hs-fs\/hubfs\/WTF%20blog%20diagrams\/image003.png?width=1804&name=image003.png\")
Context<\/h3>\n
![\"UX](\"https:\/\/blog.container-solutions.com\/hs-fs\/hubfs\/WTF%20blog%20diagrams\/UX%20Model%20old-new%20comparison.png?width=1928&name=UX%20Model%20old-new%20comparison.png\")
<\/p>\nEfficiency<\/h3>\n
Presentation<\/h3>\n
![\"New](\"https:\/\/no-cache.hubspot.com\/cta\/default\/2252258\/2adeef32-5f13-4584-ba6a-d3d423329c26.png\")
<\/a><\/span><\/span><\/p>\n