Adam Churchill: Welcome everyone to another episode of the SpoolCast, Donna Spencer is one of our favorite presenters and has regularly gotten rave reviews for her workshops at our live conferences.

Early this year I approached her about doing a UIE virtual seminar for us. And thought we had some great ideas but Donna told us she had the great new thinking she was ready to share and it was one about organization schemes.

So back in September from half-away around the globe in Australia she gave a great presentation on this topic of organization schemes.

As is always the case with our extra ordinary presenters and their talks we had our audience thinking and got oodles of great questions. But we were left with some we didn't get to so Donna has graced us with her presence again and has joined us again to try and tackle some of those questions.

Hello Donna and welcome back.

Donna Spencer: Good morning, how are you?
Adam: Very good. Now folks who did not listen to Donna's seminar can still get it at UIE user experience training library, which has gotten over 40-recorded seminars from experts just like Donna.

Donna those who were not listening with us on the presentation that day can you give us a quick overview of what are organization schemes and why the people need to think about them.

Donna: Anytime you have a project that involves organizing large amounts of information or even small amounts of information. But, of course it matters more when you can be working with larger.

You need to figure out not only what the labels will be and things like that. But the actual, the schemes you are going to use to present that information to people.

And what I mean by that is are you going to organize it according to alphabet or are you going to organize it according to its geography, are you going to use like an audience base scheme where you break it up according to who your different audiences are.

Or maybe a task base scheme or and the most common one we tend to use it is like a subject or a topic scheme. Something that is just around the topics that the contents about.

And that's actually one of the important decisions in any sort of information architect product is figuring out which schemes or schemes are going to be based for your stuff. Then a follow on design work, which is actually figuring out what, goes within them.

Each of them has pros and cons naturally and works differently for different types of content. And sometimes this would be just completely yep duh; we know it is going to be you know if you have an obvious choice. Sometimes it takes a bit of thinking to figure out what's what.

There's also some tricks entered in that some of the schemes people tend to use a lot and mainly audience schemes. Sometimes seeming obvious and seem like there going to be a good choice and like pretty much a no brainier but are really, really hard to make work well.

Adam: All right that's great, let us get to some of those questions that were left over. So, card sorting you literally wrote the book on it as we talked in the beginning of your seminar you had people thinking along the lines of "how do I approach my lines of information architecture."

So, Janice wants to ask do you always start your information architecture planning by doing a card sort first? And, how strictly do you adhere to what users might suggest in that exercise?

Donna: So I'll backtrack a touch with that as well. The reason that card sorting, actually I'm maybe going to backtrack a touch more. Card sorting, in case people have not heard of it before, is a technique where you write down content ideas on index cards; this can be done physically or online.

And you give those index cards to the people who will be using your site. This is something you can do with your team but really, the value of it is giving it to other people and then they group them together into groups that make sense for them.

And the real value you get from that is understanding how people think about what goes together and why it goes together. So, it is a fairly well used technique for information architecture work.

A lot of us do it as a research part of our project to get ideas of how we might do things but also to really understand how our users think about that content.

So, even though I wrote the book on card sorting, I don't use it for every project. I use it for a lot but the types of projects I tend to use a card sort for are ones where when I've worked through many other user research and when I worked through the content. I'm still a bit certain about a good way to go about organizing it.

I might also do it when I have good ideas, who know if my ideas are good.[laughter] When I have ideas about how we might go about it but I want to confirm either that, I am not on the wrong track or I want to show that it provides the evidence that the ideas are good. So there is some of the reasons might use it.

The times that I don't when I'm already pretty comfy with the topic, the users, the content, and I don't feel like I'm going to get anything additional out of card sorting.

I always will have done some other type of user research that whether it's interviews or surveys or having a chat with people on the phone, or looking at emails that come in.

So, I've always spent some time understanding users this isn't, I'm not just being a genius designer and making it up as I go along. There are types of situations when I might use a card sort and then say I've done a project and I've run that and I have some results back.

The most, most, most important thing in a project is you don't pick up the results from the card sort and say, "look users said this, therefore that's our information architecture."

And that's because even though you can get incredibly good insights and you can get sometimes better insights from the discussions that people have while I do it if you do it in small groups than from the actual you know what went with what. You use those insights to put together with everything else you know to come up with your information architecture.

And, I don't know, that might seem really quite obvious but I have seen lots of situations where people didn't do any other user research, did a card sort, use that as is for there information architecture it just doesn't work.

Sometimes part of the reason it might not work is some of your users might have gone well this card is for current students, this one is for future students, and this one is for staff and organized all the cards into a sort of basic organization scheme and some might have said well that is about fees that are about enrollment that is about graduation.

Then you got this topic scheme when you look at the results all together there is nothing consistent anyway.

So if you used it like that you would end up with a great big mess. But using the insights and then combining them with other things is incredibly useful.

Adam: What I'm hearing you say it is a tremendously useful exercise or process but it is always best to, can I use the phrase checks and balance?
Donna: Absolutely.
Adam: So when you use other research practices that you put in and play with it, checking your data?
Donna: That is right and we all talk about this with all sorts of user research. It is never good to just rely on one source of information. Every user research method we use has biases, things like focus groups which can be incredibly useful if you know how to run them well can get into some group think or some, you know, go down tangents and miss key points.

And surveys do not always catch a lot of rich data, but capture large volumes. Interviews, I don't know if interviews have biases, interviews are awesome. Everything has a bit of bias in the way you collect it. So, if you only use one source of information you are going to miss some important things.

I wrote an article on it somewhere it was about triangulating user research. Which is about saying I am going to use different sources and I am going to pick out the pieces that are the most consistent. Because I can trust that there's some reality in those.

Adam: We got to a part in your seminar where we talked about testing. Even though we couldn't see our audience you could tell they were nodding there heads in were wrapping there minds around this concept you were talking about.

When we got to the testing piece our question and answer box filled up because it was, that is what people wanted to know next. So, Ann asks a simple question; how do you test a scheme once you've hit the magic point?

Donna: Let us say were in a project situation we have gone in and come up with our draft information architecture basically. You know your content well; you know your users well. You've taken a creative leap and gone, "Here's how I think we might do this."

So let's say we're working with, I don't know, maybe a fairly information heavy site. You've come up with maybe some top level categories and some second level categories for those, and maybe some third level as well if we're talking about a sort of hierarchy. And you've also come up with names.

Of course, in this process you might have come up with, again in the organization schemes idea, you might have come up with two different ways that you could do it as well.

You might have decided you've got a basic subject scheme, but you want to see whether an audience scheme is going to work. Or you want to see whether people would prefer to access your information according to its geography.

So, you might even have two things that you want to test. But you definitely will have some categories, and you'll definitely have some labeling that you are thinking of using for those.

So once you have that piece of information, it's a perfect time to go and do some testing on it. So, this is before you've drawn wire frames, designed navigation, designed content pages or anything. All you have is some basic idea about the information architecture.

The value of doing testing at this point is that you can test the categories and labels, and even the concept, in abstract of everything else that might eventually interfere.

So, you can really focus on just looking at how well those work without worrying about whether people actually saw the navigation, or whether they could read it on screen, or all those sort of things.

It's certainly not the only usability test you should do on a project, but it's a great time to just focus in and really see whether these are working.

The way that I do this - This will always depend on the client and the situation, and how easy I have access to users - I basically write out a big pile of scenarios of things that people I know from our research and things, that people might want to do with this site.

So it might me, to use one of Jared's old examples. You're sitting in your lounge room surrounded by books. Find something to shelve all these books without actually saying, "Go find a bookshelf." I'm sure Jared's example of that one has better terminology.

Or, where would you go if you needed to find out what this University offered in terms of architecture programs? So you write out this big pile of scenarios, and you write out your hierarchy. When I say write out, you can do this two ways.

If you are in contact with your users and this is a perfect way to do it for an intranet. I do this on cards, just like I do a card sort. So, one set of index cards has the scenarios, and one set of index cards has the hierarchy.

So, I'll just write it out by hand on these index cards. So the first card has the top level, and then for each item in there I have another set of cards, and the next level, and the next level, or however many levels you might have.

It's very hard for me to describe this in words. You should see me; I'm drawing it in the air as I go. [laughter]

I could give you some references later on, where there are some photos of this too.

So, there we go. We've got a bundle of scenarios and a bundle of cards. This is a really, really fast usability test. So if I'm doing this with something like an intranet, where I have access to people. I might make arrangements to, you know, to talk to people, or I might just actually zoom around people I know, or zoom around the building, and ask people for five minutes of their time.

I'll basically say, it's something like, "We're working on the organization's intranet. We've got some ideas about how we want to organize this, but we want to check that it's working. Can you tell me, for this thing," and you point at the scenario "... where if you want to do that. Where would you look?"

And they point at the card on the thing they might choose. You pull out the next set of cards for that level. "OK. Where would you look again? Where would you look again?" Until they get down to a point where they go, "I reckon it would be there."

Now there's a couple of tricks of it. I never let them try more than twice, because I'm not asking them to go scavenger hunting through my cards. I'm asking to find out where their gut reaction, where they would go first, is. Because that's the thing you want to learn. Where, if they had to do this in real life, where would they go?

And, I make sure that it's really clear that I'm not asking them to find the right answer. I'm asking them to give their reaction where they'd look.

Now, if I'm not in with a client, I might do this online. There are two tools that are good for it, and I'll give you the links for these. One is called Treejack. That's done by Optimal Usability, who also does the card sorting tool Optimal Sort.

And the other is called PlaneFrame, and is done by the guy who does WebSort. Because these tools all work together.

Both tools work in a similar situation with what I just described with physical. You write down a pile of scenarios. You put in your hierarchy. You shoot it out via email to potential participants and ask them to spend a couple of minutes telling you where they might look for that particular content.

The results are really, really easy to analyze. You basically get really clear information about where people would look for a particular scenario.

I usually drop it into a great big spreadsheet, with maybe the hierarchy down one side, and the scenarios across the top. I just mark where people are going to look and you see the patterns really quickly.

Something else that I do when I do it in person is, if I'm seeing fairly quickly that people are struggling with a concept, or struggling with a label, I just rewrite the card.

I make a note of who did which set of cards so we can analyze it, but I might just rewrite a label and see if it works better with the next sort of people. It's sort of like A/B testing on the run.

So don't be afraid of going, "You know, this really isn't working, I'm going to change it." You could do that online as well. You could keep an eye on the results as they come in. Stop the activity, make a few changes, and go again.

Just again, keep your results separate so you can see the differences. But it's a great way of then adapting and trying different things. Of course with both types, physical or online, you can definitely test both, one or more approaches.

Adam: OK. So, Casey wants to know when you're doing this testing. She asks a question about how you tie your users and the content together.

Specifically she asks, "When you're testing a scheme with a large site, all sorts of topics. How is it best to test it? Should you take sections of the topic and test only the groups that would be familiar with that type of content?"

"Or do you just kind of throw everything out there and ask everybody that you're testing to kind of spread themselves over the whole gamut of content?"

Donna: That's a really, really good question. And in order to make a decision about which way to go with that, you need to have some fairly good information about your users already.

Of course with this type of testing, especially if you're doing it face to face, you could just ask people to skip over scenarios that they would never do. I can't remember off hand whether the tools let that happen. I think that you can just skip the task.

The reason that you would do that is because there's little point - and this goes for all types of usability testing -

There's little point testing things with people who aren't of the right audience, or aren't going to do the tasks in their life. Because they're just making it up, it's not real information. You really want to be getting this information from people who would have to do it.

So, you can either try to figure that out ahead of time, and only ask parts of your audience to be involved in testing of the things that make sense to them.

Especially if you got a really big site, that you want to narrow it down and just focus on a part of it. That's a fantastic way of doing it. Or you could still let everybody try the whole lot, but making sure that they're allowed to skip things that they would never do.

Now, I just had another thought about this idea as well. This is only going to test the concept of somebody coming in maybe via your home page and walking through your hierarchy.

You do have to remember also that a lot of times people will land in the middle of a site from Google, and weren't necessarily be going linearly through from the home page down.

So, I'm not suggesting that you start testing at the bottom level, because that's not going to work. But just be aware of that as well that you're only testing one path down through the site.

Adam: One of the questions we tackled during the seminar, and I know we talked about circling back on it, was the one that came in from BackCountry.com. Their question had to do with how you deal with competing or what you might refer to as multiple organization schemes on the same site.

The example they posed was somebody goes to a site. They're thinking about planning their summer vacation. So you might have schemes for summer, family travel, vacation, all of those things in a single interface. How do you deal with that?

Donna: The interesting issue for that particular example is that when you think about summer and vacation, and family holidays, or whatever. If you think about the types of content that might be underneath those, there's really going to be a fair bit of overlap. That's OK to an extent.

I'll go back a bit to the thinking process of when you're coming up with those groupings and those schemes.

One of the things that I've discovered in working through lots of projects is there are lots of times when the groupings that you might want to use because you know that they are meaningful to people and particularly these and this is a fantastic example -

Because people might be planning there summer vacation or a thing with their kids or have a particular way of thinking about their holiday.

So you may know this about your users and you may want to go, "I know people think like this let's make sure there's an entry point and a way to get into our stuff for them."

As you do that, let's say you come up with some good headings and you really like them and they feel good. Then the next step of thinking it through is to look at your content and see what content assigns across each group. Now this comes up a lot with for audience schemes as well.

If when you go and look at your content and apply it across those groups, if all content is covered by all groups or even a large proportion of content belongs to each of those groupings, that for me is usually an indication that I am on the wrong track.

Because it does mean people will be getting confused. They will be looking going, "ah, it could be here, it could be there or I'm not sure where to go."

If however and again using this type of example with summer, family travel, vacation, holidays with kids. If you are working through something like that and when you look at your content you, will least have a fair proportion that only applies to one of those groupings? That is an indication again that you are on a fairly good track.

That when people come to it they might look and go OK, I think my themes are going to be around here.

So it is definitely OK, to have things that overlap. Really the advantage of it is that when you are working with anything that people think about it in different ways or have different ways of organizing themselves or their approaches.

They will see something on the screen and go yes, that one is for me. And they will just go into that area and everything is there for them a life is wonderful. That is really the benefit for the users. So it's fine to use.

The other thing that this question could relate to is whether it is OK to use. Again, this holiday example is a fantastic one, is it OK to use stuff like topical, so family travel, plus maybe I don't even know what we would call this, seasonal summer, autumn, winter.

Plus maybe geographical where is your holiday and again it's OK to use more than one of those types of schemes. Because people may be thinking about it differently.

Some people may think here's a good example; some people might think that they know they want to go to the Boston area in autumn to see the trees. I know I have done that it was an incredible experience it was a seasonal issue. Because you see them in autumn and it's got a geographic aspect.

So, if you know you want to do that seeing it geographically or by season may be perfect. But, it is not going to help you if you are looking for something that is going to work for the family. Having different types of schemes is also fine because people may be more approaching the content in different ways.

Adam: Ann wants to know what are some of the best practices are for naming tasks. This came up in the seminar and we talked about it a bit but what are your best practices for naming tasks so that users can recognize them easily?
Donna: Sometimes with the information architecture work coming up with the categories and the concept and like what schemes are you going to use and things is relatively easy. Sometimes the real trick is coming up with the words that you are going to use to describe them so the labels.

And this could be really tricky. When somebody approaches your staff and they got something in their head and they are looking for it on screen we need to make a connection with what they have in their head and what they are saying. So, we really need to make sure we understand the terminology our users use and make sure that is available to them.

Said like that, it sounds not too hard, you do some user research, you understand what your users say, and you make sure you use those labels.

The trick with that and boy this can be hard is that often users use terminology that might be out of date. So in Australia the thing you get at the end of the tax year from your employer that then you use to do tax stuff is called I think it's called now "pay as you go certificate."

However, for years, it was called a group certificate. It has not been called for oh man, at least 15 years I suspect but people still use the word group certificate.

So people will use old terminology, they will use the accurate terminology and if you try to use that in an interface people who prepare the content and who know the most about the content [laughter] will have kittens and validly because language is all about trying to be fairly privies so were communicating well with each other.

So, people call things particular things so that you communicate an idea. We definitely do not want to use terminology that users use if that terminology is inaccurate because people who do know it will go, "what?" and you just never win that war with your content office because it is wrong.

The thing we really need to do is build bridge between those two things. So, if you got something that leads straight forward you can use the user terminology. But, if you got something a bit more complex, sometimes scientific, we've got to bridge between them.

And there is no absolute answer is to how you build that bridge between your terminology and users' terminology, it depends how far apart they are. One of the examples I used in my book is from my favorite site, which is called yogajournal.com.

Yoga poses are known by English names and Sanskrit names and an individual yoga teacher through a class will juggle between the two as well. Sometimes we know, like I know Bakasana is crow pose, the thing you get up on your arms and you look up standing like a crow. So the same Bakasana and crow pose, some yogis will know one some yogis will know another.

You go to the website to look up that pose and they actually got a listing of all poses side by side with English and Sanskrit side by side so you can find it easily and you can build that bridge. I thought that was a nice example of building a bridge between user terminology and more technical terminology.

If it is going to be a big deal for you, you need to work through and design a solution for it. Sometimes glossaries and things like that can help as well, so that is important and hard.

The other things we really want to make sure we do with labels make sure we use them consistently. So, don't call something one thing in one part of the site and something different in another part of the site.

And also remember that people spend time on websites other than yours so if there is a term that is frequently used within your industry or on other sites that people will be using. There is nothing wrong with using that same terminology; we do not have to reinvent everything and be unique in everything.

If all consultants call their services stuff services it does not hurt to use that same term. People will have experience with what's it called and be able to fairly easily spot it and go yes I know what that is all about. So be inventive where it is worth being inventive and be boring where you do not need to.

So yeah, making sure you are consistent internally and consistent externally. And with your labeling being really as clear and precise as possible. Not using fancy terms or calling things by weird names. I was looking at but something the other day it was called E-Press and E-Publications and I looked at that and went, "haven't a clue."

One, why does it need to be called E? Two, what actually does it mean? And I still do not know what E-Press and E-Publications would mean.

I had a long argument with somebody many years ago about an intranet they wanted to call library stuff I-Gate. But like all the users new about the library so it was like just don't use that fancy term because nobody's going to get it.

We would have to educate everybody on what an I-Gate was when they actually new about the library. But going back to our discussion before about testing these are things that are easy to test. So you can have a go at your labeling, throw it out to a quick user ability test and you will quickly see whether people understand it or not.

Adam: Well this was awesome Donna, thank you for coming back to tackle these questions.
Donna: Thank you for having me again.
Adam: Thanks everyone for joining us for another episode of the SpoolCast. Good-bye for now.