Information Architecture the Adaptive Path Way: An Interview with Indi Young

Indi Young, a Founding Partner of Adaptive Path, specializes in task analysis and navigation repair. She is also the creator of the mental model diagram and gap analysis process. User Interface Engineering’s Josh Porter recently sat down with Indi to talk about Adaptive Path’s methodology for developing a solid information architecture.

UIE: Adaptive Path’s methodology for creating information architectures has gained a lot of attention lately. How do you go about creating an IA for large sites?

Indi: The methodology we use includes many sub-components. We bring them together in many different (adaptive!) ways based on the business needs of our clients.

In our work, we start with discovery, where we learn about the business plans and priorities of the stakeholders. At the same time, we determine our initial audience segmentation—how potential users of the application fall into groups. We base this segmentation on how we believe these groups will approach their tasks, not on demographics.

Next, we conduct interviews with people who fall into these audience segmentations. Through conversation, we urge them to tell us, in their own words, about their own approaches on the topic.

After we have interviewed enough people from each audience segment to see some patterns emerging, we start data analysis. We review every word each person said in the interviews and pull out their tasks.

When we see similar tasks, we bundle them together into conceptual task groups. From this, we start to see nuances between the component steps of the tasks and we track whether the different (say, international) audiences share these nuances.

We then create a mental model diagram of these conceptual task groups. This diagram, pulled from interview data, delivers us a visual representation of how users view their workflow.

Once we can see the workflow, we then conduct a content gap analysis. This process helps clients understand “the whole” and puts the project into perspective for them. We may find that the web site or software doesn’t support a core task that audience members regularly perform. Alternately, a new design may provide a key tool that the audience can adopt into their mental model to make them more efficient.

From a business standpoint, these “content gaps” are all potential opportunities for discussion. It is always fantastic to see people grasp the connection between the audience’s mental model and the services the business provides.

Finally, we derive the architecture and navigation from the combination of the business requirements, the mental model, and the content gap analysis. The beauty of this is that we’ve derived the architecture from research. We avoid the “office politics” that often bog down a project. One group of individuals, whose opinions and expertise another group may doubt, didn’t just create it. This ensures that the organization will launch the site instead of perishing in the details. This solid foundation also ensures a recognizable return on the investment, in a way that is favorable to the business.

Let’s talk about the mental models you develop from interview data. How does Adaptive Path define a mental model and what role does it play in creating a solid IA?

A mental model is how users think about and approach their tasks and goals. It represents the way in which users do something—for example, how they solve a problem, or complete a process. You can make a mental model of just about anything someone does, from how they make coffee in the morning, how they brush their teeth, and how they decide whether to mail or FedEx something.

Ideally, designers want to create an information architecture that corresponds to the users’ mental models. Based on our interviews with users, we derive mental model diagrams showing how they think about their workflow.

Over the years, I’ve mapped out models of how employees buy expensive software for their company, how laypeople learn to invest, how media buyers make choices between TV or radio ads, how grocery shoppers decide what to buy, and many other workflows.

You recently worked on Agilent Technologies’ intranet. How did you employ Adaptive Path’s methodology to derive their information architecture?

The human resources group at Agilent Technologies wanted to pull all of their different departments into a single, cohesive architecture. Web proponents, who had enough influence to get their department site launched, started Agilent’s ad hoc intranet. This is true of many company intranets. When the HR group contacted us, they wanted to pull these disparate sites together in a more intelligent fashion, yet preserve the meaningfulness of providing grassroots, non-centralized content.

Early on in our work with Agilent, I could see they wanted to build a solution for “every person” at the company—over 40,000 different people! The designers at Agilent were concerned that this would involve hundreds of different solutions.

We started by teaching them how to segment their audience according to the Human Resources tasks. By looking at the differences in the way employees approach HR tasks, we reduced the tasks of 40,000 employees into 21 representative types.

Agilent’s team was data-intensive folks themselves and this process made their eyes shine. They can now use these 21 representative types for years to come. They can develop these types into personas and use them for recruiting interviewees and usability participants.

We then interviewed users that Agilent’s designers had recruited from all over the world about their HR tasks. We built mental models, re-assessed the audience segmentation based on those models, and condensed them into three distinct “super groups” of Employees, Managers/Executives, and HR Staff.

Next, we took the designers’ analysis of the worldwide content and matched it to the mental model, adjusting the model as needed. Then, we derived three architectures from the models for each of the audience groups. These would represent three different web sites, accessible from each other with the same login and password.

Were there any surprises?

The biggest surprise was that, regardless of what countries they were from, everyone talked about HR tasks (such as checking on their paychecks, setting up health benefits, and recording time off) in the same way. People do the same thing from country to country. Laws may differ (like the length of a work week), and circumstances may differ (such as socialized health plans), but people performed the same tasks everywhere.

You have a degree in computer science. How has this helped you shape your career up to and including your work at Adaptive Path?

All this task modeling comes from state-machine modeling. That’s actually how I came up with my first mental model back in early 1995 for Visa. I was trying to understand the tasks of a Customer Service Representative and the best way I could do this was with a state machine.

Also helpful are the concepts of object-oriented design, re-use of modules, normalized database architectures, meta data, and controlled data types… all of these guide how I solve problems for clients. (Embarrassingly enough, it even guides how I organize my garage. I think being compulsive helps in this industry.)

What challenge do you think plagues web teams the most?

Politics. Definitely politics.

In our work with development teams, we’ve observed a certain inability to admit that rivalry, disinterest, egos, and bottlenecks exist in an office environment. Typically, we find that a company has centralized their web teams, and the centralized team doesn’t necessarily have a hold on the power structures around them.

At Adaptive Path, we encourage web developers to explore this challenging atmosphere. With our clients, we first define the roles of all the stakeholders, determine how to achieve approvals, and find out the history of each player and who has an interest in the project.

We also emphasize the need to talk to everyone on the development team and building relationships with all team members. After communicating with the stakeholders and team members, we recommend that development teams work everything they’ve learned into lists. The lists should prioritize information based on importance to both the user and the business, taking into consideration any technical and resource feasibility issues. Eventually, the teams gain consensus. With consensus, projects won’t fail when they least expect it.