Summary: Information architecture helps avoid waste and capture maximum value earlier in the development and test process. Agile and lean teams should always begin projects with information architecture for any project that will run eight weeks or longer.
Thinking back, I can't recall a single development team where everyone didn't agree on documenting the interface in some fashion. Maybe it was a sketch or a wireframe or some prototypes, but whatever it was, everyone agrees you need something where everyone can agree: yes, this is what we're building.
Whenever you hear some UXer running into some friction on lean and agile teams, it's almost always around whether or not the team should spend cycles on things like personas, mental models, or user flows. These are architectural activities that explore users, their context, and their interaction with the system.
And the developers are correct. They don't need any information architecture.
If your team has already agreed on how the problem is defined, on the architecture of the problem space, then there is little value in re-hashing that definition. If you've agreed on how the problem is defined, then the best value comes from design, development, and testing.
So, when should you go back and rehash the information architecture? We cover that in In "Information architecture's place in the design and development process"
That leaves one question: when should agile and lean teams invest in information architecture at the outset of a project?
Will your project run longer than eight weeks? You should start with information architecture.
Information architecture reveals wasteful assumptions before they're built
Whenever any project starts, and everyone walks into the room, everyone in the room already carries assumptions in their heads about how the problem is defined. Everyone has an assumption about who the user us. Everyone has an assumption about the user’s context and how the user will interact with the system. Everyone in the room has already defined the problem and already gone one step further to identify not only the possible solutions, but also the solution that's most likely to achieve the most optimal results.
Information architecture is not some magic discipline that reveals what the correct problem space should be. Information architecture is a collaborative discipline that reveals how everyone in the room has already defined the problem space and helps the team identify any gaps that already exist in their heads.
Information architecture helps the entire team agree on what the problem space should be.
Going back to the mountain example from the previous post, information architecture at the outset of a project helps the team evaluate whether or not they really want to get to 1000 feet in altitude or whether they want to move 1000 feet down the road. And if everyone agrees you’re going for altitude, then information architecture helps the team evaluate whether their assumptions about climbing a mountain are accurate, or whether they should start building a plane instead.
Information architecture maximizes earlier return on value
In the lean world, it’s not just about defined and undefined problems and solutions. Lean emerged out of a context where your resources are also undefined. Specifically, in a startup you’re not sure when your money will run out. Lean focuses on testing and optimizing as a way to maximizing return value on resources that could disappear at any time.
In this context, information architecture at the outset of a project helps mitigate the risk of wasting time in two ways. I’ll use the mountain example again.
First, if half the team thinks they’re climbing mountains and the other half thinks they’re building airplanes, then it will take the team much longer to develop and optimize a well-defined solution. This extra time requires you use what few resources you have across a longer timeline before realizing maximum value. Aligning the team into a single problem space at the outset helps make sure you are testing and optimizing as soon as possible.
Secondly, if everyone walks in at the outset assuming climbing mountains is the way to go, information architecture helps the team evaluate that assumption upfront. If it takes six months to design, implement, test, and optimize mountain climbing before you learn mountain climbing is an insufficient solution, then you’ve burned six months of resources. In contrast, if information architecture helps the team identify that airplanes are the way to go from the outset, then the team can avoid wasting six months on a sub-optimal solution.
How much does information architecture cost lean and agile teams?
Suitable information architecture for anything from a simple to a reasonably complex system can be completed in 2-4 weeks. (Two weeks for a simple system. Four weeks for a complex system.) Investing in information architecture at the outset of a project can help lean and agile teams return maximum value earlier in the process by avoiding greater waste later in the project.
Investing 2-4 weeks in information architecture helps mitigate development risk. On any project with a timeline of eight weeks or longer, investing in information architecture is the best way to safeguard the project’s return on value.