Aesthetics, Visual Appeal, Usability and User Satisfaction:
What Do the User’s Eyes Tell the User’s Brain?
Gitte Lindgaard
Australian Journal of Emerging Technologies and Society
Vol. 5, No. 1, 2007, pp: 1-14
Summary: looks are more important than usability, but why?
Exploring the reasons why "people may be more satisfied with a beautiful product that performs suboptimally than with a more usable by less appealing product."
This paper really is almost a literature review unto itself. Mostly a grouping together of different studies into a cohesive narrative. No actual new research is discussed in this paper.
Compares seeing a website for the first time to meeting a person for the first time. Right from the start you have an instinctual like or dislike that has nothing to do with reason.
"Exposure effect" People prefer things that they've seen before, even if they don't recall seeing them - illustrated by Zajonc (1980). In web terms could mean people like things that they already know and understand, standards.
"Confirmation bias" Once a person has made up their mind, they tend to search for things that confirm that bias while rejecting things that disprove it. (Mynatt, Doherty, & Tweeney, 1977)
Lindgaard, 1999 illustrated the importance of color in determining "visual appeal, perceived usability, and user satisfaction in web sites. Color was cited as the main reason for disliking a web site and content was the reason stated for favoring a web site." White and blue were the most favored while yellow and black were the least. Pastels were also deemed favorable while most dark shadings were least.
Reading time: 25 minutes
------
I re-read this post on 6/8/2012 and the part about the most favored/least favored colors really caught me. Just this morning I had a choice of two gas stations. Whenever they have the same price on gas, I always favor one over the other and I was pondering why. At first I though "it looks friendlier" but that's very vague. Going further I thought about the colors and the one I favored was blue and white while the other, which I had deemed "ugly", was yellow and black. Just a surprise to see those exact colors listed in the exact favorable/unfavorable scenario in a totally different context.
Friday, January 21, 2011
Thursday, January 20, 2011
Paper: Attention Web Designers: You have 50 milliseconds to make a good first impression!
Attention Web Designers: You have 50 milliseconds to make a good first impression!
Behaviour & Information Technology, Vol. 25, No. 2, March-April 2006, 115 – 126
GITTE LINDGAARD, GARY FERNANDES, CATHY DUDEK and J. BROWN
Human-Oriented Technology Lab, Carleton University, Ottawa, Canada
3 studies to determine how fast people form an opinion about web page visual appeal and the reliability of those judgments.
Study 1: Participants rated the visual appeal of web pages presented in two phases for 500ms each. Purpose: "to determine the reliability of visual appeal ratings and select a subset of the pages to use in the second study."
Study 2: Same as first, but added a 3rd phase where participants viewed each page for as long as they liked while rating each web page on 7 visual design dimensions (bolded items had high correlation to visual appeal: simple-complex, interesting-boring, clear-confusing, well designed-poorly designed,good use of color-bad use of color, good layout-bad layout, imaginative-unimaginative). Purpose: To determine the reliability of visual appeal ratings of the subset of pages and to begin to explore visual characteristics that may be related to visual appeal."
Study 3: Same as first, but some saw the pages for only 50ms while other saw them for 500ms. Purpose: determine whether the first impression may be formed in an even shorter amount of time than 500ms.
Visual appeal ratings were highly correlated from on phase to the next as were the correlations between the 50ms and 500ms conditions and the 7 factor ratings.
"Halo Effect" or "Confirmation Bias": When users ignore evidence contradictory to their initial impression and pay attention only to evidence that confirms the impression.
Visual appeal factors may be detected first and these could influence how users judge subsequent experience and enjoyment of the site. (Jennings 2000, Tractinsky et al. 2000) (Lindgaard and Dudek 2002).
Even if a website is highly usable and useful and presented logically, if the first impression is not a good one, the user may not be willing to see the site positively. Therefor, it's crucial to make the first impression a good one regardless of usability or content.
TODO: Test eCAFE to see if increasing our "visual appeal" has an effect on our completion rates. Could try a different design for each campus and compare against historical numbers.
1/20/11 (12 pgs, 70m = 5.8 mpp) minutes per page
Behaviour & Information Technology, Vol. 25, No. 2, March-April 2006, 115 – 126
GITTE LINDGAARD, GARY FERNANDES, CATHY DUDEK and J. BROWN
Human-Oriented Technology Lab, Carleton University, Ottawa, Canada
3 studies to determine how fast people form an opinion about web page visual appeal and the reliability of those judgments.
Study 1: Participants rated the visual appeal of web pages presented in two phases for 500ms each. Purpose: "to determine the reliability of visual appeal ratings and select a subset of the pages to use in the second study."
Study 2: Same as first, but added a 3rd phase where participants viewed each page for as long as they liked while rating each web page on 7 visual design dimensions (bolded items had high correlation to visual appeal: simple-complex, interesting-boring, clear-confusing, well designed-poorly designed,good use of color-bad use of color, good layout-bad layout, imaginative-unimaginative). Purpose: To determine the reliability of visual appeal ratings of the subset of pages and to begin to explore visual characteristics that may be related to visual appeal."
Study 3: Same as first, but some saw the pages for only 50ms while other saw them for 500ms. Purpose: determine whether the first impression may be formed in an even shorter amount of time than 500ms.
Visual appeal ratings were highly correlated from on phase to the next as were the correlations between the 50ms and 500ms conditions and the 7 factor ratings.
"Halo Effect" or "Confirmation Bias": When users ignore evidence contradictory to their initial impression and pay attention only to evidence that confirms the impression.
Visual appeal factors may be detected first and these could influence how users judge subsequent experience and enjoyment of the site. (Jennings 2000, Tractinsky et al. 2000) (Lindgaard and Dudek 2002).
Even if a website is highly usable and useful and presented logically, if the first impression is not a good one, the user may not be willing to see the site positively. Therefor, it's crucial to make the first impression a good one regardless of usability or content.
TODO: Test eCAFE to see if increasing our "visual appeal" has an effect on our completion rates. Could try a different design for each campus and compare against historical numbers.
1/20/11 (12 pgs, 70m = 5.8 mpp) minutes per page
Monday, January 10, 2011
Book: Rocket Surgery Made Easy, by Steve Krug
Krug, Steve. Rocket Surgery Made Easy. Berkeley, CA: New Riders Publishing, 2010. Print.
"Usability Testing:" Watching people try to use what you're creating/designing/building (or something you've already created/designed/built), with the intention of (a) making it easier for people to use or (b) proving that it is easy to use.
Quantitative test: Attempting to prove something through measurement.
Qualitative test: Attempting to gain insights to improve something.
These tests are of the qualitative kind.
I watched the demo he mentions in chapter 2: http://www.sensible.com/rocketsurgery/index.html
- Most tests last about an hour
- Have a simple site up like Google, something that won't distract the user while he introduces himself and explains the process.
- Use his script for the introduction.
- Bring up the site you want to test.
- Ask user to say what they're initial thoughts are, what the site is for, what it does, who it's for, what they would likely learn from the site. Don't click on anything.
- Ask user to do specific tasks. Read it aloud and give them a printed copy. Give them a scenario so they know "who they are supposed to be." Let them go through the process, clicking and all. Remind them to verbalize if needed.
- If they suggest a new feature, ask them how they would visual it working.
- Ask them to look around to see if there's anything else that might be relevant (if there is, and they missed it).
I noticed that while I watched the demo, and the woman was clearly going down the wrong path, I kept trying to tell her what to do in my head, even though I had nothing at stake. This could mean bad things for when I do a test for my own system. I'll have to watch that my frustration doesn't get displayed. It turned out her straying was useful in finding other issues. You have to let them reach their own conclusion, but if they get off topic, you can prompt them to revisit the issue once they reach the end of the thought process they were following.
Testing an existing site:
- Useful because you'll learn what you are currently doing wrong so you don't make the same mistakes as you redesign.
Testing other peoples sites (like other instructor evaluation sites):
- It's a free learning resource to see what works and what doesn't in the same genre.
Testing the sketch on a napkin:
- Hand someone, anyone the sketch and say "Can you tell me what to make of this? What do you think this is supposed to be?" Don't ask "Do you like this?" or "What do you think of this?" Ask them what they think it IS. Listen to what they say, and you can ask a few probing questions like "What do you think term 'x' means?"
- Lets you know if people "get it."
Testing wireframes:
- Wireframes are schematic diagrams of a page. Shows where different kinds of content will go, the relative prominence of things like headings, and the navigation devices like menus and search.
- Wireframes tests focus on interaction.
- Make up tasks, usually all related to navigation.
- Ask "How would you find..." or "What would you expect to see when you click on this link?"
- Tells if things are where people expect to find them, if the category names make sense, if the navigation is clear, etc.
Testing page design:
- Checks to see if the visual design has introduced any usability issues after we know the navigation, etc works via the wireframe tests.
- Start with home page, lead user through visual treatments of the pages and ask them to do a narrative of each one.
Testing working prototypes and beyond:
The People:
- It generally isn't important to test with people who are representative of your target audience. It's nice, but valuable data can be had from anyone.
- Three people per round is enough.
- He has a discussion on how to recruit users, screen them, & follow up.
- Tell users ahead of time what to expect, and schedule the time place. Send an email confirming the session along with reiterating the details and providing the non-disclosure agreement.
- After the meeting, send a thank you note.
- Have a backup "emergency" user in case one doesn't show.
- You cannot reuse the same people. One test per person unless it's a different application or site.
The Tasks:
- First, choose the tasks.
- The trick is making sure your list of important tasks are the things your users really want to do.
- Decide which ones to test in this month's round of testing.
- Typically a session lasts 50 minutes with 35 minutes of the participant actually doing tasks.
- There may be just one long task or as many as 10 small ones.
- If a given user is particularly fast, have "filler" tasks, like doing something on a competitor's site.
- To decide which tasks to try, ask yourself: What are your most critical tasks? What keeps you awake at night? What does you other user research suggest may not be easy to use?
- Second, expand the tasks into scenarios. Little stories that add context. It gives your user character, motivation, what they need to do, and a few details. "You are..." and "You need to..." and provides information they need to complete the task (like the username and password to the test account).
- Don't give any clues in the scenario. Avoid terms they will encounter on the site.
- You may want to place two restrictions: "Don't use search" and "Stay on this site"
- Pilot test the scenario to make sure they are clear, complete, and unambiguous. Use a co-worker, family, or friends. Anyone will do.
- Print out the scenarios in two formats: All on one page for yourself, and one per sheet for participants. Don't number the tasks.
Action:
- Use the checklists he provides so details don't get missed
- Facilitator: The person in the room with the participant. Part Tour Guide, part Therapist.
- Observer: Watch, learn, take notes. Write down the 3 most important usability problems they saw in that session. Suggest questions for the facilitator to ask the participant. Come to the debriefing session.
- The computer and screen recording software.
- A standard computer mouse, people shouldn't have to figure out how to move the pointer.
- Will likely need a microphone as the participant won't always face the computer.
- Follow his pre-test prep checklist (pg 68)
- Be aware of your biases and don't let them influence the participant in either direction.
- Participants should leave the room in no worse shape than when they entered.
- We may need to get permission from our Institutional Review Board to ensure we're meeting ethical standards.
- Make it a spectator sport. Seeing is believing. Watching as a group generate more ideas and discussion.
- Could use "Go To Meeting" for screensharing with observers.
The Debriefing:
- Prioritize the most important issues that can be fixed in the next month.
- Summarize the tests, issues, and decisions in a follow-up email.
Recommendations:
- KEEP IT SIMPLE!
- Do a round of testing one morning a month with three users. Debrief over lunch, spend the month fixing the issues, repeat next month.
- It needs to be a regularly scheduled thing or it won't happen.
- Tweak, don't redesign. Then verify.
- First impulse is to add something, consider taking something away.
Most common problems:
- Starting off on the wrong foot. The home page does a bad job of orienting the user.
- Failure to shout. People are moving too fast to notice subtle visual cues.
Summary:
- Keep it simple, this is quick and easy testing.
Remote Testing:
- Use screen sharing software and speakerphone for the participant (or VOIP)
- GoToMeeting is a good option for screen sharing.
- Could use "UserTesting.com" to test with just a user or two. Send them a task.
Maxims:
- A morning a month.
- Start earlier than you think makes sense.
- Recruit loosely and grade on a curve.
- Make it a spectator sport.
- Focus ruthlessly on a small number of the most important problems.
- When fixing problems, always do the least you can do.
TODO:
- Look into software that will record everything the user does on the site, like where they move their mouse and what they clicked on, etc. If it can record sound too, that'd be perfect. Don't need to record the actual user, so they don't need to worry about being identifiable.
- Set up a regularly scheduled test day once a month. Use co-workers, student help, and instructors, staff, or advisory board members who have volunteered. Take my laptop over to them with the test site up and recording software and just do the test. Do it on paper if needed and record with my iPhone.
- Look at and test other related sites that evaluation University instructors. Like RateMyProfessor. We can see what works and what doesn't. (follow process from chapters 5-9). Have each user do the same task on 2 to 3 different sites.
- Look into "remote testing" (chapter 14)
1/09/11 pg 1 - 13 didn't record time.
1/10/11 (10pgs, 13m = 1.3mpp) minutes per page
1/10/11 (11pgs, 15m = 1.4mpp)
1/11/11 (13pgs, 40m = 3.1mpp)
1/12/11 (26pgs, 16m = .6mpp)
1/13/11 (17pgs, 17m = 1mpp)
1/18/11 (45pgs, 36m = .8mpp)
Total: ~150m = 2h 30m
"Usability Testing:" Watching people try to use what you're creating/designing/building (or something you've already created/designed/built), with the intention of (a) making it easier for people to use or (b) proving that it is easy to use.
Quantitative test: Attempting to prove something through measurement.
Qualitative test: Attempting to gain insights to improve something.
These tests are of the qualitative kind.
I watched the demo he mentions in chapter 2: http://www.sensible.com/rocketsurgery/index.html
- Most tests last about an hour
- Have a simple site up like Google, something that won't distract the user while he introduces himself and explains the process.
- Use his script for the introduction.
- Bring up the site you want to test.
- Ask user to say what they're initial thoughts are, what the site is for, what it does, who it's for, what they would likely learn from the site. Don't click on anything.
- Ask user to do specific tasks. Read it aloud and give them a printed copy. Give them a scenario so they know "who they are supposed to be." Let them go through the process, clicking and all. Remind them to verbalize if needed.
- If they suggest a new feature, ask them how they would visual it working.
- Ask them to look around to see if there's anything else that might be relevant (if there is, and they missed it).
I noticed that while I watched the demo, and the woman was clearly going down the wrong path, I kept trying to tell her what to do in my head, even though I had nothing at stake. This could mean bad things for when I do a test for my own system. I'll have to watch that my frustration doesn't get displayed. It turned out her straying was useful in finding other issues. You have to let them reach their own conclusion, but if they get off topic, you can prompt them to revisit the issue once they reach the end of the thought process they were following.
Testing an existing site:
- Useful because you'll learn what you are currently doing wrong so you don't make the same mistakes as you redesign.
Testing other peoples sites (like other instructor evaluation sites):
- It's a free learning resource to see what works and what doesn't in the same genre.
Testing the sketch on a napkin:
- Hand someone, anyone the sketch and say "Can you tell me what to make of this? What do you think this is supposed to be?" Don't ask "Do you like this?" or "What do you think of this?" Ask them what they think it IS. Listen to what they say, and you can ask a few probing questions like "What do you think term 'x' means?"
- Lets you know if people "get it."
Testing wireframes:
- Wireframes are schematic diagrams of a page. Shows where different kinds of content will go, the relative prominence of things like headings, and the navigation devices like menus and search.
- Wireframes tests focus on interaction.
- Make up tasks, usually all related to navigation.
- Ask "How would you find..." or "What would you expect to see when you click on this link?"
- Tells if things are where people expect to find them, if the category names make sense, if the navigation is clear, etc.
Testing page design:
- Checks to see if the visual design has introduced any usability issues after we know the navigation, etc works via the wireframe tests.
- Start with home page, lead user through visual treatments of the pages and ask them to do a narrative of each one.
Testing working prototypes and beyond:
The People:
- It generally isn't important to test with people who are representative of your target audience. It's nice, but valuable data can be had from anyone.
- Three people per round is enough.
- He has a discussion on how to recruit users, screen them, & follow up.
- Tell users ahead of time what to expect, and schedule the time place. Send an email confirming the session along with reiterating the details and providing the non-disclosure agreement.
- After the meeting, send a thank you note.
- Have a backup "emergency" user in case one doesn't show.
- You cannot reuse the same people. One test per person unless it's a different application or site.
The Tasks:
- First, choose the tasks.
- The trick is making sure your list of important tasks are the things your users really want to do.
- Decide which ones to test in this month's round of testing.
- Typically a session lasts 50 minutes with 35 minutes of the participant actually doing tasks.
- There may be just one long task or as many as 10 small ones.
- If a given user is particularly fast, have "filler" tasks, like doing something on a competitor's site.
- To decide which tasks to try, ask yourself: What are your most critical tasks? What keeps you awake at night? What does you other user research suggest may not be easy to use?
- Second, expand the tasks into scenarios. Little stories that add context. It gives your user character, motivation, what they need to do, and a few details. "You are..." and "You need to..." and provides information they need to complete the task (like the username and password to the test account).
- Don't give any clues in the scenario. Avoid terms they will encounter on the site.
- You may want to place two restrictions: "Don't use search" and "Stay on this site"
- Pilot test the scenario to make sure they are clear, complete, and unambiguous. Use a co-worker, family, or friends. Anyone will do.
- Print out the scenarios in two formats: All on one page for yourself, and one per sheet for participants. Don't number the tasks.
Action:
- Use the checklists he provides so details don't get missed
- Facilitator: The person in the room with the participant. Part Tour Guide, part Therapist.
- Observer: Watch, learn, take notes. Write down the 3 most important usability problems they saw in that session. Suggest questions for the facilitator to ask the participant. Come to the debriefing session.
- The computer and screen recording software.
- A standard computer mouse, people shouldn't have to figure out how to move the pointer.
- Will likely need a microphone as the participant won't always face the computer.
- Follow his pre-test prep checklist (pg 68)
- Be aware of your biases and don't let them influence the participant in either direction.
- Participants should leave the room in no worse shape than when they entered.
- We may need to get permission from our Institutional Review Board to ensure we're meeting ethical standards.
- Make it a spectator sport. Seeing is believing. Watching as a group generate more ideas and discussion.
- Could use "Go To Meeting" for screensharing with observers.
The Debriefing:
- Prioritize the most important issues that can be fixed in the next month.
- Summarize the tests, issues, and decisions in a follow-up email.
Recommendations:
- KEEP IT SIMPLE!
- Do a round of testing one morning a month with three users. Debrief over lunch, spend the month fixing the issues, repeat next month.
- It needs to be a regularly scheduled thing or it won't happen.
- Tweak, don't redesign. Then verify.
- First impulse is to add something, consider taking something away.
Most common problems:
- Starting off on the wrong foot. The home page does a bad job of orienting the user.
- Failure to shout. People are moving too fast to notice subtle visual cues.
Summary:
- Keep it simple, this is quick and easy testing.
Remote Testing:
- Use screen sharing software and speakerphone for the participant (or VOIP)
- GoToMeeting is a good option for screen sharing.
- Could use "UserTesting.com" to test with just a user or two. Send them a task.
Maxims:
- A morning a month.
- Start earlier than you think makes sense.
- Recruit loosely and grade on a curve.
- Make it a spectator sport.
- Focus ruthlessly on a small number of the most important problems.
- When fixing problems, always do the least you can do.
TODO:
- Look into software that will record everything the user does on the site, like where they move their mouse and what they clicked on, etc. If it can record sound too, that'd be perfect. Don't need to record the actual user, so they don't need to worry about being identifiable.
- Set up a regularly scheduled test day once a month. Use co-workers, student help, and instructors, staff, or advisory board members who have volunteered. Take my laptop over to them with the test site up and recording software and just do the test. Do it on paper if needed and record with my iPhone.
- Look at and test other related sites that evaluation University instructors. Like RateMyProfessor. We can see what works and what doesn't. (follow process from chapters 5-9). Have each user do the same task on 2 to 3 different sites.
- Look into "remote testing" (chapter 14)
1/09/11 pg 1 - 13 didn't record time.
1/10/11 (10pgs, 13m = 1.3mpp) minutes per page
1/10/11 (11pgs, 15m = 1.4mpp)
1/11/11 (13pgs, 40m = 3.1mpp)
1/12/11 (26pgs, 16m = .6mpp)
1/13/11 (17pgs, 17m = 1mpp)
1/18/11 (45pgs, 36m = .8mpp)
Total: ~150m = 2h 30m
Book: Don't Make Me Think, by Steve Krug
Average reading speed: 1.2 ppm
Krug, Steve. Don't Make Me Think: A Common Sense Approach to Web Usability. Berkeley, CA: New Riders Publishing, 2000. Print.
The number one point is "Don't make me think!" A site should just be self-evident, a user shouldn't have to "learn" how the site works, they should be able to just scan the site and know how to accomplish their goal. They shouldn't be left to wonder "Is that a button?" or "What does that do?"
Use the most common term. Don't write "Quick Search" when the user is likely scanning for "Search."
Whatever is clickable should look clickable. Don't use links or images where a button is needed. A user shouldn't have to waste a single moment on whether or not something is clickable.
Users don't read, they scan with something in mind that they are looking for. They may be thinking "How do I start?", "What is this site for?", or "Where is 'x'?" Your job is to anticipate what they want and present it in an way that's immediately obvious when their eye scans over it and that they can tell is clickable.
Make the important things stand out. Make things into a hierarchy via standards, font size, defined areas, color, and nesting. Group things together logically and use the elements listed to indicate what the important item is that they're likely scanning for. Organize and prioritize the elements on the page.
"Conventions are your friends." Use standards that people are used to. Don't re-invent the wheel unless the new way is self-explanatory or truly worth the pain of thinking.
Keep it quiet. Don't make the site so busy it's overwhelming. Any elements that can be toned down should be so the important stuff stands out. Less is more. Unless you need it, don't include it.
Define your terms. You can't assume the user knows the subject matter and knows what the terms mean. Make it clear what will happen if they click on a button or link.
"Omit needless words." They aren't going to read it anyway, so get rid of it. Anywhere that text is needed, it needs to be parsed for any extraneous words and reduced to its bare essence. If you need to provide instructions, you've failed as designer, the site should be intuitive.
Labels, breadcrumbs, and navigation. The user should be able to scan for the words they want and find it. As they drill down into your site, there must be a means for them to see where they are, how they got there, and how to get back. Consistent navigation and visual cues are key. It's important to work out the entire top-to-bottom navigation from the beginning. Every page should have a search box and a name in a consistent and prominent location with the name matching the text of what the user clicked to get there.
Breadcrumbs help users back up a level or go back to the home page, but they need to in conjunction with a navigation scheme. They work best when they: are placed at the top of the page above all content, use tiny font, separate items with a greater-than sign, are labeled "You are here", and have the last item boldfaced.
Color Coding is good, but don't rely on it. 1 in 12 men are color blind in some way. Use contrast more than color.
Tabs: Work well, make sense to even inexperienced users. Make sure there's a tab selected when the user first enters the site and that the selected tab has a strong contrast to the others.
A user when dumped randomly on some page on your site should be able to answer the following questions easily: "What site is this? What page am I on? What are the major sections of this site? What are my options at this level? Where am I in the scheme of things? How can I search?"
Always avoid stacking underlined text links on top of each other as they're very hard to read. Left or right alignment is better than centered items in creating a hierarchy.
Home Page Design: Tells where you are, what the site is for, what you can do (navigation takes care of this), has a search mechanism, gives the user a reason to stick around, some timely content, sign-in/registration, shortcuts as applicable, has a clear starting point. It needs to answer these questions: What is this? What can I do here? What do they have here? Why should I be here? How do I start?
Pulldowns and rollover popups both have same drawbacks: you have to click on them to find if it's what you want, you can't scan, they show and hide too easily with minor mouse movement.
Home page sins:
- A Banner Ad. Pushes down the branding, negative 1st impression, slows down the page load.
- Promoting everything. Overwhelming. Clutter hides what's really important.
- Too many cross-promotions. Don't address user needs, so they leave. Nascar effect.
- Greedy for data. User has to trust you before they cough up data. Don't require registration without letting them see the goods or ask for an email address before there's a compelling reason for user to provide it.
There is no Average User. Instead of asking "Do most people like pulldown menus", ask "Does this pulldown, with these items and this wording in this context on this page create a good experience for most people who are likely to use this site?" The only way to answer that is by testing.
Usability testing: one user at a time is shown something and asked to either figure out what it is or try to use it to do a typical task.
Testing:
- Testing one user is 100% better than testing none.
- Testing one user early in the project is better than testing 50 near the end.
- The importance of recruiting representative users is overrated. It really doesn't matter who you test (there are some exceptions to this, eCAFE's situation is one of them).
- The point is not to prove or disprove something, it's to inform your judgment.
- Testing is an iterative process.
- Nothing beats a live audience reaction.
You only need to test 5 users, they'll uncover 85 percent of the site's usability problems and any more result in seriously diminishing returns. Test 3 users, fix the issues, test 2 more, fix the issues.
Do "Get it" tests, Key task tests, Cubicle tests on your friends, co-workers, neighbors, passerbys, anyone.
Summary:
- Don't make me think.
- Use obvious/common terms.
- Whatever is clickable should be obviously clickable.
- Users don't read, they scan. Make it scannable.
- Make the important things stand out.
- "Conventions are your friends."
- Don't overwhelm the user.
- Define your terms.
- "Omit needless words."
- Labels, breadcrumbs, and navigation.
- There is no Average User.
- There is no substitute for testing.
Krug, Steve. Don't Make Me Think: A Common Sense Approach to Web Usability. Berkeley, CA: New Riders Publishing, 2000. Print.
The number one point is "Don't make me think!" A site should just be self-evident, a user shouldn't have to "learn" how the site works, they should be able to just scan the site and know how to accomplish their goal. They shouldn't be left to wonder "Is that a button?" or "What does that do?"
Use the most common term. Don't write "Quick Search" when the user is likely scanning for "Search."
Whatever is clickable should look clickable. Don't use links or images where a button is needed. A user shouldn't have to waste a single moment on whether or not something is clickable.
Users don't read, they scan with something in mind that they are looking for. They may be thinking "How do I start?", "What is this site for?", or "Where is 'x'?" Your job is to anticipate what they want and present it in an way that's immediately obvious when their eye scans over it and that they can tell is clickable.
Make the important things stand out. Make things into a hierarchy via standards, font size, defined areas, color, and nesting. Group things together logically and use the elements listed to indicate what the important item is that they're likely scanning for. Organize and prioritize the elements on the page.
"Conventions are your friends." Use standards that people are used to. Don't re-invent the wheel unless the new way is self-explanatory or truly worth the pain of thinking.
Keep it quiet. Don't make the site so busy it's overwhelming. Any elements that can be toned down should be so the important stuff stands out. Less is more. Unless you need it, don't include it.
Define your terms. You can't assume the user knows the subject matter and knows what the terms mean. Make it clear what will happen if they click on a button or link.
"Omit needless words." They aren't going to read it anyway, so get rid of it. Anywhere that text is needed, it needs to be parsed for any extraneous words and reduced to its bare essence. If you need to provide instructions, you've failed as designer, the site should be intuitive.
Labels, breadcrumbs, and navigation. The user should be able to scan for the words they want and find it. As they drill down into your site, there must be a means for them to see where they are, how they got there, and how to get back. Consistent navigation and visual cues are key. It's important to work out the entire top-to-bottom navigation from the beginning. Every page should have a search box and a name in a consistent and prominent location with the name matching the text of what the user clicked to get there.
Breadcrumbs help users back up a level or go back to the home page, but they need to in conjunction with a navigation scheme. They work best when they: are placed at the top of the page above all content, use tiny font, separate items with a greater-than sign, are labeled "You are here", and have the last item boldfaced.
Color Coding is good, but don't rely on it. 1 in 12 men are color blind in some way. Use contrast more than color.
Tabs: Work well, make sense to even inexperienced users. Make sure there's a tab selected when the user first enters the site and that the selected tab has a strong contrast to the others.
A user when dumped randomly on some page on your site should be able to answer the following questions easily: "What site is this? What page am I on? What are the major sections of this site? What are my options at this level? Where am I in the scheme of things? How can I search?"
Always avoid stacking underlined text links on top of each other as they're very hard to read. Left or right alignment is better than centered items in creating a hierarchy.
Home Page Design: Tells where you are, what the site is for, what you can do (navigation takes care of this), has a search mechanism, gives the user a reason to stick around, some timely content, sign-in/registration, shortcuts as applicable, has a clear starting point. It needs to answer these questions: What is this? What can I do here? What do they have here? Why should I be here? How do I start?
Pulldowns and rollover popups both have same drawbacks: you have to click on them to find if it's what you want, you can't scan, they show and hide too easily with minor mouse movement.
Home page sins:
- A Banner Ad. Pushes down the branding, negative 1st impression, slows down the page load.
- Promoting everything. Overwhelming. Clutter hides what's really important.
- Too many cross-promotions. Don't address user needs, so they leave. Nascar effect.
- Greedy for data. User has to trust you before they cough up data. Don't require registration without letting them see the goods or ask for an email address before there's a compelling reason for user to provide it.
There is no Average User. Instead of asking "Do most people like pulldown menus", ask "Does this pulldown, with these items and this wording in this context on this page create a good experience for most people who are likely to use this site?" The only way to answer that is by testing.
Usability testing: one user at a time is shown something and asked to either figure out what it is or try to use it to do a typical task.
Testing:
- Testing one user is 100% better than testing none.
- Testing one user early in the project is better than testing 50 near the end.
- The importance of recruiting representative users is overrated. It really doesn't matter who you test (there are some exceptions to this, eCAFE's situation is one of them).
- The point is not to prove or disprove something, it's to inform your judgment.
- Testing is an iterative process.
- Nothing beats a live audience reaction.
You only need to test 5 users, they'll uncover 85 percent of the site's usability problems and any more result in seriously diminishing returns. Test 3 users, fix the issues, test 2 more, fix the issues.
Do "Get it" tests, Key task tests, Cubicle tests on your friends, co-workers, neighbors, passerbys, anyone.
Summary:
- Don't make me think.
- Use obvious/common terms.
- Whatever is clickable should be obviously clickable.
- Users don't read, they scan. Make it scannable.
- Make the important things stand out.
- "Conventions are your friends."
- Don't overwhelm the user.
- Define your terms.
- "Omit needless words."
- Labels, breadcrumbs, and navigation.
- There is no Average User.
- There is no substitute for testing.
Thursday, January 6, 2011
Qualifying Exam Study Guide
Exam Coverage in terms of the ACM (Undergraduate) Curriculum
DS: Discrete Structures
Book: Discrete Mathematics and Its Applications, 6th ed., K. H. Rosen - McGraw-Hill Science/Engineering/Math, Chapters 1-11
o DS1. Functions, relations, and sets
o DS2. Basic logic
o DS3. Proof techniques
o DS4. Basics of counting
o DS5. Graphs and trees
o DS6. Discrete probability
o DS7. Matrix algebra
PF: Programming Fundamentals:
Book: Introduction to Algorithms, T. Cormen, C. Leiserson, R. Rivbest, C. Stein - MIT Press, Chapters 1-4, 6-8, 10-13, 15-16, 22-26
o PF1. Fundamental programming constructs
o PF2. Algorithms and problem-solving
o PF3. Fundamental data structure
o PF4. Recursion
AL. Algorithms and Complexity
Book: Introduction to the Theory of Computation, M. Sipser - PWS Pub. Co, Chapters 0-5, 7, 10.6
o AL1. Basic algorithmic analysis
o AL2. Algorithmic strategies
o AL3. Fundamental computing algorithms
o AL5. Basic computability
o AL6. The complexity classes P and NP
o AL7. Automata theory
AR: Architecture and Organization
Book: Computer Architecture: A Quantitative Approach, 3rd ed., J. L. Hennessy and D. A. Patterson - Morgan Kaufmann, Chapters 1, 2, 3.1-4, 4.1-3, 5.1-9, 7.1-7, A.1-5
o AR1. Digital logic and digital systems
o AR2. Machine level representation of data
o AR3. Assembly level machine organization
o AR4. Memory system organization and architecture
OS: Operating Systems
Book: Operating System Concepts, 8th ed., A. Silberschatz, P. B. Galvin, G. Gagne - John Wiley & Sons, Inc., Chapters 1-10
o OS1. Overview of operating systems
o OS2. Operating system principles
o OS3. Concurrency
o OS4. Scheduling and dispatch
o OS5. Memory management
NC: Net-Centric Computing
Book: Computer Networks and Internets, 5th ed., D. Comer - Prentice Hall, Chapters 1-4, 13, 15, 16, 20-27, 30 OR
Book: Computer Networking: A Top-Down Approach, 5th ed., J. Kurose, K. Ross - Addison Wesley, Sections 1.1-6, 2.1-5, 3.1-5, 4.1-5, 5.1, 5.4-6, 6.2, 6.3, 8.2, and 8.3
o NC1. Introduction for net-centric computing
o NC2. Communication and networking
o NC3. Network security
o NC7. Compression and decompression
PL: Programming Languages
Book: Modern Programming Languages: A Practical Introduction, A. B. Webber - Franklin, Beedle & Associates, Chapters 1-19, 23,24
Book: Compilers: Principles, Techniques and Tools, A. V. Aho, R. Sethi, J. D. Ullman - Addison-Wesley, Chapters 1-5
o PL1. Overview of programming languages
o PL4. Declarations and types
o PL5. Abstraction mechanisms
o PL6. Object-oriented programming
o PL7. Functional programming
o PL8. Language translation systems
IM: Information Management
Book: Database Management Systems, 3rd ed., R. Ramakrishnan, J. Gehrke - McGraw Hill Higher Education, Chapters 1-5, 8, 16, 19
o IM1. Information models and systems
o IM2. Database systems
o IM3. Data modeling
o IM4. Relational databases
o IM5. Database query languages
o IM6. Relational database design
DS: Discrete Structures
Book: Discrete Mathematics and Its Applications, 6th ed., K. H. Rosen - McGraw-Hill Science/Engineering/Math, Chapters 1-11
o DS1. Functions, relations, and sets
o DS2. Basic logic
o DS3. Proof techniques
o DS4. Basics of counting
o DS5. Graphs and trees
o DS6. Discrete probability
o DS7. Matrix algebra
PF: Programming Fundamentals:
Book: Introduction to Algorithms, T. Cormen, C. Leiserson, R. Rivbest, C. Stein - MIT Press, Chapters 1-4, 6-8, 10-13, 15-16, 22-26
o PF1. Fundamental programming constructs
o PF2. Algorithms and problem-solving
o PF3. Fundamental data structure
o PF4. Recursion
AL. Algorithms and Complexity
Book: Introduction to the Theory of Computation, M. Sipser - PWS Pub. Co, Chapters 0-5, 7, 10.6
o AL1. Basic algorithmic analysis
o AL2. Algorithmic strategies
o AL3. Fundamental computing algorithms
o AL5. Basic computability
o AL6. The complexity classes P and NP
o AL7. Automata theory
AR: Architecture and Organization
Book: Computer Architecture: A Quantitative Approach, 3rd ed., J. L. Hennessy and D. A. Patterson - Morgan Kaufmann, Chapters 1, 2, 3.1-4, 4.1-3, 5.1-9, 7.1-7, A.1-5
o AR1. Digital logic and digital systems
o AR2. Machine level representation of data
o AR3. Assembly level machine organization
o AR4. Memory system organization and architecture
OS: Operating Systems
Book: Operating System Concepts, 8th ed., A. Silberschatz, P. B. Galvin, G. Gagne - John Wiley & Sons, Inc., Chapters 1-10
o OS1. Overview of operating systems
o OS2. Operating system principles
o OS3. Concurrency
o OS4. Scheduling and dispatch
o OS5. Memory management
NC: Net-Centric Computing
Book: Computer Networks and Internets, 5th ed., D. Comer - Prentice Hall, Chapters 1-4, 13, 15, 16, 20-27, 30 OR
Book: Computer Networking: A Top-Down Approach, 5th ed., J. Kurose, K. Ross - Addison Wesley, Sections 1.1-6, 2.1-5, 3.1-5, 4.1-5, 5.1, 5.4-6, 6.2, 6.3, 8.2, and 8.3
o NC1. Introduction for net-centric computing
o NC2. Communication and networking
o NC3. Network security
o NC7. Compression and decompression
PL: Programming Languages
Book: Modern Programming Languages: A Practical Introduction, A. B. Webber - Franklin, Beedle & Associates, Chapters 1-19, 23,24
Book: Compilers: Principles, Techniques and Tools, A. V. Aho, R. Sethi, J. D. Ullman - Addison-Wesley, Chapters 1-5
o PL1. Overview of programming languages
o PL4. Declarations and types
o PL5. Abstraction mechanisms
o PL6. Object-oriented programming
o PL7. Functional programming
o PL8. Language translation systems
IM: Information Management
Book: Database Management Systems, 3rd ed., R. Ramakrishnan, J. Gehrke - McGraw Hill Higher Education, Chapters 1-5, 8, 16, 19
o IM1. Information models and systems
o IM2. Database systems
o IM3. Data modeling
o IM4. Relational databases
o IM5. Database query languages
o IM6. Relational database design
Subscribe to:
Posts (Atom)