Design Ethics – Encouraging responsible behaviour

I got a call from my bank, HSBC, the other morning. The call started something like this.

Rob: ‘Hi, this is Rob from HSBC. Before I can continue this conversation I need to confirm some security details with you. Can you tell me your date of birth please’.

Leisa: ‘You must be kidding Rob. I have no reason to believe that you really work for HSBC. Why on earth would I just hand over my personal information like that?’

Now, I don’t know whether Rob was just improvising, or whether this is an official HSBC script, but it is wrong, wrong, wrong. What Rob and HSBC are doing here is treating people to NOT take care with their personal information. What is this going to do for HSBC and their customers? It’s going to make them both much more likely to get stung by fraudsters, and to both lose time and money for no good reason.

Surely HSBC should be going out of their way to educate their customers NOT to hand over personal information whenever some random person calls up asking for it.

Either way, Rob was not impressed. He did have a backup plan (I give him part of the information and he confirms the rest… which is slightly better), but he took *that* tone with me for the rest of the call. You know, that ‘you’re an irritating customer’ tone. Not a great start to the day.

You know what it reminds me of? And it’s something that more and more of us are guilty of participating in – especially those of use who are designing applications that support social networks. It reminds me of this:

Facebook - Find Friends

This is the ‘find friends’ feature that we’re seeing on more and more sites (this one is taken from Facebook) where we are blithely asked to put in the full log in information for our email accounts, or our IM accounts or our other social network site accounts – and, more often than not – we do!

Now, clearly there is a big incentive to do so because these kinds of applications work well only when you’ve managed to connect with the people you know and care about, and using existing information like the contacts from your email or IM account makes this reasonably painless. The application does most of the work for you.

But do we really realise what we’re handing over when we give this log in information away? Do we realise how much we are trusting Facebook, for example, to play nicely with that information? Think of all the email and IM conversations you’ve had that are accessible using these login credentials… now think about the level of security at somewhere like, say, HM Revenue & Customs (where they recently ‘lost’ the personal information of millions of UK taxpayers), and now think whether somewhere like Facebook would have better or worse security… both now, and potentially in the future.

Sure, they *say* they’re not going to store or use that information… but are you really willing to take them at their word? Are you willing to TRUST Facebook (or any other site) that much?

We don’t really think much about this when we’re giving away our username and password, do we?

And why not? Because, just like Rob at HSBC, it’s almost as though we’re being pressured into just handing over the information otherwise we’ll get inferior service (and/or an attitude). We’re actually being trained to believe that handing over this information is the RIGHT thing to do.

Brian Suda calls this ‘Find Friends’ form an anti-pattern. He says in a recent Sitepoint article:

Another pitfall that you’ll want to avoid is sites that ask for the login details for your email account. This is a huge security hole. By handing over this information, you’re giving a random provider access to all your emails and friends, not to mention access to APIs through which they could edit and delete your information. And, as none of us want to admit, we often use the same passwords for many different services. Provide your email password to a site, and its owners can not only get into your email, but possibly your bank accounts (and a bunch of other services) as well. You should never give your password to anyone! Creating assurances of privacy lulls us into a false sense of security — it relaxes us into thinking everyone can be trusted and everything will be safe. This bad behaviour is exactly what phishers love to prey upon.

Enter design ethics. If ethics plays any part in the way that you’re designing your application or website, then this should be raising hairs on the back of your neck… you should be thinking that this is not right and that there is probably something you should be doing about this.

In fact, there are at least TWO somethings that I think we should be doing in this situation.

  1. The first is that we should be doing our best to help our customers/users/members to protect themselves. We should be educating them about the risks of handing over this kind of information and we should NOT be normalising this kind of behaviour.
  2. The second is that we should be looking for and encouraging alternatives to this ‘find friend’ functionality and we should be encouraging our clients/companies to opt for implementations that help our customers/users/members be more secure.

The kind of alternative that we should probably be looking for is something like OAuth which is an open protocol to allow secure API authentication in a simple and standard method from desktop and web applications. It is designed to help you get the information you need to give your end users a good experience without asking them to hand over personal information, like a username and password. Check out this demo of the current user experience. As far as I know, OAuth is not live on the web anywhere yet, but its cousin, OpenID is starting to be more widely adopted.

Of course, if we all had portable social networks, then that would also make things an awful lot simpler and more secure but it all seems quite a way off yet… why so far off you ask? Well…
So far, however, the drive to develop and promote these more secure alternatives is very much being driven by the more technical people on the web. There are lots of scary sounding discussions around exactly how these methods should work. Designers are, for the best part, not to be found in these conversations.

This is problematic from couple of perspectives.

  1. Firstly – if anyone is going to be able to drive the uptake of something like OpenID or OAuth, then it is going to be UX people, the people who are designing the experiences and making recommendations about what constitutes a good experience. Unfortunately, too often by the time the techies get a look in, all the functional decisions have been made and it’s too late to retrofit what would potentially be a much better solution for our end users. We have a responsibility to know about these things and to promote them.
  2. Secondly – from a user experience perspective, there are a lot of challenges to be found in OpenID and OAuth, primarily because you need to educate people about what is going on and also because you are typically moving them through quite a complex flow – including from one site or application to another and then back again. At the moment, the user experience of OpenID and OAuth are far from ideal, but rather than using this as a reason not to work with them, we should be seeing this as an opportunity to engage with these design problems and to use our experience and expertise to help get the user experience as good as it can be.

At any rate – looking after the security of our end users is now very much a part of the responsibility of the designer – whether it is through helping to educate those end users not to hand over information irresponsibly, or by guiding our clients/companies to use methods that better protect our end users. We need to be engaging in these discussions and helping to guide them both from the perspective of the businesses we’re working with as well as in the ongoing technical discussions about how these technologies work.

I think we have a responsibility to help protect our end user, even from themselves. To ignore this responsibility is unethical.

Four kinds of failure (for Richard Branson)

I’ve been experiencing some pretty average customer service lately but it really all came to a head when I moved house recently. As I spent hours and hours repeatly calling VirginMedia, who were supposed to supply us with an internet connection, cable TV and a phone line, I had plenty of time to contemplate the ways that companies fail us. By my calculation there are about four types of failure. And, perhaps surprisingly, they’re not all bad.

  1. Might as well set a trap. This is the worst kind of failure (and the one I experienced – continue to experience – repeatedly from VirginMedia. You know this kind of failure, because you can feel the blatant disregard for your experience as a customer. These companies seem to go out of their way to avoid or ignore customer feedback. THis is clear in both their service design and any UI design you come across. It’s typified by long waits on hold, little and/or contradictory information provided, a strong sense that you (the customer) are being a pain in the butt and causing the company and it’s representatives unending trouble, user interfaces that are so poorly designed that it is inevitable you will not get to the end successfully, a sense of loneliness and hopelessness as a customer. Mistakes happen often. The company couldn’t care less.
  2. Could try harder. Obviously some effort is being made. Most of the information you need is available and reasonable (sometimes good) design is in evidence, but there are still major customer experience failures and no obvious feedback channels. Often the solutions to these experience failures are quite simple. Frequently they’re as simple as building in more feedback or simple error prevention. But often… these easy fixes don’t happen. Contextual research is required to identify the pain points to enable these simple fixes to be designed and applied. There is a lot of potential for improvement here.
  3. Thoughtful and Responsive.  Things still go wrong from time to time but you don’t mind so much because it doesn’t happen often and when it does, it is clear that an effort is being made to be responsive and supportive and to take responsibility for the failure. Failure is still frustrating, but it is no longer necessarily a negative exchange between the company and the customer.
  4. Surprise and Delight. For some, failure is actually an opportunity to make contact with a customer and learn from them - and having the chance to surprise and delight them. Kathy Sierra wrote of screaming users:

    “As Henry Petroski writes in To Engineer Is Human: The Role of Failure in Successful Design, we learn more from our failures than our successes.  But only if we pay attention to the failures and figure out what to do right the next time.” 

    Every now and then I fire off an email in annoyance, and every now and then, an actual human emails me back much more quickly than I expected and resolved my failure. Jeff Turner of Blogbeat (now Feedburner) did this all the time. Even when the server was down and I annoyingly couldn’t get access to the data I wanted, his quick and helpful response would always make me smile and think well of his company.

So, what’s the moral?

Failure happens, but through contextual research and good service and interface design you can minimise the negative impact of these failures and actually turn them into positive points of contacts with your customers.

Oh, and think really seriously before you sign a contract with VirginMedia.

why bother calling if you call so late?

Don’t get me wrong… it’s not that I don’t want to work with you. I’d love nothing more to help make sure that your design is great and people love to use your product.

It’s just…  by the time you get to the part in your project plan that says ‘Usability Testing’, there’s not much I can do. You’ve left things too late.

Sure, I know. That’s when you do the usability testing, isn’t it? In that mad rush when you’re trying to get everything coded up and launched. I know, because it usually means that we don’t get much time to do the testing, and it’s usually not with the finished product.

And, you know… that probably would be ok, if we’d have done some testing earlier on in the piece.

OK, so you might not call it testing. You might call it research. Or you might just call it putting some ideas in front of people who might be using your product in the future and seeing what they think.

No, we don’t need your finished product before we can test. Not at all. We’ve tested with scraps of paper in the past and discovered we were heading down the wrong path altogether. We’ve learned a LOT about how our design should work even with some ugly wireframes.

And the great thing is that scraps of paper and wireframes cost nothing… compared to the amount you’ve invested in getting to the ‘Usability Testing’ line item on the project plan.

Compared to the amount you’ll probably have to spend if you want to implement any of the things we’ll probably learn if we do that testing now.

Of course… between you and I…. we know that’s probably not going to happen anyway, is it. There’s no time for changes. There’s a launch date fast approaching, and hardly enough time to finish the work you have already.

We’re just ticking a box here, aren’t we. With the best of intentions.

It’s a shame tho’. We could have been a good team.

We could have got to a kick butt design, one that we *knew* would work. We could have stopped all this coding and re-coding. We could have had good strong answers to questions that the business was asking. We could have taken so much of the guesswork out of it.

We could have been launching this thing with out the sneaking suspicion we’d be back at the drawing board (literally) in the very near future.

But I’ll tell you what I’ve found, and you tell me that you don’t have time to do anything about it.

And hopefully, next time, we can work together from the beginning.

I think that would be a much better idea.