Stuff In The World

“Beyond Here Be Dragons” – Or, Don’t Design For The Edge Cases

by Paul Sherman on September 4, 2009 · 3 comments

in Design

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 }

Does Anyone Else Confuse The “Door Open” and “Door Close” Buttons?

by Paul Sherman on April 23, 2009 · 9 comments

in Design


(Click picture to see full-sized)

I don’t know if this happens to all y’all, but I always have a hell of a time figuring out which button *opens* the elevator doors and which button *closes* them.

It happens every time I get in an elevator. Invariably, after I’ve already boarded someone runs to make the elevator before the doors close completely. As soon as I see them, I try to be helpful. I go to hit the “door open” button, hesitate, shift my gaze from one to the other in a semi-panic, and then jab the WRONG button.

I think I’ve figured out why I have such trouble discriminating between the two icons: the “door open” button (on the left in this picture) looks to me like the image of a *closed* door, and for some reason the action implied by the outward-facing arrows just doesn’t register with me.

Similarly, the “door close” button on the right, with its two strong vertical lines defining the outer edge of the icon, just seems to me to look like two open doors. And like the other image, I just don’t grok the arrows in the picture.

Is it just me that has this particular problem, or is does this design confuse others as well?

{ 9 comments }