Not This Product
Today in preparing to head to StarEast I was gathering my ticket, directions, and other official info. One of the websites I'd just ordered from sent me details in my hotmail inbox. I'd asked for this email, so I was fairly certain it was safe, but check out the warning I got:
As I see this I know that hotmail would see this "as designed" since they are protecting me from what could surely bring peril and also have provided me a workaround. What about the well known company who sent the email? This doesn't happen with non-hotmail accounts, so clearly they have no responsibility to make this experience better.
So, what if I was an average user? Would I be worried that I had an email virus? Would I become so desensitized to seeing these errors that I always open them anyways?
I say that this is a user experience issue. It is an issue for the product formerly known as hotmail, a.k.a. Microsoft Betty, Windows Live The New Busy Bees Knees Email system. Why? Because it is annoying to get false security messages and each false warning you give a user makes it less likely they are going to heed any warnings.
It is also an issue for the sender of this email. It is harder to conduct business with the company who sent the email if I am not sure I can trust them. This email warning message gives me the message that there is something wrong. Rather than the confirmation raising confidence, it has lowered my confidence.
How many issues that impact customers daily are closed as "not this product", "not a bug", or "as designed". If it hurts the customer experience, it still is an issue. What do you do when an issue isn't a bug, but still impacts the user experience?
As I see this I know that hotmail would see this "as designed" since they are protecting me from what could surely bring peril and also have provided me a workaround. What about the well known company who sent the email? This doesn't happen with non-hotmail accounts, so clearly they have no responsibility to make this experience better.
So, what if I was an average user? Would I be worried that I had an email virus? Would I become so desensitized to seeing these errors that I always open them anyways?
I say that this is a user experience issue. It is an issue for the product formerly known as hotmail, a.k.a. Microsoft Betty, Windows Live The New Busy Bees Knees Email system. Why? Because it is annoying to get false security messages and each false warning you give a user makes it less likely they are going to heed any warnings.
It is also an issue for the sender of this email. It is harder to conduct business with the company who sent the email if I am not sure I can trust them. This email warning message gives me the message that there is something wrong. Rather than the confirmation raising confidence, it has lowered my confidence.
How many issues that impact customers daily are closed as "not this product", "not a bug", or "as designed". If it hurts the customer experience, it still is an issue. What do you do when an issue isn't a bug, but still impacts the user experience?
Posted by Testy Redhead at 26 Apr 2010 
Categories: uncategorized
Tags: testing integration expected results inbetween bugs who's bug is it anyways user experience
Categories: uncategorized
Tags: testing integration expected results inbetween bugs who's bug is it anyways user experience
Hi Lanette,
In my experience how effective we can be at “defecting” user interaction issues is almost entirely based on the maturity of the people working within the organisation.
I have worked with user interaction designers that fight tooth and nail and claim their original design is sacrosanct whilst others will sit down, discuss and if necessary change their design based on the feedback from testing. It’s not hard to guess which I prefer to work with.
My basic process is to raise these issues formally and then sit down with the UI designer for a jolly good discussion. If the issue is significant enough and you can’t come to an arrangement getting a user testing session up and running at short notice may alleviate or illustrate the problem. It may be possible to use the A/B testing technique here to come up with quantitative numbers. Often I learn why their design went the way it did.
I think speaking their language helps when raising issues. I suspect that it comes across more as a peer review, a fellow designer suggesting an improvement, rather than a defect from the testing area.
One thing that was tried here recently was using replacing the word defect to “request for clarification”. It was a sticking point for the interaction designers because they didn’t like being defected for potential design issues. It was an easy change for us; even though I felt they were being a bit precious.
I'd be interested to find out if anyone uses a different process for getting these issues resolved.
Cheers,
Ryan
Reply to this
Hi Ryan,
What a cool and detailed comment! My experience has been that a demo works well, but also that I have to be careful to back up my claims with real customer data.
One example is we have a long standing copy/paste cluster of bugs. I helped put together a demo that really showcased how they all grouped together to create a bad experience. Well, come to find out, the customers are so used to it not working how they want that they just avoid it. Instead they want engineering to work on other issues they can't work around. I have since made sure to check with users for their top issues and think more about how many customers this bug could impact given everything I know from available user data and talking to people. I still think showing the demo of how the bug impacts people is a good technique.
One other thing that has been working for me is to be clear that I have a usability concern, not a code defect on my hands when bringing up something a customer might encounter. That helps it be understood by all that I realize there isn't a "bug" in the traditional sense.
One of the issues we face that makes this testing difficult is that the feedback often comes too late in the cycle. I wish that it was a priority to allow end to end usability testing early enough that making changes isn't a danger. So often the team forgets that the overall experience a user has with the software is what they based their recommendation of the product on, not a list of features or if it works "per the requirements". They never see the requirements.
Thanks,
Lanette
Reply to this
about email context: In my observation, it does makes sense to warn the user for potential hacks via emails and make user responsible for his/her own decisions.
regarding "It is also an issue for the sender of this email." -- Isn't this one of the reasons why companies when you transact with also indicates to add their server name into the safe list so you can receive the email in your inbox and assuming some mailer servers may put them in junk folder or deleted folder based on the rules?
Reply to this
interesting - site didn't confirm if my prv comment was submitted or not. resending just in case.
--------
regarding "It is also an issue for the sender of this email." -- Isn't this one of the reasons why companies when you transact with also indicates to add their server name into the safelist so you can receive the email in your inbox and assuming some mailer servers may put them in junk folder or deleted folder based on the rules?
Reply to this
These sort of false warnings are indeed a nuisance to e-mail users! Anyone seeing such a warning would never open that mail thinking that there would be a virus which would cause their system to crash! So what can be done about such false warnings? It would really harm the companies (as in this case) who are trying to do their business online. With so many businesses being done through the internet, it is very important that something be done about such false warnings!
Reply to this