David Burrowes' Blog

Here it is, three days before the Christmas holiday. Sun, in the United States, shuts down from December 25th to January 1st each year. So, I'll have no posting here next week. Instead, I'll be spending some time away from computers for a while!

I was part of a discussion about command line interfaces this week, where the issue of optional option-arguments was being discussed. For example:

$ myutility --foo  thingie

$ myutility --foo=value thingie

The discussion went on for great length with the folks discussing (among other things) whether this was a different kind of interface detail than one other.

This got me thinking about small interface details. I remember one email discussion, a few years ago, which went on for days about the use of ellipses ("...") at the end of menu items. How and when they should be used. I've seen long debates about whether icon X or icon Y should be used.

While I was part of the NetBeans project, I remember times where someone would suggest a tiny interface change and there would be a storm of discussion about this on nb-ui. At other times, a design for a big change to the interface would be suggested and there would be almost no comments raised.

Why is this? Why is it that tiny details raise such intense discussions while larger issues often don't? Here are some thoughts:

* The people challenging the idea are actually seeking some level of ownership over it. When they are focusing on the particular detail, they aren't actually interested in that detail but instead are seeking to try to use this detail to persuade themselves to adopt the ideal.

* Those challenging the idea may actually be trying to test out the presenter. They've picked this more as a way to verify that the presenter knows what he or she is talking about, and again are less interested in the detail itself.

* Both sides hope that by convincing the other about this small detail, the other's whole framework will collapse. So, the discussion around the detail is actually hoped to be a vulnerable and critical point in the whole system.

Perhaps there are others, too. In all those cases, the detail is being used as a proxy for discussion about something larger.

In many cases, though, I think the reality is that it is simply easier to think about and criticize a small thing than a big thing. This is actually dangerous both for user experience practioners and for those challenging them. As a UI person, I've more than once delved into offering "constructive feedback" on the details of some design and neglected the larger issues (e.g. worrying about the naming of some menu item and neglecting that the menu item would probably never be used because of some systemic usability problem). And I've certainly been on the receiving side of that as well.

The funny thing is that good UI design often requires one to look at as large a picture as possible. The usability problems there can easily dwarf any and every small (and easy to identify) usability problem. By the same token, successful design in the big picture can render small usability problems basically irrelevant (because, really, people can usually overcome small problems relatively easily).

The message here is that when doing UI design, one should often strive to let go of the small details and concern oneself with the big user experience issues. Don't worry about the positioning of buttons first (an easy thing to identify). Instead, make sure the tasks that someone would want to do can be done with the app (a hard thing to identify).