Structural Arguments for Information Architecture

Congratulations, you’ve identified a mess and even have a potential solution in mind!

You’re ready to take on the challenge and create a better structure for making sense of that mess of yours. But as you embark on this journey, you quickly realize that the biggest hurdle is not the structural work itself, but convincing others to join you in making your proposal a reality.

In fact, the success of your information architecture (IA) effort largely depends on your ability to make a compelling argument for your proposal. IA work is not just about figuring out the right structure, it’s about bringing the right people together to make it happen.

I’ve learned that there is no one-size-fits-all solution when it comes to structures as well as how important it is to evaluate and compare multiple options carefully against your intentions.

Documenting a structural argument is one of the most effective ways I have encountered to compare potential options. In this article, I’ll be sharing seven common components of effective structural arguments that I’ve found useful in my own practice and in teaching others to practice IA. 

What is a structural argument?

A structural argument is an accounting of how a specific structural proposal is strong or weak.

Given the subjectivity of information architecture work, forming a structural argument (if only to argue with yourself) is a worthy use of your time and energy. 

Unlike relying on stakeholders to create their own structural arguments in their head about our proposal, we can more easily change hearts and minds (sometimes even our own) by making a clear and effective structural argument. 

There are three outcomes from this exercise I find benefit teams the most:

1. Comparability of Options: A structural argument can serve as a needed even playing field to compare potential structural solutions and is often how you can more clearly highlight less desirable or risky aspects of otherwise well-supported ideas on the table.
2. Empathy Across Roles: Compiling a structural argument can become a treasure trove of empathy for the other roles, processes and teams involved in delivering a proposed structural change. While excellent for improving working conditions, this increased empathy also has the awesome side benefit of a much more accurate estimation for aspects of change management like timing and resourcing.
3. Scope & Risk Assessment: The discussions that documenting a structural argument pushes forward often put cross-functional responsibilities, scoping specifics and risks into clearer focus allowing for less unexpected trade-offs along the way.

Common Components of Effective Structural Arguments 

To help you develop effective arguments for information architecture changes you want to see made, I’ve compiled a list of thought-starters, examples, and pertinent questions for each of seven common components of structural arguments I make all the time.

• Intention
• Information
• Content
• Facets
• Classification
• Curation
• Trade-offs

Intention

When we come up with solutions, we have to be sure to relate them back to the intentions we set out with for this structure. This part of our argument has to relate the solution back to a larger “why” for the stakeholders comparing solutions.

For example, I once had a student working on an app idea only to find out in comparing it back to their intention that they couldn’t rely on their audience to proactively download an app. It might sound like a bummer moment, but imagine learning that lesson after releasing an app. 

To assess the information part of your structural argument, ask the following:

• Who is this structure for?
• What is the intention of this structure?
• What alternative audiences and/or intentions are being deprioritized in proposing this structure?
• How does this particular structure reinforce or weaken your stated intention? 
• How is this structure measurable against your intention? At what pace?

To have a strong outcome in this component of the argument we need to know whether a structure is directionally in line with our intentions, but we also have to have ways we can measure that hypothesis over time. 

Information

A core point raised about practicing information architecture is that we can’t actually make information, in fact our users do that for us. All we can do is provide content in a structure that we hope is interpreted as intended by our audience. 

When arguing for potential structures, spend extra attention thinking about and researching how an intended audience might interpret the structures being proposed. This is the part of the structural argument that most invites us to think about this structure through the mind of a user.

For example, I worked with a client who had structurally buried content about their pricing deep into their site hierarchy. In doing so, they unintentionally created mis-information that they were super expensive. 

By pointing out how their mental model of “not being pushy with price” created such unintended consequences, I was able to make a strong structural argument for a change that raised the priority of pricing content in the navigation hierarchy.

To assess the information part of your structural argument, ask the following:

• What messages is the audience leaving with from encountering this structure? 
• Does the proposed structure “make sense” to them? 
• Are you sure it “makes sense” to your audience? How do you know? 
• How will they tell you when something doesn’t make sense?
• What is the cost of this not making sense to your audience?

To have a strong outcome in this part of the argument we need to be able to confidently project how an audience might interpret a structure. If you feel like you are just making stuff up in this stage of building an argument, it’s a good signal that you need to talk to and observe more real users.

Content

A structure’s strength cannot be evaluated without an in-depth knowledge about the content that the structure will coordinate the use of. When making a structural argument there are some potential solutions that end up falling down under the weight of real content (or lack thereof).

For example, in the early days of social media I served as an IA for a product that was entirely dependent on user-generated content to be interesting. In order for the project to be successful, we had to coordinate specific strategies to get users to produce and upload that content. And the first few weeks of launch were critical since it was the first chance we had to be of enough interest to our intended audience to participate. 

If we had launched that product without the help of our marketing and PR partners, I can’t even imagine how fast the project would have tanked, regardless of its structural strength.

When considering this component of your structural argument, be sure to ask yourself (and your colleagues) for an accounting of the entire content lifestyle in context to your organization and systems. There are details about how content is made, approved, stored, accessed, manipulated, rejected … the list goes on … that matters deeply to the success of a structure.

To assess the content part of your structural argument, ask the following:

• What are the “things” actually being organized? 
• How is content created, managed and shared? And at what pace?
• How much content is there currently vs. expect to be overtime? 
• Who owns each piece or type of content? 
• Who determines content quality? And by what rubric of heuristics?
• What ethical considerations need to be made in regards to the expected content?
• At what pace do different pieces of content age? What processes need to be in place to handle that pace?

To feel like we have this part of our argument solid, we need to have thought through a lot of details about how content will be made and managed. If your structural argument involves a ton of “TBD” in the content bucket, think about whether you know enough yet to make this kind of structural argument. 

Facets

When it comes to content, there is an equally important layer in a structure called facets. Facets are what we know about the content we are organizing. In digital products this layer often takes the form of metadata we have about the content we are managing. We use facets to determine what to show where to whom. 

For example, when working on a large eCommerce platform I was part of a team that was exploring inferring metadata about items that had been uploaded to the platform by users. In our first round we identified 20+ metadata attributes that had low adoption from users that we felt confident in our machine learning model to assist in inferring metadata and presenting it for user confirmation. Once confirmed by the user we could then use this inferred data to make more powerful filters and personalization experiences throughout the product.

Facets are a powerful medium in the creation of structures, and as such there are alot of important questions you should be asking. 

To assess the facets part of your structural argument, ask the following:

• What can be known about each type of content being organized? (e.g. date created, creator, category, price etc)
• Who provides each piece of that knowledge about the content?
• How is this knowledge about content captured? At what pace? In what format/tool?
• How is the quality of that knowledge determined? By whom/what?
• What ethical considerations need to be made in regards to how facets are collected, manipulated or distributed?
• Which facets are being utilized to generate the proposed structures?
• Which facets are being relied upon to create a quality user experience inside the proposed structure? 
• What are the right labels for communication of facets when sorting and browsing?

We will know we have properly covered this part of our argument when we can say that we are confident that we have what we need to power the structures being proposed. If you find yourself with a growing facets-wishlist at the end of this part, consider whether you are relying on too much magic, and not enough reality when it comes to what facets you can reliably work with. 

Classification

Classification is the rules we use for sorting things into labeled groups. When we have content and a structure we intend to house that content, we have to decide and document how our content will sort itself into the structure being proposed.

If you were to look at jumpsuits on a few fashion websites, you might run into a classification issue that is running rampant in the fashion world: Is a jumpsuit a dress? 

Objectively jumpsuits do not share the one facet of dresses that seems to matter most to classification: lack of leg separation. And yet this problem abounds where brands really seem to want to put them in the same place as dresses. 

As jumpsuits have become more popular so have entire categories to merchandise them on some eCommerce sites. But in many cases where a category of ‘jumpsuits’ exist, you will see jumpsuits classified into both the ‘jumpsuits’ category and the ‘dresses’ category. 

This is an effective structural strategy to get an audience who is less jumpsuit-aware to consider a new category when seeking a dress, which shares many contexts with wearing a jumpsuit. What smarties. 

In some cases the needed rules are pretty obvious and often simple, especially when you understand your content well. But there will inevitably be a “jumpsuit” type item that comes into your sorting context every once in a while. And when that happens, it’s important to have had classification discussions earlier in your process so you (or the system) knows how to handle it.

To assess the classification part of your structural argument, ask the following:

• What rules will drive the classification behind the proposed structure? 
• Which facets drive which groupings? 
• What could break the classification as proposed?
• What clarity might you risk losing from ambiguous or vague categories? 
• What flexibility might you risk losing from forced precision in prescribed categories?
• What ethical considerations need to be made in regards to classification?

Classification is much more art than science, so to know that this area of your argument is strong we need to make sure we have talked about classification enough to feel like it has been pressure tested against our future intentions. If you are already running into lots of instances where polyhierarchy (classified into multiple categories) are needed, perhaps this part of your structure is not yet solid enough to argue. 

Curation

Even when we have a strong proposal for how content should be classified for use in the system, there are still important details to consider when it comes to how the content is curated throughout an experience.

You can think of the classification part as identifying the superset of faceted knowledge, while the curating part is identifying the subsets that will be used for specific purposes.

For example, when I worked on improving an online community for creative people to share small business insights I created a controlled set of tags that users would use when classifying their posts. Internally we used those tags to curate content throughout the experience, from suggested articles to what appeared on the home page. We also had another set of tags meant for admin-only. These allowed us to more tightly curate some parts of the experience to better control for quality. 

Lastly, we documented a set of rules to sort the old content into the new tag taxonomy. This was a curation decision we made so the original goodness of the community didn’t disappear or create a weird silo-d island of pre-migration vs. post-migration content.   

To assess the curation part of your structural argument, ask the following:

• Where is curated content required? 
• At what pace is curation taking place? And in what systems/tools?
• How often is something added, changed, or removed in this system? At what volume?
• In what ways might this plan for curating potentially negatively impact your intended classification? 
• What ethical considerations need to be made in regards to curation?

This part of a structural argument is dependent on a clear understanding of the proposed content strategy for bringing this structure to life and keeping it fresh overtime. If you feel like this part of your argument feels like a pipe dream to orchestrate over time, take it as a sign to keep pushing on this conversation to reveal how the structure needs to adjust for the reality of your resources. 

Trade-offs

I am not a pessimist for saying there is no such thing as an effective structural argument that doesn’t name at least one trade-off that is being made. If you are having trouble finding fault in the structure itself, make sure you are also looking at “side effect” trade-offs like migration management, potential system down times, staffing changes to support, skills and services that need outsourcing, the cost and time of cleaning data etc etc etc.

For example, I was once in a meeting where 10+ creative people presented concepts they felt strongly would resonate with the intended audience based on user research and competitive analysis. 

They were all met with ohs and ahs, because the concepts were freaking rad. And then someone (it me) had to point out that not a single concept presented was possible to implement without a significant investment in data cleaning. 

While this was bummer news to deliver at the moment to those smart creative folks with unbuildable solutions, it ultimately became a strong point in my argument for a longer term investment into data cleanliness. 

To assess the trade-offs of your structural argument, ask the following:

• Who might be negatively impacted by this structure? Even temporarily.
• What resources are required to build and maintain this structure?
• What tools, data, skills or services that are currently available to you will be needed to support this change?
• What tools, data, skills or services that are NOT currently available to you will be needed to support this change?
• What is the cost of implementation?
• What are the benefits of implementation?
• What is the perspective on short vs. longer term stability and effectiveness?
• What is the expected return on investment (ROI)? 
• In what timeframe should ROI be measured given the proposal?

When it comes to managing up through your reporting line, or across teams this part of the structural argument is often where a lot of clarity and compromise can be found. If you get to the trade-offs part of your argument and feel like you are making a proposal that sounds like a real drag, think hard about whether the return on that investment is inline with the effort. 

Got it? Ok …er, now do it twice.

Now that we have walked through the seven common components of structural arguments I am going to end with some advice that usually really ticks off my students AND is often scoffed at, especially by busy teams of practitioners.

I recommend that you make not just ONE structural argument. I want you to make at least TWO. 

By creating two alternative structures that potentially help you reach your intention, and then thinking deeply about each component of a structural argument for each, you will end up with a stronger argument for whichever structure will better serve you. 

I know this sounds tedious, and many of you may file this into for-students-with-ample-time advice, but I cannot tell you how often I make that annoying second alternative structure only to find it is a better and simpler solution OR at the very least this exercise teaches me how strong my original proposal is and what to plan for when arguing its strength. So, to me, it’s a win either way.

You don’t have to show stakeholders both options or put things up for a vote, although there are times when doing that opens up great discussions that would perhaps not have been had with only one option on the table. Structural argumentation is an activity that can be as open or closed as you feel is useful. 

In the end making a structural argument is the best way to gut check your own work as you move from the 20% of coming up with a proposed structure, into the 80% of doing everything else needed to make structural change actually happen. 

To close, I hope you are taking two important points away:

1. Never argue for a proposal you haven’t fully thought through
2. Don’t underestimate the power of NOT settling for the first idea

Now, go find someone to argue better with. 

—

✍️ If you enjoyed my thoughts on this topic you might also enjoy reading some case studies of my information architecture work for Nike, IHOP and Hanna Andersson. 

🎥 If this article about IA has you interested in learning more, I offer a 30 minute FREE video eCourse called Information Architecture for Everybody covering basic concepts, methods and common questions people ask while learning about IA.

🤓 If you are ready to go from curious to confidently practicing information architecture in your own context, consider becoming one of my students by registering for The Practitioner’s Guide to How to Make Sense of Any Mess. This course includes access to my LIVE monthly office hours. 
 💌 If you want to keep up with the latest from me, join my monthly email list. And if you found this to be of value, I would be so appreciative if you sent this piece to anyone else who might also find value in it.