Deliverables and Methods: Special Deliverable #8

“User experience tasks and activities were aimed at answering these questions: Who is the user? How do they interact with the system? Does the system work?”Toward a universal methodology
When I was at the consultancy-that-shall-not-be-named, I worked with a talented group of user experience consultants as part of a multi-office initiative to establish the user experience practice. The purpose of the practice was to define standards and tools that could be employed across the firm. The standards and tools had to be flexible to accommodate the range of approaches resulting from the Frankensteinian merger of offices from around the world. At the same time, we wanted a product that could be proprietary to the firm.

In our efforts to define a methodology, we decided to boil our process down to three essential questions. User experience tasks and activities were aimed at answering these questions:

• Who is the user?
• How do they interact with the system?
• Does the system work?

These questions gave us a framework that all offices could use to map their methodologies. Those offices that employed a “Discovery” phase could say that those activities mapped to the “Who is the user?” question. Offices using the Rational Unified Process could correlate those activities to these questions. We imagined that these questions could be asked in any order, in case a project called for a quick interaction design or for testing the usability of a legacy system. We imagined that the questions could be asked iteratively, to form increasingly lucid responses.

In hindsight, this approach appears too simple. Indeed, with the growth of the user experience field, I do not think our questions would have scaled to accommodate the complexity of either large systems or long-term projects. Either way, however, this approach allowed us to place our deliverables in context. Ultimately, a deliverable or document is only as valuable as the activity it supports.

To date this column has focused on how to make deliverables more effective, either through their content or through the tools to create them. For this issue, I would like to explore the relationship between deliverables and methodology. Unfortunately, this calls for a definition of IA methodology, which may challenge the definition of IA as the hardest question in our field.

To define methodology, I’ll look at activities and issues. These two components are not mutually exclusive. Activities describe what information architects do and issues are what they do it with.

The two activities of IA method
I have always thought of methodology, in these circles, as consisting of two activities: understanding the problem and solving the problem. Most “creative” methodologies are documented in this way, with a series of steps or phases leading up to a conception of the problem (creative brief, for example), followed by a series of steps or phases leading to the creation and implementation of a solution (one part of which may be a style guide).

For example, in the “old days” a design firm would be approached by a client who wanted a commerce-enabled website to sell patriotic ice cream flavors. (Alas, strange consumer goods abound in times of war.) This is a general statement of the problem. The firm would spend days or weeks (in the government, months) to elaborate on the problem: everything from the kinds of ice cream to the expected sales to the legal implications of potentially shipping ice cream across the country.

Ultimately, all this information contributes to the team’s overall understanding of the problem and sets the bar for the final product. Transitioning to problem-solving activities, the firm must make a series of decisions: the look of the homepage, the information collected at checkout, the way the website database hooks into the fulfillment vendor’s database. Each design decision is evaluated against the problem statement, and the firm must convince the client that the decisions they made effectively solve the problem. Ultimately, the distinction between understanding the problem and solving the problem comes down to the difference between What and How.

If you haven’t yet had a What and How conversation with any of your clients, it goes a little something like this:

Client: I want tabs across the top of my homepage, like my favorite site, [fill in high-profile ecommerce site here].

You: We can look at using tabs, but we first need to establish the main purpose of the site.

Client: Can the tabs be green?

You: Once we figure out the main navigation categories, we can make some decisions about how the page should look. But we can’t even figure out navigation categories until we understand the kinds of information you’d like to make available.

Client: We have a lot of information, but I only want one row of tabs.

You: [After writing down: “has lots of information.”] The issues you’re bringing up will help us describe HOW the site needs to look. We need to first understand WHAT the site needs to do. We can look at the HOW (the design of the pages) only after we establish the WHAT.

For “waterfall” methodologies–those that consist of phases occurring in a linear series–this framework meshes nicely. The first several phases are dedicated to understanding the problem, and the last several phases are dedicated to solving the problem. So-called “iterative” methodologies follow this structure as well, though they are composed of multiple conception-solution cycles. Each cycle tends to be limited in scope or time. Ultimately, having solved enough of the small problems, the iterative methodology will solve the larger problem.

The three issues of IA method
Distinguishing between these two main activities, however, is not enough. For each activity, the information architect must consider several issues. Each person may define these issues differently, but for the sake of simplicity, I’ll use business, users, and content as the primary issues information architects must address. In understanding the problem, the information architect must understand it from these three aspects.

Likewise, a solution must also address these three aspects. Any given system must have a business case, a marketing plan, and a content strategy. While information architects may be responsible only for the last of these, the aspects cannot exist independently of one another. (More often than not, IAs find themselves involved with all three.)

Where deliverables fit in
What I’ve presented is, no doubt, an oversimplification of methodology, but it provides a useful framework for considering deliverables. Any deliverable is serving one of two purposes: helping the design team understand the task, or documenting the solution itself.

In the first category of deliverables, a document may help set the context through business goals or user descriptions; or it may help put a stake in the ground with respect to scope by showing the breadth of the existing system. Documents in the second category capture the decisions made by the information architect–metadata for a content management system, structure of browse navigation, or a task flow for a checkout process.

At the same time, any given deliverable is addressing at least one of three issues: business, users, or content.

	Business	Users	Content
Problem-Understanding
Problem-Solving

Considering deliverables in this framework leads to some interesting insights:

• There is not necessarily a linear progression left-to-right. The three aspects are mutually exclusive but not independent of one another. Indeed, in order to come to a complete understanding of the business problem, one must also have a complete understanding of the user and content aspects of the problem.
• There is not necessarily a linear progression up-and-down. In other words, having an understanding of the problem from the user aspect does not immediately imply that a solution from the user aspect will solve the problem.
• Only a complete understanding of the problem, across all the issues, will lead to a complete solution. A good content solution is dependent on understanding all aspects of the problem. A single deliverable does not necessarily live in one, and only one, box. A single deliverable can capture multiple aspects across a single activity. A sitemap, for example, may indicate how different users can access the information.
• BUT: a single deliverable should not attempt to both understand and solve the problem.

More on this last point: About a year ago, I did a concept model (a simple sitemap-like document showing the relationships between different concepts) for a client that described different “content types” for their organization. The client had never seen anything like it, nor had they attempted to define content types for the organization before. It’s easy to see how this could be part of the solution, and would fall into the second category of deliverables on the second row of the table above.

On the other hand, the deliverable did not describe how the ultimate solution would behave or look. It did not ask the client to do anything differently with their content. Its value, instead, was to help the team (both consultant and client) get their arms around the scope of content produced by the organization. Sometimes a good understanding of the problem masquerades as a solution.

Conclusion
Mapping deliverables to this methodology framework allows IAs to understand the purpose of their deliverables and clarify their role in evolving towards a solution. Admittedly the distinctions used here to describe methodology may be helpful for clients, but an oversimplification for professional information architects. On the other hand, even if your methodology includes more subtle distinctions in activities and issues, your deliverables must be geared toward getting closer to a solution. The deliverable may be the solution itself or a step in that direction. Understanding how your deliverables fit into the larger picture–by mapping them to a particular activity and issue–will make them more effective communications.

Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank.