I have an account with a public-sector bank. It’s a bank that opened a branch right next to the office I was working in then, and it’s where my salary was credited. I still have that account, but since it’s about 7 kms from my residence, I was thinking in terms of internet banking…
“Not a chance”, scoffed the brother. “It’s a public sector bank; they’re dinosaurs.”
I didn’t agree with that line of reasoning, so I went and checked their website. Sure enough, they had internet banking facility. They even had an FAQ for users of their internet-banking facility. I saw the FAQ page and saw red. The following image is a composite screenshot of their FAQ page peppered with my red-ink comments.
To see the picture better, click on it twice but not in quick succession – Click 1 opens the picture in a new tab, and Click 2 expands it to fill the screen.
bankfaq_edit1
And then it struck me. I was looking at the Web page as a techwriter, not as a user.
An average internet-banking user of this bank would be an Indian whose primary language, either at school or at home, was not and is not English. Such a person would not even notice the errors I’ve marked. Such a person would find the text totally comprehensible, unambiguous, and useful – though a tad incomplete because it answers only about four questions and doesn’t even address the how-to of the options provided by the internet-banking facility.
Such a person is the average user of the webpage. Which means, none of my edits are required.
Does it matter at all that a minuscule percentage of users, like me, are put off by badly-written help? And no, it’s not because I am a tech-writer that I am put off. Ever since I can remember, I’ve hated badly-written text (even before I knew – courtesy technical writing – why I hated them). It somehow smacks of a cavalier attitude.
Coming back to the example in question – I, as that minuscule user percentage, am put off by the bank’s FAQ page and will never read it. How does that effect me, the user, and other users like me? I, for one, will never use their internet services, preferring to physically visit the bank for my transactions – if they can’t get their webpage right, they won’t get my online transactions right as well. Presumptuous and unfair of me, but still… Does it effect the bank? Nope. They’ve still got my account with them. But in the longer run, I may be leaning more towards banks that care…
So, where does audience analysis begin? And stop?
December 1, 2008 at 1:22 pm
Hi Anindita,
Good post! I tend to agree with almost everything that you’ve said. I’m not sure if I’ve understood what you mean by “where does audience analysis begin and stop?”
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