Post-Mortem: Our First Usability Test

As you may have been aware from seeing the calls for participants here and on our Facebook/Twitter pages, we recently wrapped up our first round of usability testing on The Events Calendar. It was an interesting experience: we lined up 3 users from all different walks of WordPress life (all the way from a user with no real WP background to speak of to a seasoned developer), whose one shared trait was that they’d all never used The Events Calendar before.

The goal was simple: to bear witness to that pivotal first impression as users jump into the plugin, which we recognize is the one shot to truly make a mark. What could we do better, we wondered, to make it easier for users to quickly feel comfortable when they fire up The Events Calendar? More importantly, how can we keep people from immediately turning away out of frustration if they can’t figure out how to proceed?

By all indicators, the test was a great success — and we couldn’t be happier with the results. There were a number of common threads between these users: the recently-introduced “Events” admin bar menu, for example, was used far more commonly accessed than we’d expected it to be; and the Events-related menu options under Appearance –> Menus were so hard to find that nobody even knew they existed.

Ultimately, we came away from last Thursday’s tests with a number of notes and issues we want to address in upcoming releases. Here are the ones we’re working towards first, all direct results of our 3 UX test sessions and which are on the docket for our 2.0.8 release:

  • Right off the bat, it was apparent that finding the calendar on the frontend is not as easy as it should be. So as a result we’ll be adding an activation message that appears across the top of the page, immediately when a user first turns on the plugin, showing where the calendar lives (ie at siteurl.com/events). In addition, we’re including obvious “View Calendar” links on the events edit list and the settings main panel.
  • There was little (if any) context on the various Settings tabs for The Events Calendar, so users were unclear what pages like the “Template” tab actually did. To counter that, 2.0.8 will include info boxes — like those seen on the “General” tab — across the board on all tabs.
  • Not all support resources that users could want are listed under the “Help” tab on the Settings page….instead, users were manually going to the tri.be site for help. We’re adjusting the list of links to be more valuable as a result.
  • To be consistent with other plugins and to make the Settings page easier to find, we’ll be adding a link to it directly from the Plugins page on a site’s backend.
  • The Events-related options on Appearance –> Menus were in general confusing. We’re experimenting with a few tweaks to make these more visible and obvious from the get-go.
  • Since it wasn’t extremely obvious which events-related fields were required and which were not, asterisks will be added to required fields (start/end date & time) to clarify.

This is just the tip of the iceberg, of course. Now that we’ve seen what we can glean from these tests, we’ve got monthly sessions lined up on a number of issues covering The Events Calendar and it’s add-ons. Future tests will not be limited to first-time users; so if you’re interested in participating in a session and would like to be added to our list, please leave a comment below or shoot an email to pro /a/ tri.be. It’s worth mentioning that your time will not go uncompensated: all UX test volunteers are provided with a free license for whatever plugin they’d been testing.

Big thanks to our first 3 volunteers — Michelle, Garry and Evan — for their help.