Intuitive to who?
April 15, 2008 8:46 PM Subscribe
Are there resources available that provide information about the intuitiveness of various user interface elements to various demographics?
I am interested in real statistics similar to the fake statistics below. I am especially interested in whether certain elements are more or less intuitive to people from different countries or cultures. Are there good books or websites available on this topic?
Fake statistics:
In a survey of 150 Americans between the ages of 35 and 55 who use computers at least once a day:
21 percent were not able to correctly use multiselect boxes to select more than one item.
52 percent found it more intuitive to select an option using radio buttons than a dropdown list.
37 percent expected to be able to use the tab key to move between fields. 23 percent expected to be able to use the enter key.
I am interested in real statistics similar to the fake statistics below. I am especially interested in whether certain elements are more or less intuitive to people from different countries or cultures. Are there good books or websites available on this topic?
Fake statistics:
In a survey of 150 Americans between the ages of 35 and 55 who use computers at least once a day:
21 percent were not able to correctly use multiselect boxes to select more than one item.
52 percent found it more intuitive to select an option using radio buttons than a dropdown list.
37 percent expected to be able to use the tab key to move between fields. 23 percent expected to be able to use the enter key.
Jakob Nielsen has several reports, mostly on web usability.
posted by djb at 9:06 PM on April 15, 2008
posted by djb at 9:06 PM on April 15, 2008
Quick answer: No.
I am a usability professional and have a deep interest for interaction design. I am not your usability professional.
The assumption within your question that makes it nearly impossible to answer is that no UI element is ever used in isolation from a task. Intents change and are shaped by culture, the information available to a person, how a user relates to his physical space, and the artifacts used to help with the task (among many other factors).
So, it is impossible to know which UI elements are "intuitive" in a general sense without knowing more about the overall task. In essence, if you really want to measure usability stats on an element to element basis, you would need a control for all of the info stated above, which is impossible, since much of it is not directly measurable (only viewable by observation).
Usability can be quantitative. It is good at catching issues that users may have and can uncover the relative severity of those issues. It is very good at measuring change in usability over the iterations within a product's life cycle. It is great for idiot proofing designs that some architect thinks may work for a user.
Usability can not predict how an application will perform, or how intuitive it will be based only on which UI elements it contains, because usability is greater than the sum of its parts--those elements are not what make the product usable. They are only a small, small part of a much larger picture that begins with intent and is highly specific to each task.
posted by |n$eCur3 at 11:50 PM on April 15, 2008
I am a usability professional and have a deep interest for interaction design. I am not your usability professional.
The assumption within your question that makes it nearly impossible to answer is that no UI element is ever used in isolation from a task. Intents change and are shaped by culture, the information available to a person, how a user relates to his physical space, and the artifacts used to help with the task (among many other factors).
So, it is impossible to know which UI elements are "intuitive" in a general sense without knowing more about the overall task. In essence, if you really want to measure usability stats on an element to element basis, you would need a control for all of the info stated above, which is impossible, since much of it is not directly measurable (only viewable by observation).
Usability can be quantitative. It is good at catching issues that users may have and can uncover the relative severity of those issues. It is very good at measuring change in usability over the iterations within a product's life cycle. It is great for idiot proofing designs that some architect thinks may work for a user.
Usability can not predict how an application will perform, or how intuitive it will be based only on which UI elements it contains, because usability is greater than the sum of its parts--those elements are not what make the product usable. They are only a small, small part of a much larger picture that begins with intent and is highly specific to each task.
posted by |n$eCur3 at 11:50 PM on April 15, 2008
Response by poster: Hmmm. Maybe I should revise my question a bit. I do understand that the design needs to be task based. But when I'm designing a process to handle a task, all along the way I'm making little choices about how to lead the user through to the next step. And often these choices are based on things that "everybody knows". For instance, "everybody knows" that a link in the form of an email address will most likely open up an email window to the recipient when clicked on. But who exactly does "everybody" include? It seems to me that my thinking on this is very sloppy.
Usually what I wind up doing is watching a few people work through the task outside of the system, then trying to capture the steps that they follow using design elements from programs that I can be reasonably sure most of the users are proficient in. Because I'm designing something to be used in-office, I can assume Microsoft Office proficiency because this is a job requirement, although this varies by program. For instance, borrowing something from Word or Outlook is generally safe, but borrowing something from Excel might not be. But there has to be a better way than this, right?
Examples: I might borrow a button with a bold "B" on it for bold from Word, or sortable columns from Outlook. I wouldn't borrow the button with the sum sign on it from Excel, because that would not be intuitive to most of my users.
posted by OrlandoFurioso at 5:35 AM on April 16, 2008
Usually what I wind up doing is watching a few people work through the task outside of the system, then trying to capture the steps that they follow using design elements from programs that I can be reasonably sure most of the users are proficient in. Because I'm designing something to be used in-office, I can assume Microsoft Office proficiency because this is a job requirement, although this varies by program. For instance, borrowing something from Word or Outlook is generally safe, but borrowing something from Excel might not be. But there has to be a better way than this, right?
Examples: I might borrow a button with a bold "B" on it for bold from Word, or sortable columns from Outlook. I wouldn't borrow the button with the sum sign on it from Excel, because that would not be intuitive to most of my users.
posted by OrlandoFurioso at 5:35 AM on April 16, 2008
And the intuitiveness depends on the experience of the users/demographic.
TO make something idiot proof, you need to include instructions for every step, as well as making the steps consistent with the expectations of the experienced user. Like appropriately using operating system conventions and tab stop order.
Even silly things like lines and boxes separating each discrete step and verbose prompts and making the new application imitate the paper form it replaces. And, if you're really good, step by step error checking.
This question brings to mind electronic voting machines. There is a lot of feedback and (when done right) ZERO ambiguity. The top of the screen says "using your finger, tap the name of the candidate of your choice. If you want to change your mind, tap another candidate. When you are done, tap the red 'next' button at the bottom of the screen." When you select a candidate, their option turns green. When you tap next, it double confirms. "You chose Milton Bradley. Tap 'record my vote' to vote for this person and continue, or tap 'go back' to change your choice.
posted by gjc at 8:21 AM on April 16, 2008
TO make something idiot proof, you need to include instructions for every step, as well as making the steps consistent with the expectations of the experienced user. Like appropriately using operating system conventions and tab stop order.
Even silly things like lines and boxes separating each discrete step and verbose prompts and making the new application imitate the paper form it replaces. And, if you're really good, step by step error checking.
This question brings to mind electronic voting machines. There is a lot of feedback and (when done right) ZERO ambiguity. The top of the screen says "using your finger, tap the name of the candidate of your choice. If you want to change your mind, tap another candidate. When you are done, tap the red 'next' button at the bottom of the screen." When you select a candidate, their option turns green. When you tap next, it double confirms. "You chose Milton Bradley. Tap 'record my vote' to vote for this person and continue, or tap 'go back' to change your choice.
posted by gjc at 8:21 AM on April 16, 2008
Response by poster: Maybe this will help clarify what I'm looking for. I recently worked with a global phone conferencing system that gave users the following prompt by voice:
Using the keypad of your phone, type in the conference number followed by the pound key.
A person attempting to attend the conference from Ireland was unable to attend because he couldn't find the (British currency) pound sign... he didn't realize that in US phone systems, "pound" is used to mean "#".
No matter how much verbosity and feedback and redundancy you supply, there are always going to be choices that are more intuitive to various demographics. "The pound key" is more intuitive to Americans than it is to non-Americans. Icons that are double-clicked to open are more intuitive to Windows users than to those who have never used Windows. The word "post" is more likely to bring up connotations of "post to a message group" for internet-savvy users, and more likely to bring up connotations of "send by the postal system" for non-internet-savvy users (especially those from the UK).
The app I am working on does not actually need to be idiot-proof -- extensive training is part of the plan, and ensuring that competent users can move through quickly is given higher priority than providing first-day-level instructions at every step. But I want to avoid innocent-seeming choices like "the pound key" that can stop certain demographics in their tracks.
posted by OrlandoFurioso at 10:09 AM on April 16, 2008
Using the keypad of your phone, type in the conference number followed by the pound key.
A person attempting to attend the conference from Ireland was unable to attend because he couldn't find the (British currency) pound sign... he didn't realize that in US phone systems, "pound" is used to mean "#".
No matter how much verbosity and feedback and redundancy you supply, there are always going to be choices that are more intuitive to various demographics. "The pound key" is more intuitive to Americans than it is to non-Americans. Icons that are double-clicked to open are more intuitive to Windows users than to those who have never used Windows. The word "post" is more likely to bring up connotations of "post to a message group" for internet-savvy users, and more likely to bring up connotations of "send by the postal system" for non-internet-savvy users (especially those from the UK).
The app I am working on does not actually need to be idiot-proof -- extensive training is part of the plan, and ensuring that competent users can move through quickly is given higher priority than providing first-day-level instructions at every step. But I want to avoid innocent-seeming choices like "the pound key" that can stop certain demographics in their tracks.
posted by OrlandoFurioso at 10:09 AM on April 16, 2008
This thread is closed to new comments.
posted by deCadmus at 9:03 PM on April 15, 2008