|
|
Technical Author - Red Gate Software
-
Posted Monday, July 12, 2010 8:08 PM |
Technical Communication UK 2010 (#TCUK10 and @TCUK_conf for twitter folks) is, unsurprisingly, a large conference about tech comms. It's hosted by the ISTC, and last year is was diverse, informative, and generally moderately awesome. This year is shaping up to be no different. If you're at all interested in tech comms, info design, content strategy, and associated malarkey, I'd suggest taking a look. If nothing else, I'll be speaking, so you can heckle, mock, and generally abuse me in person. Here's a quick run-down of the sessions I'll definitely be going to, and why I think they sound awesome: Day 1: - Using web analytics to improve technical documentation
Rachel Potts' workshop on how to handle web analytics data properly. I don't think I'd be half as effective a technical communicator, or a quarter the content strategist without not only web analytics, but knowing their limitations.
I won't be about for the workshops, sadly, but this should be well worth a look. Day 2: - The spork/platypus average: content strategy at Red Gate Software
I can't really get out of being in the room for this one. Which is a pity in a way, since it's on opposite Zoe Rose's presentation on SCORM and designing content for e-learning. Zoe is voluble and engaging on all sorts of stuff in the e-learning, search,publishing, content, and metadata space. - Terminology - who cares?
I do, and so do most organizations that care about talking to their users/customers and having the faintest hope of being understood. This stuff is hard, and I'm hoping Jill's session will shed some light on how not to screw it up. - Everything you always wanted to know about psychology (and how it relates to technical communication) ... but were afraid to ask
Last year, Chris gave an entertaining, accessibly-academic presentation on the cognitive psychological background for information design and tech comms. More of this, please. - Documentation as an emotional experience for the user
Ellis Pratt on customer experience, engagement with technology, and how users have changed. I've never been to one of Ellis' presentations and not left with buckets of stuff to think about. - Wabi-sabi: co-creation and technical communications
You had me at the title. You definitely had me at ".stealing from Knowledge Management, Humantics, dungeon mastery, artificial language learning and Japanese cartographers". Again, this is an irksome clash, as it's up against Gordon McLean on social media. Day 3: - Information and Interpretation
I've also heard this billed as "embedded user assistance for forests". Neat. Also, information curation is a big deal. - Content strategy for everyone
David Farbey on content strategy. Probably more theoretical and less riddled with precocious grandstanding than my offering on the subject. - Questions and rants
Again, you had me at the title. So many conferences have an emergent theme, something in their subject matter's culture that is teased out over the course of the event. There's rarely time to talk about it outside hurried breakout sessions. Last year at TCUK, it was the social media "conversation". At the content strategy forum, it was the idea that maybe the we suck at being web-like. I'm hoping this will be a big, robust engagement with what's going in on in tech comms, and what's emerged from TCUK. So, yeah - some fascinating, eclectic stuff there. You can also find a one-page overview of the event on Gordon McLean's blog.
|
-
Posted Friday, May 14, 2010 10:18 AM |
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?
|
-
Posted Thursday, May 13, 2010 1:46 PM |
In April, Paris hosted the first ever Content Strategy Forum. The event's website proudly proclaims: 170 attendees, 18 nationalities, 17 speakers, 1 volcano... Content Strategy Forum 2010 rocked the world! The volcano was in Iceland, and the closest we came to rocking the world was a cursory mention in the Huffington Post, but I'll grant the event was awesome. One thing missing from that list, however, is "94 companies" (Plus a couple of universities and freelancers, and what have you). A glance through the attendees directory reveals a fairly wide organisational turnout - 24 students from two Parisian universities, countless design and marketing agencies, a series of tech firms, small and large. Two delegates from IBM, two from ARM, an appearance from RIM, Skype, and Facebook; twelve from the various bits of eBay. Oh, and, err, nobody from Google, Microsoft, Yahoo, Amazon, Play, Twitter, LinkedIn, Craigslist, the BBC, no banks I noticed, and I didn't spot a newspaper. You get the idea. Facebook notwithstanding, you have to scroll through a few pages to Alexa rankings to find company names from the attendee list. I find this interesting, and I'm not wholly sure what to make of it. Of the large, web-centric, content-rich organizations conspicuously absent, at least one of two things is true: - They didn't know about the event
- They didn't care about the event
Maybe these guys all have content strategy completely sorted, and it's an utterly naturalised part of their business process. Maybe nobody at say, Apple or Play.com ever publishes a single piece of content that isn't neatly tailored to their (clearly defined, of course) user and business goals. Wouldn't that be lovely? The thing is, in that rosy and beatific world, there's still a case for those folks to join the community. There are bound to be other perspectives, and things to learn. You see, the other thing achingly conspicuous by its absence was case studies. In her keynote address, Kristina Halvorson made the point that what content strategy really needs is some big, loud success stories. A point I'd firmly second as a content strategist working within an organisation. Sarah Cancilla's presentation on content strategy at Facebook included some very neat, specific examples, and was richer for it. It didn't hurt that the example was Facebook - you're getting impressively big numbers off base. What about the other big boys? Is there anybody out there with a perspective? Do we all just look very silly to you, fretting away over text and images and users and purposes? Is content validation and maintenance so accustomed a part of your business that calling attention to it is like sniffing the air and saying "Hmm, a lot of nitrogen about today."? And if it is, do you have any wisdom to share?
|
-
Posted Wednesday, April 14, 2010 10:44 AM |
Last night was the CS London group's event Content Strategy, Manhattan Style. Yes, it's a terrible title, feeling like a self-conscious grasp for chic, something sadly commensurate with the venue. Fortunately, this was not commensurate with the event itself, which was lively, relevant, and engaging. Although mostly if you're a consultant. This is a strong strain in current content strategy discourse, and I think we're going to see it remedied quite soon. Not least in Paris on Friday. A lot of the bloggers, speakers, and commentators in the sphere are consultants, or part of agencies and other consulting organisations. A lot of the talk is about how you sell content strategy to your clients. This is completely acceptable. Of course it is. And it's actually useful if that's something you regularly have to do. To an extent, it's even portable to those of us who have to sell content strategy within an organisation. We're still competing for credibility and resource. What we're doing less is living in the beginning of a project. This was touched on by Jeffrey MacIntyre (albeit in a your-clients kind of a way) who described "the day two problem". Companies, he suggested, build websites for launch day, and forget about the need for them to be ongoing entities. Consultants, agencies, or even internal folks on short projects will live through Day Two quite often: the trainwreck moment where somebody realises that even if the content is right (which it often isn't), and on time (which it often isn't), it'll be redundant, outdated, or inaccurate by the end of the week/month/fickle social media attention cycle. The thing about living through a lot of Day Two is that you see a lot of failure. Nothing succeeds like failure? Failure is good. When it's structured right, it's an awesome tool for learning - that's kind of how video games work. I'm chewing over a whole blog post about this, but basically in game-like learning, you try, fail, go round the loop again. Success eventually yields joy. It's a relatively well-known phenomenon. It works best when that failing step is acutely felt, but extremely inexpensive. Dying in Portal is highly frustrating and surprisingly characterful, but the save-points are well designed and the reload unintrusive. The barrier to re-entry into the loop is very low, as is the cost of your failure out in meatspace. So it's easy (and fun) to learn. Yeah, spot the difference with business failure. As an external content strategist, you get to rock up with a big old folder full of other companies' Day Two (and ongoing day two hundred) failures. You can't send the client round the learning loop - although you may well be there because they've been round it once - but you can show other people's round trip. It's not as compelling, but it's not bad. What about internal content strategists? We can still point to things that are wrong, and there are some very compelling tools at our disposal - content inventories, user testing, and analytics, for instance. But if we're picking up big organically sprawling legacy content, Day Two may well be a distant memory, and the felt experience of web content failure is unlikely to be immediate to many people in the organisation. What to do? My hunch here is that the first task is to create something immediate and felt, but that it probably needs to be a success. Something quickly doable and visible - a content problem solved with a measurable business result. Now, that's a tall order; but scrape off the "quickly" and it's the whole reason we're here. At Red Gate, I've started with the text book fear and passion introduction to content strategy. In fact, I just typo'd that as "contempt strategy", and it isn't a bad description. Yelling "look at this, our website is rubbish!" gets you the initial attention, but it doesn't make you many friends. And if you don't produce something pretty sharp-ish, it's easy to lose the momentum you built up for change. The first thing I've done - after the visual content inventory - is to delete a bunch of stuff. About 70% of the SQL Compare web content has gone, in fact. This is a really, really cheap operation. It's visible, and it's powerful. It's cheap because you don't have to create any new content. It's not free, however, because you do have to validate your deletions. This means analytics, actually reading that content, and talking to people whose business purposes that content has to serve. If nobody outside the company uses it, and nobody inside the company thinks they ought to, that's a no-brainer for the delete list. The payoff here is twofold. There's the nebulous hard-to-illustrate "bad content does user experience and brand damage" argument; and there's the "nobody has to spend time (money) maintaining this now" argument. One or both are easily felt, and the second at least should be measurable. But that's just one approach, and I'd be interested to hear from any other internal content strategy folks about how they get buy-in, maintain momentum, and generally get things done.
|
-
Posted Wednesday, March 17, 2010 1:28 PM |
There was one of those little laugh-or-cry moments recently when I heard an anecdote about content strategy failings at a major online retailer. The story goes a bit like this: successful company in a highly commoditized marketplace succeeds on price and largely ignores its content team. Being relatively entrepreneurial, the founders are still knocking around, and occasionally like to "take an interest". One day, they decree that clothing sold on the site can no longer be described as "unisex", because this sounds old fashioned. Sad now. Let me just reiterate for the folks at the back: large retailer, commoditized market place, differentiating on price. That's inherently unstable. Sooner or later, to keep growing, they're going to need one or both of competitive differentiation and process optimization. I can't speak for the latter, since I'm hypothesizing off a raft of rumour, but one of the simpler paths to the former is to become - or rather acknowledge that they are - a content business. Regardless, they need highly-searchable terminology. Even in the face of tooth and claw resistance to noticing the fundamental position content occupies in driving sales (and SEO) on the web, there's a clear information problem here. Dilettante taxonomy is a disaster. Ok, so this is a small example, but that kind of makes it a good one. Unisex probably is the best way of describing clothing designed to suit either men or women interchangeably. It certainly takes less time to type (and read). It's established terminology, and as a single word, it's significantly better for web readability than a phrasal workaround. Something like "fits men or women" is short, by could fall foul of clause-level discard in web scanning. It's not an adjective, so for intuitive reading it's never going to be near the start of a title or description. It would also clutter up search results, and impose cognitive load in list scanning. Sorry kids, it's just worse. Even if "unisex" were an archaism (which it isn't), the only thing that would weigh against its being more usable and concise terminology would be evidence that this archaism were hurting conversions. Good luck with that. We once - briefly - called one of our products a "Can of worms". It was a bundle in a bug-tracking suite, and we thought it sounded terribly cool. Guess how well that sold. We have information and content professionals for a reason: to make sure that whatever we put in front of users is optimised to meet user and business goals. If that thinking doesn't inform style guides, taxonomy, messaging, title structure, and so forth, you might as well be finger painting.
|
-
Posted Thursday, March 04, 2010 2:32 PM |
Cognitive fluency is - roughly - how easy it is to think about something. Mere Exposure (or familiarity) effects are basically about reacting more favourably to things you see a lot. Which is part of why marketers in generic spaces like insipid mass-market lager will spend quite so much money on getting their logo daubed about the place; or that guy at the bus stop starts to look like a dating prospect after a month or two. Recent thinking suggests that exposure effects likely spin off cognitive fluency. We react favourably to things that are easier to think about. I had to give tech support to an older relative recently, and suggested they Google the problem. They were confused. They could not, apparently, Google the problem, because part of it was that their Google toolbar had mysteriously vanished. Once I'd finished trying not to laugh, I started thinking about typography. This is going somewhere, I promise. Google is a ubiquitous brand. Heck, it's a verb, and their recent, jaw-droppingly well constructed Paris advert is more or less about that ubiquity. It trades on Google's integration into any information-seeking behaviour. But, as my tech support encounter suggests, people settle into comfortable patterns of thinking about things. They build schemas, and altering them can take work. Maybe the ubiquity even works to cement that. Alongside their online effort, Google is running billboard campaigns to advertise Chrome, a free product in a crowded space. They are running these ads in some kind of kooky Calibri / Comic Sans hybrid. Now, at first it seems odd that one of the world's more ubiquitous brands needs to run a big print campaign in public places - surely they have all the fluency they need? Well, not so much. Chrome, after all, is not the same as their core product, so there's some basic awareness work to do, and maybe a whole new batch of exposure effect to try and grab. But why the typeface? It's heavily foregrounded, and the ads are extremely textual. Plus, don't we all know that jovial, off-beat fonts look unprofessional, or something? There's a whole bunch of people who want (often rightly) to ban Comic Sans I wonder, though. Are Google trying to subtly disrupt cognitive fluency? There's an interesting paper (pdf) about - among other things - the effects of typography on they way people answer survey questions. Participants given the slightly harder to read question gave more abstract answers. The paper references other work suggesting that generally speaking, less-fluent question framing elicits more considered answers. The Chrome ad typeface is less fluent for print. Reactions may therefore be more considered, abstract, and disruptive. Is that, in fact, what Google need? They have brand ubiquity, but they want here to change accustomed behaviour, to get people to think about changing their browser. Is this actually a very elegant piece of persuasive information design? If you think about their "what is a browser?" vox pop research video, there's certainly a perceptual barrier they're going to have to tackle somehow.
|
-
Posted Friday, February 19, 2010 5:14 PM |
A lot has been written about how driving content strategy from within an organisation is hard. And that's true. Red Gate is pretty receptive to new ideas, so although I've not had a total walk in the park, it's been a hike with charming scenery. But I'm one of the lucky ones. Lots of people are involved in content, and depending on your organisation some of those people might be the kind who'll gleefully call themselves "stakeholders". People holding a stake generally want to stick it through something's heart and bury it at a crossroads. Winning them over is not always easy. (Richard Ingram has made a nice visual summary of how this can feel - Content strategy Snakes & ladders - pdf ) So yes, a lot of content strategy advocates are having a hard time. And sure, we've got a nice opportunity to get together and have a hug and a cry, but in the interim we could use a hand. What to do? My preferred approach is, I'll confess, brutal. I'd like nothing so much as to take a scorched earth approach to our website. Burn it, salt the ground, and build the new one right: focusing on clearly delineated business and user content goals, and instrumented so we can tell if we're doing it right. I'm never getting buy-in for that, but a boy can dream. So how about just getting buy-in for some small, tenable improvements? Easier, but still non-trivial. I sat down for a chat with our marketing and design guys. It seemed like a good place to start, even if they weren't up for my "Ctrl-A + Delete" solution. We talked through some of this stuff, and we pretty much agreed that our content is a bit more broken than we'd ideally like. But to get everybody on board, the problems needed visibility. Doing a visual content inventory Print out the internet. Make a Wall Of Content. Seriously. If you've already done a content inventory, you know your architecture, and you know the scale of the problem. But it's quite likely that very few other people do. So make it big and visual. I'm going to carbon hell, but it seems to be working. This morning, I printed out a tiny, tiny part of our website: the non-support content pertaining to SQL Compare I made big, visual, A3 blowups of each page, and covered a wall with them. A page per web page, spread over something like 6M x 2M, with metrics, right in front of people. Even if nobody reads it (and they are doing) the sheer scale is shocking. 53 pages, all told. Some are redundant, some outdated, some trivial, a few fantastic, and frighteningly many that are great ideas delivered not-quite-right. You have to stand quite far away to get it all in your field of vision. For a lot of today, a whole bunch of folks have been gawping in amazement, talking each other through it, peering at the details, and generally getting excited about content. Developers, sales guys, our CEO, the marketing folks - they're engaged. Will it last? I make no promises. But this sort of wave of interest is vital to getting a content strategy project kicked off. While the content strategist is a saucer-eyed orphan in the cupboard under the stairs, they're not getting a whole lot done. Of course, just printing the site won't necessarily cut it. You have to know your content, and be able to talk about it. Ideally, you'll also have page view and time-on-page metrics. One of the most powerful things you can do is, when people are staring at your wall of content, ask them what they think half of it is for. Pretty soon, you've made a case for content strategy. We're also going to get folks to mark it up - cover it with notes and post-its, let us know how they feel about our content. I'll be blogging about how that goes, but it's exciting. Different business functions have different needs from content, so the more exposure the content gets, and the more feedback, the more you know about those needs. Fingers crossed for awesome.
|
-
Posted Friday, February 12, 2010 3:51 PM |
Have a look at this Read Write Web article, specifically the paragraph in bold and the comments. Have a wry chuckle, or maybe weep for the future of humanity - your call. Then pause, and worry about information architecture. The short story: Read Write Web bumps up the Google rankings for "Facebook login" at the same time as Facebook makes UI changes, and a few hundred users get confused and leave comments on Read Write Web complaining about not being able to log in to their Facebook accounts.* Blindly clicking the first Google result is not a navigation behaviour I'd anticipated for folks visiting big names sites like Facebook. But then, I use Launchy and don't know where any of my files are, depend on Firefox auto-complete, view Facebook through my IM client, and don't need a map to find my backside with both hands. Not all our users behave in the same way, which means not all of our architecture is within our control, and people can get to your content in all sorts of ways. Even if the Read Write Web episode is a prank of some kind (there are, after all, plenty of folks who enjoy orchestrated trolling) it's still a useful reminder. Your users may take paths through and to your content you cannot control, and they are unlikely to deconstruct their assumptions along the way. I guess the meaningful question is: can you still support those users? If they get to you from Google instead of your front door, does what they find still make sense? Does your information architecture still work if your guests come in through the bathroom window? Ok, so here they broke into the house next door - you can't be expected to deal with that. But the rest is well worth thinking about. Other off-site interaction It's rarely going to be as funny as the comments at Read Write Web, but your users are going to do, say, and read things they think of as being about you and your products, in places you don't control. That's good. If you pay attention to it, you get data. Your users get a better experience. There are easy wins, too. Blogs, forums, social media &c. People may look for and find help with your product on blogs and forums, on Twitter, and what have you. They may learn about your brand in the same way. That's fine, it's an interaction you can be part of. It's time-consuming, certainly, but you have the option. You won't get a blogger to incorporate your site navigation just in case your users end up there, but you can be there when they do. Again, Anne Gentle, Gordon McLean and others have covered this in more depth than I could. Direct contact Sales people, customer care, support, they all talk to people. Are they sending links to your content? if so, which bits? Do they know about all of it? Do they have the content they need to support them - messaging that funnels sales, FAQ that are realistically frequent, detailed examples of things people want to do, that kind of thing. Are they sending links because users can't find the good stuff? Are they sending précis of your content, or re-writes, or brand new stuff? If so, does that mean your content isn't up to scratch, or that you've got content missing? Direct sales/care/support interactions are enormously valuable, and can help you know what content your users find useful. You can't have a table of contents or a "See also" in a phonecall, but your content strategy can support more interactions than browsing. *Passing observation about Facebook. For plenty if folks, it is the internet. Its services are simple versions of what a lot of people use the internet for, and they're aggregated into one stop. Flickr, Vimeo, Wordpress, Twitter, LinkedIn, and all sorts of games, have Facebook doppelgangers that are not only friendlier to entry-level users, they're right there, behind only one layer of authentication. As such, it could own a lot of interaction convention. Heavy users may well not be tech-savvy, and be quite change averse. That doesn't make this episode not dumb, but I'm happy to go easy on 'em.
|
-
Posted Tuesday, February 02, 2010 3:09 PM |
"Technical communications" is, let's be honest, quite a vague term. I think this is fantastic. More than that, I think it's important. Some folks don't agree. I'm deeply baffled as to why. What a technical communicator isn't In a discussion about what constitutes technical communications experience, the phrase "Ergonomics is not technical communication" popped up. It's an assertion you could probably argue with. But I'm not convinced it would serve any more purpose than asserting it in the first place. That a dog is not a duck utterly fails to help me if I have a problem that requires more than or subsets of dogness or duckness. The - not unreasonable - rationale was that ergonomics doesn't typically share much by way of output with something like technical authoring or illustration. The equally reasonable rejoinder is that an ergonomist with enough interest in technical communications to want to call themselves a technical communicator might well have something to contribute. They might be experiencing a creep/overlap/expansion of role comparable to the shift from all-paper tech author to online information designer. I've always felt it's this very vagueness that the term "technical communicator" was coined to handle. It's an umbrella term. It's deliberately not "technical author", though it may have evolved from there. It's inclusive with plenty of space to spare, because technical authors (or illustrators, or information architects, or oh, I don't know, gibbons that really like graphs) are evolving into plenty of spaces. So what do we do, really? By that, I don't mean to ask what our "deliverables" are. Paper manuals, web pages, pop-up books, video tutorials, or a subtly nuanced aria reflecting the intricacies of a database schema - none of these are more or less valid, and all are broadly irrelevant. What we do, when we get down to it, is produce user-optimised information to meet business needs. That's pretty vague, but it needs to be. It needs to be vague because the best combination of user and business needs might well be served by a quick-start flashcard in one case and a twenty minute mime in another. Now, it happens that lots of us do this by writing, but our professional body isn't the Accredited Technical Authors Club. The ISTC (UK) and STC (International) are a wee bit broader than that. Professionally, we enable people to understand and do things. And we're a long way from being alone. Technical communication, information architecture, user interaction design, marketing, content strategy, and any number of other disciplines are ways of labelling aspects of this process. There goes the neighbourhood Interestingly, the ISTC rule book says "technical communications" can ".also include visual, aural, tactile or other means of conveying the said information". So it's, umm, communications, then. And there's a much, much more sensible discussion of that on Rachel Potts' blog To have such a wide definition is to accept that, for example, should I produce a felt collage that attempted, by texture, to fully evoke the feeling and process of installing Apache on a server, it would, if it succeeded, be an acceptable act of technical communication. This is not merely silly, it's controversial. To me, the disagreement feels a bit like the tired old "is it art?" argument: a sniffy and patrician red herring. It's in a gallery: it's art. That wasn't ever a meaningful question, and the definition isn't where the value lies. The useful questions are: What are its meanings? Does it add anything to the culture? Is it interesting? Does it provoke powerful reactions? Early critics of Duchamp's Fountain more or less became part of its meanings by bickering about its validity. They are not widely remembered as noble guardians of cultural integrity. So what are we doing by trying to define a technical communicator? Are we trying to get better at making information, or are we chalking "no girls" on the side of the tree-house? I asked Twitter. My favourite response came from John Ellam: "Title's not important. I did not have to buy a license to do my job. Work produced is key" I agree. A rigorous definition seems to serve little purpose unless you've some peculiar vested interest in issuing that license. Doing technical communications is increasingly about doing whatever your organisation needs done to the information it presents to its users. As those organisations wake up and smell the content strategy, the role is only going to get fuzzier and more important. Is there a case for a license? Yes. The exact same case as for requiring a spelling and grammar test before letting people post on an internet forum, and with comparable practicality and odds of success. Robust accreditation is one heck of a proposition. My solution: we take a cue from IBM and re-brand as "Information developers". Then have a whip-around to fund some bus ads: "There is probably no such thing as a technical communicator; stop worrying and get on with your lives."
|
-
Posted Monday, January 11, 2010 11:45 AM |
Most surveys suck. Think about how many you've seen and just sighed, or clicked away from in frustration, or struggled to understand. They suck. Partly, this is because survey design is hard - requiring sound statistical and research methodological experience, and a grasp of information design. Partly. You can make surveys suck a whole lot less by doing two really, really basic things: - Think about how your user thinks, and if possible don't make them do it at all
- Sort out the writing
The first one is the really, really important one. The second one is just getting it across. Ask a silly question 
Yes, it's a pathological example, but it's quite closely based on a survey I came across last week. The survey designer here clearly wants nice, clean, quantitative data about users' creature nibbling predilections. Who wouldn't. Problem is, they don't seem to care about how much cognitive load they impose to get it. Most folks don't have quantitative breakdowns of all their behaviours on the tips of their tongues, and in this case they're being asked for one in a madly counterintuitive way. It takes too long to parse the question, much less answer it. I'm going to take a wild guess and suggest that this kind of thing typically happens when people lose sight of a vey well-worn usability cliché: remember your user isn't you. For surveys this means the information you want isn't necessarily something you can ask them for directly. They are likely to understand things differently, and almost certain not to share your grounding assumptions. Terminology Make sure you're phrasing things in a way the users think about them. (Why are the number of legs important, and what does that mean about implicit categories?). For instance, being British, I might be expecting a totally different kind of answer to most Americans if I asked a question about "football". More usefully, do the way your users experience your business, and the way you talk about it match? Here at Red Gate, two of our business divisions are SQL Developer Tools and DBA Tools. If we asked somebody, say, "What is your most used Red Gate DBA tool?", they'd be well within their rights to answer "SQL Data Compare". That's a fairly toothless example (and the "wrong" answers might themselves be interesting) but you get the idea. Use their terminology over yours. And if that means you have to do some thinking at the end, tough. If the question isn't instantly easily intelligible, you'll get lousy data. Again, thinking is your job, not the users'. (As a side-note, psychometric tests are a fascinating counterexample. Many are riddled with weirdly obscure assumed categories, requiring you to decide if you're more "Mauve and insouciance" or "goal-oriented and butterscotch". Personally, they just make me incredibly angry. Presumably some subtle wizardry is going on) Instructions We've got a smug adage in technical communications: if it's hard to explain, it's probably hard to do. A survey question that runs into multiple sentences is probably badly-phrased or overloaded, or both. If it really needs to be that complicated, make sure you use line breaks, and every trick you know to make it easier to read. In our bad example, "Choices must add up to 10" is foregrounded, it's the first thing you read. Which, for a second leaves you with no idea of what choices or why. It's just in the wrong place - its predicate hasn't yet been established. It's also by no means the most important part of the instructions. In practice, you'd re-write the whole thing: 
It's not quite the same question, sure, but it's massively simpler, and it's phrased in terms people can easily visualise. Also, concrete units that readily relate to users everyday experiences make questions much simpler to answer. If we'd asked them, for instance, to estimate goat consumption in tonnes per financial year, or assign twenty-two billion points rather than ten, we'd have lost them even more. Quick wins Sometimes I edit surveys. The big scary stats stuff isn't quite my field, but this is what I do to the words: - Paragraphs and line breaks
These are critical for ease of reading. People skim web text, so don't make it dense. Most of what I do when somebody asks me to edit a survey is breaking up the text. - Don't say please
Get right to the point in the fewest words possible. Avoid "Please supply your email address so we can contact you". "Email (optional):" will do. - No maths
If you must make me think, don't make me add up. Try and re-frame the question. - Keep it on one page
Or few, rationally grouped pages. - Keep it short
Every extra question raises the dropout rate. It's probably also worth keeping each page's content above the fold. - Make sure questions aren't leading (unless they need to be)
You can get some real gems from those "Any other feedback" style free-text fields. But you mostly get nothing. It can be worth adding some gentle suggestions. Any other tips for making surveys less soul-destroying?
|
-
Posted Monday, January 04, 2010 12:25 PM |
The discipline of theodicy is a branch of theology and philosophy. It attempts to reconcile various belief systems with the existence of evil. By way of a simple - if fatuous - example, it addresses questions like why a god might allow bad things to happen to good people. A certain kind of cynic might conclude that this amounts to a system of conceptual pussyfooting and complex evasions - a way for spiritual thinkers to avoid the conclusion that there is at least no loving god, if indeed any to speak of. That, rather obviously, is beyond the scope of this blog. But the world of web design, usability, information design, and so forth is a little simpler. It has a problem of evil all of its own; and I have no qualm at all concluding that anybody building a pure Flash help portal is not a loving designer, if indeed any designer to speak of. I recently encountered a couple of all-Flash support portals, and they made me sad. One of them was the subject of a conference presentation. An hour on how to use the help. Gosh. Problems of evil Let's assume you're not completely ignorant of human behaviour on the internet. Let's also imagine you create a knowledge base article on, say, a specific error message in your new product. You get the basics right - you call it "Error code 38Q when using the SuperFuntime-Widget-o-Matic", it has clear headings, concise content, and a code snippet to help the user with a workaround. You then decide to deliver this article in a Flash portal. - What if the user can't right click, then cut and paste the code snippet, but is instead offered the wonderful opportunity of learning more about Adobe Flash Player?
- What if a user types "38Q error SuperFuntime-Widget-o-Matic" into Google and doesn't get your article?
- What if a user with an immediate problem has to sign in, wait 30 seconds for the site to load, and laboriously browse a non-standard interface to your article?
- What if a user has IE 6, with Flash player 5, in heavily locked down conditions?
If any of these things happen, you haven't helped them properly. You knew, or could reasonably be expected to have known about that. You have done something bad. Worse luck, it turns out the SuperFuntime-Widget-o-Matic makes shoes for orphans, but a 38Q error means it's now killing kittens. Christmas is ruined, and it's YOUR FAULT. Seriously, though: how are you going to reconcile a broken Flash portal with your values as a content/information professional? (yes, yes, they're not all broken...) Well, there are some things you can try to get right, if you're absolutely set on having a Flash interface. Path of least surprise Web pages have been around for a while now. Users, you know, understand what a web page is. Web pages have accustomed behaviours around navigation, information architecture, and to an extent functionality. Users often also, get to web pages from other web pages. There are contexts and expectations. If you really think you know better, you need to make damn sure you're right. I point this out because when you deviate from very well established user interaction norms, people find stuff harder to use. When you surprise them, they don't like it. There's a reason "how did you expect it to work?" is one of the more asked questions in usability testing. It's also worth remembering that folks are often already a bit fraught when they go looking for help. Try to impose no extra stress. You don't get very far by making people struggle. So if you're going to take somebody who's looking for information from a web page to a flash interface, you'd better make sure: - The navigation conventions are upheld
- Contexts are obvious
- It's quick to get in and out
- You still preserve best practices for web writing
- It's really, really, invisibly fast
- They can open everything in a new tab
I'm going to bang on about that last one. What do you think a right click menu is for, I wonder, Mr Flash Portal Designer? Conventional wisdom says it might be, oh, I don't know, a context menu. It might contain things you want to do quickly in a specific context. Things like copying text, something nifty form a Firefox plug-in, or just opening a link in a new tab. You almost certainly do not, when hovering over a promising-looking link, want "About Adobe Flash Player 10." Nobody wants that. Ever. Get it fixed. Loading times Some flash sites are a bit slow. Particularly if they're trying to do a lot. I've alluded, in blog after blog, to the fact that nobody wants to be in your help system. They want the fastest possible solution to their problem, and the one that takes them away from their workflow the least. It is utterly, utterly incumbent upon us to give assistance-seeking users the help they need as quickly and as obviously as we possibly can. Make titles useful, keep cognitive load low, and make it easy to get in. Paywalls, fancy designs, perceptible loading times, mandatory decisions - often really, really bad. Visibility from Google People use search. I'm fairly certain about that one. Rather than navigating your help system, many users will hammer the shape of their problem into Google, and expect to get your specific help, along with blog or forum solutions from other users. They'll then pick the likely looking ones (they might even right-click to open multiple tabs.). - If your content isn't visible to Google, it doesn't exist for a whole bunch of users.
- If your content isn't visible from Google, it's harder for users to get in and out quickly without deviating from accustomed behaviour.
- If your content isn't visible form Google, you'd better make damn sure your own search was built by magic space ninjas.
It's only fair to admit here that yes, if you're charging for support content, you don't necessarily care about or need search visibility. Although complete invisibility may not be the best way to show off your value. ...Or just don't use Flash Not for the whole UI, at any rate. I'm by no means holding it up as a paragon, but Google Wave is choc full of fruity functionality whilst still behaving broadly like a web page. Let's face it, web pages actually aren't that bad for delivering structured textual information. If you really want a certain set of bells and whistles, you could build an AIR app, I guess. If you're going to use flash, you should probably use it for this
|
-
Posted Thursday, December 17, 2009 1:21 PM |
In my last post, I offered a quick example of how to spot misbehaving content. Analytics are a great tool for showing you the suspects, but it takes a bit of work to pick the really bad content out of the line-up. To overload the metaphor yet further, this becomes a prime time forensic drama, complete with whizzy lab equipment, and an avuncular serial killer if the content in question has no known purpose. Typically, you'll start with a content inventory (or audit, or whatever) to tell you what you have. Then the analytics give you the warning signs, then you have to read stuff in detail, and think about how it relates to other content, business goals, user needs, house styles, and of course if it's at all well-written. Since one of the things we're trying to do here is reduce the time spent creating, maintaining, and generally chasing after the specious claptrap that passes for so much web content, this isn't ideal. Here at Red Gate, we've just launched the Schema Compare for Oracle early access program. It's a brand spanking new tool; so we've got a fresh start with the content. One of the things that's quite exciting about the project is just how involved various parts of the business have been. We're normally pretty good at this, to be fair. But with Schema Compare for Oracle (I wish we could have found a shorter name) as well as close involvement from product management and support, our brand manager has been more or less part of the development team. Technical authors have been part of the development team at Red Gate for a while now. When that started, it made a huge difference. From where I'm sitting (surrounded by developers, testers, and UX) this feels like the next step. We've been able to work together on content, so we've had an idea of what we need, why we need it, and how we'll know if it works. The traditional boundary between the "product" end of our website as owned by marketing, and the "supportcentre" end as owned by technical communications has become deliciously fuzzy, with both of us offering expertise to ensure the content is as good as it can be. In fact, we've been quite explicit about this. We're doing it backwards - content inventory first. Of course, it isn't actually backwards. Spending a week trawling through web pages just to work out what you've actually got on your site is the backward part. We'd rather track what we do, as we do it. So come the release of say, version 12, we'll still be able to point to any piece of content, and tell you what it's for, how we expect to know if it's any good at it. It's nothing flash, just a table: | What is it? | What's it for? | How do we know if it's any good? | | Product page | Get people to try the EA, give them basic information, direct them to more detailed information. | They try the EA. The other linked pages get traffic from here. | | Help landing page | Known issues & prerequisites. | Few calls/posts/questions/complaints on stuff we know is wrong, or problems installing and with first use. | | Feedback form | Let people tell us general stuff: feature requests, broad feedback. | Lots of responses. Most are useful. Few are about existing issues. | | Support forum | Let people tell us specific stuff. Make fixes and workarounds publically visible. Tell users about subsequent releases. | We get detailed, new, bug reports and UX feedback. | | Email updates | Get people to the product page (because they think SCO could help them) | Good traffic to the product page from emails. | | Walkthrough | Help users who've never seen a Red Gate tool get started. | Page gets used. Little poor feedback on getting started. | It's a bit rough and vague, I'll admit, and the proof of value will only come from actually making measurements and curating accordingly, but it feels like a heck of a start. There's a conspicuous missing column, too: "is it any good?". It's really too early for that. The early access release has been out in the wild for only a few days now. The numbers are looking cautiously promising, but it would be easy to get specious. Viewing the product page generally leads to downloads, and it looks like people are reading the help and walkthrough content. At this stage, it's harder to know how useful they're finding those, but we're getting relatively few gripes about the things those pages cover. Again, I can't claim any causal relationship there. We know more or less what we're looking for, and we'll evaluate the content once it's been out there a bit longer. There's an editable version of this on our internal wiki. I'm hoping it gets updated, and that we continue to find it useful. It may well be that this isn't the best way to track our content. I can certainly see it being unwieldy. After all, the SQL Compare content inventory is already a 40 row spreadsheet, and probably about half done. I freely admit, I'm making a lot of this up as I go along. Any tips?
|
-
Posted Tuesday, December 15, 2009 2:26 PM |
I've talked a lot about content strategy lately. Let's do some. Here's a whistle stop example of drilling into some of our web content using Google Analytics, and asking those questions: what's it for, and is it any good at it? Today's victims are the SQL Compare "case studies": short articles outlining how SQL Compare has been used by some of our customers to solve their problems. In principle, they're fantastic. They could show real, complex problems, and solve them in a useful, portable way, at once making a sales case and offering assistance. I love this type of messily liminal technical/marketing content. You know the deal - the stereotypical technical author writes help to solve a user's problem with a tool; the stereotypical marketing writer comes up with copy about how the tool solves the user's business problem. Then there's the fun middle ground where knowing how to use the tool to solve the business problem is big and complex and needs to be true, but is also the best way to sell. Quite often, this is where bad writing lives. Not least because in a pre content strategy culture, getting it right doesn't look like any one person's job. That, or the here be dragons factor. Example Preaching aside, we've got some case studies. They seem like a good idea, and their usage stats look a bit like this: 
I've marked up one or two of the obvious questions. Some of this content is either irrelevant or invisible to its intended users. The stuff that gets found has problems. Analytics at this high level don't give me that much detail, but they signpost content behaving oddly. What's wrong with this picture? Well, let's look at number 10 there. I'm fairly sure that if we ever did know what the page was for, but only eight people viewed it this year, and for rather less time than it takes to read, something is broken somewhere. There are a few options: - Irrelevant and invisible?
There's a quick fix - we could put it out of its misery. If it's only one of those things, we have less fun: we have to understand it in a fair bit of detail. - Irrelevant and visible?
It shouldn't have been created in the first place, or should have been modified as soon as that became obvious. - Relevant and invisible?
There are probably architectural and/or SEO issues we can address around visibility. Ideally, this would also have been caught by early curation. - It isn't both relevant and visible. We know that much.
So is it doing any harm? Now, perhaps not, but I don't know for sure, and it could be a missed opportunity. Those are the obvious culprits, but there are also two more: - Relevant, but looks irrelevant
Readers online are busy or fickle or both, and poorly designed information retains no attention to speak of. Structure, presentation, tone, scanability, all sorts of things play a part. - Irrelevant, but looks relevant
The evil twin, and what might be going on if there were high pageviews, with low time on page and/or high exit rates. Typically this means useful-sounding titles attached to utter twaddle. Content with those last two problems makes me sad. The first four, we can fix with curation - knowing what things are for, measuring success, and acting on it. The last two need informed creation - people sharing expertise to make sure that information is optimised for the needs of our users and our business. The content we're looking at is a few years old now, and picking on it like this is a bit unfair. But was it used back when it was created? Sadly, I don't have the data. I hope so. It's a miserable waste of time and resources otherwise. So what should we do - fix all the legacy content? That isn't cost effective for every page, although we could go for quick wins on pages that are visible. No, what we should do is not let this kind of thing happen in future, by making sure we create in an informed manner, and curate early and often. More information
|
-
Posted Monday, November 23, 2009 3:06 PM |
I read an interesting blog snippet a while ago about information visualizations and their capacity to set change our view of the world. It asks whether we as information designers have a moral responsibility to our users that governs how we model their worlds ("First, do no mimetic harm."). I feel like that about documentation sometimes: it's not ok to keep kicking the rescue dog, regardless of how used to that he is. I've spent a bit of time with the documentation for a very large, very serious and business-y product lately. We'll be doing something in a similar sphere. Some of it is loathsome. There's poor design, poor writing, typos, and inconsistencies. It's hard to navigate, and harder to get quickly into and out of if you have a specific workflow problem. And its users lap it up. They laud it; it's what they claim to want. This makes me sad. But is it better to pander to their lowered expectations, or take the moral high ground and give them help that, well, helps? At a glance, it's a no-brainer. Existing documentation in the sphere is "bad" (my definition, admittedly), and a user-centred approach is "good", so we'll do it the good way, right?. But the bad documentation has set the expectations. So by making something that looks like the existing offering of obtuse reference tomes, we'd look less threatening, less unusual, maybe more serious and credible. Could it, pathological though this may seem, even be more usable? In that blog post, Andrew Walkingshaw argues that information representations can shape experiences more powerfully than we might first realise. We know that a bad (or worse, misleading) documentation experience has a detrimental effect on a user's view of a product or brand, but what happens if the documentation is useful and true, but fails to match a pre-existing mental model? Do existing users really love the "bad" documentation, or are they just habituated to it, experiencing a contorted kind of of Stockholm Syndrome for manuals? It reminds me of a tweet a while ago, something like "If you knew it would increase revenue, would you change your website's font to Comic Sans?" There's a whole separate blog in that, but briefly, I'd want to know exactly what users were responding to, and why. I guess I feel just as queasy about high-handedly deciding I know what's best as I do about continuing to kick the puppy. It comes back to content curation again - if it isn't working as designed, we'll have to revisit and likely change it. Still, it's hard to know which way to go first.
|
-
Posted Tuesday, November 17, 2009 11:46 AM |
There's a technical communications email discussion list I'm part of. It has a bit of bickering about commas, sure, but also interesting things. Some of those things make me cranky. Recently, discussion turned to social networking, and I got quite, quite cross indeed. Essentially, there are technical authors who don't see the point of Twitter / LinkedIn / Facebook / Bebo / whatever. Fair enough, that's not a problem. There's a problem with the tone of, and assumptions underpinning some of these objections, however. Here's a (slightly straw-man) cross section: "Social networking tools are just toys for teenagers", "It's just time wasting", "My docs aren't on the internet, why should I care?", "You can't write a help system in 140 characters", "What possible relevance could Myspace have to my business?" (ok, you've got me there, especially if you're say, documenting avionics), or "Why do I have this friend request from a Russian hooker I've never even met?" Many of these arguments seem to issue from an assumed position of authority, often with a dismissive sneer. I can hardly criticise that, I suppose, but I'd prefer a more rational underpinning. If nothing to do with your product is on the internet, and none of your users care about it, then these may indeed not be the droids you're looking for. For the rest, there's a kind of causation/correlation problem. Lots of social networking tools do indeed appeal to young people. Young people are also often early adopters, and quite likely to make up a goodly chunk of any online user base. Like all humans, some of them are noisy. The loud, prolific contributors to any social forum, aside from tending to be quite a small group in most cases (see again Anne Gentle's book) set a lot of the tone for that forum. It would, in short, be quite easy to get the impression that Facebook is just about poking people, Myspace about emotional navel-gazing and eyeliner, Twitter about Bay Area hipsters flapping their lips in 140 character exhortations to buy ever skinnier jeans. It would be easy, and raises an easy smile, to be just as childishly dismissive as I was there. But there is no necessary equivalence between the platform and the idiot on the platform. However much the idiots annoy you, however nosily vacuous they may seem, there's a certain amount of messenger you oughtn't to shoot. An email discussion list is a social networking forum. When a comment annoys me, or I get some spam, or even when a tedious-sounding meeting request hits my inbox, I don't decry email. Email, like Twitter, Facebook, or even Livejournal is just the platform. Is it a toy for teenagers? Maybe, and it can certainly be a place where teenagers talk. But it's unlikely to be "just" that, and dismissing any new communications technology as a toy has a bad history of making you look silly in the long run. So what use is social networking to a technical communicator? Well, I could tell you to go read Anne's book, or Gordon's blog, or any number of things; but in short, it's about talking to your users and your peers. Technical Authors can use things like Twitter, LinkedIn groups, or even an email discussion list to share knowledge and experience. We can use more or less any social resource to gather information about the needs of our users, or even help them directly. We can, as the buzzwords currently go, "join the conversation." And we should, because it'll still happen if we don't. Plenty of organisations even provide some social resources. There are buckets of products documented on Floss Manuals, for example. Google SideWiki potentially offers social documentation for any product. Red Gate maintains Simple Talk, SQL Server Central, Oracle overflow, the Future of Monitoring, and our own forums - all to enable us to talk to users and users to talk to each other. What does enabling that enable? Apart from the raw social benefit of it being nice to talk to folk, people have knowledge to share, and needs we want to understand. For actual, useful information on this kind of thing:
|
|
|