Say you are a software designer at the upstream side of development. The system is very powerful, and of course your requirements are to not overwhelm the user and let them work efficiently in a system they might not fully understand. The remedies to this situation include anticipating user's needs and giving them a dialog or prompt that will provide for the action you think they want to take. Here are the pitfalls to avoid with this:
- Dev time and negotiation with detecting a granular level of states
- Make sure you don't present more than one option to the user
- Make sure you enable the user to do this task later on their own without prompting
- Don't add automation "do this every time" that further confuses the initial question, and hides functionality
- Don't add the feature as a band-aid to something you should redesign anyway

Overall, you should not be paranoid about this need for user education. There's no sense in thinking: if the dialog or prompt looks like user education, then your colleagues will think you don't know how to design. If you listen to that voice and avoid anything that looks like user ed, you will make your design look like functionality when that is its secondary purpose. Remember that menus, which look like functionality, are actually there for user education in most applications. The user menu-surfs in order to find out what the product can do, but then they'll use a toolbar button to perform the tasks.

Good example of a dialog that breaks these guidelines is the "Windows can perform the same action each time you insert a disk..." dialog in XP.

comment []10:38:09 AM