Perimeter
2/8/2012
02:41 PM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

I'm Sorry I Called Your Baby Ugly ... But It Is

Your product's user interface may not be as appealing as you might think -- and it might just be jeopardizing its adoption

I like to use technology that is intuitive, solves a problem, and is a "fit" for me. On the other hand, I also like technology that is aesthetically pleasing. Some vendors have managed to deliver on my requirements, which is why I own several Apple products, buy the same brand of suit, and rarely drink domestic beer. But when it comes to security products -- namely the user interface (UI) of security monitoring products -- I am often disappointed and left wanting.

I speak to numerous vendors across different product sectors on a daily basis, so sometimes my disappointment in their UIs squeaks past my gritted teeth. I do my best to provide constructive criticism based on what I hear from customers, friends, and similar vendors, but the receiving vendor often takes offense. I understand. I called its "baby" ugly. Unlike an ugly baby whose appearance is usually beyond the control of its parents, security UIs can be made better.

Why make a UI more aesthetically pleasing? Well, for one thing, if a user can form a connection with the product, then he'll likely learn it quicker. We, as humans, tend to gravitate toward things we like and distance ourselves from those we don’t. If a provided interface is off-putting, how do you think that might impact the user’s learning curve and subsequent adoption?

Another reason is that many security monitoring products have become indistinguishable. I often say that you could take any SIEM vendor’s product marketing materials, strip any mention of its company or product name, and customers would have an extremely hard time assigning the correct company name to the associated materials. Since security monitoring vendors have done little to differentiate themselves, choosing instead to battle for competitive parity, why not innovate the often touted "single pane of glass?" Perhaps it's time to change the way we force users to interact with products.

I mentioned in my previous blog post -- "Where's My 'Minority Report' Dashboard?" -- that ever since I first saw the movie Minority Report, I’ve been waiting on the edge of my seat for a SIEM vendor to emulate the UI employed by Tom Cruise to solve crimes. I’m not saying that a UI of this nature would make a SIEM product more technologically capable than its closest competitor, but it would almost certainly add a bit of shine and differentiation in a product sector that’s quickly approaching commoditization.

Revamping a UI is not only an expensive undertaking, what with customer requirements gathering, design, development, and testing cycles, but it may also be considered a distraction from a vendor’s technical road map. So how do we balance some "UI bodywork beautification" without drastically impacting other core deliverables? Nearly every security product vendor leverages computer and, sometimes, electrical or mechanical engineering students in a work placement or cooperative education capacity. Not only does this provide inexpensive labor for menial tasks within the organization, but it may also serve to entice the student to come back to the company upon graduation -- providing a semi-trained resource already indoctrinated in the company's culture and processes. What I have yet to see, however, is a company bringing in design students to help overhaul, or even iteratively update, its UI. Sure, you could likely go to Starbucks, throw a rock, and hit five people capable of redesigning your product’s UI, but why not use students who are hungry to prove themselves in the real world? I assure you that the cost savings would likely be dramatic.

A balance between utility and aesthetics can be found, but vendors need to take a step back from their babies and objectively ask the question, “Is my baby ugly?” They also need to ask their customers, partners, friends, family (especially school-aged children), and strangers they meet at airports or in elevators what they might do to improve the UI of their product. They might be surprised to learn that they do, in fact, have an ugly baby.

Andrew Hay is senior analyst with The 451 Group's Enterprise Security Practice and is an author of three network security books. Follow him on Twitter: http://twitter.com/andrewsmhay.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web