I was a Whole Foods first-timer
I am not a foodie. Okay, now that that is out of the way: Whole Foods is amazing.
One evening at last week's IUE2009 conference in Ann Arbor, Michigan, my colleague Jackie and I breezed through the local Whole Foods store. From a user experience perspective, my Whole Foods experience was really great. But, let me digest it a bit further.
As author of "Neuro Web Design" Susan Weinschenk explained, our "old brain" triggers on 3 questions: can I eat it, can I have sex with it, and can it harm me.
Upon entering Whole Foods, we were first met with luscious fresh fruits and vegetables. They appeared and smelled a factor better than the normal produce at the grocer in my village. I walked in with the intetion to buy one item: baking powder that uses potato starch instead of corn starch, so when I realized I was gazing lustily at the asparagus, I swallowed my mouthful of saliva and steeled myself with the rational part of my brain. Discipline! I would not succumb. Still, it was delightful to walk around and see the beautiful cuts of meat, the great selections at the deli, the desserts, the wine, the cheeses.
We had circled the store and were approaching the checkout and realized that we hadn't seen the baking section.
So consider: We were in an unfamiliar store and had not located the item I was seeking. I was not irritated by this. The general happiness of walking through this great store put me in a very tolerant mood. I actually looked forward to seeing what other great things we'd see on the way to finding the baking powder, and I had high expectation that they would, in fact, have the baking powder. They did have it. I bought two cans of it, at a premium price. And, I ended up buying some turbinado sugar that was in the same aisle, since I was nearly out of demerrara sugar that I use for baking (and in coffee and on oatmeal…).
Designers! If you haven't yet, read "Emotional Design" by Don Norman. Oh, and Weinschenk's book too.
IUE2009: Now what?
Now comes the after-conference exhalation. (And I just attended! Imagine the organizers.)
My employer, Covenant Eyes, sent a small crew of people to the conference…8 of us in all. For all but me, it was the first time at any UX conference, and I think we all learned quite a bit.
So now the question becomes, what did we learn from all these tutorials and sessions, what ideas will help us do better work, and how can we make sure to build these ideas into our daily work.
I understand that most of us will gather on Monday to start hashing out those questions, but in the meantime I thought I'd share my initial map of ideas, recently jotted onto my whiteboard. Click the photo for a larger, more readable version.
Concepts on the board:
- Use Cases
- Field Research
- Personas & Persona Maps
- Rapid Iterative Design, "Kleenex Tests"
- Branding+Content+Search Engine Optimization
- Social Web (Podcasts, Twitter, Facebook, etc.) But Be Real!
IUE2009: A few photos from the last day
I had a little break after Cora Bledsoe's presentation, and took a few minutes outside. Just sharing a few photos.

The outside of the Morris Lawrence Building, where the conference was held.
IUE2009: Thursday’s tracks
Okay, that was a great conference.
The last day was built on parallel tracks of presentations, most were about an hour-long. I'm only going to write about 3 of the ones I attended.
- Now That I See It, Dan Klyn, Flannel
- In-House Recruiting, Cora Bledsoe, Quicken Loans
- Grown-Ups Guide to the Social World of Web 2.0, Jan Welborn-Nichols, Market Arts Creative
Now That I See It
Dan Klyn's talk was enthusiastic and thoughtful. He asked the question about information architecture, is there more we can learn from "regular old" architects? Of course, the answer is yes.
One idea he garnered from architecture is the spectrum of architecture work. Which level should it meet?
- Shelter
- Comfort
- Convenience
- Prestige
Ask that about any Web project. What an excellent model for thinking about the aims of a project! Associated with each is the level of customization, the speed of delivery, and the reliance on established patterns of use. E.g., for many sites that need comfort or convenience, building a site using Wordpress (or another blog CMS) would be fine. However, if you need certain convenience or prestige, more custom approaches/implementation of information architecture may be needed. An out-of-the-box CMS may not be able to reach that level of work.
I suspect most of us make these strategic calls at the early stages of projects, but I found this spectrum of shelter to prestige to provide a nice frame.
Dan also talked about some discussions he's had with Richard Saul Wurman, who wrote a book a published in 1997 with "Information Architects" as the title. I've not read the book, but been aware of Wurman by references from a number of authors in the IA field. My general take is that he pushed thoughts on the topic forward, but that the book was focused more on what today we call information design. Funny, I've watched a number of TED presentations, but had no idea that Wurman was behind that project.
It's been so long since I've been in a room with other information architects. I love IAs.
Dan is working on a book called "Now That I See It." I'm looking forward to seeing it!
In-House Recruiting
Cora presented one of the most immediately applicable ideas of the conference. In short, it is the idea to create a place for people interested in participating in user research to gather, so that when Quicken Loans needs to recruit participants, they have an existing pool of possible participants to pull from. See a core part of the answer at feedbackcentral.quickenloans.com.
Awesome idea. Perhaps we'll do this at work.
Grown-Ups Guide to the Social World of Web 2.0
Jan presented a fast-paced survey of many Web 2.0 sites out there, and gave her review of many of them. She shared many recommendations on making the most of each one. Her talk was great and entertaining…and I need to get to work. Read LOTS more about her talk at Zach's blog, and visit her company's site at market-arts.com.
IUE2009: Keynote track
Presentations this morning
- Threshold of Acceptable Usability
- Neuro Web Design: What Makes Them Click?
- Bringing left-brain and right-brain together (or, the happy spot)
- Anatomy of a bus map
There was an interesting hodge-podge of presentations at the Internet User Experience conference this morning. I suppose, relatively speaking, I'm an old-timer in this field…which is to say I found 1 and 3 sort of boring. I like to think and learn new things. 2 was good, except that I had already studied the book, so it wasn't new to me. Strangely, the most chaotic and incoherent of the morning sessions, #4, I found the most interesting.

Ed Vielmetti presenting "Anatomy of a Bus Map" at IUE2009
This Vielmetti guy (I have no idea who he is) walked in and so ensued the chaos. He started by asking a room of 150 UXers to fold a prototype of an 8-panel bus schedule. It involved folding and tearing of paper. It was a fun usability exercise (though it wasn't intended as one). I think I ended up folding it correctly, but didn't end up needing to tear it? Eh.
His talk rambled fairly well, and included some brief glances at interfaces. Primarily, though, he riffed on stories of people needing to find a way to get on a bus to some other place. For a number of years not long ago, I was a daily user of CATA, the bus system in Lansing, MI, so I appreciated his stories.
One concept that came through his lecture is how the motivations of public organizations (like a public transit authority) have strange—and sometimes missing—intersections with motivation and information expressions of other agencies, such as an apartment management company or customers of the transit system. User motivations, of course, will differ from out-of-town conference attendees versus commuters. Knowledgeable users of a bus system will ultimately know valuable information, or stories, that employees of the bus systems will simply not know. He gave an example of a pedestrian path that services as a shortcut to another bus stop that has buses every 15 minutes, instead of the one that is physically closer but has buses every 30 minutes. Certain expert users know this, but others and the public agency just won't, and sure won't capitalize on it.
Small contextualized apps are built often by individuals scratching specific itches, when given the time and free information to manipulate.
I fear this blog post is perhaps as chaotic as the talk. I know I should edit before posting, but…this is, after all, just my personal blog.
By the way, Zach Spencer is also posting lots of notes about the conference on his blog "Life of a Web Programmer." Here are Zach's posts tagged with IUE09.
IUE2009: Field research class
Today at the Internet User Experience conference I attended a field research class led by Danielle Gobert Cooley.
The morning session was lecture and discussion on differences between lab-based research and field research, and some guidelines and tips on doing field research. Then we paired up and went out to observe some employees at Washtenaw Community College, which is where the conference is hosted. In the afternoon, after doing a couple of research sessions, we came back together as a group and did a little group processing where we tried to analyze our findings.
The sessions themselves were fun, but were missing the benefit of us having done prep and having a clear purpose or inquiry focus. So the analysis was a little tough. Plus, we didn't do enough observations of people doing similar work to get a rich set of observations. This is no critique on the instructor; it is just that we had to work with fairly random volunteers who volunteered on short notice (and we are grateful they did). Despite this, actually going out to do the observations was great.
Let me point out a couple highlights that I really appreciate.
- Book recommendation: "Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design" by Karen Holtzblatt, Jessamyn Burns Wendell, and Shelley Wood.
- I really, really like doing field research.
Okay, so that second point won't really help any of you that much.
We did two different field research excursions today, and I now I recall that I really enjoy that part of UX work. I want to do more.
For the first half-dozen or so years of doing UX, all user research I did was in the field, mostly because I needed to operate fast or I was doing it for purely qualitative reasons and sometimes without full awareness from management or project managers. Basically, I needed real design research that I could use right away, so I went out and got it.
But, in the last few years most of the user research I've done has been with a little more formality. While I can't honestly call any of it "Formal," it did happen in labs where we brought people out of their own environments.
So, here's a story with a little subtlety about why it's important to go out into the field for this kind of work. (The design research field is thick with more obvious stories, like, oh the users kept spilling their coffee on the controls, so we built the next version with cup-holders. This isn't quite that obvious.)
About 8 years ago I was working on a website that people could use to browse photos and purchase high resolution TIFFS or JPEGs to download for their own use. We were envisioning primary use by graphic designers. At this particular institution, it was quite possible that graphic designers couldn't actually purchase something, but might have a secretary in their unit do the actual purchase. So, one user test we did involved a secretary as the participant.
The secretary proceeded through the tasks (and yes we observed a number or areas we could improve in), and in the wrap-up discussion she asked "So, when will the prints be delivered?"
Funny how we never thought that people might think they had just ordered prints. It became clear that she hadn't realized that she had downloaded a picture file to her computer. That's a really important observation. Usability tests rock.
Had we been in a lab instead of at her desk in her office, she might not have mentally processed through what she was going to do with the photos after-the-fact. She was picturing a nice framed print of the beautiful landscape photo she had just ordered on the wall in the office. If she was in a sterile lab—away from her normal surroundings—that might not have occurred to her, because she would have been focused on the study itself. Or, maybe not. We don't know. I, however, suspect that her normal surrounding played a big role in her thoughts and normal reactions in the study.
Of course, lab research has its benefits. They just don't generally appeal to me as much.
So, thank you Danielle for a fun day of practicing field research! I hope to be able to do more field research in the near future.
IUE2009: Use Cases and Scenario-Based Design
Today at IUE2009, I attended an excellent workshop led by Jan Moorman on scenario-based design and use cases.
My experience with use cases has been limited to what I've read from websites like AListApart.com, some select pages returned from Google searches, and snippets from books like Martin Fowler's UML book and "Designing the Obvious" by Robert Hoekman, Jr. Based on what I've read, I have created UML diagrams for use cases and written out a few.
This limited knowledge may have been ideal for today's workshop, because it gave me experience with which to make sense of the topic, while acknowledging that I have much to learn.
Jan led us through a number of different topics, but in general I remember focusing on these areas:
- Using scenarios, drawn from observations of users, perhaps through contextual inquiry, to put context to a user's experience.
- Thinking of use cases as storytelling. (Possibly use storyboards in addition to textual stories.)
- Use cases can exist at many different levels, as needed for the project
- Big picture of what is happening from a business goal perspective
- Use cases with brief details in simplified steps
- More detailed use cases which may include flow diagrams
- Use cases that include sections on data definitions and other functional requirements
- Different examples of creating use cases that represent multiple systems and/or users, and use cases that map actors/goals to business logic to systems.
And what of use cases and Agile?
In addition, we spent some time discussing how use cases may fit into Agile methodologies, specifically Scrum, which we use at Covenant Eyes.
I thought Scrum and use cases would fit together well, but when we actually tried to speak to the similarities, it became tough. Seems strange, right? I mean, user stories are kind of like abbreviated use cases. Well, they are, sort of.
In spite of the user stories from Scrum, the tough part is that the language we use in Scrum is angled very differently than the language we use in UX, and specifically with use cases.
For instance, in Scrum we have a user story of "As a customer, I want to purchase the items I have in my shopping cart." That user story could then become a product backlog item. We would then create a series of tasks needed to complete that backlog item. These tasks might range from finding information, like "Find out from accounting exactly what information we need to gather from customers" to coding tasks such as "Write Javascript to validate billing detail form" or "Write unit test to confirm that the shipping costs are applied to the bill."
Note the language in the tasks. These tasks are worded for use by the developers in the Scrum. The presence of the user in these Scrum tasks is gone. It may be there if you read between the lines, but consciously, the work is at the nuts and bolts level now.
Use cases are worded on behalf of the actors, which are often our customers or users. They tend to be user-goal oriented, or exist a level-down from the goal nearer to the nuts-and-bolts level. The terminology is still geared closer to a user, though. For instance, "The customer sees shipping options with prices and selects an option." You can see, as in that case, the user's goals are still near at hand.
Benefit of use cases for Agile development
Based on observations from today's seminar, it seems like one of the key reasons why we should do use cases in Agile development is that the process of hammering out use cases feeds the user stories and thereby the product backlog items. Without use cases, it is very easy to miss a big area of development, simply because we hadn't considered it. Use cases forces some discipline into the process, and keeps the user's goals front and center, along with the motivations of the business and developers.
Use cases can also be turned about to use as input into the planning of usability tests during design and development and acceptance tests during QA.
If we have a good batch of use cases, those can feed into development. Meanwhile, QA can receive those same use cases and begin writing acceptance tests. When development is ready, QA can step right in and run acceptance tests (which are based on use cases).
Now, what remains to be seen for us is how well we can integrate this valuable process of writing and using use cases into our Scrum process.
It's been a long day! I hope to post more tomorrow about the session on field research.




