September 2009

In general I try to be strategic, which usually means talking about “big” user experience and staying oriented on the business value of UX.

But every once in a while I just have to point to a particularly bad interaction, then cluck my tongue and wag my finger.

So it is with this time zone setting interaction from Typepad.

What a pain in the tuchas. I actually gave up trying to set my time zone because a) the list is so large and unmanageable and b) I couldn’t find Dallas or Houston, much less Austin. I understand that this service is meant to be used world-wide…but how hard would it have been to lead off the list with “US Eastern (GMT – something)”, “US Central” (GMT – something)” etc?

Oh, and if you go to your Typepad account settings page I challenge you to figure out which fields are required. Hint: you can’t. Because they don’t tell you until after you fail to fill one out. Nice.

{ 7 comments }

In my last post I advised that my pending UXmatters.com article would be covering the topic of whether designers can usability test their own designs. The article is now available here. In it I presented feedback from several people about the wisdom of testing one’s own designs, and generated some recommendations for how to do it well if you find yourself in the position of having to test one’s own design.

Quoting myself:

When testing your own designs,? always concentrate on the negative.

To focus on the negative aspects of your design, try to keep yourself focused on your long-term goal, which is to solve your users’ problems.

I also discussed how to recognize when your design should be scrapped instead of modified:

If your users are unable to grasp the task at hand or are experiencing repeated failures and missteps when navigating your design, you should consider? rethinking the entire design.

Hopefully you’ll find this article useful. Also, the comments in my previous UsabilityBlog post are very instructive. Have a look.? Here’s another link to them.

{ 1 comment }

I’m putting an article together for UXmatters on the topic of usability testing and validating one’s own designs. My goal is to develop some guidelines for self-testing.

I’d love to get your feedback on some questions I have:

  • Testing your own designs: all-around bad idea? Or is it possible to do it well?
  • If so, what should you do / not do when testing designs you’ve created?
  • What should you look out for?
  • Got a good story or anecdote to share? Please do. Either success stories or cautionary tales are welcomed.

Thanks in advance. -Paul

{ 12 comments }

Let me be up-front about this from the beginning: this is a half-formed thought. But its implications are very, very interesting.

So here’s what just happened: I had a desire to take in some emerging thoughts in the user experience field. I wanted some fresh thinking, some exposure to new presentations.

For about 8 years, my first instinct has been a) browse to Google, b) type in “user experience”, and c) browse the list of returned search results to see if anything new strikes my fancy.

This morning, I didn’t do that.

Without even realizing I was changing an ingrained habit, I went to Twitter.com, typed “#ux” in the search box, and browsed the list of returned tweets. I clicked a few, starred a few, and made a mental note to come back and check out some of the links to preso’s.

Then I sat bolt upright when I realized what had just happened.

This, colleagues and readers, is an early warning. An indication that one of my consumer habits is open to change, and could very well tip into a new and different routine.

And if it happened to me, it can happen to any of us.

I don’t know if you’re grokking the import of what happened, so I’ll restate it: something in my sub- or semi-conscious mind decided that the resource I’ve been relying on for years might not be cutting it any more, and it directed me to try a more real-time and dynamic resource.

I will certainly follow up on this in future posts. But right now, I think this incident opens up several interesting research and design questions, such as:

  • How much of customer behavior is consciously directed, and how much is directed by the sub-, un-, or semi-conscious?
  • What factors influence customers’ willingness to change behavior?
  • What are the leverage points for changing customers’/users’ habits?

{ 14 comments }

Found this on Digg.com today, and promptly added it to my “Questionable_Designs” set on Flickr.

What a great example of after-the-fact design modification.

It makes me wonder what the context was. Did someone set this up for a young child or an older relative? Or did they do it for themselves?

In any case, it’s a great reminder of why us user experience professionals do what we do.

For those of us in design: remember, you shouldn’t design for *all* the edge cases. You shouldn’t even design for most of them.

Why? Because you clutter the user interface when you try to account for all possible user needs.

A reasonable question to ask at this point is this: if you have a set of rich capabilities that *some* small subset of people might want to access, what do you do?

That answer is actually easy. There’s two things you can do in this very specific case of a TV remote.

Both of them are examples of what I think of as “beyond here be dragons” design. Without going into the etiology of that (in retrospect kinda obtuse) metaphor, let’s just say that it’s often a VERY good idea to surface the UI for your minimal main user stories while burying the controls and interactions for the complex edge case capabilities behind an access point that clearly indicates that the functionality is not intended for most people.

So how do you do this for a TV remote?

  • Method 1: Put the advanced functions underneath a sliding cover. This was all the rage 8-10 years ago. Not seen as much today.

Advantages: The cover makes it clear that, well, beyond here be dragons. Effective.

Disadvantages: Presence of physical parts probably means higher cost to manufacture. Physical parts (i.e., cover and slide) also wear out.

  • Method 2: Put the advanced functions in the onscreen portion of the UI. The simple controls on the remote can then be used to step through the advanced dialogs and tasks.

Advantages: No additional hardware requirements. Provided the unit can receive updates, the software interactions can be improved if the initial UI design support for the complex stuff isn’t, shall we say, usable.

Disadvantages: Slowwww. Error-prone, especially for interactions requiring alphanumeric input via “point and pick”.

{ 3 comments }

I’ve been collecting and tagging pictures of interesting user interfaces on Flickr for about three years now. Typically I’ve blogged them one at a time.

It suddenly occurs to me that UBlog readers may be interested in seeing the whole set now that it’s pushing 75 pics.

So here’s the link. Enjoy!

Questionable Designs ::? Paul Sherman on Flickr

{ 4 comments }