Presenting security UX: a hard sell

When I started working at a cloud backup company I looked for some easy places in the web app to make life just a little bit nicer for their customers. One of those places was where we asked for passwords: instead of forcing customers to type their passwords twice into 2 fields, I saw we could update those screens to show a single password field along with a show/hide capability. Simpler, friendly, and more helpful for catching typos. I made a quick design and proposed it to my sprint team.

Now at that time, making people type their password twice was the common standard. “Show password” had not yet been implemented across hundreds of major websites/apps — and it certainly had not been folded into Microsoft Windows. It was not as common as it is today.

The challenge

My design proposal was met with immediate pushback from all members. My design seemed unprecidented to everyone in the room. I was suddenly asked a bunch of questions like:

  • “How safe is this?”
  • “Is anyone else is doing this? Are companies in our industry doing this?”
  • “Is there a legal difference? We don’t want to get sued.”
  • “How do you know this is a friendlier solution?”
  • “Will all this need to be custom code or is there a certified library?”

Just as suddenly I realized I wasn’t prepared to answer all of these questions. At that moment I had a choice to make of how to respond. I could either let the idea die right there or I could try some other way to keep it moving forward.

What I did

I said, “I don’t have answers to all the concerns you’re raising right now but I can address them if you give me a day to research. Will that work?”

I got a room of nodding heads and I noted down the questions raised.

Over the next day, I scoured the web for info to back up my design. I found screenshots, research papers, code examples, and also looked into alternatives which I compiled into this comparison chart. I then called another meeting to present my findings.

The result

Over the course of my show and tell I addressed each team members’ concerns and got their buy in. With their fears quelled, a new level trust in my work was established and my team agreed to put it into the product.

Sometimes convincing people doesn’t happen right away and sometimes you’re not as prepared as you think you are. But if like most teams, everyone in the room is reasonable and smart, it can happen when it should. Pursuasion depends on trust and decisions are enhanced by appropriate information.

This is true in both directions. There have been a few times when I’ve intended on convincing people of a plan but after I’d done some further investigation or testing, found that I was the one convinced otherwise. Either way I’ve found it’s a good practice to go deeper into a solution when concerns are raised.


Originally published at www.ihoby.com on May 16, 2016.