Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

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

by Jared M. Spool
on August 27, 2008

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

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

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.

Share Your Thoughts with Us

How have you tackled your site content challenges? In your
experience, what skills do the best information architects possess?
Share your thoughts and experiences on our UIE Brain Sparks blog: Brain Sparks Blog.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.