UX IRL Ep. 20: Information Architecture in Product

UX in Real Life
UX In Real Life
Published in
9 min readJun 2, 2022
Cover image for Episode 20

Hello! Here are our show notes for episode 20 of UX IRL: Information Architecture in Product. We hit the highlights in this article, but get the full context by listening to the episode:

In this episode, we talk about what information architecture is like in products! IA in product might not be as obvious as it is in websites, so we dig into why it’s important as well as some tools and resources you can use. This episode is also a primer for a future episode when we talk about the Modified-Delphi Card Sorting method. Talk to us on the zeroheight Slack community! (bit.ly/zheroes-slack), comment below, or reply on Twitter @uxinreallife or Instagram @ux.inreallife.

IA basics and IA in product

IA stands for information architecture. Mary Fran loves Abby Covert’s definition from her book How to Make Sense of Any Mess — ”the way to arrange parts of something to make it understandable.” If you’re new to IA, information architecture might sound daunting. Michelle likes to consider it as everything has a home. You’re trying to organize things to find that item easily.

When it comes to websites or apps, it can seem like things are everywhere. Consider that a page can only have one location, but you can access it in multiple ways. It’s very similar to how you can only be in one place at a time, but people can get in touch with you in numerous ways — visiting you in person, calling you, Slack messaging you, etc. Information architecture is figuring out how to organize content and navigate to that page.

We wanted to talk about IA specifically in products because it can be something a lot of products struggle with for a few reasons:

  • Products can suffer from a “Band-Aid” effect or a hospital effect. In this effect, solutions get tacked on without considering things holistically. So you’re adding Band-Aid after Band-Aid or hospital unit after unit. It can be challenging to navigate and untangle features in the product at some point.
  • IA in product is a little more obscure. On websites, we have site maps, so IA is more tangible. When IA in product is more elusive, getting the structure down might not be obvious. Instead, as features get added, things can evolve into something messy.
  • Designer backgrounds can lean heavily on the visual design elements and not so much on the structural aspects. When products are more complicated, teams need to think about how the content and information are structured. Visual-leaning designers and content designers must collaborate to ensure a great user experience. This synergy is also why it’s crucial to build a team with a comprehensive skill set.

UX IRL Takeaway: As you work on products, don’t forget about the structure and the organization of information. IA is the backbone structure of your product. From the backbone, you can logically build features.

Why do we love IA?

We love information architecture!!

For Mary Fran, it was the first topic in UX that she really gravitated toward. She feels it ties in nicely with her English degree. Similar to how she broke apart and analyzed structures in literature, she applies those skills to break apart complicated information structures, analyze, and reconnect them. She also loves it because you can examine user experience before looking at anything visual.

For Michelle, it’s super fun! She enjoys breaking things down into words, labels, and definitions, then trying to make sense of all the items. It also fits into her love of puzzles and puzzle games. She enjoys the challenge of thinking of things differently, eventually leading to something that quickly makes sense to people.

UX IRL Takeaway: If you love information architecture, let us know! We always welcome having more IA friends.

When to tackle IA in product

When might there be an IA issue?

For us, telltale signs of an IA issue include:

  • When navigating a product is tricky — you can’t figure out how to accomplish a task.
  • Misunderstandings around terminology — maybe there are questions around the taxonomy, or the labels for items aren’t resonating with the users.
  • When there’s too much information — users might be inundated with a lot of information and aren’t sure where to go next.
  • If you have several support calls coming in — there could be an underlying issue with labels or finding things.
  • The product has several offerings or continues to add more features and offerings — all these features need a home. Are they being added to the product where it makes sense?

If you’re running into some of these issues or feel like you might be soon, it might be worth looking into the IA of your product.

Is there a moment or right time to consider IA in the product?

  • Ideally, we think teams should consider IA throughout its journey. As with any other iterative design process, it’s good to examine your IA to ensure it’s working for the product.
  • Whenever you’re adding a feature, make sure you’re intentional about where it’s going and how users will access it. Skipping this could come back to haunt you later.
  • Early on and any time you can, try to future proof how your product might scale. It doesn’t have to be a significant effort to design this. For example, if you add a feature to the nav bar across the top, ask yourself, “What happens if we added two or three more things? Will we have room? Will it make sense?”

Keep in mind that no one will probably advocate for the IA since it’s not a feature that people will want to sell. So it probably won’t get recognized until there’s a crisis or a redesign.

UX IRL Takeaway: Always be thinking about the IA of your product. If you need help, lean on your teammates for feedback. It’s healthy to have everyone thinking about IA!

Special considerations for IA in product

As you work on IA in product, we have a few things to consider that might be different from a website IA. Consider:

  • How different devices might affect the IA. For example, the desktop vs. mobile experience could expose specific actions or features differently. How can you adapt the experiences yet maintain the mental model?
  • Your IA might be different depending on the browsers and operating systems. Ideally, the IA will be the same. But if you work at a large company, your product’s desktop app could be worked on by a different PM/Engineering/Design team than your iOS app. And everyone could opt to do things differently. This scenario is also where auditing (which we talked about in our last episode) is a great exercise to get a sense of how aligned things are.
  • How priorities and timing factor into releases. While we might want to change the whole IA in one fell swoop, it might not be feasible (e.g., different engineering teams, release cycles, etc.) Think of how you can work with disparate teams to align or how they gracefully stagger things, so they’re not so jarring for the users.
  • Your team might need convincing that IA work is necessary. Since IA isn’t as noticeable in products, people might want to jump into designing right away. It might take some effort to convince your teammates, but it’s worth it.
  • How you’ll communicate changes to the org. You’re working on a foundational backbone for the product. After the effort, ensure you document how the IA works so people will know where they can put future features into the product. This guidance is essential if you’re working with multiple PMs.

UX IRL Takeaway: IA in product is a little different. Keep in mind these considerations, and they’ll help you make things a little more manageable.

Our experiences with IA in real life

Mary Fran worked on an IA project for two companies that were merging. They were also redesigning the two sites into one. For the site’s redesign, she had a lot of questions about the taxonomy and definitions. For example, trying to figure out if there was a difference between “products” and “solutions” or even “services.” While IA wasn’t on the team’s radar, she advocated for it. She was successful by being scrappy and was at least able to get some information to make educated decisions. (Check out our episode of being scrappy with user research!)

She recently worked on the IA of settings across 8–9 endpoints for one SaaS app. It was fun and complicated to unpack why settings were different from browser to browser or operating system. She found out how other endpoints managed their settings and how they could be organized and streamlined. She also discovered content that had nothing to do with settings and would be better suited elsewhere!

Michelle’s experience included a redesign that ShareFile was going through in 2016. Initially, the team was ready to do some usability testing, but the researcher thought it might be helpful to look at the IA before diving into designs. Michelle joined the effort to tackle the IA, which although fun, it wasn’t easy. This redesign would be the first time the team looked at the app’s IA. She used the Modified-Delphi Card Sort method for her research, which we’ll talk about in a future episode. Working on the IA had the team focus on defining things well to ensure clarity. What’s been great is that enough time has passed, and she can confidently say that the IA has done its job — it’s stood the test of time. (Learn more about this project here: Advocating for IA in Product: A Case Study with Citrix ShareFile (IA Summit ’16 Poster))

Michelle’s latest challenge, which she’s still sorting out, is the IA of design systems. Design Systems are inherently complex. Design system documentation must ensure that the components and info about them are organized. There’s also a lot of information that can be specific to the operating system, device, situation, accessibility, etc. She’s drawn to the challenge of figuring out how to make tons of information easy to find. There must be clarity and consistency so designers and engineers can feel confident with the info they’re seeing.

UX IRL Takeaway: If you’d like to join Michelle in this IA challenge with design systems, she’d love to collaborate.

Our IA go-to methods and additional resources

If you want to learn more, here are some of our favorite methods and resources:

Card sorting — a way to group items into categories. We didn’t talk about this too much because we’ll be talking about it in a future episode.

  • OptimalSort — this is an easy-to-use tool with a free version you can try. We like how it synthesizes the data.
  • Card sorting with physical cards — we like the tactical aspect of moving cards around and engaging with participants. In terms of a similar experience, you can probably replicate it in a whiteboard tool like Miro.
  • Modified-Delphi Card Sort — this is Michelle’s favorite method of card sorting. Stay tuned for all the details in our future episode!

Tree testing — this is a tool that presents users with top-level categories. The users then drill through a navigation “tree” to identify where they would go to accomplish a task.

  • Treejack — this is another tool from OptimalWorkshop. We love its ease of use and the nifty pie tree diagrams it creates!

Guerilla testing — you can test the IA with or without a UI. You can even do quick testing to get feedback on terminology to see if you’re going in the right direction.

Books! You know we can’t go an episode without recommending a few books.

Conferences and networking

  • Information Architecture Conference (IAConf, IAC) — this conference is amazing! If you want to find your IA people, they’re here. Michelle likens this conference to summer camp! They have talks on practical UX topics and some hardcore academic subjects.
  • Lean on your community for mentorship and sharing. Since there aren’t as many IA geeks out there, definitely run things by your IA friends.

We’d love to hear from you!

Do you love IA as much as we do? What questions about IA do you have? Feel free to comment below or reach out to us on the zeroheight Slack group.

--

--

UX in Real Life
UX In Real Life

A podcast where we examine user experience design at work and the world around us. Brought to you by @soysaucechin + @maryfran874