Over the last few weeks, I’ve asked folks about what practices they believe practitioners need to know about information architecture. For the most part, replies have focused on issues related to communication and strategy.

Although this corresponds to my experience as an information architect (i.e., IA is a strategic function that often delves into political waters), it’s not what I expected. I was after more basic practices: the sorts of things designers do when using tools like Figma.

Perhaps we take these practices for granted and gravitate toward other skills we’d like to improve. But a strategic mindset and excellent communication skills are essential to other areas as well, and they can’t compensate for a lack of competency in a few core practical skills.

My list includes nearly thirty practices, but I’ll focus on nine essentials in this short essay. Why nine? Because I divide my practice into three broad areas:

  1. Researching
  2. Modeling
  3. Prototyping

There’s a neat symmetry in identifying three critical practices for each. Of course, there are many more — but the arbitrary limit makes for a good prioritization filter. Perhaps you can suggest others that fit in each area?

Before we get into it, I’ll state the obvious: these practices aren’t exclusive to IA; other design disciplines also employ them. These are just essential to IA projects and define the work in some ways.

Research practices

The work always starts with research. In particular, you want to understand the system’s content, context, and users. There are lots of practices that help here. (This was the most challenging area to narrow down.)

  • Content audits are a systematic way of analyzing a website or app’s content. You’re looking to grok underlying structures: what types of content does the system include? Which are more important than others? Who’s responsible for what? Etc.

  • Personas are research-based fictional characters designed to represent system users. A solid set of personas guides the team toward user-centric decisions. I’ve picked them as key because they result from other research practices, such as user interviews.

  • Card sorts are research studies that ask participants to organize concepts into groups. The goal is to understand how users think about the subject domain, which will go on to inform the system’s structure and navigation.

As I said, it was hard to pick only three research practices. In making this list, I’ve realized there’s no shortage of ways to learn. (Some runners-up include stakeholder interviews, ecosystem diagrams, heuristic evaluations, and desk research.)

Modeling practices

After understanding the system’s content, context, and users, you want to model new system structures. Modeling entails defining high-level information groupings and distinctions and labels to describe them.

  • Conceptual models are high-level representations of the system’s key concepts and how they relate to each other. The goal is to gain a “big picture” understanding of the system’s concepts to ensure they support users as they look to complete particular tasks.

  • Site maps are diagrams that represent a website or app’s structure. The aim is to clarify the system’s hierarchical structure: where users might expect to find particular concepts. Drawing these maps is the practice most closely associated with IA.

  • Tree tests allow you to validate and refine structural decisions by testing the findability of particular topics. I prefer to do these as early as possible to refine structures before moving on to higher-fidelity artifacts such as wireframes.

Again, you might quibble with my choices. E.g., why are tree tests listed as part of modeling? Because for me they’re part of the modeling process. I’d love to hear from you if you think differently or if there are other practices that should be here.

Prototyping practices

Modeling entails working with abstractions. But eventually, you must represent structural decisions as things people can interact with: screens, pages, navigation menus, etc. Screen-level prototypes allow you to validate findability and understandability and communicate your intent with other collaborators, such as UI designers and developers.

  • Wireframes serve as blueprints for how elements (including navigation and content items) will be laid out on screens. Wireframing allows you to explore how structural decisions impact the user experience before delving into visual design.

  • Taxonomies are lists of the terms that comprise system categories and labels. They directly affect the findability of information. I’ve included them under prototyping because you want to define such lists comprehensively at this stage.

  • Usability testing, also called (erroneously) user testing, entails evaluating prototypes with real users for findability and understandability. As with tree tests, you want to do this relatively early so you can iterate.

The process doesn’t end with prototyping; much work is needed to drive projects to production. But subsequent stages delve into visual design, content authoring, front-end engineering, etc. — areas where IA plays a more advisory than hands-on role.

Of course, I’ve left many practices out. Do you agree/disagree with my choices? What did I miss? (I plan to write more about these; your feedback would help make this list more valuable to new IA practitioners.)

A version of this post first appeared in my newsletter. Subscribe to receive posts like this in your inbox every other Sunday.