Adaptive Path Blog

On every project, there comes that time when the original information architecture has been picked apart and your team has worked out a new structure for the site, and you think to yourselves, “this seems right, but how do we know for sure?” This question becomes especially important when the new site structure also suggests a need for new sections, new content, and new features.

This was the situation we faced on our recent project to redesign Changemakers.com. Before we took the leap to design, the team felt that validating our proposed design was important, especially for a redesign that fundamentally overhauls a system’s structure. The trouble is, how?

After rejecting more traditional techniques like card sorts, we hit on the idea of a scenario-based exercise to help us validate the proposed IA. Read on to discover what we did, and how to run your own scenario-based IA validation exercise.

Looking Before You Leap

During user research for Changemakers, we found that Changemakers.com serves as an important social network for change-minded people and that users were interested in finding other people through two important lenses: location and issues. We also knew that the Changemakers team had been planning to add a groups functionality to the site and our user research reinforced that this would be an important feature for their users, as well. In our redesigned information architecture, we identified these areas as key hubs for the new information architecture.

With this revised information architecture, we setup a working session with the Changemakers team where we all rolled up our sleeves and got busy with our scenario-based IA validation exercise.

After briefly presenting the revised IA, we shared a user scenario to show how a person might expect to move through the content and information on the site. (No interface sketches were included at this point, just allusions to the types of information that users would be finding within the scenario.) We then asked the team to follow the same story and, using a basic storyboard template, sketch ideas for the corresponding UI. We took about 15 minutes to sketch, and then another 30 minutes for everyone to share their sketches. Working quickly helped the team, some of whom had never sketched interfaces before, to get over any initial fears and just start sketching.

The resulting storyboards helped us validate that the IA was essentially complete for supporting a target user experience-i.e., nothing major was absent that would have prevented “Lucy,” our fictitious user, from achieving her goal.

In doing this exercise, we were pleased to see that the new hub sections of the site (locations, issues, and groups) seemed to have natural, intuitive relationships—even in rough sketches. The team also ended up sketching some new ideas that we hadn’t considered-for example, a “projects” section. These ideas weren’t pervasive or urgent enough to warrant revising the IA, but they definitely hinted at different directions that it might make sense for Changemakers to take the site in the future.

If you’re interested in trying this out on your own projects, here are the steps we followed and some sample templates of the Storyboard and IA Scenario. Good luck, and let us know how it goes.

Scenario-Based IA Validation Exercise

1. Write a scenario that describes a user moving through the site to achieve a specific goal. Include starting points and ending points. Where does the user begin? What information brings them into the site? What do they move through along the way? Where do they end up? What do they do with what they find?

2. Create a storyboard template that roughly maps to this scenario. Include a blank panel for each “scene” in the scenario.

3. Using simple visuals (stock photos or rough sketches) take the team through the scenario. Visuals help because they reorient everyone from a systems-oriented, IA view to a people- and usage-centered view of the system.

4. After talking the team through the scenario, give everyone a storyboard template, and ask them to sketch out the screens that the user is seeing at each point in the scenario.

5. Give everyone about 15 minutes to sketch as much as they can and then the opportunity to share their sketches with the larger team.

6. If new information, functionality, or categories emerge in the sketches, point them out, and discuss as a group their impact on the new information architecture.

Will we look back on the desktop experience of today in much the same way we reflect on computer punch cards of yore? If so, when will the desktop and mouse become irrelevant? How do people who want to explore the world of technology experiences that are free from the tethers of the keyboard and mouse begin?

These along with a host of other thought-provoking questions were among the topics of discussion, debate, and jest at last week’s Beyond the Desktop panel discussion. I was honored to be in the company of six brave and talented designers who are exploring the frontier beyond the desktop and thrilled to see such active interest in this topic by the San Francisco UX community.

Here are a few of my favorite quotes of the evening:

We’re still skeptics and I think that is an important perspective to have. I wouldn’t say the technology that we work with is better than anything out there right now, it’s just different. A lot of this is still a hammer looking for a nail. People come to us and say, “we want a multi-touch application.” and we say, “Why?” The challenge for us is developing an understanding for what this technology is well suited for. ~ Daren David

We use play in a lot of our design process. We find as we design stuff, we end up opening a box of things and emulate experiences on the table that way. That is one of the big things that has changed for us – our deliverables have gotten more physical and less visual. ~ Nathan Moody

The truth with all these emergent interactions and interfaces is that the conventions haven’t been established, so you don’t actually know how to work and you end up experimenting a lot more. ~ Noah Richardson

Prototyping used to be a luxury, but these types of emergent interactions, it is an important part of the design process. ~ Daren David

Often times the technology we’re designing for is still being developed. So there’s a lot of give and take and trying to understand what is possible… so we often have to attack from both ends. ~ Jennifer Bove

How do we go from bling to kaching? This is new and shiny right now, but five years from now when this become ubiquitous, what will be the meaningful experiences? And what will be the proper uses of these kinds of technology? ~ Daren David

It really comes down to experimentation. The recognition about a lot of this stuff and the reason I think a lot of people are here is that everybody recognizes and has this feeling that there is potential in this stuff, but we don’t really know what it is.
~ Jeevan Kalanithi

The common element all these interactions share is that they’re all more sociable. ~ Brett Fitzgerald

I have two Roombas in my house and they engage in gladiatorial combat. It’s awesome. I don’t feel like they’re gonna get hurt because they look like frisbees. ~ Nathan Moody

When your Roomba saves your life you won’t feel so cavalier about them. ~ Daren David

… there was a project that reminded us how different emergent interactions can actually open up different affordances and provide accessibility to people who haven’t had it. I have a two-year-old daughter and she instinctively knows how to use my iPhone. It’s frightening. And to see her walk up to the television and try to swipe it… you realize that some of the things being created by natural user interfaces really open things up…. I tend to be fairly optimistic with respect to technology and I think there is this notion of accessibility in a lot of the work that we are doing that we can take a fair amount of pride in. ~ Noah Richardson

I would advise people who want to start exploring interactions beyond the desktop to start by looking at the applications or experiences on the desktop they are currently designing and understanding that it is an instantiation of something that is probably broader. Start thinking about what happens when a user walks away from the computer. What are other the other opportunities? ~ Jennifer Bove

For those of you unable to attend the event, here’s a video of the 90 minute discussion:

Beyond the Desktop Panel Discussion from Adaptive Path on Vimeo.

Sketch note by Kate Rutter

Photo credits:
Panel discussion photo courtesy of Allison McCarthy
Sketch note photo courtesy of Jennifer Bove

Last week, Tim O’Reilly delivered a short address at the Web 2.0 Expo where he offered insight into the five applications he believes point the way for the evolution of the web.

Two themes stood out: sensors will surpass humans in front of their keyboards as the primary data source on the web and Moore’s Law will need to be applied to humanity’s greatest problems. (via ReadWriteWeb)

He cited Google Voice Search on the iPhone, an application that combines both voice and sensor input, as an important technology to watch.

One of our panelists – Noah Richardson, manager of Tellme’s Mobile User Experience group – will share his expertise designing voice-driven systems and interfaces.

He’ll be joined by the following all-star lineup:

I hope you can join us. If you can, please head over to Upcoming and let us know. And if you have ideas about the panel or the topics you’d like covered, comment here or twitter with #btdpanel

A podcast of Jesse James Garrett’s impassioned closing plenary from this year’s IA Summit is now available online via Boxes and Arrows.

Jesse’s assertion that we are all experience designers has stirred controversy within the community, and justifiably so. Professional identity is a slippery slope. However, I can’t help but feel Jesse’s important message is getting lost in these discussion threads. Arguing over the definitions of our roles and judging the value of the contributions of each does little good if it becomes divisive within our community. Instead, it distracts us from working together towards the more important common goal: to elevate the understanding of the user experience field to the world at large.

Regardless of your position on this issue, I hope you will give this podcast a listen. It is packed with inspiring messages and ideas. My hope is that it will inspire you to generate a discussion about how we can work together to pursue the ideas – not discussions about our roles, or our processes – but ideas about how we can improve broken experiences in the world, and the big problems our industry can help solve.

About a year ago, Jesse came to me and suggested I change my title from Information Architect to User Experience Designer. He gave a number of reasons, but none of them resonated with me. I clearly remember commiserating with some dear friends at the IA Summit 2008 about this proposed change in title.

I didn’t want to give up the title. I considered myself an information architect first and foremost. I’ve called myself an IA for nine years now. I was proud of the name. It was who I was. So I didn’t change it.

In Memphis this past weekend, at the IA Summit 2009, I spent a lot of time talking with first time attendees and those new to the field of information architecture. I hosted a round table at lunch for those new to IA. They were a great table, with tons of questions.

One of the things they really wanted to know was how to become a great IA. My answers surprised me. I didn’t tell them that they had to master multi-faceted classification or be able to generate thesauri and controlled vocabularies from scratch. I didn’t tell them about stencils and templates for making better wireframes.

I told them how important it was to listen to the customers of the organizations they would be working for and to deeply understand their behaviors and motivations. I told them to be champions for the user. I told them to listen to the pain of their clients, and think about how their designs could ease it. I told them not to go in shouting about CVs and classification and indexing and how their clients were doing it all wrong. Be subtle, I said. Listen for their needs. Present classifications and metadata and all that cool stuff as the way to get your designs implemented, not as an end in and of itself.

And I realized… I wasn’t telling them how to do good information architecture. I was telling them how to do good user experience design. I realized while I love IA, and it is my core competency, it is also only a small part of what I do.

For that reason, I am taking on the title of User Experience Designer.

Tomorrow kicks off the IA Summit 2009…a gathering of souls with a passion and vocation for information, design and making things findable (oh, and so much more!) It promises to be an energetic and spirited conversation, filled with workshops, talks, hallway synchronicity, new perspectives and new directions.

I’m really excited about attending two of the pre-conference workshops: Beyond Findability: Reframing IA Practice & Strategy for Turbulent Times with Andrew Hinton, Livia Labate, Matt Milan and Joe Lamantia; and The Architecture of Social Websites with Christina Wodtke, Bryce Glass, Christian Crumlish, and Joshua Porter. There’s a whole host of interesting ideas bubbling around the IAsphere this year. The week promises to be a true high point of the season.

Adaptive Path folks will be out and about, so track us down…

• You can find Leah at the pre-conference workshop Sketchboards and Prototyping — Methods for Rapid Iterative Design (co-taught with Todd Zaki Warfel.)
• On Friday, Chiara’s telling us all about The Semantic Web: What IAs Need To Know About Web 3.0
• On Sunday, I’ll share my adoration for my favorite lifeform (and the lessons it holds for us) in Lessons from Slime Mold: How to Survive and Thrive in Ever-Changing Organizational Environments
• And stay for the rousing end with Jesse James Garrett, who sends us back into the world inspired and invigorated with his closing keynote.

We’re seeking a good place to have a round of drinks on Adaptive Path on Saturday evening. So if you’re at the Summit, watch twitter or grab one of us to find the place.

See ya in Memphis!

I’ve been looking for a metaphor or a model that I could use to describe how the Information Architecture day of UX Intensive is structured. The day is focused on metadata, controlled vocabularies, classification schemes and search. They sort of build on each other, but not in a simple, neatly stacked way. I was thinking about this while in Copenhagen a few weeks ago, when the answer hit me: Stone Soup!

Do you remember the story of Stone Soup? It’s a Grimm Brothers’ tale about returning soldiers and their guise to get a selfish, starving town to learn the lesson of cooperation and its benefits. They can make soup from their stone, but it will be a more tasty and filling soup if they get the whole town to pitch in and add ingredients.

Information architecture is like Stone Soup. You can make a website without explicitly thinking about the IA. You don’t have to use metadata or control your vocabularies or develop thesauri. You don’t have to tweak your search engine and play with recall and precision to improve your results.

But it will be better if you do.

Putting structure into your unstructured data allows you to make your site that much better. It’s a way to “plus” it. A way to add some “BAM” to your site, to borrow a phrase from Emeril Lagasse. Because it’s easier to slice and dice and do interesting things with structured data than it is when your data is a big, undifferentiated mass.

IA from a stone? Fancy that.

Two years ago I inaugurated the IDEA Conference, an attempt to recognize the power of information architecture to help in all manner of our lives, not just on the web. I continued working on it last year, and this year, I handed the reins over to the very capable Jorge Arango. Jorge has put together a great program this year (including Jesse talking about Aurora!), spanning a range of interests, but all with IA at its core. Check it out!

This weekend I attended the BlogHer conference in San Francisco. There was lots of talk about traffic to blogs, and what you can do to increase readership, and generally promote your blog. Most of advice made sense, but there was one thing mentioned that got my blood boiling.

I was in a session on DIY Content Syndication and Promotion, and one of the audience members asked how you could use tags to help with promotion. One of the speakers, I don’t remember which one, advised that the best way to use tags is think of the most general topic you post is about and tag with that. Also, if you are commenting on someone else’s post or video, you should copy all of their tags and add a few of your own.

Um… excuse me? Sure, that’s best practice if you want to add tag spam, water down results and piss off people when they come to your post only to find that you are tangentially related to the topic they are interested in. Remember, it was this broad spectrum, shotgun approach to tagging that taught search engines they couldn’t rely on the keywords metadata field..

The rules for tagging are very simple:

1. Tag only significant mentions.
2. Tag at the level the item is about.
3. Use one tag per concept.

I like to use this rule of thumb to check to see if the tags I’ve chosen are accurate: If I did a search for the tag I’m considering, would I be happy getting this post/image/content item? If the answer is no, I drop that tag.

Following these rules to tagging insure that your tags are appropriate for your post/image/content item. Targeted tags help ensure that recall as well as precision are high. You want the folks who are interested in your specific topic to find your thing. If you are talking about the giant green dinosaur with glowing red eyes in South Dakota, you don’t want to tag your post with general terms like “United States” or “statues.” Better choices would be “Wall South Dakota,” “dinosaur statue,” “glowing red eyes,” and “kitschy roadside attractions.”

Recently on projects I’ve found myself designing a number of search results pages. While each project has its own set of requirements and nuances, I think there are a handful of elements that should be included in most all result page interfaces. If you start out with this list, and then tweak as your situation requires, I think you’ll end up with a pretty good page.

Here are the items on my checklist, in no particular order:

• Highlight the query term in the results.
• Restate the query on the results page.
• Show the number of results that were found.
• Include next and previous buttons, as well as links to additional pages, to move through results. These should be smartly linked; no link on previous if you are on the first page and so on.
• Include a query box so the user can search again.
• Don’t show the URLs of the result pages, unless your audience is techy enough to derive meaning from the URL.
• Have meaningful page titles and descriptions for each result.
• The page title should be the link to the result.
• Allow sorting and refinement tools if appropriate for your users and content.
• Indicate if a result is not a regular page (e.g., a PDF file).

What items do you have on your checklist?