If software was perfect, could we finally get rid of FAQs? Earlier this week I joined one of the online events that were presented as part as the first-ever Web Heroines conference, and an interesting discussion ensued…
The session was a presentation by Rachel Andrew, talking about lessons from launching a product (their Perch content management system, specifically). Rachel had loads of interesting things to say about launching a software product, but one area that she’d found took a lot of energy was dealing with support calls. The approach she and her colleagues take is to design out the need for support as far as possible, taking great care to turn customers’ feedback and struggles into action that improves the experience for future users. It’s refreshing to hear of this approach for CMS software – usually one of the worst culprits for unpleasant user experiences.
An aspect of this approach that Rachel mentioned was an attitude that “FAQs are essentially bugs”, which I understood as: if you have to write an FAQ then there’s something wrong with the product; i.e. the product should be designed in a way that means you can just use it. I was intrigued by this approach, so I tweeted:
Some interesting discussion followed. The general feeling was that getting rid of FAQs is indeed an admirable aim, but perhaps not realistic – certainly not if “FAQs” refers to all user information that is outside the UI.
FAQ’s for software – the main points:
1. FAQs are unhelpful. Information may be needed outside the UI, but FAQs are not a good way to do it:
2. It’s admirable but unrealistic to aim for no information outside the UI:
What Roger’s getting at here is that the cost of fixing the UI isn’t always justifiable, so some information is needed… it’s good to keep that information within the UI if you can … but some things just need longer explanations than you can deliver well within a UI.
Want to find out more?
The implication of this is that as long as companies use FAQs as part of their user information, then at least some will always have to exist.
3. FAQs (or other user information) *are* part of the UI, so should be fully integrated with user experience and interaction workflow.
What we mean by this is that – assuming information is needed somewhere to support the user – the whole question of whether it’s in the UI or not misses the point. The information, wherever it is, is actually part of users’ interface with the product … so FAQs effectively *are* the UI. This brings us back to the approach that Rachel Andrew described: the UI should aim to enable people to complete tasks without them needing to step out of their workflow … so if FAQs are part of the UI then they are indeed bugs!
My thoughts on how to recognize poor design software?
I roughly agree: FAQs are rarely ideal. Ideally, only minimal user information should be needed, and preferably not delivered as FAQs.
However, from usability testing and analytics data I’ve seen a couple of things that are worth bearing in mind in this discussion:
1. If you have FAQs, people will look at them. FAQs may not be the best way to deliver information, but if people feel that their issue or question is a common one, then they will look at FAQs if they’re offered. Conclusion: if you publish FAQs, they’d better be good – don’t fill them with fluff!
2. Some people just like to get a deeper understanding of software before they download and play with it. I don’t have any data about what percentage or types of user this applies to, but those people are definitely out there. This means you do need to provide some user information – even for the most easy-to-use applications – and some of that information will need to be available outside the UI…which may mean you need to publish something very like FAQs.
3. People ultimately don’t particularly care where their information is delivered to them or what it’s called … as long as it’s easy to find and answers their questions without causing them pain. The application UI is often the best place to put information, but users are equally happy with a tooltip within that UI or a link within the UI that takes them to a separate web page – as long as they can feel confident they’ll end up at the right information and they can get back to their workflow easily after reading.
Originally published on 23.01.12