Great information architecture starts with understanding the target system’s content, context, and intended users. Researching user needs and mental models entails interviewing and observing folks, which takes time to set up and carry out. As a result, I often start projects by doing desk research instead.

By “desk research,” I mean research you can do independently, without interviewing users, stakeholders, subject matter experts, or other actors. Desk research can take many forms. But unless you’re looking to understand an established subject matter — the sort of thing you read about in libraries — you’ll sit in front of your computer reviewing materials and searching for stuff online.

What kind of stuff? An obvious place to start is by examining existing research: often, teams have material from previous initiatives that can inform design directions. Some will require updating but can serve as a starting point. Let’s put these aside and assume you’re starting a greenfield project — that is, one with no prior research. Here are some materials you can review at your desk:

  • Subject matter literature
  • Competitive websites and products
  • User feedback
  • Usage data
  • Third-party resources

Let’s look at all of them in more detail.

Literature review

Literature reviews entail reading through existing materials. These can include presentation decks, PDFs, email threads, articles, white papers, or other materials that might illuminate the subject. An obvious place to start is by Googling the subject you’re dealing with.

For example, I worked on a system that used a particular artificial intelligence technique as a key competitive feature. I didn’t know anything about the technique, so I read everything I could about it online, including research papers. I took notes as I went and learned about how the technique worked, which ended up informing the structures we proposed for the product.

The keys here are 1) learning good search techniques and 2) synthesizing what you learn to derive valuable insights. The second is an art unto itself, but I recommend Dan Russel’s book The Joy of Search for the first. (Check out my interview with Dan on The Informed Life.)

Competitive analysis

Competitive analysis entails looking at how competing products work or how competitors market their products.

Examining marketing materials is straightforward: you can look at competitors’ websites and note how they organize and explain their offerings. Analyzing competitors’ product UX can be more challenging since it requires access to the product itself or a demo.

(Tip: when researching product UX, YouTube is your friend. Many companies and their partners post video walk-throughs and tutorials of product UIs. These can be very helpful when looking to understand how products are structured.)

There’s a specific IA angle to competitive analysis: you’re looking for the particular language and distinctions competitors use since your users will likely compare competitors to your offerings. Your competitors’ language and categories will inform users’ mental models.

You want to consciously choose whether to use similar language and categories to other industry players or position yourself as an outlier. Either case requires that you understand your competitors.

User feedback

If your product is available in app stores or other venues that allow reviews, you should look at what people are saying. Is the product well-liked? Are users calling out particular issues? Again, remember that we are primarily concerned with language and categories.

If you’re working on a consumer product, look for user reviews. People sometimes upload reviews to YouTube or share their thoughts on social media or blog posts. Another important source of user feedback is support requests. Ask your organization’s support teams to share with you comments from customers. Are there recurring issues with people getting confused or lost?

Sometimes, customers and prospects also suggest how things should work. Talk to members of your sales team to see if they’ve heard anything that might help. (This starts to move away from desk research, since you’ll likely have to meet with these other team members to learn about this kind of feedback.)

Data analysis

Another important source of information is system logfiles and reports. The most common is site performance metrics, such as those you get with Google Analytics. These offer helpful information about the site’s most and least visited pages.

If you’re working on a product rather than a website, look to see if there’s telemetry data about user activities on the product. These are similar to site performance metrics in that they can give you a sense of the system’s most important or most used parts.

And if your product or website uses an internal search engine, you also want to examine your search logs. These capture terms users search for in your system, which can teach you much about what they’re looking for, what they might call things, and whether or not you are serving the stuff they need. (Lou Rosenfeld’s Search Analytics for Your Site is a good resource here.)

Of course, these suggestions assume you’re working with an existing product or website. You won’t have much data available when working on a new system.

Third-party resources

One final area you can look at is third-party resources such as industry case studies and reports from analysts such as Forrester and Gartner. These are useful in helping you understand the broader context you’re working within, competitive product ratings, and the categories industry observers might care about.

When considering how your product or website might be organized, you can take these as input. Again, when working on IA, the focus is understanding the concepts users need to encounter and the language they use to describe them. Look for key words or phrases that seem standard across the industry you’re dealing with.

Learn and share

To recap, IA research entails understanding the system’s content, context, and user mental models. While some of these areas require interviewing and observing folks, there’s a lot you can learn from searching stuff online and by reviewing existing materials. You can start doing these activities immediately without scheduling meetings and interviews.

You’ll learn a lot by devoting time to examining existing materials. But remember to capture and synthesize what you learn so you can share it with other team members. Also, be open to taking your research in new directions based on what you discover — after all, you don’t know what you don’t know. Set up opportunities for frequent reality checks. Desk research is only valuable if it generates insights that inform design directions — and that won’t happen if you keep it to yourself.

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