A conversation with Information Architect, Joe Elmendorf.

Joe Elmendorf is an Information Architect at The Understanding Group. We talk about how to define information architecture, how it overlaps with UX, and his process for delivering effective solutions.

Where do you see the connections between Information Architecture and physical Architecture?

It’s not coincidence that it’s called information architecture; the discipline takes a lot from the practice and theory behind physical architecture. At their core, they are both about making places for people; the building architect makes physical structures people inhabit with their bodies, and the information architect makes information structures people inhabit with their minds. This common purpose of making places for people is one of the reasons why we at The Understanding Group model our process after that of a building architect. 

Hear about upcoming conversations:

How does Information Architecture interact or overlap with other disciplines, like User Experience?

Information architecture has been tacked on to user experience for years. There are models that show IA as a subset or focus of UX, and years ago at an IA Summit there was polarizing call to do away with the title “Information Architect” in favor of “User Experience Designer.” However, I think the two positions are distinct, both in skill sets and in process. Information architecture is more about understanding and aligning on what something will be rather than how it will be. An IA works to figure out what should be made and expresses that through structures of language and meaning. Once the what is figured out, the UX designers are able to shine and make that what the best version of itself.

There are two quotes I share with my students about the difference between architecture and design. The first is from architect Peter Eisenman, “Architecture is not design: it’s a different discourse. Architecture is an analytical process of identifying exceptions. Design is a synthetic process for solving problems.” The second quote is from Dan Klyn, co-founder of The Understanding Group and information architecture thought-leader, “Your project is a piece of cloth. Architecture is where the cuts go; architects hold the scissors. Design is making the resulting parts be the best parts they can be, solving the problems defined in the act of cutting.”

Architects and designers are functionally different, as their processes and considerations are fundamentally different and dependent on one another. The architect analyzes a situation and creates frames and bounds that help people understand; then the designer works within those bounds to make those places the best they can be for their intended purpose.  

What’s the biggest hurdle you face when communicating the importance of your work to potential clients?

The biggest hurdle is figuring out what the client expects that I, as an information architect, am going to do for them. At The Understanding Group, we have a proven process for delivering excellent information architecture projects; Program, Analysis, Synthesis, Sustain—PASS for short. Program is where we facilitate and document with the client what it is that we are going to be making and defining what “good” means. In the stage of Analysis, we understand anything and everything that we can about how things are put together today, as well as what users expect from the system. Next, Synthesis is the first point at which we begin talking about shaping the future state of whatever it is we’re making. Lastly, Sustain is intentionally vague because it’s less about a particular task than it is about supporting whatever the client needs to actually execute on the architectural plans that have been delivered. So while this process is proven in that we’ve run over 100 projects successfully using it, and while we can talk about it confidently, it isn’t always the most intuitive to clients what happens at each step.

Unless the client has experience with this particular way of making, we’re often asking them to trust us to do a bunch of activities they’ve never heard of to create artifacts that may only be useful as an iterative step towards an end that isn’t yet working software; it can be uncomfortable because it’s new and unknown for them. As the industry has matured and information architecture has become a tiny bit more mainstream, we are now seeing clients coming to us who are primed for our way of working; and for those who aren’t we’re still perfectly happy to guide them through and teach as we work. 

When you aren’t able to go as deep on a project as might be needed, how do you pare down your process? Which steps are crucial vs. helpful?

I don’t believe you can create something good without going through the right sequence of steps; the amount of time spent on each step can be scaled based on the budget, but we can’t just leave out a phase of the PASS process in order to get to wireframes sooner. If a client has a tight budget, we often focus on the high-level architecture and structural parts and then hand that architecture to an in-house design team. More often than not, clients come to us not because they don’t have a team, but because we offer a higher-level perspective than their teams are allowed to have based on their workload; it’s really hard to think high-level and strategic when you’re trying to get sprints done.  

What is the biggest mind shift you need to initiate in order to get the best results for your clients?

The biggest mind shift that our clients need to have is an understanding that even though we might be adding 6-9 months to the front of a project, that investment (which might seem painfully slow) pays dividends down the road and will result in a more efficient software development process and a better-performing end product. 

If there was a second helpful mind shift, it’d be looking at the world through abstractions. Every human makes their way through life aided by the use of models and abstractions, but sometimes the amount of abstractions used to explain a system can take some getting used to. If no one on the client team has any desire to step into these abstract concepts to play with the structure of their ecosystem, and prefers instead to wait for the concepts and abstractions to be instantiated in code or mockups, there is a risk that they will say, “Ah, now that I see it, this isn’t going to work.” The sooner we can co-create, or at least co-validate, an information architecture with the client, the better it will be (in both quality and efficiency!).

Are you ever translating high level findings into tactical products? What are the biggest challenges there?

We always want to make clear connections between high-level structures and the more-tactical wireframes, content models, and taxonomies. I tend to be obsessed with rationale; I don’t want to have to just make a decision—I don’t trust myself that much—I need to make decisions based on reasons. I think the biggest challenge in making those connections has more to do with the level of effort and resources it takes to document the rationale and connection between the high-level and the tactical. I can’t not have those connections exist in my head when designing, but making those connections explicit isn’t as straight-forward; it takes time to make them clear. 

How do you define design? Why should organizations care about it?

I got parsimonious earlier about the differences between architecture and design, but for most people, I think that design means the intentional creation of something. Some things happen by accident and some things are designed. There is a lot of talk these days about how organizations just need to spend time designing things and then all the problems will be solved.

I think that design offers organizations an opportunity to make things that are good for people, but design can also be weaponized, used to more effectively extract things from people and marginalize one group over another. So while many organizations are seemingly just coming around to understand that design as a thing is important, there are others who are realizing that it’s not enough to just design, we need to think about what happens when we make things and whether or not those things should exist.

Organizations should care about design because design is effective and it is powerful at creating change and shaping the world; it is an opportunity to make the world a better place. As designers working for these organizations we need to make sure that we are creating ethical things that make the lives of all humans better, not just make things that extract as much from people as possible. 

To learn more about Joe Elmendorf, visit The Understanding Group.