|
In marketing the UI 6 West Conference, the folks at User Interface Engineering interviewed me about some work Adaptive Path did with PeopleSoft. The interview is nowhere to be found on the web, so I'm reprinting it here.--> Feature: Designing a New Information Architecture
An interview with Peter Merholz of Adaptive Path 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 go. 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
module. 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 partners. 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. We're looking forward to learning more about this project and your techniques at the conference. Peter: My pleasure.
2 comments so far. Add a comment.
Previous entry: "Speaking of Game Design..."
Next entry: "The Semantics of File Formats."
Comments:
COMMENT #1
You don't get some of the 'fidelity' you'd get from a contextual inquiry [when you use phone interviews], 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.
Care to elaborate? If you had the budget, would you have done contextual/ethnographic/behavioral interviews, or put the bucks into other efforts? I'm pushing for contextual research in our enterprise portal development, and just don't see phone interviews providing the depth to understand how employees are going to use thousands of pages of content and dozens of online applications...but if I could get the same kind of information on the phone that would be good too. I'm just not clear at how voice is a good medium for observing behavior & environment...
Posted by Jess @ 03/15/2002 12:14 AM PST [link to this comment]
COMMENT #2
It sounds as if what Peter's describing doesn't include online applications, Jess, where I think that contextual design would add a lot. In looking at the (public) parts of PeopleSoft.com, it seems like it's almost all info retrieval. It's a nice site.
Posted by Andrew @ 03/15/2002 12:53 AM PST [link to this comment]
Add A New Comment:
|