Not parsing phone numbers into area code-exchange-suffix is just plain lazy coding. It makes for hard-to-read numbers.
’nuff said.
OK, I didn’t say enough. This is yet more evidence that the price of usability is eternal vigilance.
Stepping off the soapbox now. Have a good day y’all.
{ 2 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 }
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?
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.
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 }
Either have I. But that’s exactly what I’m going to do tonight. I’m driving up to Dallas to observe a full day of utesting with one of my Dallas friends who works for a game publisher.
I will blog – in fact, I may even liveblog – my experience tonight.
Stay tuned.
{ 2 comments }
