6

I have been support a web app that is used by a user base who's age range if from 40-65. The app is very good and has the latest ajaxy stuff etc. What we would now call very user friendly and responsive. I am amazed as to how this app is not so userfriendly for that user base. I was told that some autocomplete features make them disoriented!! Also, a lot of accidental clicks happen, they sometimes say "its not going thru!" then I realize that one of required check boxes were not clicked. I hope I made the scenario clear.

Could someone provice me resources/tips for this? Is not so much as an accessibility issue.

Argalatyr
  • 4,629
  • 3
  • 34
  • 60
Perpetualcoder
  • 13,105
  • 8
  • 58
  • 98
  • If your users don't think it's friendly then it's not user friendly. Sounds like you need to spend some time watching them use your interface and find out what needs to change. – Simurr Jan 20 '09 at 17:30
  • good idea!! But unfortunately I can not make this decision. – Perpetualcoder Jan 20 '09 at 17:34
  • I agree with YUUTA. Sounds like the perfect opportunity to propose some usability tests. What better way to solve for your user base than observing them interacting with the application and make changes based on that information? I also second the reference to "Don't Make Me Think" below. – Colin Brock Jan 20 '09 at 19:03

12 Answers12

9

Don't make me think

is like a bible, a must read lecture

Rulas
  • 1,154
  • 3
  • 16
  • 22
7

I had similar trouble with an application used by a workforce with a good proportion in their 50s.

I learnt an amazing amount just by sitting with them while they used the application. If they tried to do something I thought was daft or missed something I thought was obvious, I'd ask them what they were trying to do, and what made them think that was the way to solve it.

It's very true, lots of things more experienced users would think are benefits and useful features can just be distractions. Be sure to take the users feedback very seriously. If you have also got savvy users, they could have an advanced mode that turns on auto-complete etc. But don't ever try to think you know best because a certain way of working allows you to work more efficiently when you use the UI.

Also. Remember to use big plain fonts, high contrast, and big buttons that are easy to hit with a mouse. I know you say you haven't got accessibility problems, but your users might appreciate these things and see it as an improvement to the UI. One issue I had was that the users didn't seem to understand the meanings of icons, text seemed to work better. Or if you've got space, include text next to existing icons.

Be very careful when you come to add new features... these can confuse this type of user massively. It's taken them a long time to work out how to do something and now its changed! So ensure new features don't upset old ones too much or at all if possible.

Another good thing to consider is the workflow. If you can organize screen elements so that users can work from top to bottom in a linear manner to achieve a task, this may improve the usability.

Scott Langham
  • 53,246
  • 34
  • 122
  • 193
3

If you want an awesome UI book, try The Design of Everyday Things by Donald Norman. It is not about computer interfaces, but is applicable to nearly all UI work.

My two cents: Make the interface consistent with something that the age group is already familiar with (probably Microsoft Office).

jle
  • 8,822
  • 5
  • 44
  • 65
2

As you've seen, there's a ton of work being done on Usability and there are even tools to test your site and so forth.

If you can get your hands on some users and do testing with them, however, that is best. UI is an empirical art -- like all programming, I think -- so if you can interact directly with your target universe, that's best.

One you have a small sample group for testing, you will see that many things that users have already reported are happening, and others are not. It may be the case that just a few users (or one loud user!) get disoriented with autocomplete, or it may be all of them. Or they may learn to use autocomplete...

On the learning front you have another thing to look into: is it possible to train your users? You might be able to do this with a course or a few intro pages on the site. I know this seems to defy standard UI logic (that it's intuitive and requires no training), but for someone who's never seen a mouse, it's a different story.

Dan Rosenstark
  • 64,546
  • 54
  • 267
  • 405
1

Use less of it. Less ways of interacting mean less things to go wrong. This doesn't mean you have to remove functionality, just hide unnecessary things until they're appropriate in context. GNOME seems to be getting this part right at least.

1

I often find autocomplete features distracting. I'm a pretty good typist by now, and I generally type by thinking of the word and letting my fingers do the rest. If I can just type something like "restaurant", that's fairly simple. If I have to type "r", then "e", then "s", then "t", then "a", and then select "restaurant", that's a lot more mental effort; similarly, if I have to do something special to avoid typing "restauranturant", that's a pain.

Some people are very adept with the mouse, and some are really clumsy, and mice aren't the only pointer devices. Some people, including me, find laptop glide pads really clumsy (and are glad it's cheap and easy to buy a decent USB mouse to plug in).

That's not necessarily the problem here, though. If a box always or never needs to be checked, don't display it in the first place. If it sometimes needs to be checked, then you need to have a way to tell the user that that box is the problem.

In general, don't get too fond of looking glitzy and using all the neat Web 2.0 toys. Real people are not difficult to find. Sit down with two or three and watch them try to use your website, and if possible ask them to think aloud. Make notes on what seems to puzzle them and what they don't like. When you make changes, try again with a person or two.

Remember that you can design a website to work with people. You cannot design people to work with a website.

David Thornley
  • 54,186
  • 8
  • 87
  • 153
1

AJAX style auto-complete and forms with lots of fields are generally meant for users who basically know what they're doing and want to get through the application as quickly as possible. In the traditional sense, slow and tedious = more painful.

It sounds like with your specific user base the definition of painful is different. Your users probably don't mind going through the application slowly if it means that they only have a little bit to deal with at a time. Perhaps what you want is to break down your form into baby steps: only present one field at a time and give feedback to the user before moving on to the next field. This leaves plenty of space for specific instructions at each step.

A possible alternative to auto-complete is to have radio buttons for common answers, with one of the answers being "Other" and a text box to type the answer into. This only works well if there's a small number of common answers, of course. Your users may find this easier, but I wouldn't assume that or even take their word for it. If you have the time to spend, try implementing it both ways and observe the effects on your users. It's possible that auto-complete works better for specific questions and radio buttons work better for others.

One final thought: a little education can go a long way. It's possible that what you want is to somehow explain to your users how to fill out web forms. That could be a kind of cop-out, though: "it's not my app that's the problem, it's the users!" :) Still, if your users are going to be using web apps other than yours, it's best to educate them in common web form practices so they aren't repeatedly frustrated.

Parappa
  • 7,218
  • 2
  • 32
  • 37
1

Some specific tips for the specific problems you mention:

  • Autocomplete: Disorientation can result from autocomplete if it means a spontaneously appearing dropdown, pane, dialog or page, distracting the users from what their typing. Consider using a fixed list box or pane to show autocomplete options.

  • Accidental clicks: Could be a result of inconsistent visual coding of your controls (such as you see on this web page), resulting in users not realizing what is clickable and what isn’t. Choose one color for all links. All links and only links should be underlined. Other controls should look and act like standard GUI controls, and generally appear a lot like their physical analogs (e.g., tabs should look like paper notebook tabs, buttons should look like electrical buttons). Stick with black for inert text.

  • Incomplete fields: Failure to notice fields may be a result of an imbalanced visual design. Each page should present a visual hierarchy that is consistent with the user’s task, where more important items stand out more than less important, and the relations among items are visually apparent. Generally, fields and controls that users interact with should be most conspicuous, and among those, required fields should be even more conspicuous. Your pages may be overall too cluttered with gratuitous text, colors, and graphics.

  • “Not going thru!”: Sounds like you need better feedback on error states so users can figure out on their own that they missed something. Consider highlighting the unanswered fields and presenting directive text (e.g., “Chose one of these ->”). Or consider taking the user to a page that has only the unanswered fields for them to complete.

In general, your app may be trying too hard be too impressive, aiming to look and act cool and exciting for aesthetic reasons. The more demanding the context (inexperienced users, complicated app), the less concession you can make for aesthetics. By all means, use AJAX, but only for improving function, not for eliciting a "wow".

Michael Zuschlag
  • 4,552
  • 12
  • 14
1

A couple of years ago, I got to about some usability results from tests conducted to create public library software. It was interesting because it turned out that a high number of library users at the time were not computer-savvy. The only GUI controls that these non-computer savvy users were able to get right away were text boxes and buttons. Instead of scroll bars, the interface used buttons like on a CD player with single up/down arrows to page up and double up/down arrows to go to the top or bottom. The search UI implemented with only these features was very successful.

If you want your users to not miss checkboxes, it may be better to force the answers into the flow of the UI. While experienced users hate wizard-like interfaces, beginners often have a better experience if they are forced to read and answer one question at a time.

One option if you have a checkbox would be to have to Take Action Buttons on the screen with each having a implied value that you would have used a checkbox for. For example, you could have a buttons labeled "Come straight home from work" and "Stop at the grocery on the way home from work" instead of a checkbox for the Pick up milk option. By putting the checkbox values on the action buttons, the user has to consider the option and make a conscious choice.

As an aside, I have always found is an interesting exercise to try to explain default values to a novice user. They just don't get it. This is why the approach of a wizard or alternate buttons can work better in a novice environment since they are force to answer every question instead of taking defaults.

Ether
  • 48,919
  • 12
  • 83
  • 153
Marcus Erickson
  • 1,511
  • 1
  • 11
  • 10
0

One of the problems in designing for less computer-savvy people is that they can't deal with the freedom of computers. UIs offer many choices and can be approached in different orders, which can lead to confusion, missing checkboxes, etc.

Non-power users have an easier time dealing with one "path" and making one choice at a time. It is theoretically possible to refactor one dialog box with a lot of choices into a series of choices that do not require going back and forth. This is longer and more annoying to power users, but is very effective for people who're afraid of computers.

For example, rather than present people with a ballot screen with four races, present them one after the other and take a choice on each. Takes longer, but less likely to miss or overwhelm people.

Also, non-computer savvy users don't notice cues like the move of the focus, grayed out buttons, etc. When we see a grayed out button it means we haven't finished entering stuff. When they see a grayed out button, they ignore it, and eventually push and push and push, not understanding that it's not enabled.

Uri
  • 84,589
  • 46
  • 214
  • 312
0

You're amazed that 40+ can't figure out AJAX-like applications? If you're targeting that age group, I would keep it as dead simple as possible.

Chris Stewart
  • 3,245
  • 9
  • 34
  • 55
  • Why would AJAX be linked to an age group? Isn't AJAX just a technology that can be used for virtually everything relevant to websites? I feel that it is more how you use the tool then what tool you use.. – Boris Callens Jan 20 '09 at 18:53
0

Just one small one. Try your absolute best to conform to the UI nuances of the OS that the application will be run on. If you can do this, users 'learn everything at once'. For example, Word 2003 is similar to Wordpad for a reason. The same reason that are planning (still?) to make all the accessories in Windows 7 use the ribbon interface.

To me nothing is worse than a QT app that was built by a Linux coder, and compiled directly to Windows. If you are targeting multiple OSes make sure you implement a design pattern that allows you to make 'conformant' UIs on each OS.

Jonathan C Dickinson
  • 6,995
  • 4
  • 32
  • 46