Sitegeist Blog - Beitrags-Archiv für die Kategory 'Web dev'

At a rate of around once a fortnight, I find myself trying to convince clients, friends or people I’ve just met on a bus that FAQs (frequently asked questions) on websites are BAD and WRONG.

I’m not alone in thinking this. Earlier this year, R. Stephen Gracey wrote a great piece about FAQs for A List Apart. And he was following on from stalwart Jakob Nielsen who talked about “infrequently asked questions” in an end-of-year summary of web mistakes on useit.com.

Both Nielsen and Gracey reflect on big problems with FAQs, but both also concede that they’re sometimes necessary. I’m not convinced. I think they’re a scourge.

So why are FAQs bad?
As a content strategist, a hefty part of my day is spent thinking about content. Not content floating on its own in the ether in a writerly, poetical kinda way. Content in situ.

Good website content (and, indeed, good content anywhere) is best when it fits (space, tone, context) and when it’s found (i.e. it is where you either expect it or need it to be).

Sitemaps, page structure, design and words…all of these things should combine online to create an intuitive, comprehensible experience for website visitors. Content should be structured (and labelled) in a way that enables visitors to see it, and to click with confidence. This is the fundamental job of content strategy and user experience folks.

FAQs = fail. They’re a generic spot where businesses and site writers lump stuff, out of context. Any stat you have that shows a user moving from any other page of your site into your FAQs is a mark of failure.

Content should be clear and in context. No room for it on the page where a user might expect to see it? Make room!

Questions are OK….sometimes
I’m not saying that question-and-answer sections are, in themselves, bad. Usually they are, but sometimes they’re the best way to communicate information, and have the advantage of forcing site writers to actually try to think like a site visitor.

If I’m selling t-shirts, it makes great sense to have a “Questions about our t-shirts” area, where I might pre-empt queries such as:

• How do I choose the right size?
• Are there special washing instructions?
• Where are the t-shirts made?
• What if my t-shirt doesn’t fit?

If I’m feeling radical, I might even keep track of questions people actually do ask, and use these on the site. Crazy, sure. But it might be just crazy enough to work.

I could link to these questions from every specific t-shirt product page (actually, I’d probably recommend listing the questions on each of these pages and linking to answers or showing them in hover windows).

I might also have a section containing info about shipping and returns. And I’d call it “Shipping and returns”. If I wanted, I could present these as a Q&A. But what’s the benefit? Might as well present my information clearly under friendly, easy-to-scan headings such as:

• Shipping options and costs
• Tracking and delivery times
• Customs
• Multiple items
• T-shirt returns

…and anything else I needed to tell people about the fine art of mailing a t-shirt to someone.

In both of these examples, it would be a mistake – a terrible, lazy mistake – to put this important info into a generic FAQ.

Why?

When did you last look at FAQs? Was it up-front when you first arrived on a new site? Did you load the site thinking, “Oh golly, I just can’t wait to feast my eyes on them FAQs!”?

Probably not.

Most likely, you were looking for information that you couldn’t find elsewhere. Your search around the site probably wasn’t exhaustive, but you figured, well, there’s the FAQs in the navigation. Maybe I’ll take a look there.

And did you find what you needed?

Probably not.

Terrible.

(As others have pointed out, FAQs are rarely actually questions people ask frequently. They’re more likely to be details the site owners want to tell people, but they couldn’t think of a better place to put them.)

Or maybe you landed in the FAQs from a search of the site. Good news – you probably got the information you needed. Shame it wasn’t placed in its logical site context, where you probably would have found it without needing to search.

Lazy.

Content strategy is about putting the right content in the right place at the right time. It’s about creating positive experiences for users. It’s about making sure the content is there when and where they need it.

FAQs fail every one of these objectives. Site designers, UX practitioners and lovers of content need to work harder. FAQs must die!

A client called me yesterday, asking me to check through some web copy. She wanted to make sure it’ll work effectively on her new site.

I agreed, of course, and asked her if she had designs or wireframes I could see, so I could understand where the content was meant to sit, and where the opportunities were for related content, calls to action, contextual links, etc.

Gotcha!

I’m the guy who bangs on and on about how the best way to develop your website is to create the content first (or at least at the same time as your designs). And here I was asking for the designs. Why?

I’m glad you asked. A couple of reasons:

History: In most cases, the designs or wireframes would have already been done. It’s not right; it’s just how people work. It’s a bad habit. But it is extremely common. For a reminder of why it’s not the best way to develop your next web project, read my first ever blog post about how lorem ipsem (placeholder content) leads to bad websites.

Teamwork: While I’m sometimes the person who actually develops the wireframes in addition to my content strategy role, this isn’t always the case. And for this project, a digital agency is doing the design work.

But this doesn’t mean I’m hopeful that they’ll wait to see the content before commencing wireframe work. The client is controlling the project, and – understandably – wants to see everything happen at once. So this means that the page design is happening in parallel with content development (good…), but the content strategist isn’t working directly with the designers (bad).

With this Chinese Wall between content strategy and design, it would actually be best if I could see the designs up-front, for the best outcome in the circumstances.

For the best outcome full stop, though, we need to tear down the wall.

Thanks to the good folks at UX Melbourne, I had the opportunity to hear former Razorfish UX pioneer and current content strategist and senior partner at Bond Art + Science in New York Karen McGrane present on content strategy.

This terrific session was held at Loop in Melbourne, and was focussed on describing the what and the why of content strategy to a group made up mostly of UX practitioners, with the odd content person thrown in.

Although from my perspective there weren’t many surprises in Karen’s talk, it was a very successful top-level overview of how content strategists can (and should) be involved in web projects. The basic take-away: leaving content (and the strategy informing it) until the last minute is a recipe for disaster.

Having worked in editorial and CS roles online for well over a decade now, I’m a strong advocate of Karen’s message (indeed, some of her main points have even featured in previous posts on this blog). The most exciting things for me were that this event even happened here in Melbourne, that the conversation has started, and that so many smart web professionals are clearly interested in taking part.

If people in project teams advocate for the inclusion of content strategists, project managers and team managers will increasingly include them…and websites will be better. Promise.

So many thanks to Karen for inspiring so many people, and a big call out to Andrew Green who was instrumental in making the event happen. Yaay.

The project was enormous! The resources would blow your mind. Mistakes? Oh yeah baby! We made ‘em. Plenty. But we fixed ‘em too! The CEO was along for the ride. Then not (for a while). Then back on board.

And, finally, after months (or years) and thousands (or millions) of dollars…we launched! We actually went live!

Yaaay. We had a party. There were clowns and free drinks and little bits of cured meat on puffy biscuits that I don’t really like and lots of back-slapping and lots of recognition of foot soldiers. Why clowns? Still don’t know…

Anyhow, along comes Monday…

Day 2.

Hmmm.

The content isn’t quite right.
Marita in accounts reckons the links don’t work.
People using Chrome are getting this weird glitch on the subscribe form.
We need to update the blog categories.
An image we used wasn’t approved.

Hmmm.

Day 2. The day after. It’s the day when nobody cares. That day, and every day after.

But
But your site shouldn’t have a day 2. Every day is day 1. Every minute is a deadline. The job is never done.

Is that intimidating?

Maybe the project was too big in the first place. Are you sure your users really wanted all that stuff? Don’t they just want fast access to the thing you do best?

Business planning is about identifying your strong suit. Content strategy is about playing a confident hand.

What’s your game like?

Speed. When we’re online, there’s nothing like it. Click and load; fast and easy.

And then we arrive at a site with…wait for it…wait….still waiting…a Flash intro. And faster than you can say ‘skip’, momentum has been lost and we’re annoyed. A waste of our time. And there’s nothing that makes a user hit the close box or the back arrow faster than having their time wasted.

I’ve been trying to think of a legitimate use for a Flash intro. And I can’t. How about a funky designer showing off what they can do? No – not if ‘what they can do’ is encouraging their clients to build sites that waste our time.

Here it is again, in case you missed it: There is no excuse for a Flash intro.

And it looks like Google agrees. In a December 2009 interview on WebProNews, Google software engineer guru Matt Cutts hinted that Google search results might take a site’s speed into account:

“Historically, we haven’t had to use it in our search rankings, but a lot of people within Google think that the web should be fast,” says Cutts. “It should be a good experience, and so it’s sort of fair to say that if you’re a fast site, maybe you should get a little bit of a bonus. If you really have an awfully slow site, then maybe users don’t want that as much.”

At Sitegeist, we believe that the content on the page is of paramount importance. If the words are right, then we’re happy to wait an extra second or two for the page to load. But the problem is that we don’t know the content is good until the page loads. And we hate waiting for a slow site with bad (or not relevant) content.

So we approve of Google’s move to reward faster sites. Content and reputation are still the reigning monarchs at Google, but a dose of speed can’t hurt either.

For developers, Google has some speed tools and tips. For the rest of us, expect things to get just a bit quicker online in the next year…