About

Last week I was happy to have the opportunity to take in this energetic, insightful keynote by Harper Reed, currently Senior Director of Software Development at PayPal and sometime CTO for Obama for America and Threadless.com (best T-Shirts ever!). It’s MSFW (mostly-safe-for-work) [F-bomb alert], but hey! our CIO invited him so I think IU employees at least are A-OK.

Enjoy this talk on Big Data, Product Design, UX & Being Only A Little Creepy. I’m pretty confident the hour will zip by.

At a recent DUX staff meeting, we spent some time talking about how to explain to laypeople (e.g., our moms) what it is we do in this department. Someone offered this helpful metaphor: Ask them, “Do you ever use your computer or the Internet and feel stupid because you can’t understand how to do something—something you think should be easy to figure out? Well,” she said, “DUX people make your machine or the website you interact with work better for you. Your machine or a website should never make you feel stupid.” I think that’s a smart way to look at web design and the user experience: Don’t forget you are not the user, that the tasks the user performs, while routine—perhaps even mundane to you—might truly be unfamiliar or confusing to the novice. Therefore, design without assumptions.

When thinking about the user experience in web design, sometimes some of the simplest things slip our minds. It’s always good to be reminded, those of us immersed in techy jargon and details, that we are probably not the target user of whatever it is we’re creating or trying to make better. The target user might have little to no tech savvy, or might see the things on his/her computer screen in ways quite different from the average designer or usability tester. Net Magazine, a really great tech magazine with lots of UX-related content, recently published a list of “10 UX Things We Remembered in 2012” for its year-end review. Again, the entries on this list might seem like no-brainers, but they are easy to overlook the more one becomes assimilated to the back-end culture of web design. I’ll let you read all ten for yourself, but I’ll highlight those entries that stood out to me most, made me utter a little “hmm” and nod my head in recognition.

#1: “You are not your customer.” While the article is aimed primarily at commercial web design, most points are applicable to all design, including the sort of stuff we do in DUX (think: reconfiguring IUCAT and the IU Libraries website). Authors Stuart Pill and Gavin Wye write: “It’s very easy to forget that your customers do not behave in the way that you would like them to . . . Even if you are working in a consultative role it’s easy to become accustomed to the way things are, and take for granted that people outside of your bubble will understand what you are trying to communicate. Your customers have much less contact with your company and its products; therefore, they may need assistance with things that appear obvious to you.”

Which leads us to points two and three. #2: “Navigating home.” Many users do not know how to navigate home, do not understand that clicking the site’s logo will typically take them to its home page; instead, they rely on their browser’s back button (assuming they landed first on the home page before moving on to specific content). It’s strange to think of users not understanding what, to techie types at least, probably seems pretty obvious, but I can certainly see this in relation to IUCAT Classic, which doesn’t allow for a very user-friendly browser-button navigation experience. One has to use the interface’s built-in navigation buttons or the “IUCAT Home” tab at the top of the page to get back home. Thankfully, New IUCAT has remedied this, and it makes my heart happy to think there will be fewer confused and/or frustrated back-button clickers interacting with the catalog.

#3: “Country selection with a drop-down list.” Here’s another supposedly obvious user task that really isn’t so easy. The article explains: “We tested the checkout for a global retail site and found many users don’t use keyboard shortcuts to access drop-down lists. Few people we observed knew that they could type a letter on their keyboard, use the arrow keys or hit enter to select the option. Users still use their mouse to navigate and hence found long drop-down lists frustrating.” Proposed, instead, is a “country selector,” wherein a user types into a traditional-looking search box the country he/she is looking for, and the box auto-completes with each letter she types. From there, he/she can select from a much shorter, much more manageable list of countries. However, to say, immediately, that this is the holy-grail alternative to the drop-down list is probably short-sighted, and defeats the purpose of point number one above.

Finally, #7: “The bar is still relatively low.” “It’s easy, when you are surrounded by and immersed in the internet, to forget how hard some people find it to do things online,” caution Pill and Wye. “The web is still a confusing place to some people. Making tasks familiar by using established design patterns increases the chances of users completing these tasks, and so leaving your site with a sense of fulfillment and satisfaction.” As a former teacher, Maslow’s “Hierarchy of Needs” was de rigueur in my education courses. Maslow counts physiological needs (e.g., food, water, sleep) as paramount to a student’s success—that is, one cannot fulfill higher-order needs, such as self-esteem, achievement, and creativity, without first meeting those basic needs. I think we can apply the same thinking to users of websites—a user cannot use and appreciate fancy-schmancy interactive features if the supposedly small things aren’t working for him/her.

I’ve been frequenting a website recently for purposes of obtaining a particular certification. The site (which will remain nameless) is broken up into learning modules, each with foundational information a user must read in order to complete a series of quizzes and move on through the certification process. I have found, sadly, that the longer I engage with this site, the worse I am doing on the quizzes. Now, I could chalk this up to my becoming increasingly dumber as the hours necessary to go through each module sluggishly go by, or I could look for a scapegoat for my poor performance. I choose the latter. My scapegoat, then, entrenched as I am in all things usability, is the site’s absolutely user-unfriendly design and its mind-numbing effects on me, the user.

I was reading this article on Mashable.com, and I think it is so on point with its outline of how to make your Website usable. The offending site I mentioned above is failing on all points, especially when it comes to readability. Two salient and simple suggestions for improving readability are:

Keep Content as Concise as Possible

Help Readers Scan Your Webpages Quickly

The article’s author, Jacob Gube, states that content should be “easy and pleasant to read, easy to understand, and skimmable.” The pages on the site I’ve been visiting include extremely long lines of text, filled to the brim with information (including much technical jargon), and tons of embedded links within the text. I feel constantly disrupted and distracted, having to click on links that navigate away from the main content in order to give me yet more huge pieces of information. Ugh.

Tech blogger Philip Webb stresses the importance of what he calls “chunking up” content for greater usability. “That’s technical talk,” he says, “for make your page more scan-friendly. Large blocks of dense text intimidate the reader and causes ‘information overload.’” With web content, conciseness is a virtue—especially within instructional websites. Dale’s Cone of Experience, which is an instructional-design model and not the name of a totally awesome PBS Kids science series, shows that people tend to retain only 10% of the information they read. And studies show that in the hyperlinked world of online reading, attending to wordy text and remembering its content is even more limited.

Here’s where a cool tool can help. The Readability Test Tool analyzes the readability of your website’s text—whether that be an entire page or a specified section—using several key readability indicators, the most popular of which are probably the Flesch Kincaid Reading Ease and Grade Level tests. Just paste in your URL or directly input the text you’d like to analyze, and the RTT will tell you how it scores.

http://www.read-able.com/

So, for instance, I cut and pasted the text of this very blog post, and it returned a reading level of about the 11th-grade, which is pretty good, considering much of IU’s blog readership consists of young adults—undergraduates and graduate students in their late teens and early twenties. However, that website that has me in a shame spiral due to my lackluster quiz scores? It has a grade level of about 17, which means more easily understood by 22 to 23 year olds. A recent report by Nielsen Norman Group stresses the importance of writing web content that is quick to scan and includes easily digestible chunks of information: “If your site targets a broad audience, aim to write at a 6th-grade reading level (or lower). Writing at this level will help audiences of all ages—young and old—quickly understand your content.”

When you aim, especially, to have your audience engage with your site at length, as with the site I’ve been visiting regularly for certification purposes, you need to be economical with words—cutting clutter, enhancing white space, and emphasizing ease of use. Keep these two simple rules in mind: Be concise and support scanning.

As a student keen on learning how the user-centered design process works, I’m intrigued by how we, as librarians and information professionals, think about websites as mechanisms that guide our users to the resources they want and need. I think about this a great deal – as a user of library websites and as an aspiring user experience librarian/developer.

This is a lot to think about, due in part because the library has so many different users. Not only do we have the faculty, graduate, undergraduate and walk-in users to consider, but also the library staff and their consequential roles as library users. Here at DUX, we are in the process of rolling out a new catalog, IUCAT Beta, while at the same time working toward a complete library website redesign. As part of this process, I think a lot about how these library tools will “successfully connect with every student, staff and faculty member to help them feel productive, enthusiastic and valued on every level of their encounter”?[1]

My mind reels. In the good way.

I recently came across what I think is, a really poignant way to think about our multiple users’ needs: trust. Provoked by a recent article on UX Mag by Ilana Westerman, I began looking at our library users as customers looking for a variety of products on a library website. Her article illuminates the basic principle of user trust, through a case study that examined the ways in which a particular design for a healthcare plan website earned consumers’ trust. The context of the website in the case study – a lot of detailed content used by numerous individuals with a variety of purposes – reminded me of our library users.

The library website will do what it claims to do. A user has expectations that the website will live up to its claims, which are assumed to be accurate and unbiased. For example, most people trust that when they hit the “Hours and Locations” menu item, they will navigate to a page that will show them the correct hours and location of the library.

Information will be correct, complete, and unbiased. When users trust the information and choices presented, they are less likely to feel a need to go elsewhere.

The library website has quality. Users want to feel confident in their choices and we all want to feel confident that our digital experiences are worthwhile and valuable.

“I will be successful.” For library users, there must be a sense that if they follow a process through all required steps, their goals and intention will be met.

I think these four points are obvious in theory, but are difficult to put into practice, particularly when working to a vast array of user’s and needs. Based on Westerman’s conclusions, and my own perspectives based on my experiences in the DUX department, I think a way to approach trust-building with library websites is through a thoughtful respect for the cognitive load put on the users of library websites. We want to build websites and other library tools that build user confidence, not ones that burden users with irrelevant material and information, which renders them unsuccessful.

I’m still trying to find a productive space to work out my thoughts on user trust, so I encourage your thoughts and comments as I continue to think about how to construct dependable, quality library websites. Meanwhile, my mind still reels. In the good way.