Four Essential Skills for Information Architects: An Interview with Donna Spencer

Donna Spencer is a recognized expert in the area of Information Architecture and author of Card Sorting—Designing Usable Categories. Jared M. Spool recently had the opportunity to talk with Donna about the specific skills that separate the best information architects from the rest. Here are the highlights of that conversation.

Jared M. Spool: How long have you been doing information architecture work?

Donna Spencer: I’ve been an information architect for nine years and have a consultancy, Maadmob. These days, I work primarily with government agencies, but I have also designed big business applications and focused on intranet work.

In your experience, have you found certain skills separate the excellent information architects from the rest?

All information architects need to think structurally, organize things well, and really care about labeling and language.

I’ve found that excellent information architects do all of these things well, but they also excel at the human component, playing really well with other people. Information architecture is never an isolated, stand-alone activity. It has to be done with everyone on the design team involved. The excellent information architects work well on a team, communicate effectively with stakeholders and content authors, and do a great job of explaining to everybody how things work.

I’ve worked with some less effective information architects who have their isolated box for accomplishing their work, and don’t want to explain or justify their decisions. The great information architects explain things well, work nicely with people, and get the job done.

Besides good people skills, are there additional skills the excellent information architects possess?

They have ability to work in great detail. But, at the same time, they can focus on broad strategic issues. The best information architects take the user research, content analysis, business goals, and all of the other input information, and synthesize it into something that really works. They can see the big picture *and* keep an eye on all of the specific details.

This is a unique skill that not many people have. Lots of information architects are really good at doing detail work and lots are really good at the strategy work. But it’s a pretty amazing skill to accomplish both at once and to flip between them from second to second.

A lot of information architects seem to have mastered the details but haven’t done the strategy work. How do they get those skills?

In many cases, information architects learn about strategy by getting immersed in the work and gaining the experience of seeing the big picture. I don’t know how you would learn how to do the strategic work without going up a level and working it through. I’ve found that it’s important to have a vision for the project in your head and think about the bigger picture.

In order to do the detail work, information architects really should have understood the bigger picture. That’s the bridge between doing broad work and detail work. It’s understanding the big picture and trying to hold the big picture together, while you’re also figuring out which content goes where and what a 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.

In our research, we’ve found that it’s essential for teams to have a solid vision and understand the long term business objectives. Have you found these are key elements for successful IA work?

Yes, they are. The whole team has to understand the business goals and understand them properly and deeply.

If a design team can start thinking about long-term design approaches, where would you suggest they focus their efforts?

If I had a wish list for making a project or web site work really well over time, I would suggest the team work in small pieces. They should conduct solid research, build something, make it work, and keep an eye on the bigger picture and goals. Then, they can move onto another piece of the project.

This approach works better than starting a massive project that takes a long time because there’s so much work to do. By the time the team finishes the project, they’ve forgotten where they started. I’ve found that tweaking small areas, or doing mini redesigns of a section of a site, is much more effective than working on big redesigns.

With one of my favorite clients, we do this all the time. If we identify a place on the site that needs improvement, we have the flexibility of doing small bits of work because they’ve actually structured it in their budget to do the work this way.

We can tackle little things rather than going, “OK, we’ve got to redesign this whole web site and it’s going to take three years, and by the end of it we’re going to have forgotten the beginning of it.”

For a long time, we’ve been telling clients to stop thinking in terms of massive redesigns and focus on some piece that’s strategically important. (See UIE’s article, The Quiet Death of the Major Relaunch)

If teams could make some improvement in a short period —months versus years —then they could see those results and learn a lot about their users and what they’re trying to do. Have you seen other advantages to working in smaller chunks?

It makes the research process less scary. When I talk to design teams, I often find they’re scared of conducting user research because it feels like it has to be a huge project. The research is easier if they break a project into smaller pieces.

For example, if a team says, “we want to improve the publication section of our site,” they can find people who use the publication, do a small bit of research on them, and make sure they capture the results so it will be available for future staff. It’s not as scary and much more approachable.

When you work on a smaller section of the site, do you find that it reduces the number of stakeholders you have to appease?

Yes, it does. With smaller projects, there are fewer people who need to be involved in that one piece. For example, if teams can focus on making the small pieces, such as getting the Human Resources site organized well, they can involve fewer stakeholders and get closer to the people who are really doing the work and need to be involved.

We’ve talked about having really good people skills, doing the strategy and detail work, and breaking things up into smaller projects instead of large designs. Is there anything else that separates a great information architect from the rest?

The excellent information architects do more than IA. A couple of years ago, 37signals said they would never hire an IA because they consider it a specialist field with too narrow a specialization. In many cases, I believe they were right.

There are a few times when you need a dedicated person to do only IA stuff. Most of us accomplish many activities beyond the core IA work of organizing, labeling, and designing navigation. We also do strategy, content writing, interaction design, and production.

I do interaction design work along with my IA work, yet everyone knows me as an information architect. This ties right back into the first skill of playing nice with others and working well within a team. Information architects shouldn’t say, “I only do IA and here are my boundaries.” Instead, I recommend they say, “Here are the activities I can do really well. I can see other members of the team do other activities really well. Let’s work together and build something.”

Thanks, Donna. This was a great conversation. I look forward to seeing you at the User Interface 13 Conference in October.

Thanks, Jared.