Monday Mar 14, 2011
Saturday Aug 14, 2010
By ultan o'broin on Aug 14, 2010
We're all familiar with the concept of the Frequently Asked Question (FAQ) type of user assistance. But I have a question of my own, infrequently asked: "If it's a frequently asked question, then why?"
Frequently Asked Questions, to me, may indicate that it wasn't possible to execute a completely intuitive user experience, this time, for some categories of users. However, if a question is "frequently asked" then it also makes sense to treat it as a requirement gathering exercise; an opportunity to improve the usability of the interface as quickly as possible using the information in the FAQ itself.
FAQs are about performing tasks directly, of course, but they go beyond the straight "how-to" procedure. Some may explain the meaning of something, the consequences of a decision in advance, or the downstream consequences of a task that a user may need to know before acting, and so on.
Oracle Applications Help System (EBS) Procurement FAQs
There's a need for these sorts of orientation and affirmation/confirmation topics during task usage, but any notion that "What's this for?" "Or how do I do that?"-type FAQ topic should persist for very long in the age of agile development, or in any great numbers, makes no real sense to a user experience professional.
Let's be clear here. I am not saying that FAQs never need to be written and published. They do reflect the reality that you can't design and build everything you want all the time. Some operations may have to remain complex, some things may note be so easily learned or remembered, or there may be other reasons to write about.
But ask yourself: How often are FAQs refreshed? And what process is in place in your organization to review and eliminate existing ones? Every task-based FAQ should immediately trigger an associated enhancement request or product backlog item added to remove the need for the FAQ topic through superior design, testing, or development. Indeed, FAQ topic value should be measured through reviewing webserver logs, feedback, ratings, and user conversation, too
Plus, If you find that your customers are writing FAQs and distributing them across in the community, without reporting issues to you, then you need to do some real thinking about your user experience methodology and how you obtain feedback on user assistance or approach the notion of information quality.
Otherwise, frequently asked questions are just perpetually published answers.
Oracle applications user experience (UX) assistance. UX and development outreach of all sorts to the apps community, helping to design and deliver usable apps.
Ultan Ó Broin. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @ultan
See my other Oracle blog about product globalization too: Not Lost in Translation
Interests: User experience (UX), user centered design, design patterns, tailoring, BYOD, dev relations, language quality, mobile apps, Oracle FMW and ADF, and a lot more.
- It's Not How You Wink, It's How You Work
- Copy is Interface Design
- APIs are User Experience Design Too
- Dress Code 2.0: Wearables
- UK Pilot Event: Fusion Applications Release 8 Simplified UI: Extensibility & Customization of User Experience
- Simple to Use, Simple to Design, Simple to Build at UKOUG Apps 13
- Why Be Shy About Applications User Experience? Be Shameless like @ultan
- PeopleSoft UX Design Principles and Guidelines Available
- Design Patterns as Grand Theft AUX? Come See Us At OOW13 and Find Out!
- Shout-out for ADF EMG Sunday at Oracle OpenWorld 2013