Post History

Source: https://writers.stackexchange.com/a/26515
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

Source: https://writers.stackexchange.com/a/26515
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

There is actually not a lot of point in describing what an option does, per se. What you should really focus on in both technical communication and interface design is what do you enable to user to do.

The goal is to enable the user to react correctly. So the first question is, given you user base, do any of these descriptions do anything to help the user act correctly that the label "Saving" does not already do.

I'm pretty sure the answer to that question is no for the examples given. By the time the user has worked out that they need to be in the setting menu, they probably understand what "Saving" means.

For some users, you may need to tell them how to organize their work in folders, etc. But that probably does not belong in a description of the setting menu because it is probably aimed at people who don't intuitively think, "I bet I can adjust the default save location in the setting menu!" Unless something thinks that way, they are not going to find that information in a description of the setting menu (except maybe by using search, if they happen to pick the right terms).

The other question to ask about documenting this setting per se is, are there things that a user who has got this far may not be able to do without more information? If there are, then that might be the stuff to document here.

Whatever the answer to these questions, though, documentation that does not add anything to what the UI is already saying (for the anticipated audience) is pretty pointless. UI design is a form of technical communication. Unfortunately, there is far too much documentation out there that simply repeats what the UI is saying. It covers everything you could learn from the UI without its help, and nothing you could not.

EDIT: In other words, there is on one right way to describe what a option does. The right way is to tell users what they need to know in order to act correctly and that will depend on many factors: who the reader is, what they are trying to accomplish, how complex or obscure the option is, and how effective the UI is.

The key question is always, what is the user trying to do, and what to they need to know (that they don't already know, and can't tell from the UI) in order to get that done.

Original score: 2