The Limits of Productive Ignorance
I’ve recently been working on a lot of user interfaces. I am not using the term in the common, rather narrow, sense of a GUI, but in the broader sense of any and all forms of abstractions that are intended for practical use. These have included:
The Ant scripts for a build/test process and the file-system layout of the project.
Class/Package interfaces for various software subsystems.
The management model for configuration of development and test environments.
The design and construction model for a user interface, i.e. how do we describe and build a UI — the interface to the interface, if you like.
In each case, a central question is “exactly how much should I hide from my users?”. The Apple ethos would suggest “everything you possibly can”, working from a desire to produce a simple interface. Is that really the best choice though? At what point do I begin to hurt the utility of the thing I am providing an interface to by protecting my users from seeing the machinery? At what point do I begin to hurt the users themselves?
The last question may seem a tad melodramatic, but I believe there’s a real danger in molly-coddling users in that you prevent them from becoming truly skilled. I’m not the only one who thinks so either: take this post from Kathy Sierra’s “Creating Passionate Users” or this one from “Joel On Software”, both of which lament the potential for making users dumber by keeping them away from the details.
Let’s be clear, I’m not talking about mass-market consumer products here. In that arena there are good reasons for making interfaces out of primary-coloured cotton-wool — users of those products have no desire to be experts. Kathy Sierra’s post above uses the example of cameras and it’s an apt one. If I buy a point-and-shoot digital, I want it to be just that and, frankly, I don’t even want to see the potential for making choices. On the other hand, if I’ve gone out to buy a “semi-professional” camera, I expect to be spending some time working out how to use it and I’d be disappointed if I found that I couldn’t set some feature or other. This post is about creating the second kind of interface, one that supports growth into expertise.
So, what’s the problem here? Surely I should just expose all the toggles and levers and let my expert users get on with it? Well, that would be nice, unfortunately:
Expert users still need a usable interface. In fact, expert users demand far more from their interfaces in terms of ergonomics. I’m sure there are a lot of factors that go into the feel of a button, but if I’m a casual photographer and the button is the only thing I have to press and I only press it a few dozen times a year… well, I don’t care much about the quality of the switch or its precise positioning. If I’m a keen photographer and I have to press it a hundred times a day as well as manipulating rotary switches and menus etc. then I care a lot more about the construction.
Not all users are keen to become experts. If they’re consumers, then it’s their choice to not be so and the argument stops there. If they’re professional users, paid to be experts then I’m afraid that some tough love may be in order.
These two forces often seem to interact in odd ways, and a common outcome is the meant-to-be-expert user who argues that they should be dumb about something — that the interface should be easier, simpler. This is the “productive ignorance” gambit of the title and I think it points to a useful analytical tool for assessing interfaces against intended users.
The argument is that the user gains productivity through not having to worry about some detail or other. For example, I find it easier to deal with mixed storage such as hard-disks, flash-drives and ftp sites through a file management interface that allows me to not worry about the differences. Another example might be that most graphics apps will load any number of different image file formats without me having to get involved in the decision about how to decode the file. So far so good. I can be ignorant and I’m better off because of it.
However, if I am an “expert” user, then maintaining that ignorance can become quite costly. Take the graphic format example. There is no harm in loading all file types automatically, but if the app hides the file type from me on saving and on creation of a new image then it’s doing no favours to someone who handles image files professionally. It’s no fun working with graphic designers who don’t understand the differences between vector and bitmap file output, lossy versus lossless compression, palettes, bit-depth etc. and abstracting the realities of those factors away has a negative impact on productivity.
Decisions made when designing interfaces need to be made with an understanding that demanding something of the user and letting the complexities show through is not always a bad thing. The sensible question to ask is not “Can I possibly hide this detail from my user?” but “Will my user gain value from understanding and/or manipulating this detail?”. The more expert your user-set, the more effort you should put into giving them power over the details through your design rather than into keeping the details away from them. It’s for their own good.
