UX design for the whole library

Coming home to a box of multiple copies of a book you wrote will never stop feeling awesome! Aaron and I wrote this book about user experience design for libraries back in 2012 and it’s finally out in real, deadtree form, the kind you can hold in your hands. It’s pretty cool. It was neat to flip it open and read the intro again, words we wrote over a year ago, and realize, hey, I like this book. I’m kind of proud of it.

You can pick up a copy for yourself or for your library from the ALA store (I wish we had some control over pricing because, damn, that’s spendy). Spoiler alert: all this UX stuff is not just for your website.

Microinteractions: Why you should sweat the small stuff

I’ve been writing a column on web design/UX for Access, the magazine of the Ontario Library Association, for the last five years (5 years! I had to double-check that to be sure, five years is a crazy long time) and I don’t think I’ve ever mentioned or linked to a single one of those articles here. I was reminded about one column in particular just last week when I experienced a series of pleasant microinteractions when ordering a book from A Book Apart — if you’ve ever ordered a book from them, you know what a streamlined, pleasurable experience that is, and all thanks to the attention they pay to the microinteractions in the checkout/purchase process. More on that in the article, reproduced below, first published in the Spring 2013 issue of Access.

Microinteractions: Why You Should Sweat the Small Stuff

About a week ago, I visited a publisher’s website to buy a couple of books. The publisher, A Book Apart, is a small, niche house that publishes books for web and interaction designers, and as such, their catalogue is quite small. When I got to the site, I easily found the two titles I was looking for, and went through the usual process to buy those titles, performing all the functions you’d expect from this type of interaction:

  • put titles in cart
  • click cart
  • add contact and shipping info
  • add payment info
  • click button to place order

All pretty routine, right? Except, something about the ordering process on that site stuck with me. Actually, it was a few somethings. For example, when I clicked a checkbox to indicate that my shipping address is the same as my billing address, the shipping address fields just disappeared. Then the drop-down box to choose my country appeared before the state/province drop-down selection (why is it usually reversed on most other shipping forms, anyway?). And when I got to the payment info, the first and last name fields were already filled in. And when I started typing in my credit card number, the form automatically selected the type of card I was using. (It’s no secret that all Visa card numbers start with 4, all MasterCard cards with 5, etc. So why aren’t all payment forms this smart?).

That sense of delight that was pulsing through me as I completed the book-ordering process was the result of what the design world calls microinteractions. Interaction designer Dan Saffer defines microinteractions as, “contained product moments that revolve around a single use case… Every time you change a setting, sync your data or devices, set an alarm, pick a password, log in, set a status message, or favourite or “like” something, you are engaging with a microinteraction.”

Do you remember the last time you hit the mute button on your mobile device? That was a microinteraction with your phone. Or the last time you turned up the brightness on your e-reader? That was a microinteraction with your e-reader. Or the last time you turned down the steam setting on your iron? That was a microinteraction with your iron. Or the last time you filled a glass of water from the water dispenser on your fridge? You guessed it: that was a microinteraction with your fridge.

As Saffer’s definition points out, microinteractions are single-task interactions with any device or interface, and we likely have a million of them in a single day. If you don’t notice a microinteraction, it’s probably because it just works the way it’s supposed to. When you do notice a microinteraction, it’s either because it’s a delightful experience (as my book- ordering), or more likely, something that annoys or frustrates you.

Speaking of annoying and frustrating, you might want to turn your attention to your library website for a moment and think about all the millions of microinteractions there that have the potential to annoy, frustrate, or delight your users. Is the sheer number of microinteractions on your site causing you to go into a mild panic? Or are you tempted to ignore all those microinteractions for the moment because your website has bigger problems that need fixing?

In both cases, I’d encourage you to take heart and not let the size or number of microinteractions on your site scare you away or cause you to dismiss them. Instead, start small. Start by examining a single process your users might go through (say, renewing a book online), then inventory every microinteraction they would encounter when completing that process. As you pull apart a single task, I bet you’ll come up with all sorts of ways to streamline the process for your users and introduce a little delight along the way.

Once you’ve worked through one process, move on to the next. Perhaps consider pulling together a group of colleagues (a Microinteractions Team!) to work on the task together. Library folk are usually detail-oriented, so this should be a fun exercise for most.

Remember: there aren’t many times where sweating the small stuff can have a big impact. This is one of them.

The best argument I’ve read for why you should develop personas

This is Service Design ThinkingWe’ve been doing a lot of service redesign work at my library lately, partly for a new service point we’ve designed and partly in an effort to harmonize the experience users have across all our various services and service points. As part of that work, I’ve been reading a lot about service design and one of the methodologies that keeps coming up is persona development. While I’ve long been a fan of personas as a user-centred design tool, I’m often challenged to sell them to colleagues in such a way that they see personas as a useful tool, rather than an exercise in creating reductive stereotypes (which is the argument I get most often).

I started reading This is Service Design Thinking (by Marc Stickdorn and Jakob Schneider) yesterday and right there in the first chapter is the best argument I’ve read for why you should develop personas:

Think of two customers. Both were born in 1948, male, raised in Great Britain, married, successful and wealthy. Furthermore, both of them have at least two children, like dogs and love the Alps. One of them could be Prince Charles and the other one Ozzy Osbourne. Though statistical customer descriptions are important, a true understanding of habits, culture, social context and motivation of users is crucial.

A service you might design for Prince Charles would be very different from one you would design for Ozzy Osbourne, right? A pretty convincing pitch for persona development as a methodology.