Home > Uncategorized > Human Factors in Information Security – Part 2

Human Factors in Information Security – Part 2

I’m constantly amazed by the claims many security product vendors make about how user friendly their products are. In my estimation some of them have acceptable usability levels, but many do not. I frequently notice usability design flaws such as highly cluttered graphic displays, unnecessarily complicated interaction steps, long lists of items in tables without any indication whatsoever of the status or meaning of each item other than the name, the need to frequently change from one input device to another, and difficult-to-read display output. Yet as I have said before, usability is hugely important in information security-related tasks.

One area of usability engineering that security product vendors need much more attention to is accommodating different levels of users’ skills and knowledge. Too often a product accommodates only naïve users or only sophisticated users, but not both. Ideally, vendor products should have two parallel interfaces, one that is “pick and click” in its nature, and another that accommodates power users. As far as accommodating naïve users goes, the user interface should be so transparent to them that hardly any training whatsoever should be necessary. Power users usually like command languages that allow them to accomplish sophisticated actions with only a few keystrokes. The command language must nevertheless be very intuitive and consistent in its syntax.

Another area of usability engineering that could use improvement in security products is menu-driven interfaces. Some products require users to transverse four or five (or even more) levels of menus just to invoke some function. Fortunately, others have few menu levels, something that allows users to get to the function they want much more efficiently. Sean Curran and I conducted some research way back in the 1980’s in which we empirically tested whether users who were not familiar with the particular menu-driven interfaces we devised would perform better if menus were deep (i.e., they had more levels, with fewer selections per level) or broad (i.e., they had fewer levels, with more selections per level). The results were very conclusive; users who were presented with broad menus found target selections significantly faster and with fewer errors. Many similar studies have also produced results of this nature.

Still another usability engineering area that needs more attention in security products is error messages. Error messages must be written in simple language, they must not insult or intimidate users, and they need to provide users with clear and sufficient direction concerning how to recover from errors that they have made. In the worst case, error messages say something like “User error” or “Fatal user error” in big, bold red letters. Such messages do little more than frustrate and intimidate users. In the best case error messages simply and politely inform users that the users’ input could not be processed because…. and then provide simple guidance concerning what to do next.

Finally, help facilities in security products are generally not up to par. At a minimum, there should be two types of help, more general help describing the meaning of terms and selections as well as how to reach and/or invoke them, and context-dependent help that shows users what the format of input into fields must be like. Help messages, like error messages, must be written in simple language.

The bottom line we have a long way to go when it comes to improving usability of security products, let alone products in general. Until such improvement comes, it is important to be savvy in evaluating vendor claims that products they make are user friendly. In general choose products that are sound from a usability engineering perspective.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.