### Summary: Ultimately, not every project needs information architecture. Or design. How well you understand the problem and the solution, as well as how that understanding changes, determines whether or not you need architecture, design, development, or testing.

This is part 2 of a 3 part series. Read part 1, "Architecture as Rhetoric for Spaces" and part 3, "Information Architecture for Lean and Agile Projects".

*Updated September 16, 2014 to add clarification that research was not included as an information architecture activity based on a comment from Peter Boersma. Research is assumed to happen prior to modeling and architecture activities.*

Previously, in Architecture as Rhetoric for Spaces, I wrote that information architecture defines the experiences that are *possible* within a given space. In contrast to architecture, design facilitates a *specific* experience. Distinguishing between architecture and design in this way, we can understand when information architecture returns the most value for the project team.

## Known/Unknown Problems/Solutions and their impact on design and development

Back in my halcyon days working with Livia Labate at Comcast, Dennis Schleicher introduced me to a grid that maps known and unknown problems and solutions:

You can use this mapping with any project to understand your next step. For example, you can implement known solutions.

Of course, lean startup and lean UX movements promote the idea that you can’t *know* if a solution works until after you implement and test it. In reality, you don’t know the solution to a problem. You can only define a solution to the problem.

In this case, you can still implement a defined solution. And once implemented, you can test the solution to evaluate how well it performs.

What if you haven’t defined the solution?

When you haven’t defined the solution, but you have defined the problem, then the design process can evaluate multiple solutions, and then define a specific solution you can implement.

(We need to be careful there. In defining the problem, it seems like I've lumped research in with information architecture activities. Really, though, I'm envisioning research as an assumed input into analysis and synthesis activities which move right into modeling and information architecture activities.)

If you haven’t defined a solution, then you have many possible solutions. Each possible solution has a probability of being implemented relative to the number of potential solutions.

Another way to say this: As you better define the problem, you reduce the set of possible solutions until you’ve defined the problem so tightly, only one solution is possible.

Based on how well the problem is defined, we can understand what kind of activity we can pursue.

Up to now, we’ve focused on how well we’ve defined the problem and the solution. Agile and lean commentary focuses on defined problems and solutions in an effort to avoid rework (an agile boogeyman). We can change our perspective, so we focus on the undefined problem.

Again, this shows the architecture activities that come out of research. Research would occur prior and extend throughout the process.

(Here I leverage Central's awesome "Design Squiggle" to illustrate how the design and development process moves from fuzzy to more defined.)

Viewing the problem space this way mirrors our movement through time as we work on a project. We can also include the entire process through implementation and testing.

We can also define the types of activity that takes place at each stage.

- If implemented, then test, so we can optimize the solution
- If defined solution, then implement, so we can evaluate the solution
- If undefined solution, then design, so we can define a solution
- If undefined problem, then architect, so we know what solutions are possible

In keeping with how I describe IA in my previous post on Architecture as Rhetoric for Spaces, architecture allows us to frame a problem, so we know what designs are possible.

Importantly, if you have already defined the problem, then architectural activities have less value. If you have already defined the problem space, architectural activities can only help validate the previously defined architecture.

## Testing and Optimizing Solutions, Climbing Mountains

Both agile and lean perspectives focus on the implementation and evaluation of solutions. This approach assumes the set of possible solutions, the architecture, has already been understood and defined. The focus is on implementing solutions, testing them to evaluate their effectiveness, and then optimizing the solutions.

During testing, you are evaluating whether the implemented solution performs as well as you expect it to.

If your solution does not meet expectations, then you optimize and retest. You continue to optimize and retest until the implemented solution performs to your expectations.

## When Optimization Isn’t Enough, Getting Off the Mountain

At some point, if you’ve optimized the solution and it continues to not meet your expectations, then you’ve reached what Joshua Porter refers to as your “local maximum”. The local maximum represent the maximum performance you can achieve with this specific solution to this specific problem.

If there is a local maximum, it’s also possible that there is a “global maximum”, another solution that can achieve even better results than the specific solution you’ve currently implemented.

Porter likens it to having a goal of reaching 1000 feet in altitude. (Porter's SXSW 2011 presentation on "Metrics-Driven Design" is required reading.) You are sure you can climb a mountain up to 1000 feet. You pick a tall mountain (your specific solution) and climb to the top. When you get there, you discover you’re only at 800 feet. That 800 feet is your local maximum, the height of the mountain you’re on.

You’re still sure you can climb to 1000 feet. The altitude of 1000 feet high is your global maximum. You believe there is a mountain that is 1000 feet tall.

You can’t get to 1000 feet on the mountain you’re on, so you need to find a different mountain to climb, another solution to implement. To find another mountain, another solution to implement, you would revisit the design process to re-evaluate the possible solutions to find a better one.

If, at some point, your design process fails to identify any mountains that are 1000 feet high, then you have to rethink whether or not climbing a mountain is the way to get to 1000 feet. The only possible conclusion is that you’ve incorrectly identified the problem space.

In that case, you would need to redefine the problem space. You would go back and re-architect the problem space, redefine the problem to reveal a different set of possible solutions.

Perhaps, instead of climbing a mountain to 1000 feet, you should build an airplane.

## Identifying the most Valuable Activities From Architecture, Design, Implement, and Test

At its essence, if you know the how well you’ve defined the problem or solution, then you know what set of activities to pursue. Specifically, in agile and lean development, you know when to optimize, when to design, and when to architect.

Throughout my practice, I use the interaction atom to help identify what methods and artifacts to use at what time. The interaction atom provides a durable model of the design process. A user interacts with an interface and that interface reacts to the user.

We can align the types of activities with the interaction atom. Architecture provides a way for defining the user, their context, and their interaction over time. Design provides methods for defining the interface.

However, the interaction atom is missing the distinction between the defined solution (the interface), and the implemented solution. We can add that to the interaction atom and map all of our activities.

When I use the interaction atom to identify what methods and activities are appropriate at a given time, I make that decision based on what information I do or do not have. As we have discussed up to now, how well your problem or solution are defined help guide whether you should pursue architectural, design, development, or testing activities.

Similarly, if you have designed, implemented, and optimized as much as you can, and it’s still not enough, then how well you have defined your problem and solution has changed, and this change can also help guide whether you should pursue architectural, design, development, or testing activities.

For different types of information uncovered by research, we can map how the new information determines the type of activity you should pursue.

The specific activities a team chooses to pursue should never be based on a canned process or team preference. The most valuable type of activity — architecture, design, development, or testing — can always be determined based on how well the team has defined the either the problem or the solution.

There's a point to both information architecture and design activities, and each capture specific value that is not available to development and testing activities. Understanding how well you have defined the problem space and the solution helps teams understand how to most effectively spend their time.

*In part 3, we explore **when a**gile and lean teams should begin projects with information architecture and look at how information architecture helps capture maximum value and avoid waste earlier in the development and test process.*