Designing for Security

Balancing Caution and Customization

This post was originally published for the Agencyport Developer Zone on October 29th, 2015. Edits have been made from the original post.


The topic of security comes up for all sorts of reasons, but there is one scenario that is commonly cited: the elusive shoulder-snooper. It’s the fear that there’s always someone sneaking around, peeking over your shoulder and attempting to steal your username/password combinations.

Identity theft continues to be a huge problem, only exacerbated by a surge in mobile-use and general lack of awareness of how to protect your personal information. Over the past decade, there have been changes in the way people input sensitive data to help quell potential threats. One of these preventative measures is screen guards, such as the ones used in grocery stores, or how an ATM PIN is completely masked on a screen.

When it comes to insurance, the real threats are the people who come in contact with sensitive data every day. This data is transferred in a number of ways — over phone, via email, and printed onto documents. All it takes is one person’s mistake for this information to fall into the wrong hands.

The product team here at Agencyport has put in measures to protect sensitive information from being compromised. Obviously, it’s part of the user’s job to be able to access this information, so we want to make it available to them. However, it’s our responsibility to put thought into the security of our products to better protect this information from being misused.

Design & Usability

As a designer, I want to design the interface to be as easy to use as possible. Part of my role in designing for security is making sure that whatever we add to the experience doesn’t aggravate the user. Lana Miller at Usabilla points out: “Minimize the time and effort required to use the feature so that it doesn’t impact negatively on the user experience. Security features are, in a sense, a ‘barrier’ to something else so it is vital that you remove any additional, unnecessary steps so you don’t discourage the user. When it comes to security, users don’t want to feel confused or lost in the process. Keep it simple.”

Making the experience difficult can have unforeseen circumstances, as pointed out in the article by Jakob Nielsen of Nielsen Norman Group: “When you make it hard for users to enter passwords you create two problems — one of which actually lowers security: Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.) The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a trueloss of security.”

In another article, Nielsen points out: “Usability advocates and security people have opposite goals that create a fundamental conflict: Usability advocates favor making it easy to use a system, ideally requiring no special access procedures at all, whereas security people favor making it hard to access a system, at least for unauthorized users.” The system we design has to be easy for the people we want it to be easy for, yet hard for everyone else. Sounds easy enough, right?

User Types

In any given implementation of the AgencyPortal product, there are numerous users with access to the same information. This makes the problem more complicated, because we can’t exactly predict who will access the information we are protecting. The information does not only need to be protected by the user inputting the information, but anyone who may see it in the future. There has to be a balance between making the information accessible to whoever needs it, while, at the same time, protecting it from those who do not.


  • When the user revisits the page, they see the masked data with an edit icon
  • Once the sensitive data has been entered into the system, it will display masked to the user
  • If the user wants to edit the data in the future, they’ll have to re-enter it in its entirety
  • A user with elevated permissions will be able to unmask the value if they have access

To Mask or Not to Mask

A lot of research has been done on how masking typically works, especially pertaining to passwords. There’s debate within the design community about whether or not masking is worth it, or if it just hinders the user. One such debate is if someone should be told whether it’s their email or password specifically stopping them from logging in. The argument is that being told the email is wrong doesn’t matter, because someone could theoretically look up that email when using the “Forgotten Password?” option. Still, it doesn’t hurt to put in place steps to get the hackers out — as long as it doesn’t get in the way of the user.

In my personal experience, I have a hard time typing in passwords on my phone when it masks as I type. Having to put in the password multiple times can be aggravating, so much so that I often give up entirely. Another issue is that using “<input type=“password”>” means the browser will ask to save that information for later.


  • When the user tabs off and the data it not valid (ex: not enough characters), there is a validation error
  • When the user tabs off and the data is valid, the data is masked
  • Use format masks when possible (ex: SSN appears as ###-###-####)
  • Allow flexibility for customization, such as a partial mask that could allow enough visible information for the user to confirm its accuracy
  • When the user revisits the page, they see the masked data with an edit icon
  • Editing the data means entering it from scratch, similar to how credit card numbers are commonly treated
  • Only users with elevated permissions can see sensitive data
  • When the page is revisited in read-only mode, it is masked and there is the edit action is not displayed

Design Considerations

We had to decide whether we wanted to add any unique design elements to make the input field look more “secure”. Most users are used to seeing the UI pattern of a lock to signify that the information is secure. However, we ran into a couple issues: IE 11+ puts their own “eye” icon into the input field. Then, we tried different variations of icons — eyeballs and locks included — only to conclude it didn’t add anything to the user experience. The information being masked already gives a sense of security, and putting in another icon conflicts with the icon system we already use on our data-entry pages.

However, placing an icon, such as the “lock”, can be valuable, depending on the experience. This Medium post illustrates that well, in the example of a credit card payment interface.


While we battle against security threats, such as “shoulder snooping”, it’s important to realize how easily sensitive data can be compromised. In the insurance business, this information is being distributed all the time. As a team working on a product handling this information, it’s important that we take care in protecting it. When researching how security is implemented in different UIs, one thing is clear: there is no “one size fits all” solution. For what we are doing, we place a lot of trust in those who use our products. For anyone designing a login interface, you will find a tidal wave of articles with conflicting opinions about how to design for security. In the end, it depends a lot on the type of website or product and the specific concerns there are for the user.

Please recommend if this article was helpful! :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.