The workshop is called ‘Fast and Cheap Usability’. It’s targeted at people who haven’t done user testing before, and aims to give an overview of different techniques for testing different things, all of which can be undertaken at little cost (except for time: I will be emphasising that good user testing takes quite a bit of time: to recruit participants, to craft the tests, to run the tests, and to interpret and apply the results).
It’s a hands-on workshop, focused on getting people to try out the user testing techniques for themselves. We’re going to:
talk about how you can recruit testing participants (and who you should be trying to test)
run open and closed card-sorting exercises (to test how content should be organised in a website)
look at ways to assess the usability of content (such as comprehension testing, and uncovering what content is most important to users)
try some in-person testing (run live task-based tests for sample websites, including those of participants if they’re feeling brave/curious)
try some online testing tools (including our own IntuitionHQ)
I’ll also be promising people some useful links, so here they are. Some of them go back a few years (the article on card sorting – still my favourite introduction to the topic – is from 2004) but these have been gathered for people relatively new to user-testing:
And I was inspired by content strategist Kristina Halvorson and user testing expert Christine Perfetti when putting together the workshop – you should definitely put some time aside to check out their presentations from Webstock this year.
I’m currently writing new copy for the Boost website, which will be relaunching soonish with an updated look and a lot of new information. This has got me thinking about what’s changed about writing for the web in the 5 years that I’ve been doing this, and what’s stayed the same.
using the F-shape to stack the most important phrases in headings and the beginnings of paragraphs
writing tightly, avoiding padding and the passive voice.
Some things I think we’ve become a bit more relaxed about. We now trust people to scroll, and fret less about page length and getting content “above the fold” – a concept in itself becoming less and less relevant as the devices people use to view websites proliferate. (I have to include here my favourite text on scrolling.)
I’ve always had a bit of a bee-in-the-bonnet about link text. Thankfully, the days of ‘Click here’ seem to have passed, and people are writing link text that indicates where you’re going to be taken when you click. Generally, I prefer to be told/shown (and tell/show people) whether the link they’re about to click will keep them within the site they’re currently on, send them off to another site, or (pet peeve) trigger a PDF to start downloading.
Much as I love the Guardian‘s website, I’m often caught out by the behaviour of their links, which sometimes take you to another article, sometimes take you to an external site, and sometimes trigger a canned search. In the example below, ‘Internet Explorer’ triggers a search, ‘high-profile vulnerabilities’ is a link to another Guardian article, and ‘Responding’ and ‘an online petition’ go to two different external sites.
Links in a Guardian article: internal page, canned search, external sites
Then again. I often feel like a hypocrite when laying down the law for link text in a blog post. Blog posts, obviously, thrive on links, and often when putting a post together you use your link text in a slightly crafty way: linking to something incongruous to make a little joke, piling up a sentence full of evidence for your argument by pointing to differentpageswitheachword. Blog posts are – along with other forms of conversational writing driven by social media tools – part of the changes to classical/corporate web writing that I’ll come to at the end of this article.
Another rule that’s stood the test of time: avoid jargon and use of acronyms (the TLA is a recurring cause of WTF on the Internet). Don’t use a fancy word if a simple one will do. That said, I’m a fan of the New York Times‘ look-up feature: if you double click on a word, a small question mark appears, and then when you click on the question mark, a definition from the American Heritage Dictionary appears in a pop-up box. Sure, it’s a bit of an insider’s trick, but it’s simple and unobtrusive. Plus, they report back on the words that stump people the most.
New York Times article with the look-up box open
I think the moral of this blog post is that good practice has generally stayed the same when you’re writing for a website, particularly a corporate or government site. But with the introduction of social media, things have changed.
Blogging, tweeting, Facebooking: these new channels demanded new ways of talking with readers, rather than telling them stuff. And they introduced new challenges for people who write for the web. As Wellington web writing guru Rachel McAlpine observed in a recent blog post:
Yes, it’s true: some communication professionals are still unfamiliar with the working principles of content management systems, search engines, and accessibility. Some profess ignorance or horror when you mention Twitter, Facebook, or even blogging. They still haven’t noticed the C in ICT, or the technical in technical communicators. They barely know what the phrase social media refers to.
This is understandable if retirement is close. But tragically, some of these communication nuns are young, really young—in their twenties. Can you believe it?
First came blogging. For the first time, we were told that a personal voice – one that came from an actual identifiable individual – was important. More informal, sometimes opinionated, sometimes playful; the blogs you return to over and over again are the ones where you are intrigued either by the quality of the content or the quality of the writing.
Then came Facebook and Twitter. These demanded something else again. Timeliness became a new consideration: you have minutes to respond to a tweet. Brevity is obviously even more of a concern than it was with classical web writing, but then again, a number of newbies who I’ve shown Twitter to over the past few years have been surprised to see that “it’s not all in text-speak”. A real voice is even more essential than with blogging. When I started writing for the web, I would never have envisaged I’d be publishing things like this as part of my job:
Talking to people about digital collections on Twitter
What room does this leave for actual writing? Stylistic flourishes do not appear to be the book’s main concern. Instead, most advice is directed at generating more page views. All the guidelines have a hypothetical reader in mind—a reader who is constantly in a hurry, would never “jump hurdles” to find a piece of information, and must be roped in at all costs.
Writing for blogs and Twitter let me play again. Sure, the basics still apply. Spelling mistakes, grammatical errors, and unnecessary verbiage won’t do you any favours. But you can’t learn this kind of writing from style guides, just like you can’t grow a personality from self-help books. The people who write for you on the web – scratch that, the people who speakfor you on the web – are now found in your web team, your call centre, your development teams.
What interests me is when the two types of writing get mashed together. When you stream your tweets to your homepage, does one kind of writing make the other seem incongruous? Is your corporate site as fun to read as your Facebook page? Should it be? What do you think?
It’s been 5 months since we launched IntuitionHQ, our online usability testing application. We have not quite found the time to write a post about IntuitionHQ but will be writing a couple over the next few months to help you find ways to improve you design and your business with usability testing.
We have however been busy. Over the last couple of weeks we have spent some time identifying areas within IntuitionHQ where we can improve the user experience.
The first area we have focussed on is the test taking page. We evaluated the existing page and came up with a list of things we think the page needs to do in order of importance:
It has to be fast
The user must be able to clearly see the task they are being asked to perform
It needs to be clear where the site ends and the test page begins
Making the list from the user’s point of view was extremely valuable and gave us a clear understanding of what needed to be done.
Improving the speed of the page loads
We started by looking at each of the steps the page takes when loading. It soon became clear that the round trip to Amazon S3 where the images are stored was taking far to long. Further investigation showed that we were searching for the bucket based on the URL each time. Fixing this has brought significant speed gains. (more…)