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.

Designing a New Information Architecture: An Interview with Peter Merholz

by Jared M. Spool
on March 12, 2002

Last year, Adaptive Path, working with interactive media agency Lot21, took on a challenging project — the redesign of three PeopleSoft sites. The
redesign involved over 40,000 pages as well as 40 divergent opinions from stakeholders!
After four and a half months, the site’s information architecture and navigation
were transformed to the accolades of both PeopleSoft and their users.

We recently interviewed Peter about this project:

UIE: Before Peoplesoft called you, what were some of their major challenges?

Peter Merholz: Peoplesoft had three independently-operated web sites
going off in different directions, telling three different stories, and offering
three different sets of information about the same products. So, operationally,
there was pain that work was being done in triplicate and not agreeing with
other similar work.

On the customer side, there was a lot of pain around the site’s navigation.
Divisions between the public, customer, and partner sites were blurry. Links
would often take users to the other sites without them realizing it. Then,
when users tried to navigate, they didn’t know where they were or where to

UIE: Can you describe some of the different types of pages and audiences
for those pages that made the site complex?

Peter: The most complex part of the basic PeopleSoft site is the product
description pages. PeopleSoft offers over 170 different product “modules” that
can fit together in seemingly infinite ways. Additionally, there is a whole
host of information (brochures, case studies, technical documents, white papers,
etc.) about product modules, product suites (certain groupings of modules),
and product lines. Not only was the interrelation between products complex,
the information for each product could be quite voluminous.

The complexity was compounded by the high degree of interaction between PeopleSoft’s
offerings. They not only sell products but also offer a bunch of services ranging
from consulting to hosting.

PeopleSoft made no attempt to make people aware of these offerings except for
a link in the global navigation. We found in our research that users consider
such services when in the process of researching the software. We therefore
developed an information architecture that put these links at the product level.

UIE: What were some of the problems for users with the old site?

Peter: Finding information about specific products was a challenge.
PeopleSoft had biased “product suites” (a desire to sell a lot of products
at once), but customers often want information about just one

Also, product information lived on the “public” site. So, users on the “customer” and “partner” sites
would get shuttled out to the public site for product information and, as a
result, lose their navigational cues. Sometimes users had to log-in again to
get back to the information specific to them. It was messy.

The new singular architecture made the distinction between “sites” far less,
instead utilizing roles to filter the kinds of information people saw. Once
you choose “customer”, everything you see is identified as “customer,” even
though some of that exact same information is available to the public or to

UIE: What techniques did you use to gather requirements? Which technique
was most effective and why?

Peter: We used one-hour telephone interviews with the appropriately
targeted user types. Telephone interviews allow you to talk to a large number
of geographically dispersed people in a short period of time. You don’t get
some of the ‘fidelity’ you’d get from a contextual inquiry, but we’ve found
that for most Web sites, that level of depth is simply unnecessary — it’s
like cracking a walnut with a sledgehammer.Particularly with folks engaged
with enterprise-level software,there are certain apparent processes at play
that we were able to glean from talking with folks about how they do their
work. We always make sure to focus on how someone does their work, not what
they feel about it.

UIE: What did you learn from the content audit and task analysis that
proved to be most helpful in creating the new navigation?

Peter: Everything! The content audit was perhaps the most important
in that it showed what content existed across the three sites, and made it
very clear which pieces were duplicated (or triplicated). This allowed us to
quickly see commonalities across the three sites that aided us in thinking
about new navigation.

A big point of our seminar (at User Interface 6 West) is discussing how our
task analysis research leads directly to a new high-level architecture. We
realized that there were 6 or 7 main tasks per audience, and we used those
as a starting point for creating global navigation.

UIE: What diagrams proved to be most useful in the development process?

The mental model diagram was probably the single most useful. Again and again
we returned to this visualization of users tasks and mental processes. For
figuring out the architecture of the product area, we developed a “crystal-molecule-atom” diagram
that showed how the product modules (atoms), belong to a particular product
line (crystal), but could be combined in any number of ways into suites
(molecules). And, the most actionable diagram was the Site Architecture Diagram
– a huge Visio doc showing all the main pages and their relationships with
one another.

UIE: Thanks Peter.

Peter: My pleasure. •

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.