Your user probably doesn’t think about the problem the way you do. And, unless you take the time to find out how your users do think about the problem, you won’t have anything like an “intuitive” interface.
Jared M. Spool defines “intuitive” as the gap between what knowledge the user has and what knowledge the application requires the user to have. In a previous post, I broke that definition down into two components:
In that last post I made the case for why, before you can create an intuitive UI, you have to understand your users’ mental models (the steps involved in achieving their goals, the kind of information required/provided, the way information is organized, and so on). I also provided some suggestions about how you could discover what your users’ mental models are. Before moving on to discussing UI design patterns, let’s take a look at some typical mental models you’ll discover as you investigate your users.
Sometimes your mental model matches your users’ model. For example, I doubt anyone organizes their appointments in alphabetical order (all the ‘Lunches’ followed by all the ‘Meetings’). In fact, most people (including you) use two models for organizing their appointments. For long term planning, most people use the “week-at-a-glance” model that shows appointments in each time slot for each day in the week (this allows people to answer the question “How can I balance out my week and avoid conflicts?”). But for short term planning, most people switch to a list view, sorted by time: what they have to do at 9:00, at 10:30, and so on. This answers the question “What do I have to do next?” Outlook is used by many people precisely because it supports both of these widely shared models.
Interestingly, all of us seem to have a mental model of buttons that matches the mental model we use for pets and children. When we want our children (or pets) to stop doing something we start small (we say “no”) and then escalate (“No,”…“NO!,”…”NO!NO!NO!”); With buttons we press the button (push) and, if we don’t get feedback indicating that something has happened, escalate through pressing it harder (Push…PUSH) to REPEATEDLY SMASHING THAT SUCKER.
However, that similarity between you and your users isn’t true of most users and tasks. I have an in-law whose model for “going to see a movie” consists of tracking down those classic movies he hasn’t yet seen on a big screen and doing whatever is necessary to see those movies in a theatre. I also have some friends who see a movie every Friday night (which means that, because they live in a small town with one theatre, they have seen both of the first two “Saw” movies). Obviously, a different UI is required for my in-law than for my friends. In fact, if my friends are one of the target groups for a “movie scheduling” application then my work is done: They don’t need a UI at all – they just show up at the theatre at 7:30 on Friday night.
My model of how a furnace works is based on the idea of “a target” so, if my house is cold and I want it to warm up, I set the thermostat to the temperature I want: My model tells me that the furnace will reach that temperature as fast as it can. My mother-in-law’s model is based on the idea of “striving” so, if her house is cold and she wants it to warm up, she sets the thermostat to 10 degrees higher than what she wants: Her model tells her that the house will get to her goal faster if the furnace is aiming for a higher goal. My mother-in-law’s model is brought over from a different kind of furnace than the one she uses now – in her childhood her family had a coal fired furnace where, when you were warming up a cold house, you did get a much hotter fire going initially and then reduced the size of the fire once you’d achieved your target temperature.
A great UI for controlling temperature for me would let me set the thermostat to the temperature I want to live with. A great UI for my mother-in-law would automatically discount any new temperature she set by 10 degrees to avoid overheating the house (my mother-in-law also deeply resents having to pay any more for her heating bill than she has to). If you prefer, you could try to convince my mother-in-law that her model is wrong and she should change it…but I’ve known her for about 40 years now and I have to you: It will be easier for all of us if you just give her the UI she wants.
I’m not suggesting, for example, that you built a UI for a notebook that “looks like a notebook”. But I am suggesting that a notebook’s UX should build on the user’s model of a notebook: a collection of entries that can be either read in sequence or directly accessed using markers/tabs. A UI built on that model will be more “intuitive” to users than, for example, a UI that included every letter in the alphabet and allowed users to link them together to form an entry (this is referred to as the trie model and is a data structure that facilitates searching for text).
As we discuss in User Experience Design for Successful Software course, matching the UX to the user’s mental model goes a long way to creating an “intuitive” interface. However, it’s just the first of two steps in creating an “intuitive” interface. In addition to matching the user’s mental model, when the user sees the application they need to be able to recognize how to interact with the UI. That’s a topic I’ll start discussing in my next post.