Here is a brief of the help strategy that we implemented, and it significantly improved the measured System Usability Score.

1. Help should be about the domain. If help veers into "how do I use the system" it is doing the wrong thing. This is just an indicator that there is a UX problem that needs to be fixed. Removed 30% of help and 50+ screenshots that were hard to maintain.
2. The domain has high level concepts - covered by a "Tell me more" link on the screen they are using. And specific domain "info" on fields relating more complex concepts. (your e.g. 'tell me about TSQL query language' sounds heavy handed? Users love things spelled out at the moment they get stuck)
3. All processes are built into the UI. Not just dumb "Wizard" style step-by-step UI, but date, progress and status sensitive guidance.
4. One system had one high-level process that was critical, but very occasional. We didn't have resources to implement workflow in that app's legacy UI. Produced a physical guide to take them through the process. (Some times have to be pragmatic and just do the best within constraints)

Notes in this

• We didn't explain how features "worked" ('click here', etc). The right UI and an understanding of domain makes right action 'evident'
• Yes, we have survey data that a high proportion users skip training, introductions and don't read manuals like a book. The more systems with a strong UX users experience the more this will be an expectation.

Now with that strategy background, to your specific questions

• our "Big picture tutorial" was simplified from a 16 page booklet down to a 2 sides of a B5 card with 14 headline points. High-level, but complete enough - because the other UI and help was improved. We consistently reduced volume of help but improved it's access route and timeliness.

• if the function is explained in terms of the user domain, then expressing what it will / won't do should be succinct and clear for any user that understands the domain. Much more complex if you ask the user to mentally map from 'System Functionality Description' to 'Domain Capabilities'

Here is a brief of the help strategy that we implemented, and it significantly improved the measured System Usability Score.

1. Help should be about the domain. If help veers into "how do I use the system" it is doing the wrong thing. This is just an indicator that there is a UX problem that needs to be fixed. Removed 30% of help and 50+ screenshots that were hard to maintain.
2. The domain has high level concepts - covered by a "Tell me more" link on the screen they are using. And specific domain "info" on fields relating more complex concepts. (While e.g. 'tell me about TSQL query language' may sound heavy handed, users actually love things spelled out at the moment they get stuck)
3. All processes are built into the UI. Not just dumb "Wizard" style step-by-step UI, but date, progress and status sensitive guidance.
4. One system had one high-level process that was critical, but very occasional. We didn't have resources to implement workflow in that app's legacy UI. Produced a physical guide to take them through the process. (Some times have to be pragmatic and just do the best within constraints)

Notes in this

• no assumption made that users are expert in domain. Made sure that guidance was on hand - even if referring to external websites.
• We didn't explain how features "worked" ('click here', etc). The right UI and an understanding of domain makes right action 'evident'
• Yes, we have survey data that a high proportion users skip training, introductions and don't read manuals like a book. The more systems with a strong UX users experience the more this will be an expectation.

Now with that strategy background, to your specific questions

• our "Big picture tutorial" was simplified from a 16 page booklet down to a 2 sides of a B5 card with 14 headline points. High-level, but complete enough - because the other UI and help was improved. We consistently reduced volume of help but improved it's access route and timeliness.

• if any constraints on functionality is explained in terms of the domain knowledge, then expressing what a specific system is, or is not, capable of should be succinct and clear for a user that understands the domain.

It is much more complex if you ask the user to mentally map from 'System Functionality Description' (i.e. How the Screens, UI controls, sequence of activities are used) versus 'Domain Capabilities' (i.e. what the system is able to achieve in a given Problem Domain)

By way of example compare 'You cannot select Option-Y and Option-Q simultaneously' to 'System does not support aggregation for external datasources"