Section 27.2. Design Principles

27.2. Design Principles

This section describes the basic principles underlying the design of ZoneAlarm:

• Know your audience

• Think like your audience

• Eliminate clutter

• Eliminate complexity

• Create just enough feedback

• Be a customer advocate when usability and competitive pressure collide

27.2.1. Know Your Audience

Our company held a weekly lunch meeting series in which we could hear an architect explain a bit of the technology within our firewall. The first meeting was packed with people anxious to learn, and about half of us were from marketing. As the words began to spill out of the architect's mouth, those of us in marketing quickly realized that the lecture

Figure 27-1. Interacting with this ZoneAlarm Security Suite GUI is seldom necessary, as most user interaction occurs through the alerts

may as well have been in Latin. What the architect had to say may have been brilliant, but it failed for the very simple reason that it didn't reach the audience.

Now imagine getting this wrong on your interface design, considering the thousands of hours it takes to design, build, test, and market a product. If you're not speaking your audience's language, all that work is wasted. But even a minor mismatch with your audience means that your product will be less successful than it could be, that it could lose its edge on the competition. and that the very customers you are trying to protect may make wrong decisions that will leave them exposed. That's why you must know your audience intimately. Skip this step, and you leave opportunity on the table. Even if your product doesn't fail outright, it won't be as good as it could have been.

A mistake I made early in my career was thinking that knowing the audience was simply inherent in my job title. I, the product manager with the arts and humanities major and a background in writing, should naturally know better than the nerdy engineers what my audience wants. Of course, I was wrong. To know the audience, I needed to get out of the office and talk to them. Without this information, your guess is no better than anybody else's. If you're the key decision-maker for your product's design, this concept is powerful

MINIMIZING USER EFFORT SAFELY

Striving to provide the strongest security that's also easy to use may seem impossible at times. For example, antivirus, standard intrusion detection, and other signature-based solutions are very easy to use but offer little protection against emerging and as-yet-unknown viruses and malware. But combating old as well as brand-new threats often involves an aware user who can react to real-time attacks and understand the difference between a real threat and something benign. You know, that user we spoke about who doesn't want to spend any of her time using your software? As pointed out in Chapter 2, "Security is dependable only if it is actually used as intended." While there is no single way to solve this conundrum, here are a few tips that help us to get closer to achieving good security:

• Create interaction points only when you absolutely must. If you interrupt users with pop-ups that have noncritical or less meaningful information, then the user is less likely to pay attention to critical information.

• If you cannot answer a question yourself, or you have a tough time explaining the question to others, your users probably cannot answer the question either. Come up with a different question to ask that may get to the same answer.

• Set up multiple layers of security so that even if a threat gets past one layer, another will stop it. This way, user errors don't have to be catastrophic.

• Create automation if you can do so securely. There may be technical solutions that can lessen or eliminate the need for user interaction. But keep in mind the raison d'être for your product and do not sacrifice security in the process.

• Explore alternative interfaces, such as wizards. Often, a carefully designed wizard can take what would be a tough decision and break it down into easier and more intuitive questions. But stay away from wizards that are too long. And if a wizard contains questions that are as tough to answer as the original question the wizard was intended to replace, then the wizard is not worth doing.

• When you're analyzing the effectiveness of your product's security, always include the customer in your analysis. If it is likely that the customer will make an error and reduce security, either redesign the experience to minimize the risk or, in extreme cases, consider revamping the technology or leaving it as an advanced option rather than a default setting.

• Remember that a false sense of security is worse than no security at all. It is better to leave out a portion of functionality if it's highly prone to failure, than to include it.

and indispensable. Know your audience, and you'll not only be able to create much more successful design, but also earn the respect and credibility of your team so that you're empowered to make good decisions. But even if you're not personally talking to users, make sure that someone on your team is.

This does not have to be a huge endeavor, by the way. If you dedicate even a four-hour, uninterrupted time slot each week to call people on the phone, send out surveys, talk to people at trade shows, visit people's homes, or even hang out at Best Buy and talk to people there, that's probably more than your competitors are doing. Of course, the more time you spend in this area, the better you will know your audience.

27.2.2. Think Like Your Audience

So, you know your audience. That's a terrific start, and you're already well on your way to creating usable security. Now begins the difficult step of applying what you've learned about your audience and, in a way, becoming them. This means overcoming noiseanything that takes away your focus on the customer. For an interface designer, noise could be sticking entirely to classroom theory and ignoring the realities of the customer or the market. An architect or developer may try to create such an efficient, elegant architecture that the customer needs cannot be accommodated. Marketing may focus too much on revenue opportunities and forget that the best way to gain and keep customers is to focus on the needs and desires of the customers. If you are the lead decision-maker on a design, it's your job to filter all of this noise for the sake of the customer. You must truly step out of your noise-filled head and into the heads of your audience to make a design successful.

One of the best ways to do this is to present your design to others throughout the design process. This forces your mind to shift perspectives and see the product through others' eyes. It's always amazing to me when, after working hundreds of hours on a design, we present it to others at a review meeting. Predictably, problems leap from the screen within a minute of the presentation as if we've put no thought at all into the design. This should be expected. There is a reason why every professional writer has an editor: once you produce something, you can no longer truly step out of your own head and see it for what it is. It's the same with software design: it takes someone else to help you find errors and tailor your product to the intended audience.

Another great way to step out of your own head is to identify a representative person or two from your target audience and design for them. When I began considering our anti-virus software design, many of the guiding principles I used came from observing my roommate, Julie, one night after work. There she sat at her desk, anxious because she had heard about a virus outbreak and wondering if her computer was safe. It took her wading through multiple panels of her antivirus product before she got the information she wantedand discovered that her antivirus software had been out of date for months.

What an advantage I had having witnessed her experience. Stepping into her head, I knew what questions to ask of our own design: can she glance at the antivirus area and know instantly and without a doubt that she's protected? Will she clearly know when her antivirus software is out of date or expired? Isn't it better for her if we put the most common controls and displays into a single panel, and we relegate all the advanced settings she'll probably never use to an Options dialog? The end result of considering this user and the other members of our target audience in these decisions was a very clear, easy-to-use interface that customers and reviewers have praised.

27.2.3. Eliminate Clutter

William Zinsser, author of On Writing Well,^[1] calls clutter "the disease of American writing." "We are a society," he says, "strangling in unnecessary words, circular constructions, pompous frills and meaningless jargon." In writing, any words that do not help to get the main idea across only weaken it. As with so many writing principles, this is also true of software design. And while designing software is difficult in itself, designing a security productsomething that so few people understand to begin withpresents an even bigger challenge. Simply put, our job is to make the complex underpinnings of a security product into tasks and metaphors that our customers can understand. We are the intermediary. So it's critical that we strive for purity in our design so that every word, button, and pixel that's present in that design is used to explain an idea or a task and that any clutter is removed.

^[1] William Zinsser, On Writing Well (New York: Harper & Row, 2001).

27.2.4. Eliminate Complexity

Whereas clutter occurs at the detail level of our designs, complexity can permeate our designs at a higher and more profound level, which can end up not only confusing a user, but also slowing time to market and introducing stability problems.

If you can barely explain your design to somebody else, then the design is too complex. From an R&D perspective, if functionality takes unusually long to write, if the code is so tricky that it creates bugs, or if the functionality permutations would take QA too long to test, that is also a reason to simplify.

A good example of this point comes from a startup wizard we were creating for a new product version (see the upcoming sidebar). The first step of the wizard had three possible branches. Moreover, each wizard permutation would turn product functionality on or off, but only if no conflicting software was found on the user's computer. This complexity bothered everyone on the team, but we proceeded heads-down toward our deadline anyway. Eventually we decided to try to do something to improve the wizard. It didn't take too long to come up with a fantastic solution: we realized that this segment of the wizard wasn't doing a bit of good for the customer, and it certainly wasn't making our job easy. When we moved the necessary functionality to a new location, it was simple and understandable.

So, when a portion of your design seems overly complex or problematic, ask yourself: is it essential? Does it make things better or worse? Can it be done in another way, at a different time, or somewhere else? One of the keys to avoiding complexity is to give priority to the most common and likely use cases. So often, someone on the design team will ask, "What if the user wants to (insert extremely unlikely action)?" While it's important to ferret out those rare-use cases and ensure that they don't end in catastrophic failure, you've also got to be able to say you're not going to sacrifice the common use cases to design for a case that may never happen.

A WIZARD MAKEOVER

ZoneAlarm Pro includes a network detection wizard that automatically pops up whenever the software detects a new network. The goal of the wizard is to help the user select the security level appropriate for the resources needed on the network. The existing wizard, shown in Figure 27-2, wasn't achieving that goal as well as we'd hoped and was difficult for novice users. Adding to the design challenge, we were outside of a regular development cycle. Changing any functionality or introducing any stability risk to the code base was forbidden; our opportunity lay only in aesthetic and textual changes. So we set out to achieve the goal of the wizard as directly and powerfully as possible, keeping and promoting those items that supported that goal and cutting all else. Each time we changed our design, we would get outside opinions from anyone who was available to make sure we were in our users' mind. Getting this outside perspective was critical to the design's success. Much like editing a document, we found clutter to remove with every pass. Our improved wizard is shown in Figure 27-3.

Here is the analysis and what was changed:

• The original wizard involved four steps: announce the new network; assign a security level; name the network (optional); and announce completion. Had the wizard been a one-time occurrence, four screens might have been OK. But traveling users would get this wizard with each new location they traveled to. This was a major point of clutter. Because only one of the four screens directly supported the goal for the wizard, we cut the others and saw instant improvement.

• The pop-up was too wordy and technical. For something that comes up multiple times, possibly at inopportune times, the text had to be a quick read with direct information. The text itself had clutter that we edited and tested out with multiple reviews.

• The formatting was wrong. Paragraphs of text overburdened the display and made it difficult to extract at-a-glance information. The text that we created was put into short bullet points. In addition, we were very careful to keep the number of different elements in the pop-up to a minimum so that it appeared simple.

• The wizard was tailored to the wrong audience. The text-heavy pop-up was intimidating, as were some of the technical terms. We substituted icons for text to immediately decrease the intimidation factor and create more whitespace. The page focus was now on simple icons and text bullets, perfect for our primary audience. The more technical information for the secondary audience remained, but with less focus.

• The optional and noncritical task of naming the network was placed at the bottom of the pop-up, purposely in second place to the main goal.

As with nearly all designs I've encountered, our improved design wasn't the only way to succeed. And deeper technical work could have made the wizard even easier to use. But the quick design proved successful at helping users choose the right security level. It also reduced support calls and was noticed favorably by the press and our distributorsdefinitely a lot of gain for a small amount of coding.

This example shows the many ways that clutter can be present in software design. It also shows how important it is to have a design goal and to identify the main and secondary audiences. Finally, it shows that multiple user reviews with the target audience are the key to making a design successful.

Figure 27-2. The four-step wizard was ungainly and difficult for less experienced users

27.2.5. Create Just Enough Feedback

Among the bad assumptions a security product designer can make is that people actually want to spend any time at all interacting with their security. This point is made throughout this book, but it is so important that I'd be remiss not to mention it here as well. Don't ask users to do anything unless it absolutely cannot be done safely without them. If you keep this in mind, you'll greatly reduce the likelihood that your users will make errors that defeat their security.

Figure 27-3. The single-step wizard keeps the critical items and removes the clutter for a much easier and more effective user experience

Keep in mind that users may not always agree with this principle. We have survey results where users of varying skill levels say they want to be involved in every decision made. But our usability studies consistently contradict this. So, what do users want? They want to be kept in the know about their security, to be reassured that they're being protected. But in general, they want this knowledge in unintrusive ways.

So, while I talk about removing interface clutter, showing pop-ups and wizards only when absolutely necessary, and keeping the security product behind the scenes as much as possible, there are some elements of the product you should expose to the user.

When we redesigned the ZoneAlarm product family, we built in some reassuring interaction points. On the main panel, two subtle lines at the top of the page report how many intrusions have been blocked since installation, and how many of those are high risk. These two little lines are cited in many of the fan-mail letters we receive, and are often mentioned by customers at trade shows. Our system tray icon is another subtle place for feedback that indicates whenever traffic moves from client to Internet. And if the product ever fails to load, the icon becomes an attention-grabbing X.

There are times for more pronounced feedback as well. Our subscription expiration screen, for example, pops up and demands attention when the subscription is about to or already has expired. We wanted this alert to stick out because out-of-date software is one of the major factors in security attacks. Another example of pronounced feedback occurs when we find a virus. Although the virus is treated automatically, we still let users know what has happened so that they know we're actively protecting them.

Our customers consistently tell us they like the reassurance we give them because they know that the software is working and that they are protected. When we provide this reassurance, we are also demonstrating the value of our products, generating loyalty, and building brand. Providing feedback is also very important as a security enhancement to alert users to a lapse in security.

27.2.6. Be a Customer Advocate When Usability and Competitive Pressure Collide

While sound usability principles are probably understood by most designers in the security software industry, they are obviously not always followed. Competitive pressure and tight internal schedules are often the reason. Although ideally everyone on your team should be the user/customer advocate, you (or whoever is in the lead position) must be. Otherwise, things that have nothing to do with designing for the audience, such as engineering restrictions, timelines, budget, and politics, will edge out the needs of the audience. Phrases like "that's the way we've always done it," or "we cannot do that" can weigh too heavily at the expense of the goals at hand to the extent that you are left asking, "what's the point?" While this type of noise is very real and must be dealt with, you must make sure you don't penalize the user by letting such things get in your way. And while there are realities that may sometimes end up making the user second, you must keep your allegiances as much as possible to the user.

Balancing customer needs with competitive pressure requires compromise on all sides, including yours. Sometimes implementing your proposed changes could affect the stability of the project or take developers away from other critical work. So you must think like a superhero. A mission may seem impossible, but you need to make it happen. Start by making sure that you know the exact goal of the intended design. Then decide if you can make headway on that goal by doing part of the work. Often, developers can help you eliminate the most risky, time-eating portions of the design that perhaps can be put off until the next release. It is very rarely an "all or nothing" decision that cannot be somewhat improved through other means.

The wizard makeover discussed in the earlier sidebar was done after the VP of development told me that I couldn't do it. So I made a deal with him: if I could come up with changes within a week that would not affect client stability or push out the ship date, he would let the improvements be checked into the product code. As long as QA found no problems, we could leave the improvements in; otherwise, they would be pulled. I worked very closely with a seasoned developer who was supportive of my goals. I came up with a design that the developer had confidence in, quickly validated it with a UI designer and some 10-minute usability testing around the office, and by deadline time, the code was checked in. After holding my breath for a day to see if bugs would show up, we were in the clear and the VP was true to his word. In fact, he later congratulated me for pushing the changes because they offered such a vast improvement.

CREATING THE PROGRAM ADVISOR

We had a difficult problem. One of the most protective layers of our firewall had become too difficult to use for a large part of our audience. This layer, program control, asks users to decide when a program should or should not have Internet access and server rights. When we first released program control, our audience of more technical users was up to the task of making these decisions. But as our product spread to less technical users, we found ourselves breaking our own principles by asking users questions they couldn't answer. Some of our competitors appeared to be providing a solution to this problem, but their methods of doing so could be so easily defeated that they rendered the feature worthless. Although we knew this, our customers did not. So we had enormous pressure to "catch up" to competitorsin a secure wayand to repair this failing security layer for our users.

Our company founder was well aware of the problem and created what at first seemed to be a complex system. This system is now in use on most of our products and has been among the single biggest usability improvements in our history. For the user, the solution is simple: we answer the pop-up so that the user doesn't have to. The underpinnings are complex, however, and require the Zone Labs security team to maintain a list of thousands of programs and their matching checksums along with a security policy for each program. Each client calls to the program policy server when it tries to access the Internet, and the server provides an instant policy to the client. This policy can be manually reviewed by the user or automatically accepted, according to user preference. Each policy can be changed by Zone Labs at any time.

In some ways, this system breaks with some of the fundamentals I described earliernamely, complexity. For users, however, the system couldn't be simpler. On average, users see 90% fewer alerts than they did before, a critical security improvement. With this system, we also know that programs are getting configured correctly, so our users' security is vastly improved over what was already an excellent system. The bottom line is that we realized that to maintain security, we had to make these critical decisions for the user.