a posteriori

Axure Prototyping for the Web Store

We’ve completed our initial pass for redesigning the UIUC web store. Including an easy-to-use search function and a category selection feature was key.

If you’re interested, you can link to our Axure prototype here, and to a summary of our design rationale here.

Things I’d like to see tested and explored in the next iterations:

• Log-in button: I think the placement is intuitive, but with our current design is a bit up in the stratosphere. While I like the white space, I’m intrigued with what we can do in terms of content placement, or in the design of the log-in component itself. The button is also spatially separated from the account box at center-right; I’d like to see how users deal with that in testing.
• Reintroduction of dynamic content to the homepage: something for updatability and visual interest, but not as garish (or non-applicable to users). Content should be determined by site analytics, by season (and the semester cycle) and by special vendor promotions.
• Personal vs. departmental purchase feature: we decided to remove the personal/unit purchase entry paths and to add them instead as part of the filter options on the product list page. While its presentation is confusing to users in the current design, I still think this is a valuable doorway to the products. I would like to see a portal on the homepage to the tune of:
                                    “___ I am shopping for myself   
                                     ___ I am shopping for my department          Go! »”
  which would then lead to a product page specifically for that purchase type, with the ability to further narrow the search.

on the other side: user testee!

Anyone who’s involved in user testing ought to switch chairs at least once and be a testee. You’ll be doing a good thing by helping improve usability, and it can be refreshing to engage in something familiar from a different perspective. Plus, because you know what makes for good test results, you’ll be the best tester they’ll have all day, and know exactly what to look for and do and always think out loud, right?

Sort of.

I had to remind myself constantly to speak aloud what I was thinking and doing, and I was so concerned with giving useful answers (answers? to what? like this is a test I need to pass!) and looking for the right things I almost forgot to just use the darn thing. I actually got nervous! Eventually I calmed down, but there’s still a part of me that hopes I gave my compatriot a good test.

Sitting in that chair reminded me of how important it is to make the tester comfortable — if you are in the room with them, even the distance from your chair to theirs makes a difference. If you’re using a camera, whether the tester can or cannot see the camera makes a huge difference, even if you tell them they are being filmed. Too much conversation during the test can be detrimental (and give stuff away), but a little human interaction can go along way towards creating comfort. The test giver tittered when I made stupid jokes — I really appreciated that. But mostly, it was fascinating to test an interface and simultaneously wonder how your input will be translated into design solutions by someone else, all the while you’re running through your own design solutions or heuristic analyses in your head. Sometimes it’s hard to keep track of what you’re thinking!

And it was fun. The interface in question was a working prototype for a collaborative web space catered to researchers in data curation. I’m afraid I’ll be making my exeunt by the time it raises its curtain to the public, but I’m still really excited to see the final product.

uiuc web store: user test

I’m a staunch supporter of user testing and user observation, and even more of a supporter of doing it in the use environment. In my time in the corporate world, I’ve built a number of automated reporting packages, Access databases and web sites to help aid the efficiency of my department peers. One of those databases I was charged to build my first day of supervisor of that department, in my first month with the company. I could have just sat down and built it: all I need is my what the folks who gave me my information systems degree told me, right? Not quite, Harvey. So I sat down with my new associates for a week, and watched them do what they do: manage and organize hundreds of incoming service records a day, using a broken Access database, filing cabinets and a baffling status system of paper placement across five cubicles. I then rebuilt a new database, and had them test it. They told me what didn’t work (never did they have a problem telling me what I did wrong, it was beautiful), and I reiterated. It wasn’t a sophisticated Oracle, interdepartmental, interoperable document management system, but it didn’t need to be; it needed to work well for my department. And it did - but only because I observed my users in their use environment and actively integrated my associates’ input into the design. This is why iterative design makes so much sense to me: those amazing, iron-fingered ladies and one gent were making me do it long before I had heard of it. And it works. Understand, Evaluate, Design, Test, and do it again. It’s exciting and satisfying, too. Your designs live, grow, evolve. Just like us: the humans who interact with them.

Herein follows a brief account of user testing for a project involving web interface design:

The University of Illinois has an online web store for all three of its campuses (Chicago, Springfield and Urbana-Champaign) that sells software to affiliates at a discounted price. Responding to a solicitation for web sites on which to conduct usability studies and redesigns, the folks at the web store offered up theirs. This project is a mix of individual and group work, under the guidance of Dr. Michael Twidale, and interface design and usability engineering expert teaching at Urbana-Champaign. I spent some time with the site, getting to know it, its flows, its purported audience, etc. Then, my fellow project members and I individually conducted user tests on the site to gather data for redesign solutions.

The Web Store in its current incarnation

That’s the homepage, up there. See the middle portion, with the blurb about Adobe? That is a sliding ticker of promotions, which change every four seconds (read quickly, friends). The News and Events boxes at left each cover all three campuses. The persona boxes, as I call them, featured at bottom link to more information for those buyer types — they are not shopping portals (wouldn’t you think so? I thought so).

What did my user think?

My tester was an employee of the University who was unfamiliar with the Web Store, so the test was her first interaction with it. Initially, I had five distinct tasks, based on a user type and a goal, that I wanted to her accomplish during the test. However, I decided to forgo those and simply ask her to use the site as she would normally use it; I didn’t want the particulars of the task I gave her to limit her explorations or deductions. In the end, she was a perfect tester: she made up tasks for herself, changed her own “persona,” and only once did I have to remind her to think out loud. Trust me, folks, I lucked out; that is not your average bear in user testing.

All in all, she wasn’t happy with it. Her interaction confirmed shortcomings I had seen, but also brought to light some surprising issues, and even elements I hadn’t considered an issue in the first place.

- Access points to product offerings are confusing. What’s the difference between Personal Purchase and Unit Purchase? Even though my tester knew what “unit” meant (department, in this case), she still wasn’t sure which was the right one to click on while shopping for herself. This link pairing appears twice on the homepage, and while multiple access points are good in theory, these are designed too differently to be well understood, and are strangely placed on the page.

- The persona boxes are useless. None of the user tests we conducted found the information linked to from these boxes to be useful.

- There are pockets of “invisibility” on the homepage. The middle text, sandwiched between the graphic-heavy persona boxes and the dynamic promotions slider, wasn’t read by any of our testers. Mine alluded to it at the end, saying the color rendered it invisibility. The menu bar at top right had similar results.

Problems continued on the product pages: categorizations are mostly unintuitive, browsing is difficult (as is searching - for one thing, there’s no search bar on the homepage! This feature only occurs on the product pages). The back button was used heavily, and my tester complained of “too much clicking” to get to the actual product.

I should mention that the site is not completely lost. Essentially, it suffers from 1) an inability to communicate effectively to its audience and 2) an inability to make task flows as effortless as possible — namely, searching or browsing for, finding, and purchasing a product.

As to the former issue, most of the attention will be paid to the homepage: simplifying it, getting rid of clutter, creating better access points and easier, more intuitive access and discovery features (that’s information science speak for adding a search bar and browsing categories). We’ll add how to provide easier access to information about the site and “how it works” (a major complaint of all our testers).

We’ll also consider how and to what extent we want to segment or individualize our users before they reach checkout. All the software offered as certain eligibility requirements: by campus, affiliate type, student type, etc. Faceted searching could make it easier for individuals to retrieve a product list of only the software for which they are eligible (this is currently doable only up to a point). Or, we could insert certain identification features into the process — for example, a feature box with radio buttons: [ _ I am shopping for myself / _ I am shopping for my department Go->], but it was argued this would require more clicking. (Personally, I think this up-front identification could be an enhancement to other access points, and in real life would champion it for testing.)

We’ll use this data in the next phase: rapid prototyping!

If you’ve still got coffee left in your mug and would like to read more about my user test, you can do so here.

ux cu book club: the art of storytelling

This month’s UX book club selection for the Champaign-Urbana, IL branch was another Rosenfeld Media book, Whitney Quesenbery and Kevin Brook’s Storytelling for User Experience: Crafting Stories for Better Design. The book is quite different in subject matter an approach than the last book we discussed, and looked forward to having a different kind of conversation as a result.

Like Site Search Analytics, Storytelling is easy to read and has an approachable, casual tone. It does, however, require a bit more time to germinate with its contents than does the former; thought it’s applicable, it’s not immediately so. It also leaves much open to interpretation — that is, how you or your team incorporate stories and storytelling into your design process. While the argument for storytelling as a strengthening component of user experience design is persuasively presented, we as a group wondered how often in practice such an approach becomes more of a luxury than a requirement.

The book considers both user-generated stories and team- (or in-house) generated stories. Finding, culling and compiling user stories can aid in developing sophisticated and rich personas; the details of a story is rich qualitative user data that can be used to complement or enhance quantitative data like card sorting results or search analytics. Finding these stories can indeed take time, but it is asserted by Quesenbery and Brooks and was likewise understood by all of us, that as user experience professionals, we are always in the midst of a user story. We have our ears and eyes open, though we may not take back with us the story as a whole. Contextual inquiry, observation testing, even casual conversations about the usability of such and such product are all rooted in stories. Our interactions with things, people, places are narratives: storytelling is how humans make sense of the world. But very often those stories are distilled into the elements upon which UX professionals can act, or translate into a spec or requirement. Q & B argue for taking the entire story back with us, and keeping it with us throughout the design process.

This does not necessarily mean that you must consider, with equal import, twenty or thirty full-detail stories as you hit the drawing board: such is consuming, expensive, and, I think, slightly dangerous. Each story in isolation is valuable, but anecodotal and highly subjective; furthermore, the process runs the risk of transforming one person’s story into something representative of a group, demographic, or situation. Rather, we decided, this approach can be useful in finding the structure, via stortyelling, of overarching user issues, which has been derived from multiple user stories.

The theorist in me is still concerned, here. I am not a structuralist, though I see the value in it. Sometimes. When taking a structuralist approach in literature, characters become generalized archetypes; plot becomes a graphable arch. You’re back to where you started. Good for persona development, but not much else.

Storytelling is also a good way to get the brain juices flowing. The devil and the design are in the details, and crafting stories at the drawing board can help flesh out and tease out design solutions. This resonates the most with me, and here is where a UX professional with a multidisciplinary background can be an asset (like Mr. Brooks, who is both a researcher at Motorola Labs and a professional oral storyteller).

Where we all agreed storytelling could be most valuable in the UX design process is in communicating design to stakeholders and developers. Of the former, effectively marketing the solution can be pivotal, and, as Mad Men has taught us, it’s always the story (and the experience!) that sells. But developers need a story to go by, too, though you may think all they need is a prototype and specs — and many in our group saw the truth to this in practice. As one of our members put it, “What happens without the story? Really smart programmers do really smart things that break everything.”

I wished for more consideration of how storytelling can inform the design itself; that is, how to incorporate narrative elements and structures into creating an interesting, engaging and persuasive experience for your users when they interact with your product. Good stories give enough information to understand the characters, the plot, and characters’ movement through and motivations during that plot; the best stories leave enough out for interpretation, imagination and mystery. Naturally, if you are a healthcare provider whose mission is to craft a thoroughly informative and peace-of-mind-making user experience, it naturally might not be wise to leave out certain details. But I wonder how, and where, such an approach can be effective on the web, beyond gaming.

New Met Museum Site

The Metropolitan Museum of Art in New York City just launched its new website — redesigned and with new features. According to the press email, they’ve redesigned the site “to make it easier to use and a pleasure to explore.”

Frankly, I’m thrilled with it.

I am familiar with the old Met site, and have visited it many, many times before, but not recently, so in comparing the two designs I’m working from my memory — be kind to the poor thing.

The homepage is slick. A photograph slideshow dominates the page but relevant information still appears above the fold. There is less content on the new page than I recall on the old, and tasks and information are well organized. I especially like the three content columns beneath the slideshow. These feature the most text, but are simple, easy to understand and presented cleanly (they also, I think, make for good sense-making. “Visit” - “Events” - “Now at the Met” : how to visit, followed by why and when you should). It is easy to see how content and navigation cater to three main groups: new visitors, old visitors and members.

I also have to admit that I like the new color scheme (I’m a sucker for neutrals).

The new gallery exploration pages and the interactive museum map are among the coolest new features — and given the cool factor, the interactivity, and the way these features “sell” the museum, I’m not sure why there’s not a direct link from the the homepage. Both require two clicks: the galleries, under Collections in the top nav, and the map under Visit (which isn’t bad, really but it took me a second to think where the map might be). The map is zoomable, and clicking on a gallery will navigate to its page in the Galleries section, each of which feature gorgeous photographs of the collections therein. It’s a nice way to do some virtual exploring for prospective visitors. One issue, however, about the gallery pages: the Galleries homepage lists each gallery by number (200 | 201 | 202, etc), but once you click on a gallery, there’s no way to click through to the next gallery without a) hitting the back button, or b) navigating to the department homepage (in this case, Asian Art), or c) using the interactive map. If I want easily to click through each gallery page in order, it takes more clicking than I’d like, and the movement is disruptive.

The suggested itineraries page, another new feature, is charming, and a wonderful addition that does not necessarily enhance the user experience of the web site, but well may enhance the user experience of the museum itself: as many times as I’ve been, I still feel overwhelmed by it. There is so much to see, and unless I have a clear mission I always leave feeling as though I missed something.

So what’s next for metmuseum.org? May I suggest the timelines, please. The introduction page is bit crowded and I don’t know where to start; the organization is slightly unintuitive; it takes too many clicks to get to a timeline; and the timelines aren’t interactive. You woo us with your map, Met. Let me wander through the history of art itself.

Go give it a gander! And if you live in or near NYC, and haven’t been to the museum, please do. There’s something there for everyone. And so much wonder. For that matter, no matter where you live: visit your local art museum.

card sorting: funner*, harder than you may think

I’m coercing friends, enemies, associates, and captive library student assistants into card sorting exercises for the VRC site (I’ll probably also do this for the ACES library site, but what that desperately needs right now is a content inventory and some critical-eyed sweeping).

Card sorting newcomers may think: make some cards, hand them out, assess the results, done and done, martini time. Indeed, I thought this myself, though I suspected that the number of blog treatises, books and other publications about card sorting belies its true complexity.

Well, I encountered my first challenge as soon as I grabbed the sharpie: how do I phrase things? Do I write each link exactly as they are currently worded on the site? If so, many links, such as “finding,” “editing,” and “creating” lose meaning without their category header (in this case, “images”). Links like “digital images,” “35mm slides” and “lantern slides” may also not have enough context to make sense of them without likewise somehow noting that these are collections. But if I re-word, am I cheating?

In the case of the former set of links, I appended the phrase “digital images” to each; thus, “finding” became “finding digital images.” Even this, however, sounded unclear: what does ‘finding’ mean? Do we mean ‘searching for’ instead, the more common parlance for online interaction? In the next iteration “find” may be replaced with “search,”but for now, I wrote “finding digital images online” on the card to see how or if  sorters would react to it. In the end, no one changed the word, and I suspect it may partially have to do with my appending “online” to make the phrase more clear.

In the case of the latter set of links — ”digital images,” “35mm slides” and “lantern slides” — I changed them slightly to “our digital images,” and so on, by which I hoped to imply that these were things that belonged to us. I believe adding the word “collection” anywhere on those cards would have simply been too suggestive.

All in all, the results were positive and surprising — and discovering how people processed and organized the cards was a lot of fun. The next challenge, now, is to turn those results into meaningful input for the site’s layout and architecture. Links like “news” and “calendar” commonly went into categories titled “general” and the like; a good sign that placing them as content on the home page rather than as individual sub pages is a good move. There were some surprising categorizations: for instance, links with “ARTStor” in the title did not always end up in the same category. It caused a slight eureka moment, actually: dispersing ARTstor-related content, and organizing the links by task or goal, may increase the site’s usability and intuitiveness over placing all things ARTstor together. Finally, in many cases categorizations aligned very closely with our own organization strategy from last week’s meeting. This means we’re on the right track.

I’d say the biggest challenge in card sorting, once you get all your cards back, is simply figuring out what to do with it all; i.e., translating or injecting the results into your architecture and doing right by your users thereby. However, despite my slight nonplussedness, I now feel more confident moving forward with prototype creation using this input, and moving on to the next step.

*funner isn’t a word!  Before you hoist that black flag, bucko**, “funner” tends to scratch across my inner chalkboard, too. But I wanted the symmetry in “funner” and “harder,” and if you abide by common contemporary grammar, which treats the word “fun” as an adjective where it was formerly only a noun, “funner” is kosher. For more info on that, check out this blurb by Grammar Girl, created when Steve Jobs launched the adjective-heard-round-the-world, “funnest,” in 2008.

**well, it is Talk like a Pirate Day. It’s a term of endearment among pirates. Really.