Trade-offs in information architecture: the return

Making design decisions isn’t so much choosing the right path, or even choosing the best path. It’s choosing the direction and being prepared for the trade-offs.

When you make a decision, you're choosing one possible outcome and costs you're prepared to live with. There are other perfectly good approaches. In choosing one direction you explicitly reject the others. Those other approaches may offer unique benefits, but in this moment one positive outcome is preferable to the others.

Trade-offs are inherent in designing anything, but perhaps most stark in designing a navigation menu and system. Navigation menus:

• Generally helps users understand what’s available on a website or in a digital product
• Typically follows a UI convention, showing hierarchical categories and contents
• Is the visible part of a site’s structure
• Has limited space

Because of these constraints and expectations, as UI elements go it’s perfect for illustrating trade-offs. You can’t do everything, so you have to decide what’s most important and what you are willing to live without.

I’ve long sought a reusable tool for designers to help them weigh trade-offs in designing navigation. The journey has been fraught, because I’m not really sure what I’m looking for in a tool. I’ve finally found a format that has some potential, but I can’t take credit for it.

In issue #74 of his newsletter, Stephen Anderson points to an article about a decision-making process called Even/Over Statements by Jurriaan Kamer. Says Kamer:

An Even/Over statement is a phrase containing two positive things, where the former is prioritized over the latter.

A good thing even over another good thing.

The simplicity is what makes it work. There are two good things, and in the ideal world, we would have both. But the reality of implementation and governance says we must always pick one to prioritize. By making both phrases about something good, they can be reversed and the statement would still make sense.

In one version of my trade-offs tool, I ask project stakeholders to indicate their preference between two conflicting design principles on a scale:

This framework has served me well in the past. It leads to interesting conversations, and highlights where the team is not aligned, but it never quite captured the trade-off.

I’d been working on another approach when Stephen’s newsletter showed up, and I put it to use immediately. In an active information architecture project, my team and I wrote a list of possible design principles, pairing them together to maximize the tension between them. We then turned these pairings into a workshop activity. James Melzer came up with the format which turned out OK:

All these principles came from things we’d heard during our stakeholder interviews and discovery work. I wrote them leading with the “-ing” form of the verb because that seemed to work best for swapping the phrases around. I would say it out loud like, “The home page should focus on getting users to a free trial even over ensuring users are getting the right product.”

As the workshop activity came together, we decided two things:

• Each pair should be about a particular aspect of the user experience, like the main navigation or the home page content.
• We should have no more than three pairs for each aspect of the user experience, to avoid any activity fatigue.

During the workshop, we asked participants (stakeholders on the project) to put a vote on the principle they think should come first. They did all three pairs for a single aspect of the site. I then read them aloud and we discussed them.

What worked

When trying a new activity I look for a few things, and these were evident here:

• Understandability: First and foremost, I’m looking to see that the activity was easy to participate in. Folks understood what they needed to do, and I sensed they understood what decision they were making.
• Surprising results: When an activity produces surprising results, I’m delighted. That’s the whole point of engaging a wide group of people, is to see perspectives that you don’t expect. On a few of the pairs, the group gravitated toward the option I didn’t expect. On some pairs, the votes were pretty evenly split.
• Discussion: Even on those options that were unanimous, we were able to talk through how people interpreted the principle and what it meant to them.

What didn’t work

I’d do this again, but with some changes:

• Getting the pairs right: The Even/Over format is flexible, and the beauty of it is that you can put any two positive things together in this way. (Puppies even over Ice Cream!) But turning Even/Over into a group activity requires more deliberation about the pairs. I didn’t feel like the participants were making hard choices.
• Two options isn’t enough: The scale activity works well because people have more than two options. In some versions of the scale activity, I only include values at the anchors, meaning participants can put their vote anywhere along the line: infinite options. That participants have more than two choices yields, in practice, more interesting conversation. It also allows us to talk about where the convergence happened along the scale; which side got more or less weight. With just two options, everyone had to pick either/or. Some nuance was lost.

In a follow-up workshop, I pitted two winning principles against each other, an Olympics-inspired “medal round” for design principles. While it was fun, and got us to talk through the principles further, it didn’t move the needle. I may try that again, but it doesn’t really solve the underlying issue. The binary forces the team to prioritize a single principle, when the reality of product design is that things are complex and nuanced.

My search for a tool to facilitate conversations about trade-offs continues, but I think we're getting closer.

What have you done with your team members and project stakeholders to engage them in conversations about design trade-offs?