top of page
Writer's pictureCatherine O'Regan

Is it time to say ‘faq u’ to FAQs?

Updated: Oct 23, 2019

Why you need to say goodbye to Frequently Asked Questions in your content design


I recently had a project manager say to me ‘Call me old fashioned, but I do like an FAQ on a website’.


So I called him ‘old fashioned’...


An Old Fashioned cocktail with ice cubes and a cherry in a vintage whiskey glass
Old Fashioned cocktail: burbon, Angostura bitters, sugar, a dash of club soda and a dose of reality

At the time in question, we were in the process of delivering a new payroll system to an organisation over over 6,000 staff. So undoubtedly, there were going to be a lot of questions about the new system, many of them would be the same questions asked over and over again.


Such as:

  • When is the new payroll system arriving?

  • How do I find it and use it?

  • What does the new payroll system mean for me (if anything)?

  • Do I need to do anything different?

  • What if it’s not working for me or I can’t access it?

  • Why should I care about a new system anyway?


So what ‘old fashioned’ would call an FAQ, I would call a list of user needs.


This list would then become the basis for my core content about the new payroll system.


Why not an FAQ then?


FAQs in theory are a good idea. You’ve got a lot of questions, we’ve got the answers. So why not put them all in the same place? However, not everyone asks all the questions, all the time. I may have only one question I need answered, I may have many questions or I may not know what questions I want to ask yet.


The problem with FAQs is not so much the content but the delivery. FAQs make users do all the work. Instead of presenting the information up front on your website, your user has to find the FAQs in the first place and then wade through them, hoping the answer to their question is in there.


FAQ sections often mutate into a combination of two things. Firstly a repetition of key information that should already be front and centre of your website. Secondly, they become a dumping ground for all the random and often infrequently asked questions that your product owner or project delivery manager thinks somebody may ask some day (believe me, they never do).


The other risk with FAQs is that they will muddy the waters of your search results. If they are duplicating content elsewhere on your site, there’s a danger your users will become confused and won't know what to select when they get two or more similar listings in your search results.


And lastly, if you use accordion style expanding and contracting FAQ layouts, you may create all sorts of accessibility issues if your interface hasn’t been thoroughly tested


What exactly do we mean by frequently asked questions?


I will only ask you the question once, I don’t necessarily care if anyone else is asking it too. Frequent is a word that should only apply to things that keep you up at night, either a bar you go to far too often or a weak bladder that wakes you up from your sleep.


If it’s a question that lots of people need to know the answer to, then it shouldn’t be hidden away in the depths of your FAQs. I recommend you use the 80/20 rule here. If 80% or more of users will need to know the answer, make it central to your content design.


If 20% or less need to know, then consider how you will manage your contact and support options for those peculiar or complicated questions. Don’t distract the majority of your users with information that only applies if it’s between 2pm and 4pm on the last Tuesday of the month and your middle name starts with B and you’re a returning customer but it’s been over 3 months and so on…


Always say no to FAQs


Service heads, product owners and project managers and other non content professionals will try and cajole you into creating an FAQ because it’s an ‘easy’ (no, lazy actually) way for them to serve their customers.


Here’s the trick… do get your service expert to create an FAQ if that’s how they imagine they’ll answer their customer’s questions. Even do it in person with them if possible. But par that list up with your list of user needs and put aside anything that’s not an actual user need that you’ve identified.


Present your content as an FAQ without the Qs by turning the questions into statements. Put the ‘answers’ in a logical, contextual place in your information architecture and for FAQs sake, give the pages and sections titles amd descriptions that people are actually searching for.


Read more


If you still don’t believe me, read these articles by two leading content designers:


And if you're still not convinced, I'll buy you an Old Fashioned cocktail. But I still won't do your FAQ...


40 views0 comments

Recent Posts

See All

コメント


bottom of page