The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

New Features create problems for average users

So it's happened again. I add a very useful new feature to a program.

Time passes. I get around 20 service incidents of people thanking me for the awesome new feature that was just what they needed.

And I get around 100 service incidents of people reporting anomalous behavior that is obviously caused by them making random 'experimental' changes to the settings in the new feature, moving on, then becoming confused by the results of those actions since they didn't know what the new feature did, they were trying to figure out by random clicking.

The related manual section is accessible with one click from the new feature and explains things well. But most users won't read it no matter how easy it is to find and how pleasant to read.

The interface is discoverable and has tooltips and explanatory prose in the window, but that doesn't help the average users.

There's also video tutorials available explaining and demonstrating each feature.

I think the only solution that will prevent service calls and confusions is to actually remove these sorts of features.

The problem is that there are 5 times as many average people who can't understand technical stuff as there are people who see something and say 'I see what this does', or can read and comprehend the manual no matter how it's written.

The average users DO understand when someone from tech support sends them a personal response explaining the feature. If the explanation is a cut and paste from the manual, they do NOT understand it, but if it is a slight paraphrase, they DO understand it. For some reason.

And I just know that for each person who contacts tech support there are 10 people who say 'this program doesn't work.'

Remove these sorts of features or not? This is an ongoing problem with all software in general. I myself can't figure out a lot of programs.
Saturday, January 27, 2007
Can these features be made more intuitive?
Saturday, January 27, 2007
I'm not sure.

The design is good, well explained, obvious. There is an intrinsic complexity to them though, plus adding any new features adds to the total complexity of the program.

The main problem seems to be that the features exist at all. No matter how simple they are made, the average user isn't going to use them at all, but in checking them out, is going to be able to misconfigure them and then become confused by the results.

Removing them from the program is a sure fire way to prevent misuse and confusion. But then the advanced/power users don't have their sparkly new feature.

I've thought about separating them into a separate program and then if you don't have that program, you don't get into trouble.
Saturday, January 27, 2007
Can you disable them by default, and enable them if someone looks for them (i.e. allow power-users to enable them)?
Christopher Wells Send private email
Saturday, January 27, 2007
That's sort of how it works right now. The default is to do nothing.

When the new releases come out, there's a list of new features. Users look at this, then seek out and activate the new feature, and mess around with it in an attempt to discover how it works. At this time, they set up random settings that could be valid ones for most people, but which aren't for their use.

One possibility is I could have it revert to the default settings each time you run the program, although that would be inconvenient for the power users.

One problem that creates this situation is that unlike most new features, this one can change the behavior of the program as a whole, so it can create changes that a user who doesn't understand the feature isn't expecting. For those who understand the feature, then everything makes perfect sense and is logical. Part of this is that I have two groups of users, the technically minded ones and ones who just don't understand technical issues. Unfortunately, many of the non-technical ones want the more advanced features of the program, but only a specific small set of them and nothing more. Otherwise I'd solve the problem with a Lite and Pro version. But there's no way to partition the Lite version to be applicable to most of the non-technical users as there is such a wide spread of how they use the program.

Maybe the solution is for the nontechnical users to have more user training (like there are books available for Photoshop and Word that allow nontechnical users to master the technical parts of the program) and just accept the additional support queries as necessary. I think that's how Adobe etc deal with this sort of thing.

I have a user support forum but the nontechnical types don't like to use it, they prefer to email for support.

There may be no solution to this problem. It might just be an intrinsic part of creating software that can do complex things and selling it to the general public.
Saturday, January 27, 2007
>It might just be an intrinsic part of creating software that can do complex things and selling it to the general public.

Scott, interesting topic. Can you give us some idea of what the software does? And why is the "general public" interested in doing complex things?

Have you ever sat down with users to watch how they use the software. You can also add instrumentation that records what folks do and reports back to you, with their permission of course. Apparently this is becoming fashionable.

Usability is complex and hard to do well.
Neville Franks Send private email
Saturday, January 27, 2007
Could you ask the people who became confused, "Where did it all go wrong? How did it confuse you? What could I do to fix it?"
Christopher Wells Send private email
Saturday, January 27, 2007
Hey guys, yes, I talk with the users so I know that for the ones it goes wrong, they are messing around, then they move on.

The software as a live video processing application. The new feature is a color correction filter on input to compensate for camera idiosyncracies. Since it is live processing, people mess with the calibration curves as a live video effect, then forget about what they have done and later write to say that 'There is a bug. The color is all messed up with this new version'. So I have them go to the calibration screen and press 'reset' and then they are 'oh yeah, I was messing with that.'
Saturday, January 27, 2007
If your new feature has persistent configuration that affects normal operation, then it might be a good idea to add a "Restore Default Settings" button to the configuration dialog.
Stephen C. Steel Send private email
Saturday, January 27, 2007
I've seen some kind of "Wizard" in some graphics software (I think it was from ULEAD?). There you could configure several filters by hand and also by using that wizard.

The configuration dialog was split vertically, on the right hand side you could modify all the parameters by hand. On the left hand side there was a 3x3 or 4x4 grid of thumbnails of the image you were working on. Each thumbnail was altered a bit more by applying the current filter. When you clicked on one thumbnail, it became the source of the next iteration cycle of the filter.

So you could click intuitively through the thumbnails to get to the result you had in mind. Once you were satisfied with the result, you just clicked "ok" and didnt have to worry about the exact values you would have to adjust for the filter. Or you just cancelled the wizard dialog.

Maybe you could do something similar? This could also help the users to get back to where they came from when they see what the program does while they "play" with the features?
Sunday, January 28, 2007
I have some similar feature in my app. It is very useful and good for the ones who understand it but it can cause confusion if one is not realising that the feature is active. Actually it is pretty much like your processing feature.

We decided to add a big large symbol that is showing that there is activity on the feature. The user can see it anytime. He can even use it to disable the feature right there even when the page where the option is activated is not visible.

Maybe there should be a big red text saying "additional processing applies, click here to disable"
Husker Send private email
Sunday, January 28, 2007
What percentage of users who use the feature incorrectly contact you?  What percentage of those that use it correctly contact you?  For a normal application my estimate (wholly unscientific) of the percentages would be 80% and 1%.  So let's say that 300 people use the feature, 200 use it correctly 100 use it incorrectly.  You get 2 thank you notes and 80 calls for help.
Tom C
Sunday, January 28, 2007
"Hey guys, yes, I talk with the users so I know that for the ones it goes wrong, they are messing around, then they move on."

Talking is not enough.  What users say and what they actually do is mostly different.  You should watch users.  It is highly frustrating to watch users muddle through interfaces that we think is obvious.  Watching users will give insights into what to make better and more obvious.

For my software I prefer to add features that make the software more automatic or more accurate etc rather than features that require user input.

For every screen I ask myself what are the clicks required here? How can I remove the requirement of those clicks by making it automatic? ie how can I give the feature without the user clicking anything.  For example if the user has two windows open a customer list window and a 'invoices for that customer' window and he has to select a customer and click update to see that customer's invoices.  I will remove the update buttom and delay load the invoices window after 0.3 seconds or whatever when the selection on the customer window changes.

Perhaps you can also consider something along those lines?  Figure out how to make the software KNOW that the user has screwed up the settings and automatically correct those settings in the background or ask the user if his settings should be corrected.
Donald Duck Send private email
Sunday, January 28, 2007
"""The new feature is a color correction filter on input to compensate for camera idiosyncracies. Since it is live processing, people mess with the calibration curves as a live video effect, then forget about what they have done"""

Without knowing more about the application's GUI I'm going to make various wild assumptions about it on the off-chance that even if they're wrong it may still give you ideas...

How do users access this feature? e.g. Is it under a top-level 'Filters' menu, a toolbar button, etc? It sounds like users haven't realised it's a global application setting, perhaps assuming it's a per-document setting due to being accessed from amongst other per-document controls. If that's the case, I can think of three potential solutions:

- Make it accessible solely via the application's Preferences dialog, which is where users expect to find persistent, application-wide settings. (This'd be the best option if the settings don't need to be changed often.)

- Make it a per-document setting. (This'd be best if it's something that often needs to be changed to completely new settings.)

- Make it a combination of the above. (This'd be best if settings need to be changed fairly often, with a small number of regularly-used combinations.) Have a per-document menu that allows users to select from a list of global presets. e.g. Under your Filters menu, have an 'Input Correction Filter' submenu with the following structure:

    Input Correction Filter >
        User-defined presets 1
        User-defined presets 2
        Edit Presets...

The 'Default' option would be permanently present and provide your baseline settings. The 'Custom' option would allow users to configure the filter for the current document only. Users could also store their own commonly-used filter settings to this menu by selecting 'Edit Presets...' to take them to a dialog for creating/editing/deleting presets. Finally, add a 'Default Input Correction Filter:' pulldown menu to the application's global Preferences dialog that lets users specify which of these settings they want newly created documents to start out with (essentially the same menu as above minus the 'Custom...' option).

has Send private email
Monday, January 29, 2007
How about the next time it runs the software, it detects if the new feature settings have been changed and asks "Are you sure?" Then it never asks that again (unless the settings are changed again). Minor annoyance for power users, major safety net for normal users.
Monday, January 29, 2007
You could have some kind of notification that a colour correction has been applied. If you click on the notification, it gives the option to edit or remove the colour correction.

What is happening is that the feature itself is discoverable, but the fact that the feature has been applied is not.
Tim Sullivan Send private email
Monday, January 29, 2007
"The design is good, well explained, obvious"

I've found your first major mistake: if it's obvious then it doesn't need to be explained, and if it is well explained then clearly it isn't "obvious" before the explanation.

Well, ok, explained beats badly explained, but "actually obvious" beats any explanation.

Also, it sounds suspiciously like the feature may be obvious - if you have the domain knowledge required in order to really appreciate it, but your users are more of the "clueful amateurs" who aren't as expert in the domain as you are. Tim has the right idea - if they're complaining that the colors are "all wrong" but this is because of the feature, then a visual indication of what has been applied could really help.

"So I have them go to the calibration screen and press 'reset' and then they are 'oh yeah, I was messing with that.' "

Lose the calibration screen, immediately.

Replace it with a panel of calibration controls on the main screen. When the relevant feature is active, *always* include a clear visual indicator, so that even if the panel is hidden they can see "Color Adjustment Active" or something, and click on it to get the controls. Then when they edit the settings, the main view should be updated in real time.

Editing data and objects by direct manipulation is always clearer than by adjusting sliders in a dialog box, even if you include a "preview".

No, not even a little bit trivial, I expect, but if everything happens in the one window, people will associate display changes with what they've done - and it'll be easier for them to think "if I click on "Color Adjustment" maybe I can fix stuff. And you'll be one up on the competition that's still stuck in the "setup? stick it in a dialog or wizard!" mentality because you've already established that the extra screen confuses people.

Also, read "About Face" by Alan Cooper. Everything I know about UI design I learned from that book. (Ok, slight exaggeration, but it's a damn good book.)

Monday, January 29, 2007
Also, this feature would have caused trouble from day one - it's not being new that caused the problem, it's the fact that "messing around" experimenting in one window leaves another window in a subtly different state. You should count yourself lucky that you at least know what the problem is - it could have been a lot worse.

Monday, January 29, 2007
I'd also like to point out that this sounds like a workflow based application. Err... you can think of it as a giant macro that takes an input and spits out an output.

As an analogy, you can "program" Photoshop to apply certain filters to images (such as removing red-eye) and then apply that sequence of steps to a batch of images. Many photographers will then basically copy an entire set of images to a working directory, launch Photoshop so that it can pre-process those images, and go off to lunch. They come back a couple of hours later, re-launch Photoshop and tweak individual photos as Adobe intended.

The first thing that occured to me when I read the problem description is that people are experimenting with and enjoying the new features in "interactive mode", and then complaining when those features are inadvertly applied in "batch" mode. As quick examples, it's one thing when you're playing around with your web cam, but it's another thing when you're handing all this over to the public access station and expecting them to press "record"; they're expecting a black box at that point.

I'm inclined to agree with Husker and Tim Sullivan. I think you need to either not auto-save the new calibration settings (but make users load them every time), or put up some obvious visual indicator so that they know they're using the right/wrong calibration settings at any time.
Monday, January 29, 2007
>>The interface is discoverable and has tooltips and explanatory prose in the window, but that doesn't help the average users.<<

You could always add an animated paper clip that appears at annoying intervals when it senses the user is trying to do something.
Tuesday, January 30, 2007
>> one can change the behavior of the program as a whole, so it can create changes that a user who doesn't understand the feature isn't expecting.

But expectations are the crux of the matter.  As Joel notably wrote, "A user interface is well-designed when the program behaves exactly how the user thought it would."  If users are struggling with the scope of application of their actions, consider these two possibilities:

1)  Does the interface create false expectations for the scope of action?  Is it clear that changes are global and persistent?  Does it feel like opening the back panel to calibrate the machine, or does it feel like adjusting the current image?

2)  Or, is the expectation right and the feature wrong?  Perhaps users should be able to expect changes made while working on one feed in one session should not bias other feeds in other sessions?  Perhaps they need to save named settings like "Camera 1" or "Studio 3."
Tuesday, January 30, 2007
3D Studio Max has a "Save current settings as default" function in some of its modifiers.  This is quite useful, as it explains itself well and requires a direct user action.  Otherwise, any tweaks you make to the modifier you're using (display a grid, color adjustments, etc) only stick around for the current session.

Would it make sense to go this route here?  Allow the users to adjust their color calibration and so on, and it takes effect for that session.  Add another menu option that lets them keep the current settings if they prefer.

Still something they could tinker with and make wrong, but at least it explains itself.
Jeremy Statz
Sunday, February 04, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz