I’ve been a bit late bookmarking this one but it is worth a watch
Similarly, a little late bookmarking this one too, but here Twitter makes an appearance in CSI… I rate CSI all the more highly for going Twitter and not FaceBook :)
We’re doing some research on a new social communication platform and need your help. More specifically – we need you and three friends you communicate with regularly online.
It’s a bit of an extended research project and you’ll need to be available for an interview in London between 17-20 December, and then again in the new year on the 7th or 8th of January and once more between 16-18 January.
We’ll make it worth your while though – there’s £120 in it for each of you and you’ll get to play with a new social communication tool and help shape its development before it is released publicly.
You need to be somewhere between 21-40yrs old, and you’ll need to be back from the Christmas break and doing whatever you usually do (work, study etc.) by 8 January.
If this sounds like something you’re interested in and you think you can rope in some friends and/or family, contact me ASAP at leisa.reichelt at gmail.com for more information.
PS. if this is not for you but you know someone who may be interested, pls feel free to pass on the details. Thank you!
This weekend I went to BarCamp and it was great. Always good to catch up with fellow campers and hear what’s on their minds.
What was on my mind this weekend was DIY User Research – you can see my slides above. This took me a little out of my comfort zone as I resolved not to say ‘it depends’ but to make some overall recommendations as to how almost anyone can afford the time and budget to do a little research, and the best ways to spend that time or budget.
This has been based on the experiences I’ve had recently doing User Research for start up companies who have very small amounts of time and money, but who desperately need the kind of research that I’ve recommended. The techniques I’ve suggested here have worked very well so far, although I hasten to add that I’ve undertaken the research work myself.
This is not to say that you can’t *really* do it yourself… if you use the right techniques you will get a LOT of value from DIY research… but an experienced researcher is, of course, worth their weight in gold :)
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:
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.
- 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.
- 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.
- 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.
- 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.