DonnaSpencerInterview Jared Spool: Welcome, everyone, to another episode of the SpoolCast. Today I am very pleased to be talking, all the way from Australia, with Donna Spencer, who is going to be speaking at the User Interface Conference in October. She's a world-renowned expert in information architecture. She's going to be doing a full-day seminar called "Information Architecture Essentials: Best Practices for Organizing Your Site's Content." Welcome, Donna. Donna Spencer: Thank you, Jared. Jared: You have a small consultancy called Maadmob, and you have been doing -- how long have you been doing information architecture now? Donna: I think I've been doing it for nine years. I always have to count back fairly carefully to figure out when I started, but around that sort of length of time. Jared: Can you give us an example of some of the types of sites and systems you've been doing this type of work for? Donna: Because I work mostly in Canberra with government agencies, I still do loads and loads of government work. I did spend a few years doing intranet work when I was working for a consultancy that specialized in intranets. I don't tend to them any more. But I do lots and lots of government websites. But I do also design big business application. So I'm working on a big call center application now, as well as working with a government client on -- I just do lots of bits and pieces for their website. So it's always big stuff. Jared: Even though you work on lots of different things, are there commonalities between these big projects, things that you seem to run into frequently? Donna: Government sites as a genre are really, really similar. So I do run into quite similar problems, which is why I also balance it up with some interaction design work. Otherwise, I would just go mad doing government sites endlessly. But, yeah, there are real consistent issues. And the absolute most common one still is that there is just a natural tendency to organize a site the way a department is organized. To structure a site according to the business organization chart. And even though, if we read stuff, we've known that that's a bad idea for a really long time. That's always the first place that I have to start with people, explaining the difference between organizing stuff for people to read it and actually pitching it to them and selling it to them and writing for the people who are going to read it, as opposed to telling the world what you do within your boundaries. And that's the big conflict that always happens at the start of nearly every government project. I don't know that it's any different from big corporates either. The one that I have worked with have the sort of mentality of, "Let's tell the world what we do, " rather than, "Let's make information available in the way that people want to read it." But it does still surprise me that it's such a common problem and I have to explain it and go into a lot of detail every single time. Jared: Oh, yeah. It is definitely a big problem in almost everything. People still approach the Web as a giant brochure. And they think in those terms. It's like, "Oh, we want to tell them everything we do." And they don't think about, why is somebody coming to this, what are they coming for. Donna: And it's that issue of, "I want to tell them what I do, " that's at the core of it, because once they can remember to think that, "I'm going to tell them the things that they want to know, " it's really a different mindset to, "This is what we do, so we're just going to explain it." And it means they actually have to think about the people who are on the other end of stuff. Jared: Right, right. That makes perfect sense. Over your travels, you've gotten to see a lot of people doing information architecture. Some people are good at it, and I'm sure you've come across people who are really great at it. I was wondering, are there things that you see that sort of separate the folks who are good from the folks who are really good, really excellent at it? Donna: You know, the thing that really separates -- and you said good, but really what is probably the more important issue is successful. Good IAs need to know the core. They need to be able to really think structurally, and be good at pulling things apart and putting them back together, and organizing well, and really caring about labeling and language, and all of those things good IAs need to be able to do. Great IAs do all that, but do the human stuff really well. So great IAs really play nice with other people. Because an IA is not something that is really ever stand-alone or that is a neat chunk and you don't talk to anybody. IA is something that absolutely needs to be done within a team, and everybody needs to be involved and you have to explain to everybody how things work. You have to talk to stakeholders and you have talk to content authors. You have to work as a team. I've worked after some bad IAs who just wanted to have their little box and do their work, and didn't want to explain or justify or have anybody involved. And great IAs who just work nicely with people, who get in and get the job done, and explain things well. Who do that human stuff really well. Jared: Can you think of a project that you worked on where this distinction really came out? You don't have name names. Donna: No, no, I wouldn't name names. [laughs] Jared: But can you think of a project where the difference between someone who was just good at the IA stuff, it was going OK, but then you got someone with really good people skills in there and you saw a marked improvement? Donna: I've actually seen the opposite. I worked on a project a while ago where somebody really good was going the IA work in the early stages. The team knew the rational for why she'd come up with particular things and were quite involved in the process and really understood it. So that when you needed to explain it to anybody and say, "The reason we're doing this is because of such and such, " everybody just went, "Oh, yeah. OK. Got it." That person left, and person with a different personality came in, who was much more into sitting in front of the computer and drawing up the IA and drawing up site maps and things. Not so much in being like a collaborative team worker. So when the team had to go and explain things to other people, show their ideas or talk to management, they lost some of that rational and the background for why things were the way they were. They had nice diagrams, but they didn't have that whole experience of this is what the IA does. The IA as a noun there, not as a human. And probably in most fields, that's where you get the difference between good and great. Good, you have the right technical skills and you know what you're doing. Great is all about working well. But there's definitely another piece that is different between good and great IAs, and that's that ability to work at detail and broad all at once, and also synthesize everything. Take the user research and content analysis and consults and discussions and business goals and all of these things that are an input, and to pull all of them into something that really works. To keep an eye on all of those, and to keep an eye on what you're doing on the detail level all at once. And I think that that's a peculiar skill that not so many people have. Lots of us are really good at doing detail work and lots of us are really good at doing strategy work, but the ability to do both at once and to flit between them from second to second, is pretty amazing as well. Jared: A lot of information architects that I meet, who are sort of past the starting stage and really getting into their work, they seem to have mastered the detail work part of it. People who are detail- oriented do well as an information architect, that's been my experience. Donna: Yeah. You have to, because you have to.... [laughs] This is the problem I have with sort of consulting IA is done, where a team will hire a consultant to do a piece of IA work of them. And the consultant does a good job, does the research, talks to stakeholders, etcetera, etcetera. I've seen lots of these, and they deliver an IA that might have the top two or three levels of a site and a bit of data from some areas, but then a team has to implement that. But the devil is in the details. It's the detail that falls apart, when you try to really plug the content in, when you try to really work the content to fit that thing. I've come in lots after consultants to do the detailed end and to try to work it into production, and I've just not been able to, and had to really restart. Because that broad level, if you haven't played with the detail at the same time, and really worked hard with the content, you don't get the broad level right. So we have to be able to do detail. It's just a core IA thing. Jared: Right. So you've got the detail nailed, if you haven't done strategy before, where do you think you start, in terms of getting those skills and getting that going? Donna: That's an interesting one. The way that it's probably going to work is by getting into it and by doing it. I don't know how you would actually learn how to do the strategy end of things without that just going up a level and working it through. And thinking about the bigger picture and working toward the bigger picture. But in order to do that detail, you should have had the bigger picture anyway. That's the bridge between doing broad work and detail work, it's the understanding of where you're heading and understanding the big picture and trying to hold the big picture together while also figuring out which content goes where and what hyperlink should be called. If you're trying to do detail work at that level without the big picture in your head, you're going to miss the mark anyway. Does that make sense? Jared: Yeah. No, it makes perfect sense. That knowing where you're heading and sort of having a vision in your head of what this experience is going to be like down the road. And knowing where that's going. And I guess part of it is also having a real sort of understanding as to what the long-term business objectives are. Understanding why do have this design in the first place? How are we going to use this to make us successful? I would think that those are key elements. Donna: They are. And the whole team has to understand them and understand them properly and deeply. Jared: Right. You do a lot of government stuff, and in the commercial world it's all about selling products and making your shareholders love you. In government it's different, it's all about playing to the constituencies, right? Donna: Probably not here so much, I don't think. In government it actually can be really, really hard to figure out. Even senior management, having discussions with quite senior people about what their goal is and what their big picture aims are, it can be really tricky to get out of them. And then especially if they don't get the Web either. They just know they want a website, and they want it OK. But they don't have often -- at least a lot of the projects I work on don't have a really clear idea of what their goals are. And a lot of work I try to do at the beginning of a project is to get people to at least think through that, more than, "We want to tell people what we do." So here a lot of the need is more an educational one. I just finished working on a big piece of a website for Australia's heritage. And they had a fairly clear goal of wanting to communicate pretty much how awesome Australia is and why our heritage is important and what's really neat about all the stuff we have. And it was a really good goal to be working with because it gave lots of flexibility, but there's still this big picture of, "This is why we're doing it." And it's quite different from saying, "This is what Heritage Division do." But it's not always that clear why. You see it not only on the Web end, but in other styles of communication. So, "Who have you produced that publication for?" "Oh, I don't know, we just had to produce it because we paid government funds for it." [laughter] Donna: But that's a part of it too. Because we used government money, we have to show what we spent that money on. So we have to produce something. And when that's the goal, it's hard to figure out who's on the end of the production, who you're aiming at, how it's going to work, who's going to use it. You just have to produce something. Jared: I've seen very similar things in business where people are sort of focused on this deliverable. "We have to produce an application to do X, because that's what we got the budget approved for." And there's really no sort of thinking about that once that's done, how does that plug into the rest of the process? How do people get a benefit from that? How do you make that a better overall experience? They're like, "Yeah, we haven't thought about that." Donna: I've thought a bit about it, and at least some of what I see, what people would really like to do is do continuous improvement, to really just keep working, to do that stuff that small agencies can do for themselves, that I can do for my own website. Extend it here and change this bit, write some new content and pep it up, and really continuously improve it. But there's this whole budget cycle thing. And because people have to bid for money to do projects, the process tends to be really redesign-heavy processes, rather than, "Let's get a tiny bit of money and do a little bit of work here. Let's get a little bit more money and do a little bit of work here." It's really project-driven, which is budget-driven, which is just backwards. You should really be able to do continuous tweaks, and to build something small and add to it, rather than going, "OK, we've got a project. We're going to start now and redesign. In six months we're going to have this new design to launch." That should just be so unnecessary. Jared: So if someone is in a place where they can start thinking about these sort of long-term approaches, what's your wish list in terms of this? Is it having a way to do continuous change? Or is it going out and going research? Do you have something that's at the top of your list. Donna: If I had a wish list for a way I could make a project or make a site work really well over time, it would be doing small pieces, doing them well, doing the research that you need to do them at the time. Doing the research, making something, make it work, keep an eye on the bigger picture, keep an eye on the bigger goals, and move onto another bit. Rather than these long projects that just really take a long time because there's a lot of work to do in them. By the time you get to the end of it, you've forgotten the beginning. Being able to tweak small areas and things, or even do mini-redesigns of a section of a site, it much more effective than always doing big budget-driven redesigns. And one of my very favorite clients I work quite freelance with and we have not a project-level budget, but a more hour-by-hour sort of thing going. And we can then do this. So if we see a spot of the site that needs some work or that we know something's coming up in the future and there's going to be attention on a particular topic, we have the flexibility of actually doing small bits of work because they've actually structured it in their budget to do it that way. And that's one of the reasons I really like working with this clients, because we can all tackle little things rather than going, "OK, we've got to redesign this whole website and it's going to take three years, and by the end of it we're going to have forgotten the beginning of it." Jared: Yeah, that's exactly that advice we've been giving our clients for a long time, which is to stop thinking in terms of redesigns of everything, and just focus on some piece that's strategically important, that if you could make some improvement of in a short period -- months versus years -- that you could see those results and you would learn a lot about who you users are and what they're trying to do. And you could apply that information to other pieces of the project and you'll be going into other portions of it without the risk of not knowing any more than you do now about how people use the site, what they're trying to do and all those issues. Donna: It also makes the research process less scary. Something that I see a lot when I talk to people is they're scared by the idea of going out and doing user research, because it feels like it's has to be something that's big. And if you're going to do some work on something smaller that you can focus in on, then research is easier than, "Oh, my god, we've got to learn everything, how on earth are we going to do that?" Saying, "I want to improve the publication section of this site." We can find people who use government publications, do a small bit of research on them, make sure we capture the results so it will be available for future staff. It's just not so scary, and much more approachable. Jared: Do you also find that it limits the number of stakeholders that you have to appease, when you're doing a smaller piece instead of a big redesign? Donna: Yeah, it does, doesn't it? Because there are just fewer people who need to be involved in that one piece, compared to doing the whole intranet for a company or department. Everybody needs to be involved. But if you focus on making your HR area sign, or your travel process work really well, then not only do you have involve fewer stakeholders, you can get closer to the people who are really doing the work and really need to be involved in detail as well. Jared: Right. That makes perfect sense. We talked about a couple of things in terms of becoming a really great IA. We talked about having really good people skills, we talked about having to do both the big picture stuff and strategic stuff, but also get to the detail. And we talked about being able to break things up into smaller projects and not trying to do large designs, but in fact do lots of little changes, see the results, try it again. Anything else that you can think of that separates a great information architect from someone who's just good at it? Donna: I think the other thing that separates a great person that does IA is that they do more than IA. And that they do more than IA well in other areas. I don't know, do you remember 37 Signals said a couple of years ago that they would never hire an IA? Jared: Right, I remember that. Donna: Because they consider it such a specialist field, and it was too narrow a specialization. I think in most cases they were right. There are few times when you need a dedicated person to do only IA stuff. Most of us do strategy, content writing, interaction design, production. Most of us do loads of other stuff beyond the core of IA of organizing, labeling, designing navigation. And so I think a great IA does other things as well, and does them well. I do just as much interaction design and detailed hard interaction design as I do IA work. Everybody just knows me as an IA. Jared: Right, right. I think that that's true. I think that it's really a luxury these days to be able to specialize in just information architecture or usability testing or interaction design or visual design or any of these. I equate it to hospitals work. A really big teaching hospital can afford a person who specializes in a particular type of cardiac surgery or pediatric oncology or something like that. Donna: I'm sure I've heard you talk about hand specialists before. [laughs] Jared: Exactly. Exactly. But if you're at an average hospital that's in the middle of a community that has to service anything that comes in the door, but doesn't have people waiting for specialties, then you have to be a doctor who can handle any type of problem that walks in. And you have to be much more of a generalist. And if that hospital can't afford someone who only does hand surgery and won't do legs or hip surgery, because they don't have enough business to keep that doctor busy on just hands and wrists 24/7. Donna: And that wraps right back into the first point of playing nice with others and working well within a team. Of not going, "I do IA and here's my boundaries." But, "Here's something I do really well, and here's something I do really well. And you do that really well. Let's just get in and do it." Jared: Now in October, on the 15th of October in Cambridge, Massachusetts, you are going to be teaching a seminar at the UI 13 Conference, called "Information Architecture Essentials: Best Practices for Organizing Your Site's Content." Do you want to take a minute and just walk us through what people are going to learn from that? Donna: I've taught this workshop for a while now, so I know what people really like about it. The stuff that we're going to cover in the workshop is some of those things I've talked about: figuring what the goals of a project are, doing user research and how user research is a bit different for IA work than for some other user experience work. Looking at content, really focusing a bit on content analysis and thinking about different types of classification and different structures. The process of how I actually create an IA. I've got all this stuff in my head on one side and I've got a blank page on the other side, how do I make an IA? And then about navigation design and things as well. So that's the stuff that we're going to talk about, and the way that I arrange it so I'm not just talking to people endlessly for six hours, is that we work through designing a website through the day. So every time we talk about an issue, we can go and put it into practice by working through this little website. And the pitch is, a bunch of winemakers from a small wine-making area have come to you and need a website. So we work through that one. It's always pretty fun, and gives us plenty of opportunity to look between structured and unstructured data and all sorts of fun things. But the things that people always tell me, and that they write on their feedback sheets, is -- the most common comment is -- "I did know all that stuff, I just didn't know that I knew it. And now I know that I know it. And now I feel more confident about going and doing it." And I also give them a really big booklet of references and follow- up readings. Some people love that as well. I think it's really important to have people walk out of a workshop with stuff that they can go home with, but not expecting them to walk out of it in their head and just go to work and do it tomorrow. So giving them things that they can follow up and other places to read and ways of making sure that they can go back and get that knowledge into their practice. But it is interesting the people that just go, "Yeah, gosh, I knew that! And I'm really glad that I know that I knew that now, and I'm confident about what I'm doing." Jared: This is a full-day workshop. Is this a session for people who are just sort of starting, or can people who've had some experience with information architecture come in and get some real value from this session? Donna: It's definitely very good for people who are starting, because I have taught it before, because I have taught it to people who have been doing IA work for a while, but started it like most of us do by just falling into it and having to figure it out. People who have been before and who tell me about their experiences, tell me that even though they've been doing IA they got a lot of out if it. One, because I talk a lot about my experiences, and people love hearing stories. And I do have a lot of experience, so I have a lot of practical things that I can tell people. I can answer lots and lots of questions as well, because I've had a lot of experience. So experienced people like that, that they can pick up things that they didn't pick up. They too are going, " I've been doing it OK, and now I've got some extra tips on doing it better." I wouldn't say that somebody who's been doing IA for five years would necessarily want to attend. [laughs] But somebody who's been doing it a while and probably fell into it and had to get started and have been playing around and doing OK work and just want that sort of bigger picture and structure, could definitely get stuff out of it. Jared: I think a lot of us fall into it, where we just sort of wake up one morning and people are like, "Hey, we need you to rethink the way we designed the website, can you go figure out our new navigation?" And next thing you're an information architect, and last week you didn't even know how to spell it. Donna: That's certainly how I've done everything. [laughs] Just having to do it and thinking things through from first principles and really figuring it out from the ground up. Jared: Yeah, I can tell you that I got into a lot of this -- and then people gave it a name. When I started doing usability work, we never called it usability work. We had stupid names for it, like "software human factors." Which I am so thankful we don't call it anymore. [laughter] Donna: That's right. At least most people understand "usability, " and lots understand "information." And if you can put "architecture" with it, they have a vague idea of what it means. Jared: Right. Absolutely. Well, excellent. It's going to be fun to see you in October. Donna: And you. Jared: Yeah. Donna: It'll be very fun. I've not been to Cambridge, so I'm looking forward to that. Jared: Cambridge is beautiful. You're going to come right in the heart of foliage season, so you might consider coming a day or two early and planning to rent a car over the weekend and drive. You won't have to go more than an hour or two to see some of the gorgeous leaves. Donna: Oh, excellent. Jared: That will be in full foliage. I guess they're not "in bloom." It's because they're dying. But they will have just turned colors and they'll be absolutely gorgeous. They'll still be on the trees and it'll be wonderful. Donna: Excellent. I will come early. Jared: Super. We've been talking here with Donna Spencer, and she's from the organization Maadmob, that's her little consulting firm. She's going to be teaching "Information Architecture Essentials: Best Practices for Organizing Your Site's Content" on October 15th at the User Interface Conference in Cambridge, Massachusetts. Thank you, Donna, for playing along with our little game show here. Donna: [laughs] Thank for having me, Jared. Jared: We'll talk to everyone next time. Thank you very much for listening.