Familiarity Now vs. Effectiveness Later
1:46 am May 26th, 2008It’s a familiar adage that an effective user interface is designed to be familiar; users don’t like to encounter systems that make them think on the first try, which usually means they like to encounter interfaces that are as close as possible to the ones they’ve encountered before. This is on my mind because I’m currently learning the interface for a new music player; it has quite a learning curve, based in large part on its unfamiliarity (not that “File” is the most reasonable choice, in hindsight, for a menu name, but is “Engage” really any better?). But the more I dig into Amarok, the more I realize that it’s incredibly full-featured, and it’s just not possible to display every feature in a commonly-understood way; once I learn the basic operations, they seem straightforward and natural.
I’m reminded that the high learning curve is a common criticism of Linux — you’ll have to learn the command line, or my favorite text editor (of course! Ctl-@ Ctl-n Ctl-n Ctl-w Ctl-y to copy and paste a couple lines!), or the Gimp, or any number of unfamiliar solutions to familiar problems. But many people, once they learn these solutions, realize that the initially tricky solution can be more efficient in the long run, and that difficult-to-figure-out interfaces are often so because there are so many things you can do with them (Photoshop’s advanced features aren’t too intuitive to figure out, either).
Building a familiar interface will allow quicker adoption of your product; but a lot of the software people are loyal to the longest doesn’t necessarily have the most intuitive interface, but the one that helps you get things done once you’ve learned it.
