Change: Three Ways to Challenge Today’s Security (UX) Thinking

Last week, I was fortunate enough to spend three and a half days on the floor at RSA for its “Change: Challenge Today’s Security Thinking” inspired conference. I was simply observing and absorbing the vast array of companies and products. As someone new to the world of security (but very well-versed in the field of UX) I was afforded an opportunity to look at an entire industry with a fresh perspective. One of the most unique challenges that faces the growing world of user experience professionals is knowing just enough about a target user group to create compelling solutions without being too “in the weeds.” In my experience, being too close to a particular industry or audience segment can prevent a more objective approach that a seasoned designer can, and should, bring to a product. Having said that, there were some interesting trends as well as some areas that could benefit from the thematic undercurrent of “Change” presented at RSA. I focused my research on 51 companies spanning multiple verticals, sizes and problem sets—and because the majority were not direct Endgame competitors, the true purpose of my research was to understand more about how the industry thinks and to find key areas of improvement for the field of UX. 

 

Color as a key component

Color played a large part in virtually every product, whether by choice or chance. Color palettes were dominated by bold hues that usually included black, gray, red, orange and blue. Yellow, purple and green were used far less frequently and likely for good reason. Traditionally, black and gray representsimplicity, prestige and balance with red and orange representing importance, danger, caution and change. Blue will always represent strength and trust. On the flip side, yellow, green and purple tend to represent sunshine and warmth,growth and fertility, and magic and mystery, unlikely traits in the security industry. Still, some companies utilized these weaker palette choices in their products, possibly without a true understanding of the “baggage” they bring.

Outside of content color, background color use went one of two ways – either dark content on light background with 80% of companies utilizing this design paradigm or the much less common, light-on-dark construct. Neither is “better” or “correct” in application development, however, the former tends to be more common in the business-to-business realm and is far more familiar to business-centric application users. When I inquired with the companies I observed who had chosen to implement the lesser utilized light-on-dark approach, they generally did so to either differentiate themselves or to successfully target a very specific population of their target market. Whether these two outcomes are true still remains to be seen. These companies were all young start-ups, clearly taking a bit of a risk.

 

Maps as presentation vehicles

There were a multitude of products that featured some sort of map – whether it was a network, geographic, server, GPS, sankey, tree – you name it, there was a map for it. This was both good and bad. For those companies that did it well, the maps provided a much-needed visualization of data that wouldn’t fare well in a tabular or list format. When a security professional needs to have a birds-eye view of where their vulnerabilities lie, providing a visual representation over a list of IP addresses may allow them to better comprehend what requires their attention in a fraction of the time. However, the maps started to suffer in situations where their presence had no clear purpose. Several products had unnecessary animations. Others were so small that the corresponding data and labels overlapped, rendering the graphic unusable. I saw quite a few stuck into a corner of a dashboard simply to fill an otherwise empty space. The D3 collapsible tree map was extremely popular, often at the cost of legibility and a clear understanding of the complexity of the processes that the visualizations were supposed to clarify.

 

Features as framework

Perhaps the greatest challenge I found in the majority of products from both small and large companies, but particularly the industry behemoths, was a clear, well thought-out information architecture (IA), particularly as it related to feature development and organization. There is a common misunderstanding that more features equates to better “sellability”, particularly in products that like to position themselves head-to-head with their competitors.  In the industry, this is often referred to as feature-bloat and time and again it presents itself in products that are designed by product management, marketing and and/or engineers. Generally, these are the individuals who are the most removed from the end-user. It’s the idea that if some is good, more must be better and the false assumption that commanding a big price tag means being able to do a lot. We see this as the mark of success in many industries including the automobile, electronics and vacation/travel sectors.

However, in an industry where time is critical and decision-making is crucial (and competitors are abundant), the feature bloat present in many products shown on the floor can be detractors to product success and may actually make them harder to use when time is of the essence. Think scalpel over Swiss army knife, especially if you’re a startup.

 

What does this mean?

The good news is that UX is starting to make inroads in the security industry and this is an exciting time to be talking about UX in this massive field. Fully bringing UX to an entire product and team takes time, but there are three things that every company can start doing now.

  • First, know your audience and your brand. Figure out to whom you want to sell and for whom you want to build (hint: they may not be the same person). What does your company stand for? What are your core values and selling points? What problems are you solving and for whom? How are you solving them? Then figure out what it is that makes your company and your product different from everyone else. This is yourown brand pyramid. Ask yourself with each new feature that gets proposed: “Does this align with our core strategy and does our product really need this? Does this solve a specific problem for the user” Don’t assume that you know the answer to this simply because you work in marketing or are an engineer. Subsequently, if your answer is “no” and/or the feature doesn’t align with supporting your original brand pyramid, it’s extraneous at best, and distracting or detrimental, at worst.
  • Second, don’t be afraid to be different—but not so different that people don’t even understand it. This is where your UX team needs to understand how to do good user research and then analyze that research. Don’t just comb your analytics—watch people use your product. Don’t just ask your users what they need—it’s  likely that they actually won’t be able to tell you. Don’t assume every user is of a certain demographic and will like some wacky color scheme. Instead try to understand what it is they want to do with your product. Have an open conversation around their roles in their organizations and what problems they face in their roles. Seek ways to create solutions they wouldn’t have thought of and then iterate on how to best manifest that within the product interface without sacrificing usability.
  • Finally, offer unique and targeted solutions even if it means having more than one product. It is better to have several separate but logically connected solutions than it is to have a bloated product with many layers of navigation and too many features. If possible, create roles within the product and give those roles specific policies that can hide data and modules when a particular user does not need them. This may seem obvious, but again, when a feature is proposed, ask “does every user in my system need this and if so, are they all using it the same way?” Chances are, they aren’t.

Interestingly enough, on several occasions at RSA I heard the question “what products will this replace?” The end goal of any product should be to solve problems, not displace the competition. If a competitor’s product already solves a user’s problem, then your company is facing an uphill battle if the only goal is to unseat that product. Instead, ask if there is a more unique way to solve that same problem. Perhaps there is a different problem worth solving. Seek the blue ocean. As Apple would say, “Think Different.” Apple wasn’t successful because Apple wanted to outsell Microsoft. Apple was successful because Apple wanted to make products that solved users’ problems. They’ve done this by investing the necessary resources into their user experience. They’ve aligned their business with user needs. Sounds simple—but it takes dedication and time.

In the end, UX does take effort. It can feel like starting over. In some ways, it is. However in every other industry that has embraced it, especially when that industry is inundated with solutions (think healthcare, education, mobile development) it’s often the difference between an “ok product” and a market success. Even if your organization has already invested a lot of time in your existing products, as RSA taught us, it’s never too late to “Change”.