If you read my rant, you'll know that I'm getting a bit of a bee in my bonnet about user interface text. But rather than just yelling about the way the world should be (short version: no UI text would suck), it seemed prudent to actually gather some data. Rachel Potts has made an excellent first foray, by conducting a series of interviews across organizations about how they write user interface text.

You can read Rachel's write up here.

She presents the facts as she found them, and doesn't editorialise. The result is insightful, but impartial isn't really my style. So here's a rant with graphs.

My method, and how it sucked

I sent out a short survey. Survey design is one of my hobby-horses, and since some smartarse in the comments will mention it if I don't, I'll step up and confess: I did not design this one well. It was potentially ambiguous, implicitly excluded people, and since I only really advertised it on Twitter and a couple of mailing lists the sample will be chock full of biases.

Regardless, these were the questions:

1. What do you do? Select the option that best describes your role
2. What kind of software does your organization make? (optional)
3. In your organization, who writes the text on your software user interfaces? (for example: button names, static text, tooltips, and so on) Tick all that apply.
4. In your organization who is responsible for user interface text? Who "owns" it?

The most glaring issue (apart from question 3 being a bit broken) was that I didn't make it clear that I was asking about applications. Desktop, mobile, or web, I wouldn't have minded. In fact, it might have been interesting to categorize and compare. But a few respondents commented on the seeming lack of relevance, since they didn't really make software. There were some other issues too. It wasn't the best survey. So, you know, pinch of salt time with what follows.

Despite this, there were 100 or so respondents. This post covers the overview, and you can look at the raw data in this spreadsheet

What did people do?

Boring graph number one:

I wasn't expecting that. Given I pimped the survey on twitter and a couple of Tech Comms discussion lists, I was more banking on and even Content Strategy/Tech Comms split.

What the "Others" specified:

• Three people chipped in with Technical Writer. Author, apparently, doesn't cut it. There's a "nobody reads the instructions" joke in there somewhere, I'm sure.
• There were a couple of hybrid roles, including Tech Comms and Testing, which sounds gruelling and thankless.
• There was also, an Intranet Manager, a Creative Director, a Consultant, a CTO, an Information Architect, and a Translator.

That's a pretty healthy slice through the industry.

Who wrote UI text?

Boring graph number two:

Annoyingly, I made this a "tick all that apply" question, so I can't make crude and inflammatory generalizations about percentages. This is more about who gets involved in user interface wording. So don't panic about the number of developers writing UI text. First off, it just means they're involved. Second, they might be good at it.

What? It could happen. Ours are involved - they write a placeholder and flag it to me for changes. Sometimes I don't make any.

It's also not surprising that there's so much UX in the mix. Some of that will be people taking care, and crafting an understandable interface. Some of it will be whatever text goes on the wireframe making it into production. I'm going to assume that's what happened at eBay, when their iPhone app purportedly shipped with the placeholder text "Some crappy content goes here". Ahem.

Listing all 17 "other" responses would make this post lengthy indeed, but you can read them in the raw data spreadsheet. The award for the approach that sounds the most like a good idea yet carries the highest risk of ending badly goes to whoever offered up "External agencies using focus groups".

If you're reading this, and that actually works, leave a comment. I'm fascinated.

Who owned UI text

Stop. Bar chart time:

Wow. Let's cut to the chase, and by "chase", I mean those inflammatory generalizations I was talking about:

In around 60% of cases the person responsible for user interface text probably lacks the relevant expertise.

Even in the categories I count as being likely to have relevant skills (Marketing Copywriters, Content Strategists, Technical Authors, and User Experience Designers) there's a case for each role being unsuited, as you'll see in Rachel's blog post So it's not as simple as my headline.

Does that mean that you personally, Mr Developer reading this, write bad button names? Of course not. I know nothing about you. It rather implies that as a category, the majority of people looking after UI text have neither communication nor user experience as their primary skill set, and as such will probably only be good at this by happy accident. I don't have a way of measuring those frequency of those accidents.

What the Others specified:

• I don't know who owns it. I assume the project manager is responsible.
• "copywriters" when they wish to annoy me.
• the client's web maintenance person, often PR or MarComm

That last one chills me to the bone. Still, at least nobody said "the work experience kid". You can see the rest in the spreadsheet.

My overwhelming impression here is of user interface text as an unloved afterthought. There were fewer "nobody" responses than I expected, and a much broader split. But the relative predominance of developers owning and writing UI text suggests to me that organizations don't see it as something worth dedicating attention to. If true, that's bothersome. Because the words on the screen, particularly the names of things, are fundamental to the ability to understand an use software.

It's also fascinating that Technical Authors and Content Strategists are neck and neck. For such a nascent discipline, Content Strategy appears to have made a mark on software development. Or my sample is skewed. But it feels like a bit of validation for my rant: Content Strategy is eating Tech Comms' lunch. That's not a bad thing. Well, not if the UI text is getting done well.

And that's the caveat to this whole post. I couldn't care less who writes UI text, provided they consider the user and don't suck at it. I care that it may be falling by default to people poorly disposed to doing it right. And I care about that because so much user interface text sucks.

The most interesting question

Was one I forgot to ask. It's this: Does your organization have technical authors/writers?

Like a lot of survey data, that doesn't tell you much on its own. But once we get a bit dimensional, it become more interesting. So taken with the other questions, this would have let me find out what I really want to know:

• What proportion of organizations have Tech Comms professionals but don't use them for UI text?
• Who writes UI text in their place?
• Why this happens?

It's possible (feasible is another matter) that hundreds of companies have tech authors who don't work on user interfaces because they've empirically discovered that someone else, say the Marketing Copywriter, is better at it. And once we've all finished laughing, I'll point out that I've met plenty of tech authors who just aren't used to thinking about users at the point of need in the way UI text and embedded user assistance require.

If you've got what I regard, perhaps unfairly, as the bad kind of tech author - the old-school kind with the thousand-page pdf and the grammar obsession - if you've got one of those then you probably are better off getting the UX folk or the copywriters to do your UI text. At the very least, they'll derive terminology from user research.

Recently, I got an email about content inventories. This is not habitually a joyous occasion. Anybody who's had to compile one - and that's anybody who's serious about the web - will attest that it's a miserable experience. Making a content inventory is in that "necessary but horrible" category; it's like talking to that doting but slightly racist aunt, or filing a tax return.

Imagine, then, my delight when the email turned out to be not only a pitch for a tool to automate the process, but an invitation to help build it.

For those who haven't had the "pleasure", a content inventory is basically a big list of all the pages on your website. Ideally, the list follows the shape of the information architecture, and contains both some quantitative and qualitative information. Mine, for instance, tend to include simple page analytics, ownership, and a few words of constructive criticism and/or petulant abuse.

They're tremendously useful for understanding what's on your site, what isn't, whether what you have is working, whether it's out of date, how it's arranged, and whether it even makes sense.

Jeffrey Veen over at Adaptive Path outlined the whole idea in one of the seminal blog posts on content strategy and curation: Doing a Content Inventory (Or, A Mind-Numbingly Detailed Odyssey Through Your Web Site)

The problem is, it's horribly, achingly boring.

While you're stepping through each webpage (there used to be over 1500 on the old Red Gate site), meticulously pasting typing and tinkering with a spreadsheet row for each,  it just feels like your time is worth so much more than this.

The payoff is great, but the efficiency? You're better off digging to the center of the earth with a spork.

Time for Page Trawler

Page Trawler is the brainchild of Tom and Ben, a User Experience Designer and Developer form our mobile arm, MobileFoo. And damn, I wish I'd thought of it.

The core idea is quite simple - automatically generate content inventories. Simple.

But we'd like to do a lot more, and that's where you come in.

We think Page Trawler could be a lot richer than a list of web pages. We'd like it to really help people ask intelligent and useful questions of their web content. So, sure, we'd like it to pull in some web analytics, and show pages with interesting traffic patterns. But how about thinking bigger.

Here's some stuff we'd like to include:

• Screenshotting all pages
• Mapping common navigation routes between pages
• Finding "orphan" pages that aren't linked from anywhere, or are hard to find
• Changes since a given date
• Content summaries
• Spotting inconsistent metadata
• Something for content gap analysis
• Consistency checking

There's bound to be more of course, but you get the idea. What I'd like to know is how that sounds to you? What's missing? What would float your content boat?

Tell us - we'll have a crack at building it.

www.PageTrawler.com

A fair bit has been written about novelty error messages, particularly web 404 pages. Opinion seems broadly split about whether they're charming or unprofessional, but lots of them are pretty memorable.

In the cases of a 404 page, I'm not sure it's something you want people remembering, but the idea is probably to try and take the edge off a nasty or disappointing user experience. The memorability (because these things are, say, incongruous, or arresting, or funny) is a nice side effect for your brand, of course.

Yesterday, I saw this tweet by Gabriel Smy:

And it really bugged me. I think it's a fantastic idea.

It's either a deliberate joke, or a typo with "sink" instead of "sick"; and it's funny. It has that Fail Whale / Tumbeast memorability. It's also a kind of error message. "Don't feed the ducks" isn't a million miles from "Are you sure you want to move this file to the recycle bin?" It's a warning message, with an informational component, howbeit a daft one.

So how about it for tech comms? Gabriel's sinking duck sign works so well because the joke plays with expectations of rationality. The ridiculousness of the idea of ducks sinking unfolds after you've read and half-digested a superficially plausible message. Structurally, it's a good joke. And it sticks in the mind.

If we're trying to get an idea across that we really want somebody to remember, is it worth making it memorably ridiculous?

The counter-arguments are obvious: it's inappropriate for various brands, audiences, or situations, and it doesn't localize (or work well at all for non-native speakers). But somebody will say that about everything in tech comms. Much of the time they'll be right, too, and the problem devolves to how much we care.

I should work that out, because I'm itching to try this.

The 3D edition of Tron: Legacy opens with embedded user assistance. The film starts with an iconic white-on-black command-prompt message exhorting viewers to keep their 3D glasses on throughout. I can't quote it verbatim, and at the time of writing nor could anybody findable with 5 minutes of googling. But it was something like:

"Although parts of the movie are 2D, it was shot in 3D, and glasses should be worn at all times. This is how it was intended to be viewed"

Yeah - "intended". That part is verbatim. Wow.

Now, I appreciate that even out of the small sub-set of readers who care a rat's ass for critical theory, few will be quite so gung-ho for the whole "death of the author" shtick as I tend to be. And yes, this is ergonomic rather than interpretive, but really - telling an audience how you expect them to watch a movie? That's up there with Big Steve's "you're holding it wrong"

Even if it solves the problem, it's pretty arrogant. If anything, it's worse than RTFM. And if enough people are doing it wrong that you have to include the announcement, then maybe - just maybe - you've got a UX and/or design problem.

Plus, current 3D glasses are like sitting in a darkened room, cosplaying the lovechild of Spider Jerusalem and Jarvis Cocker.

Ok, so that observation was weirder than it was helpful; but seriously, nobody wants to wear the glasses if they don't have to. They ruin the visual experience of the non-3D sections, and personally, I find them pretty disruptive to the suspension of disbelief.

This is an old, old, problem, and I'm carping on about it because Tron is enjoyable mass-market slush. It's easier for me to say "no, I can't just put some text on it. It's fundamentally broken, redesign it." in the middle of a small-ish, agile, software project than it would be for some beleaguered production assistant at the end of editing a $200 million movie. But lots of folks in software don't even get to do that.

Way more people are going to see Tron, and be annoyed by this, than will ever read a technical communication blog. So hopefully, after two hours of being mildly annoyed, wanting to turn the brightness up, and slowly getting a headache, they'll realise something very, very important: you just can't document your way out of a shoddy UI.

Regardless of how good it is, you'd have to have a heart of stone not to make snide remarks about Rockmelt. After all, on the surface it looks a lot like some people spent two years building a browser instead of just bashing out a Chrome extension over a wet weekend.

It probably does some more stuff. I don't know for sure because artificial scarcity is cool, apparently, so the "invitation" is still in the post*. I may in fact never know for sure, because I'm not wild about Facebook sign-in as a prerequisite for anything.

From the video, and some initial reviews, my early reaction was: I have a browser, I have a Twitter client; what on earth is this for?

The answer, of course, is "not me".

Rockmelt is, in a way, quite audacious. Oh, sure, on launch day it's Bay Area bar-chat for the kids with no lenses in their retro specs and trousers that give you deep-vein thrombosis, but it's not really about them.

Likewise,  Facebook just launched Google Wave, or something. And all the tech snobbery and scorn packed into describing it that way is irrelevant next to what they're doing with their platform.

Here's something I drew in MS Paint** because I don't want to get sued:

(see: The technology adoption lifecycle)

A while ago in the Guardian, John Lanchester dusted off the idiom that "technology is stuff that doesn't work yet". The rest of the article would be quite interesting if it wasn't largely about MySpace, and he's sort of got a point. If you bolt on the sentiment that risk-averse businessmen like things that work, you've got the essence of Crossing the Chasm.

Products for the mainstream market don't look much like technology.

Think for  a second about early (1980s ish) hi-fi systems, with all the knobs and fiddly bits, their ostentatious technophile aesthetic. Then consider their sleeker and less (or at least less conspicuously) functional successors in the 1990s. The theory goes that innovators and early adopters like technology, it's a hobby in itself. The rest of the humans seem to like magic boxes with very few buttons that make stuff happen and never trouble them about why.

Personally, I consider Apple's maddening insistence that iTunes is an acceptable way to move files around to be more or less morally unacceptable. Most people couldn't care less.

Hence Rockmelt, and hence Facebook's continued growth.

Rockmelt looks pointless to me, because I aggregate my social gubbins with Digsby, or use TweetDeck. But my use case is different and so are my enthusiasms.

If I want to share photos, I'll use Flickr - but Facebook has photo sharing. If I want a short broadcast message, I'll use Twitter - Facebook has status updates. If I want to sell something with relatively little hassle, there's eBay - or Facebook marketplace. YouTube - check, FB Video. Email - messaging. Calendaring apps, yeah there are loads, or FB Events. What if I want to host a simple web page? Sure, they've got pages. Also Notes for blogging, and more games than I can count.

This stuff is right there, where millions and millions of users are already, and for what they need it just works. It's not about me, because I'm not in the big juicy area under the curve.

It's what 1990s portal sites could never have dreamed of achieving. Facebook is AOL on speed, crack, and some designer drugs it had specially imported from the future. It's a n00b-friendly gateway to the internet that just happens to serve up all the things you want to do online, right where you are. Oh, and everybody else is there too.

The price of having all this and the social graph too is that you have all of this, and the social graph too. But plenty of folks have more incisive things to say than me about the whole privacy shebang, and it's not really what I'm talking about.

Facebook is maintaining a vast, and fairly fully-featured training-wheels internet. And it makes up a large proportion of the online experience for a lot of people***. It's the entire web (2.0?) experience for the early and late majority. And sure, no individual bit of it is quite as slick or as fully-realised as something like Flickr (which wows me a bit every time I use it. Those guys are good at the web), but it doesn't have to be. It has to be unobtrusively good enough for the regular humans. It has to not feel like technology.

This is what Rockmelt sort of is. You're online, you want something nebulously social, and you don't want to faff about with, say, Twitter clients. Wow! There it is on a really distracting sidebar, right in your browser. No effort!

Yeah - fish nor fowl, much?

It might work, I guess. There may be a demographic who want their social web experience more simply than tech tinkering, and who aren't just getting it from Facebook (or, for that matter, mobile devices). But I'd be surprised. Rockmelt feels like an attempt to grab a slice of Facebook-style "Look! It's right here, where you already are!", but it's still asking the mature market to install a new browser.

Presumably this is where that Facebook sign-in predicate comes in handy, though it'll take some potent awareness marketing to make it fly.

Meanwhile, Facebook quietly has the entire rest of the internet as a product management resource, and can continue to give most of the people most of what they want. Something that has not gone un-noticed in its potential to look a little sinister. But heck, they might even make Google Wave popular.

*This was true last week when I drafted this post. I got an invite subsequently, hence the screenshot.

**MS Paint is no fun any more. It's actually good in Windows 7. Farewell ironically-shonky diagrams.

*** It's also behind a single sign-in, lending a veneer of confidence, and partially solving the problem of usernames being crummy unique identifiers. I'll be blogging about that at some point.

I came across three things a while back that made me smile:

• Nation Shudders At Large Block Of Uninterrupted Text
  An article in the Onion, gently needling the atrophy of reading and attention
• Big Graphic Blueprint
  Nathan Yau at Flowing Data pokes fun at design patterns
• InternetOnlineWebsite.com
  A really slick piece of advertising making the point that the web is hard

The third is sort of the sum of the first two: function without form, then form without function, then a compromise of placeholders for each.

I’m trying very hard not to say “It’s funny because it’s true.”

But if any of that raises the kind of half-guilty recognition smirk of observational comedy, then you may well have a problem.

Nearly a year ago, the internet fought through another round of the  lorem ipsum furore. In the nervous truce that followed, the consensus seemed to be that yes, you can wireframe without being shot, provided you remember that design and content need to live together at the end.

Shortly after this, unconnectedly, Red Gate fought through another round of “isn’t it time we updated the website?”. This time we actually meant it. So we did that thing we do and in a haze of enthusiasm, innovation, and nostalgia for the start-up days: we locked some folks in a room and told them they could come out when it was done.

For the first few weeks, our lucky detainees were the (awesome) Red Gate UX team. They’ve blogged about the experience. As you can imagine, I was a little nervous.

You see, the exciting part of the Lorem Ipsum fight is the counter-argument, the point the Onion piece makes far better than I ever could: a bare content stack is just as useless as a content-free wireframe.

It would be easy for a “designer” and a “writer”, each toiling away with little contact to both forget that they were working together to make a meaningful user experience with a delineated business purpose. Their skill sets are superficially worlds apart, and since their outputs can be delivered separately, it tends to fall out that they are. Projects have schedules, after all; and it’s not quite desirable that every <p> tag be a committee decision. Personally, I reckon this is why we need a new website now: our design and content requirements have become… shall we say somewhat syncopated.

The key of course is “little contact”. Plenty of interaction, a shared understanding of scope, and a healthy mutual review process ought to ensure that no matter how much lorem ipsum or how little photoshop get used at each stage, the outcome serves its purpose.

Print media has known practically forever that although form and function can be separated to no ill effect, they are stratospherically more powerful when treated as parts of the same thing. Consider BLAST (full text here) or Paris (pdf), or Google’s Chrome ads, novels like House of Leaves and Tristram Shandy, or any number of magazines, books, or billboards. Or comics – a publishing sector that’s had this licked more or less since its inception.

People making the web sort-of-know it’s no different. But as soon as doing something takes two humans, unfortunately you need them to cooperate. I can’t help but wonder how much of the content/presentation separation we see is a result of one group of folks wanting to “just get my stuff done” without external dependencies, or all that pesky collaboration*. Again, that’s fine in the short term. My stuff might be a block of text, and your stuff might be a page layout. The user? They see our stuff. And our stuff is a web page, and they don’t want to see the joins.

Happily, in the end I didn’t need to worry about the web project for two reasons. First off: the design team were  working with a vast body of feedback about the information architecture and content delivery requirements of various sectors of the business. Up second: they dragged pretty much every other content developer into the maelstrom with them. In fact, I’ve only just fought my way out.

For the last few weeks I’ve been the web dungeon’s content-monkey-resident. The process of actually implementing the new site requires a phenomenal content migration. This has been the ideal opportunity to get our grubby little content strategy fingers all over the site. So in the interest both of cutting down the workload and of producing a new site where content and design actually do work together, Tech Comms and Marketing have been doing a fair bit of the heavy lifting. This means everybody has had to engage with everybody else’s world a little.

It’s not a bad blueprint for web projects. Sure, let your designers go and do the wicked-creative of- the-wall stuff, but first talk to everyone. Get folks to look at architecture and content examples from all over the place, and tell you what they like, what they don’t, and then what they want to be delivering themselves. The migration phase is an excellent time to curate, and yet another way to keep people involved. And for the love of the Flying Spaghetti Monster, do it all collaboratively,  preferably in the same room.

So I’m pretty optimistic about our new site, and a big part of that optimism is that I’m fairly sure I wont have to tear anybody a new one over templates and layouts that just aren’t appropriate to the content.

I’ll be doing a proper post on the new Red Gate website once it’s launched. Also, I’ve got through this whole article without using the word “stakeholders”, and frankly I believe I deserve a cookie.

*Some, obviously, comes from content creators fatalistically internalising the idea that they’ll never get allocated any development resource. But that’s a whole separate rant.

Last week, over on a blog called Flyosity, there was a post: Your design is wrong

I liked it, I liked it a lot. Although many of the errors it cites may seem like rather small things, I absolutely buy the idea of objective design mistakes. It got me thinking about examples from the world of technical communication and information design.

Then, a couple of days ago, the perennially awesome A List Apart ran the article Good help is hard to find

Completely reasonably, it’s pretty down on bad help, particularly help that’s long-winded or tonally alienating. I chewed a pencil for a bit and came up with some more tech comms “errors”.

To what I’m sure will be your enormous surprise, most of the ones I came up with boil down to my recurrent hobby-horse:

It’s not that nobody reads the help, it’s that nobody wants to spend time reading the help.

Anyway, here’s 5 ways I think help can be flat out wrong:

Describing the user interface

You can’t document your way out of a bad UI, and you don’t need to describe the minutiae of a good one. Or a familiar mediocre once, come to that.

If you’ve ever found yourself writing something like:

Select Open… on the File menu to open a file

You’ve done it wrong. You’ve also wasted your time, bloated your docs (see: tl:dr), and – in that specific example – broken the rule about writing in the right order that we’ll get to in a minute.

Ideally, the only time you spend writing about the details of the user interface is the time you spend making sure that the buttons and menu items and so on all have the right names in the first place. It’s massively more useful to explain how to do specific things with a product than it is to explain what the bits of a product do. The former comes closer to actual user problems, the latter makes them think about how to solve their problems – something they really don’t want to do.

Writing in the wrong order

In Matt Groening’s Futurama, a caricature bureaucrat asks “Why isn’t this jacket in alphabetical order? The zipper should be at the bottom.”

If you don’t find that funny, I feel sorry for you. If you’re a technical author, and you do find that funny, and then a small part of you realises that actually, you’d want the zipper at the bottom in order to put the jacket on, I salute you.

What? I’m getting there. Let’s re-write that previous example:

Select Open… on the File menu to open a file

becomes:

To open a file, on the File menu, click Open

The instructions are in the order you’d use the UI, and the boldface-emphasised UI elements that stand out now end on the final one you want. The purpose of the exercise is at the beginning, so you don’t have to parse the whole sentence to resolve the sense. This enables F-Pattern scanning and rapid clause-level discard of irrelevant information; both crucial web reading behaviours.

The zipper is at the bottom, and all is well.

Hiding behind a flash portal

I’ve ranted about this. I won’t bore you twice. Don’t do it, it's unhelpful and there’s no excuse.

tl:dr

… is an acronym of “too long, didn’t read”. You know that, right. You’ve been to earth.

This has its origins in blog comments and the like. It speaks not of some tired patrician jeremiad on the attention spans of the young, but rather of the fact that humans generally won't spend a lot of attention if there’s a low perception of likely return.

The List Apart article makes the brevity point, but I’m restating it because it’s really, really important.

There’s an article on Tefl Spin, too, claiming no list should go over 7 items for more or less this reason. The 7 there is very likely prompted by the questionable assertion that we can think about 7 things at once (pdf). Cognitive load is well worth remembering. Quite apart from looking like a poor attentional investment, long-form complex information will very likely lose people.

If any meaningful, coherent sub-unit of your help is really long, it’s probably at least partly wrong. This could be as simple to fix as a run-on sentence or a two page list. It could also be more complex, like a single topic that’s just trying to do too much at once. Regardless, we have a duty to get people back to the task they were trying to do as quickly an easily as we can.

Topics don’t just need to be brief. Their first impression needs to be of something you can quickly get your head around.

In the spirit of fairness, here’s one of ours . Yeah, it sucks, and we’re working on it. In fact, I think my colleague Tom is replacing it with a short animation.

FAQs

The List Apart article is cautiously welcoming of the FAQ style, noting that they’re open to being done badly. That's probably fair.

A problem we’ve had here, and one I very much doubt to be unique, is that FAQ pages have been written by people working on a product launch who are neither information delivery specialists nor particularly technically well-informed. They’ve often seemed to duplicate help content, but with less rigor and accuracy, and they've been created because that’s what we do.

That last one is a red rag to a content strategist.

Ideally, FAQs will always fail the content strategy “What is it for?” test. They’ll fail because the information they would contain is delivered more accessibly and to a higher standard everywhere else. You product page will tell you what the product is, and what its requirements are; your help will tell you how to do things with it, and so on.

FAQs, hiding as they do behind facade of harmless familiarity, ought to be utterly redundant. They’re a bucket for unsorted information, a data scrapyard heaped in the way of actual, useful content.

Oh, and their usability is completely predicated on the phrasing of the question; a problem amplified by the question construction making them wordier and less web-scannable. I just can’t see FAQs being the best way to help or inform people.

Any suggestions?

How about you guys? What little (or not so little) things are just plain wrong? Am I wrong about things being wrong? Salted popcorn – yes or no?

Last night, I was challenged to explain (and defend) content strategy. Three sheets to the wind after a pub quiz, this is no simple task, but I hope I acquitted myself passably. I say "hope" because there was a really interesting question I couldn't answer to my own satisfaction. I wonder if any of you folks out there in the ethereal internet hive-mind can help me out?

A friend - a rather concrete thinker who mathematically models complex biological systems for a living - pointed out that my examples were largely routed in business-to-business web sales and support. He challenged me with:

Say you've got a political website, so your goal is to have somebody read it and vote for you - how do you measure the effectiveness of that content?

Well, you would... umm... Oh dear.

I guess what we're talking about here, to yank it back to my present comfort zone, is a sales process where your point of conversion is off the site. The political example is perhaps a little below the belt, since what you can and can't do, and what data you can and can't collect is so restricted. You can't throw up a "How did you hear about this election?" questionnaire in the polling booth. Exit polls don't pull in your browsing history and site session information. Not everyone fatuously tweets and geo-tags each moment of their lives. Oh, and folks lie.

The business example might be easier to attack. You could have, say, a site for a farm shop that only did over the counter sales. Either way, it's tricky.

I fell back on some of the work I've done usability testing and benchmarking documentation, and suggested similar, quick and dirty, small sample qualitative UX trials. I'm not wholly sure that was right.

Any thoughts? How might we measure and curate for this kind of discontinuous conversion?