(Note: Here’s another guest post from Andreas Bossard, proprietor of the blog News of the Future and author of several excellent UsabilityBlog posts. Today he talks about his travails with the Paypal help system. Enjoy. -Paul)
I wanted to get help in Paypal, that’s why I clicked on “Help” and expected to see the help section of Paypal.
Instead I saw the following:
All that I read when scanning through the page is:
Help information isn’t available in English yet. […] select U.S. English.
So I need to change the language to U.S. English. Okay, I try to remember all the steps that they tell me, go through them and reach this page:
Hmm. I cannot see U.S. English. How to select U.S. English now? I think I will contact the Help Center. …But wait a minute… I could not access the help pages, that’s why I came to this page in the first place. I’m trapped in a can-not-get-help-loop. *argh*
Note: If I select German, then the help center is shown! But if I was an English speaker I would not be able to get help. I think this bug exists only for Swiss users, otherwise it would be fixed since a long time.
What to learn from this mistake by Paypal:
- Let me select the language for the help pages directly
- Or give me a direct link
- But no lengthy instructions please
When I clicked the help link, I need help immediately!
This is just a quick pointer to my latest UXmatters column, which is a follow-on to my article from September about the perils and pitfalls of testing your own designs.
In this follow-on, I revisited some of my more bombastic points about testing one’s own designs. Thanks to some excellent comments by several colleagues (and colleague-slash-wife), I modified and built upon my original recommendations and provide some modified guidelines. Here’s the summary guidelines. To understand the reasoning behind them, go read the whole article.
Guideline 1—When testing your own designs, don’t think of it as a test to pass or fail, think of it as part of your design process.
Guideline 1a—Test early, test as often as possible, and test lo-fi prototypes rather than making usability testing a make-or-break event in your design lifecycle.
Guideline 2—When testing your own designs, you should seek disconfirming evidence, but be alert for joys and delighters, too.
Guideline 3—When you’re trying to solve a design problem, usability testing serves design. It’s a tool. Use it to improve your design, not to justify your actions.
Comments about these guidelines? Email me via UsabilityBlog, or comment at UXmatters.
Testing Your Own Designs Redux ::? Paul Sherman via UXmatters
(Here’s another guest post from Andreas Bossard of News of The Future. He actually submitted this about two weeks ago, and I’ve just been too busy with project work to post it…my bad. My apologies, and thanks for the pic and post Andreas! -Paul)
The following user interface of a video-conferencing system cries for simplicity. It’s crammed with so many buttons that the average viewer easily gets overwhelmed.
Even the core task of “setting up a video conference connection” becomes a challenge.
User-centered design was definitely not part of the software development process for this product.
Here’s another guest post from Andreas Bossard, who you may remember did a well-received post last year on the Sony Ericsson PC Suite. Thanks for contributing again Andreas! -Paul
- – - -
How fast things change. I wanted to write about a workflow in LinkedIn, which had annoyed me for months, but they have fixed it in the meantime, before I could publish the article. :) So anyhow, here is the article. -Andreas
One of the most used functions in Linkedin is to add a new user to your own network. If you don’t know the e-mail address of the person or other personal information you can choose “I don’t know xy”.
Then the user can enter a personal message and click the “Send Invitation” button. Which opens the following message:
The only way to proceed is to click “Go back to xy’s profile”. The personal message is lost! You stepped into the Linkedin user trap.
Of course, according to the Linkedin policy you’re supposed to add only contacts you personally know, but since you can bypass this rule anyhow by selecting “Friend”, it’s illusory to educate the user by punishing him to re-enter a personal message.
There are two solutions to avoid this unpleasant interaction:
- A “Close”-Button instead of a “Go back to xy’s profile”-button
- Pop up the message immediately, when the user selects “I don’t know xy”, instead of giving him the feeling, that he now can enter a personal message for that person.
As we can see, they solved it with a “Cancel” link.
I got an email from a reader saying he had a usability issue to rant about, and could he do a guest post. I said sure thing. So without further ado, here’s a post from Andreas Bossard, proprietor of NewsOfTheFuture.net. I’ve got a Sony Ericsson phone too, and I’ve been annoyed by this little feature as well. I hope you enjoy UsabilityBlog’s first guest post, and a big thanks to Andreas for putting it together. -Paul
Every time I connect my Sony Ericsson phone to my Windows PC, I am reminded of an annoying feature of Sony Ericsson’s PC Suite: The time checker that checks if the time of the cell phone is the same as the time of the PC (see picture below).
Every time I connect it pops up and asks me if I want to change the time of my cell phone. The program assumes that the time of the PC is always correct. But the opposite is the case: The cell phone time is correct, but the Windows time is wrong. So I always have to select “No”. The funny thing is that “Yes” has the option “Every time I connect. Do not show this message again”, but “No” doesn’t ‘t have such an option.
Only about 30 seconds difference, but PC Suite sees immediate need for action…
What designers can learn from this mistake:
- Make the right assumptions. Here it is assumed that Windows time is always correct, which may not always be the case.
- Give the user the possibility to disable an unwanted feature. Especially if it is an annoying pop-up window.
Note: The current version of PC Suite is version 3. This time-checker-feature was present in version 2. Nevertheless, it’s a good example of bad usability.
