When faced with a design decision in which one option is more intuitive, and the other is more efficient, what guideline should be used to prioritize one desideratum over the other?
Which is more important depends on what you are designing. My general guidelines would be:
Intuitive matters mast when you're designing an app that people aren't going to invest time into learning. It's important that they get a win as soon as possible, and that means that they need to be able to use the product with little or no time learning it. Think of a small mobile app. Instagram is a great example.
Efficiency matters when people are likely to use the app a lot and they are prepared to spend time learning it. This applies when the perceived value in learning to use the application is greater than the perceived initial learning barrier. Note, perception matters a lot here. Think of an app which a programmer will use all day. VIM / VI / EMACS are good examples.
That said it is hardly ever such a clear decision between one or the other. It's a compromise between the two. Sometimes you can make something a little less efficient and a lot more intuitive and the other way around.
Spend some time thinking through what really matters to your target audience or, even better, ask them and do some early stage usability testing with them. You may just be surprised what you learn!
Looks like JohnGB beat me to it.
As he says, efficiency wins out when:
- the user will be spending a lot of time with the application
- the application will become important to the user, and they have an investment in understanding its nuances
- the application exists in a time-critical domain
A good example might be a stock tracking application for a city trader. Traders obviously have a massive investment in getting the latest, up to date knowledge on the state of the market - thousands of pounds are at stake. So a trader will be quite willing to spend some time learning the app's shortcuts and nuances. Time is of the essence in stockbroking, so anything that shaves seconds off could really be worth it.
Good answers here for your typical consumer app. However, if you want to get beyond rules of thumb (such as “more use means favor efficiency over intuitiveness”), then you need to apply a formal human systems integration (HSI) approach.
With HSI, you look to minimize total lifecycle cost (or maximize revenue) by designing a system with optimal levels of out-of-the-box usability, training, personnel needs, and manpower. You do this by getting numeric estimates of the cost of each for your alternative system designs.
Training. When intuitiveness conflicts with efficient design, there may be less total cost in training the users to correctly use the efficient UI than going with the alternative intuitive UI and avoiding training costs. Training is mostly but not purely an up-front cost. A non-intuitive UI will typically also require periodic re-training for unusual situations to minimize operational human errors.
Personnel. Alternatively, there may be better savings in selecting users based on their ability to use the efficient UI without training. Maybe there is some population of users that do find the efficient UI to be intuitable, or at least they can figure it out quickly on their own. Of course, finding and retaining these users implies more cost, especially if the skills of these users are particularly in demand (e.g., they know SQL).
Manpower. Another alternative is to have more users. So an app is less efficient. So what? If it’s less productive, maybe you can make up for by throwing more users at the problem. Depending on turn-over, that might be a cheaper way to go. Inefficient call-center app UI? Hire more call center staff. It also can impact the system design: Maybe you can break the system into smaller simpler apps each assigned to a different user group. Each part is both efficient and easy-to-learn to that user group, but now you need more users.
If you want, you can also toss in the cost of health, safety, habitability, and survivability into the equation, if they’re relevant.
This approach could be applied to the UX of a public web site or application.
“Training” in this case is self-training –the time the user spends studying the site and reading in-line or linked documentation in order to figure out how to use it. Is the time spent reading made up by efficient use later? Include in your cost calculation those that “drop out” and don’t complete the “training.”
“Personnel” is your audience. Maybe you don’t want a web site for all users. Maybe you want something for a particular niche of users with certain skills or experience. Make that clear on the home page and non-appropriate users won’t waste their time.
“Manpower” may mean breaking your site up into simpler sites for different tasks or audiences of users.
Is your case really worth the effort of a formal HSI analysis? I guess that’s the meta-HSI of HSI. Estimate the cost of a formal analysis against the chance and cost of you coming up with a sub-optimal solution without it.
While it is very much dependent on the app, you should always balance the two. The efficiency of an application is an important part of the intuitive use - that when you do something, the system responds as quick as possible. If the system is inefficient, then you do not get the response, and so you lose efficiency.
OTOH, if the application is not intuitive to use for the target user - which may be someone who has spent some time learning - then the performance speed of the code will be irrelevant, as the user efficiency will be reduced.
So you have to balance the two in each situation, to find the best compromise.