Anyways, I’ll share with you (very briefly) how we used to develop user assistance for web-based applications in my previous organization – we used a combination of embedded help and external help (nonembedded) used together. To develop embedded UA, we had to do the following: 1) Perform UI reviews and suggest changes to the UI components so that it becomes self-intuitive for the user. 2) Develop help content (popup text, etc.) for specific areas in the user interface so that the user can perform the task using the information (popups) against the various fields, buttons, etc. Now, how do you determine in which areas of the UI does the user require assistance? One way is to use the application yourself to complete a task and see where you get stuck. Another way is by reading “user profiles”. User profiles were provided by the PMs, developers, etc. and these user profiles were usually prepared by the UX folks, product managers, etc. after doing extensive research on what kind of users use the products and how they use them. User profiles contained info about the user – qualifications, skills, experience, frequency of usage of that particular page, etc. The information developers used this information to gauge which areas of the UI required help and what type of help. But, sometimes we had to go back to the PMs when not sure if some area in the UI or some UI component required help or not. The whole logic behind this was to get the users “doing” stuff right away without an overview, concept, etc. For nonembedded help, we used to provide links (within a UA panel) that led to conceptual information, procedural info, FAQs, etc. depending on what kind of information is suitable for that particular page – again this was decided based on the user profiles. This information could be used by the users if they wanted to learn more or if embedded help wasn’t sufficient (remember, real estate is very limited on the UI!). So, in a way, audience analysis was done by the usability team, product managers, developers, and information developers. I guess this would start at the UI prototyping stage and go on till the TWs developed content, performed peer reviews, the PMs and developers performed technical reviews of the type of help content we developed (and approved them or suggested changes). I personally feel we would also have to revisit our audience analysis even post-release, based on the user’s feedback after using the actual product.
For more info on embedded help (if you don’t already know), read this – http://www.stcsig.org/oi/on_articles/0601_help_embedded_ovw.htm
We used almost the same logic that is provided in the link above.

Coming specifically to your example of internet banking, I personally feel, embedded help must be provided on the UI to perform the tasks (transfer funds, etc.) Also, an FAQ link or procedural info link (nonembedded help topics) would be very useful (without the language errors, etc especially since in this case you may not be able to exactly gauge the user’s level of expertise with internet banking. Better still, make the UI itself as intuitive as possible (for any user who is familiar with computers and internet!) There lies the challenge!
These are just my thoughts. I know, in my reply, I’ve digressed a bit from the main topic; but I hope this has been of some use to you. Hope to see more interesting posts from you!
- Hemant