Skip to content

6 Common Information Architecture Culprits and What Spotify Can Teach Us About IA

person going through vinyl records

What’s your favorite music genre?

According to Spotify, there are at least 1383 different ways to answer that question. Maybe Hip hop is your thing or Rock, but also maybe Heavy Christmas, Pirate Metal, Hatecore, or—God forbid—Ambient.

My top genres are Rap, R&B, Pop, Indie, Soul & Funk.

While all 1383 music genres exist and are totally valid, when you open a music streaming app like Spotify or Deezer (what I use), you don’t see all genres on the homepage. That is an information architecture decision.

Information architecture (IA) is the practice of structuring information. While I also consider the organization of books in a physical library information architecture, people usually refer to IA in the context of websites and digital products.

For example, every week, Spotify “makes” 2 personalized playlists for every single user. Many elements are involved in making this happen, but 2 acronyms play an especially vital role.

AI and IA.

Casey Newton, one of my favorite journalists, wrote about Spotify’s recommendations engine in Platformer:

“On Fridays you get Release Radar, which points you to new music from artists that Spotify already knows that you like. And on Mondays you get Discover Weekly, which attempts to point you toward music that Spotify’s math suggests that you might like. Sometimes that means an older song from an artist you recently discovered; other times it’s a lesser-known gem from a genre you like

Like a lot of AI, these recommendations started out mediocre but have gotten significantly better over time. By this point, Spotify clearly understands how old I am, what music I listened to in high school, what genres I love the most, and what gaps exist in my musical knowledge. Each week it works gently but relentlessly to fill those gaps.”

Those elements in bold (genre, artist, publish date) are basically ways to categorize information. But how would someone go about structuring information?

The information architecture process usually looks like this:

  1. Content inventory – A content inventory is a single document that stores everything published by a digital entity (say, your favorite specialty coffee shop’s website) in all the years it has existed as a digital entity.
  2. Talking to people – You’ll meet the people who were involved in the creation of the current navigation and/or the people whose work is affected by the navigation to understand the current state, pain points, and digging into the desired future state.
  3. Reviewing analytics Google Analytics and Hotjar are some of the tools we use. They provide information on analytics metrics like time spent on page, device breakdown, most visited pages, or scroll depth (do people scroll to the end of the page?).
  4. Talking to other people – You’ll meet the people who use the website and understand what they like about the current website, what’s confusing, and what’s missing. This process is also known as user research.
  5. Talking to more people – Damn, we do this a lot, huh? By this point, you should have a lot of ideas on how to improve the website to make it easier to use. Someone might say you have too many ideas. That someone is probably a product manager or engineer who can provide incredible clarity on technical feasibility, timelines, and budgets so you’re not presenting something that would take a year and 10 full-time engineers to build.
  6. Usability testing – You’ll ask users to perform certain tasks on the website like order the house blend, find the coffee shop’s address, or add a review for their no-handle espresso cups (10/10, I’m obsessed with these!). I’ll dive deeper into this in a separate article, but you’ll assess each task as successful or not. For example, if it takes users 5 minutes to find the address, while that task is considered complete, it’s still considered a failure because finding the address is a key user task and most users wouldn’t look for that long outside of a testing scenario. You’ll make updates to the information architecture based on these findings. This process is commonly known as user testing, but I find the term slightly problematic since we’re not testing users and this puts the responsibility on the user.
  7. A new information architecture that makes the website easy to navigate!

Information architecture vs Sitemaps vs Foundational architecture vs Taxonomy

You’ll likely hear all these terms during a website redesign or information architecture refresh, some less than others (foundational architecture, for example), and some used interchangeably (IA and sitemaps). They are different, though:

  • Information architecture (IA) is the practice of structuring information on a website or digital product.
  • While the 7 steps above are all important, IA is often associated with sitemaps which represent the website’s public-facing structure aka navigational menu and footer.
  • Foundational architecture (FA) is part of IA and it maps content types and how they’re related within the site. This isn’t public-facing. For example, while Music may be a key content type on Spotify, and Genre is one of its attributes, all 1383 Genres aren’t displayed on Spotify’s app homepage. Rather, users would only see the 10 most popular genres OR they’d see a personalized list that’s populated dynamically based on their preferences.
  • FA work is often also referred to as taxonomy. Yes, the same one you learned about in biology class when you were 12! The word is used across disciplines, and it’s a type of classification of items in groups, often showing hierarchical relationships between items.

6 common information architecture culprits

You don’t have to be a content designer or user experience specialist to be affected by information architecture.

One of the most brilliant information architecture thinkers of our time, Abby Covert, wrote one article each month of 2023 explaining how IA impacts different roles or types of organizations: authors, teachers, marketers, non-profits, etc. She said Dr. Brené Brown is an information architect (and so are her interns) which I loved and shared with my Brené Brown-loving manager.

Whether you’re a seasoned design professional who hasn’t had to deal with IA before or if you’re part of a team at work that’s steering the new website project, I love making sense of messes (what information architecture is all about) and I’d love to empower you to find out how much fun that can be.

There’s no quick-win cheat code, but if you follow the 6 steps above and keep in mind the 6 common information architecture culprits below (yes, 6 is my favorite number), I think you’ll be golden.

1: Lack of people who specialize in information architecture

Pure information architect roles are pretty rare (compared to product design, UX design, or even content design roles).

If you’re wondering what that role would look like, borrowing from a recent Splunk Information Architect job posting, an Information Architect will:

  • have experience from concept definition, to terminology and metadata, and to the realities of making it easy to find content and working across organizational boundaries to steward related improvements.
  • lean into innovating to resolve information recall and structure problems by working cross-functionally on all aspects of content taxonomies and mapping of core taxonomies, including keyword research, analytics, terminology-portfolio maintenance, application in product navigation and UI, application to content strategy, site search optimization, and implementation of technical SEO tactics.
  • seek beauty in the portrayal of content, and create value through clarity and organization.

Since web design has reached new peaks in the past few decades and we’re seeing more and more standardization across navigation, themes, and design systems in general, understanding IA is simply not a skill designers have had to develop.

This is equal parts scary and exciting to me, scary because I think you can’t design realistic solutions that work across organizational boundaries without a strong understanding of the foundational structure of the product, and exciting because building that understanding is fairly straightforward and can make designers even more valuable to companies.

2: Reliance on specific methods

“I’m not a fan of most UX models and diagrams because they’re either too complex to be useful, or I never seem to be in a situation where I can apply them.”

David Hamill

When researching information architecture, you’ll come across many ✨frameworks✨. Each author swears by the framework they use which sounds great in theory until you read another author’s post where they explain why that first framework doesn’t work and go on to explain virtually the same process with peripheral changes (bonus points if something like X is dead is in the title), and so on. The importance of sharing publicly our learnings and mistakes can’t be overstated, but that being said, be flexible about your methods and stubborn about outcomes and you shall be victorious!

3: Workshops for the sake of workshops

At the start of this process, you and the people on your team will feel it. It—the desire to gather as much information as possible from stakeholders—is inevitable. Fight it. Both culprits are common (not gathering enough information before you start building; gathering too much information), but since you’re reading this, you’ll likely suffer from the latter. During workshops, we discuss user needs and pain points and much more, but sometime after the third or fourth workshop, we get to the point of diminishing returns where we’re getting a lot of information and it’s coming from the relevant SMEs, but it’s not relevant to this project’s goals. You should be clear on how the information you’re asking for unblocks next steps.

4: Focus on aesthetics over usability

There are many cool things you can do with motion and interaction design in the navigation. You can search for “creative navigation menus” for inspiration and choose to do similar things for your product, but usability should remain your focus and main goal. Simple and useful > fancy.

5: Insider jargon

Something you’ve likely experienced more than once when visiting a website is seeing names like these in the menu: Analytics Keep, Pro Series Analytics Tool, Analytics Hybrid, usually listed under Products. What do these mean?! Who knows? Not me. However, they’re super clear to the company. If you’re a Senior Software Engineer working on Analytics Keep, you’ve seen references to it every morning for the past 4 years when you’ve opened your computer and accessed Slack, GitHub, or your company’s HR platform since your organizational chart reflects the product names. This type of naming convention based on familiarity is very common which is why step 6, Usability testing, is so important.

6: Tendency to overcomplicate

Look, I get it, if you’ve spent months on something, you want it to reflect that. For example, this Why Japanese Denim Is So Expensive video from Business Insider explains why some Japanese jeans cost over $2000. The price reflects the craftsmanship, quality, technique, and attention to detail. You want the end product to reflect all the time and work and care that went into it and it’s common to inadvertently make that happen by overcomplicating things. Resist the temptation to fall back on complexity as a litmus test of overall quality. Your users will appreciate it.

In Spotify’s words, that’s a wrap! If I had to choose the 3 key takeaways, they are (in no particular order):

  1. information architecture can be fun (it’s a giant puzzle… of words!)
  2. information architecture doesn’t have to be complicated (Avril Lavigne was right!)
  3. people enjoy weird music (let them eat cake… as they listen to Pirate Metal!)

Further reading
Gift ideas for the information architect in your life
  • Grand Taxonomy of Rap Names – 282 sobriquets from the world of rap music, arranged according to semantics
  • Everyday Information Architecture – book by Lisa Maria Marquis. This is not like a regular IA book, it’s a cool IA book. You can probably tell from this excerpt: “Of course, user needs aren’t the only consideration on a website—otherwise, something something downfall of capitalism.”

Add a comment...

Your email address will not be published. Required fields are marked *