user_experience

“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 }

The User Experience Of Enterprise Software Matters, Part 2

by Paul Sherman on March 24, 2009 · 0 comments

My latest column at UXmatters was just posted. It’s part 2 of my December article “The User Experience of Enterprise Software Matters.” Again, my main points are:

Organizations making enterprise-level technology selections often do an incomplete job of assessing the real-world effects of the new applications they impose on their staffs’ workflows and processes.

and:

The technology selection process typically neglects methods of evaluating the goodness of fit between the enterprise users’ processes, workflow, and needs, and the vendors’ solutions. Organizations could avoid many a rollout disaster simply by testing the usability of vendors’ solutions with employees during a trial phase.

In this part 2, I pick up where part 1′s “j’accuse” leaves off, and actually provide a framework for enterprise user experience practitioners to employ when trying to get involved in the assessment of enterprise software under consideration by their organization. Rather than recap it all here, I’ll just point you to the article.

The User Experience of Enterprise Software Matters ::? Paul Sherman

{ 0 comments }