Guerrilla usability testing at our open days

With thousands of potential students descending on campus for our open days last week, we had an ideal opportunity to get out ‘into the wild’ and carry out some guerrilla usability testing on the recently launched study at York pages, our new course pages, and a new homepage design that we’re working on

What’s different about guerrilla testing?

In guerrilla usability testing there isn’t a recruitment or screening process to find participants, you’re basically walking up to willing-looking strangers and asking if they’ve got a few minutes to spare. The tests can take place anywhere that you can find people - coffee shops, train stations, shopping centres, etc. Open days are ideal because everyone who comes to campus is going to be in our target demographic!

How we did it

Although guerrilla usability testing is a lot less formal than a lab-style usability test, we still used a script (cribbed from Steve Krug’s Rocket Surgery Made Easy) to make sure that our introductions covered the basics of who we were, what we were doing, how long it would take, and perhaps most importantly, that we would reward participants with chocolate.

Essential supplies for a bit of guerrilla website usability testing at #YorkOpenDay!

A photo posted by Paul Kelly (@itspaulkelly) on Jun 24, 2016 at 8:38am PDT

Before we got our participants to use the site, we asked them a few questions about the course they were hoping to study and what specific bits of information that they’d look for to help them decide if a course was right for them. We then asked them about other factors that would influence their decision to apply to a particular university. Based on their responses we came up with some scenarios on the fly.

What we tested

Over the course of the two open days we ran 17 tests, using both laptops and phones. Each test took around 10 minutes.

As well as course information, our participants looked for information on accommodation, the college system, the city, sport, societies and nightlife.

What we learned

• Everyone likes a Yorkie bar!
• Overall our participants were able to complete all the tasks that we gave them and liked the look of our redeveloped pages. 
• It was reassuring to see a lot of our assumptions validated, especially on our new course pages (eg BA Politics) - students found it easy to tell what they’d be studying each year, and really liked seeing authentic quotes from current students. 
• We got a lot of positive feedback about the in-progress new homepage design, with students liking how it looked, finding it “professional” and “welcoming”. One area that caused some confusion was the section on research, so we’ll be refining that further to make it clearer.
• We found a few small bugs to fix with how the site works on mobile. It’s on our roadmap to set up a device lab so that we’ll be able to catch things like this sooner.
• Several students used the main site search (rather than the course search) to find courses, which resulted in a much less direct path. There’s some work to be done to see how we can improve that.

We’ll definitely be doing this again. As well as the value of the testing itself, it’s always great to get out of the office and meet the users of our site.

Further reading

• The Art of Guerrilla Usability Testing Guerrilla testing - UX Booth
• Guerrilla testing - Government Service Design Manual

This week's screening: Rocket Surgery Made Easy by Steve Krug

Next up in our regular series of lunchtime digital screenings is a usability test demo by Steve Krug, author of Don't Make Me Think!: A Common Sense Approach to Web Usability and Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems (both essential reading!).

In this short video (25 minutes) Steve will run through an example usability test - if you've ever thought of running a usability test yourself but aren't sure what types of questions to ask, this is a great place to start.

Everyone welcome, feel free to join us in HG17 Heslington Hall this Wednesday at 1pm.

Building the York Research Database

Today we launched the brand new York Research Database to the public. This is a web view of all York's research activity, as stored in Atira's Pure, the University's CRIS (Current Research Information System). It's been a long time in gestation while the data has been cleaned and updated, but I think it's been worth the wait.

Encouraging discovery

Initially the Web Office's involvement was just to help skin the public view of the data that shipped with the product. We did that, but something felt lacking - if you knew what you wanted then you would find it, but then what? We wanted people to explore and discover the breadth and depth of the research going on at York, and our first implementation didn't quite nail that.

We worked closely with our local Pure project team and the team at Atira to build features that would encourage a deeper dive into the data. Development work was being handled by Atira so we went through several rounds of generating ideas, building mockups and then liaising with them about implementation. It was a great process, covering everything from adding big features to me being very pedantic about micro-copy in the pages, and the whole team at Atira were brilliant throughout.

Eureka

I confess I was sceptical when I first looked at web views of research data, both York's and at other Universities; they never really held my interest. My 'eureka' moment with our system came when I was testing the latest iteration of our work with Atira one day and realised I'd stopped testing and was just browsing computer science research. If the system could distract me from nitpicking about the design and features, I was confident it would encourage others to dig deeper too.

Features to help exploration

A few of the things we added to the vanilla product which I think make a big difference:

• 'Refine your results' links, with indicators to show how many results you'll get with that refinement applied, on search results pages. These just apply advanced search filters, but make them much more visible and easier to toggle on and off.
• 'By the same authors' and 'From the same journal' sidebars on publications pages. These are great for following a trail of related content.
• 'Recently viewed' links in the footer of every page. Each record in the database that you look at during a visit to the site stacks up in a series of lists in the footer of every page so that you can easily get back to the things you've seen already.

Links from staff profiles and department pages

Now that the York Research Database is live, we've enabled a field in the staff profile template in the CMS to make it easy to link to your profile page. There are more details on the Pure web pages for staff, including images to use to make links from departmental research pages and elsewhere too.

Measuring success

I'll be poring over Google Analytics in weeks to come to see whether we've managed to make the site as engaging as I hoped. You can let us know what you think in the comments, by tweeting us @uoywebteam or by emailing me direct at dan.wiggle@york.ac.uk.

Back to basics: No surprises please - links should do what users expect

Following on from the first ‘back to basics’ post about why you shouldn't use ‘click here’ as link text, I’m sticking with the link text theme.

This time, the thing to remember is that what happens when a user clicks a link should never be a surprise to them. Users expect links to lead to other web pages. If your link leads to something else and the link text doesn’t say so, that’s going to be a nasty surprise for the user.

We often create links to email addresses. These should include the email address in the link text because this gives a big clue about what the link is to. Instead of writing ‘To find out more, contact us’ and linking to an email address, try ‘To find out more, contact us at name@address.com’. You might reasonably expect the former to link to a contact form, but there will be no surprises what the latter one does.

Links to files such as Word, Excel, PDF or MP3 can also be unpleasant surprises, especially if they are large downloads. A user might not have the correct program to open the file, or they might prefer to not download a hefty PDF and start up Acrobat Reader if they can avoid it. Instead of writing ‘find out more about our module in widgets’, try ‘find out more about our module in widgets (PDF, 700kb)’. No surprises.
PS. If you’re using the University CMS, you get this one for free - the system labels your links for you :)

New windows are another common surprise for users. If you feel you absolutely must open a new window (even though usually I would advise that you don’t), it’s much better to say so: ‘see this other website (opens in a new window)’. Pop-ups can be frustrating and confusing for users, but they’re much less so if they know what’s going to happen before they click the link.

So, whenever you create a link always ask yourself ‘What would a user expect this link to do?’ and make sure you’ve crafted it to avoid surprises.

Back to basics - don't "click here"

A simple tip for the start of a new occasional series of ‘back to basics’ posts: Don’t use ‘click here’ as link text in your web pages. Ever.

This may be old news to seasoned web authors reading, but it’s one of the most common mistakes we see on the University website. Fixing it is one of the easiest ways to improve your web content.

A good summary of why ‘click here’ is bad circulated on Twitter a few weeks ago. I’ll not repeat the reasoning here, but definitely encourage you to read that article. It even quotes Tim Berners-Lee, inventor of the web, who encouraged good linking right from the birth of the web.

‘Read more’, ‘more details’ or just ‘more...’ are bad too, for similar reasons. Use descriptive, scannable links instead and you’ll have made a huge improvement to your web content for very little effort indeed.

More back to basics tips coming soon...

Update to freqently asked questions CMS template

If you're a CMS user you might have spotted that pages generated using the FAQ template have changed slightly in their appearance and behaviour, which should increase their usability a bit.

Before

Here's how they used to look. Clicking a question reveals the answer.



After

Here's how they look now:



Have a look at a live example on the Department of Physics website to see the full effect.

What's changed

• The answers now slide into place rather than instantly appearing. With the previous instant reveal there was always a chance of "blink and you'll miss it", and not quite noticing that the answer had appeared.
• The background colour and borders should help to tie the question and answer together - in the previous style it wasn't always clear where one answer ended and another question began, especially when the answer contained headings, or when FAQs have been used amongst normal page content.
  
• Minor change to font size and removal of underlines on headings to increase readability.
• The whole width of the question area is now a link, so there's a larger link target for people to hit.