10 information architecture traps we all fall into: Part 1

Designing an information architecture (IA) is a process like any other — things don’t always go to plan. Stuff happens. Nobody’s perfect! We’re all on our own journeys and we’re all dealing with our own unique challenges and constraints. In Part 1 of this series, let’s take a look at 5 common IA traps we’ve all fallen into, how they happen and how to avoid them.

1. Not running a benchmarking tree test when redesigning an existing IA

It can be tempting to launch straight into fixing a problematic IA and then test that thinking, but if you don’t do a benchmarking tree test upfront you may run into trouble down the track. Benchmark tree testing will not only provide you with a quantifiable picture of what you’re working to improve but will also help ensure you’re solving the right problems. If you don’t run a benchmark tree test on your IA, you won’t have hard data to compare your future progress to and you may also end up creating more work for yourself by missing some key issues that need fixing.

This tends to happen when we join a project late in the game or the time and funding constraints tighten and you may find yourself feeling the pressure to deliver. The thing is, doing a benchmark tree test will actually save you time in the long run and will also provide you with the means to prove the value of your design work which we all know can be quite a tricky thing to do. Avoid this trap by running benchmark tree tests where possible and if you happen to join a project late in the design process, see if you can get your hands on the original version of the IA and run a test in parallel to whatever stage your process is at. Benchmark tree tests don’t need to be big or expensive — you can easily run one using the free version of Treejack.

2. Not doing a card sort upfront

If you don’t do a card sort upfront you won’t really know how your users expect your content to be grouped. So when you’re designing your IA, you’ll be guessing a lot more than you need to be and creating unnecessary additional work for yourself. Like the benchmark tree test, this one can happen when we join a project late or those pesky resourcing constraints come knocking — but this doesn’t have to be difficult or expensive to fix.

Again, no matter where you are in the process try and get ahold of the original IA.

You can easily run a card sort on the cheap by launching an OptimalSort study. You don’t have to run a card sort on the whole thing either — you can scale it down and focus on the area of your website that you’re working to improve. You could run a moderated card sort using the printed cards from OptimalSort and take your team and stakeholders along for the ride and then scan the cards back into the tool for quick analysis. This will give you something to compare future iterations to and will also potentially course correct what’s already been done.

3. Aligning your IA structure to your organizational structure

Structuring your IA based on how your organization or government department is structured is never really a good idea. Unless your user research indicates that this is indeed how your users expect your content to be grouped and structured, don’t do it.

This is a common problem with government websites and intranets. People will often fall into the trap of thinking that users think and view these structures the same way they do but this isn’t always true. People don’t always understand government and your internal staff may not think the same way as the people who designed your organizational structure. Claw your way out of this one by doing your research. Don’t make assumptions and don’t just replace one IA with another one that may or may not be fit for purpose. Do a card sort and tree test for your information architecture to find out how and where people actually expect to locate information.

4. Making it look like Google

Whacking a giant search bar in the middle of your home page and hoping that will take care of any gaps or missteps in your IA is a recipe for disaster. Same goes for overly relying on search capability in general. It might be that the organization spent a lot of money on a search tool and they want to make the most of it or perhaps a senior stakeholder or project team member asked you to do it this way. Unless people are searching for very specific things that happen to be called equally very specific things, it’s not the most effective way to find your way around a website. Whatever the reason, search capability should never be used to prop up an IA.

Think of your website as a house. The IA is the frame and layout of the rooms, the taxonomy defines which pieces of furniture belong in each room, the navigation is the hallways and the doorways and search happens when we lose the TV remote. They all live under one roof but the use of the whole house shouldn’t depend on someone’s ability to rummage through couch cushions! Google looks and behaves the way it does because that is its job — to search for things. Things like your website — not more search engines.

Avoid this situation by creating information architecture through a design process built on research, best practice, usability testing and iteration. If you’re redesigning or refining an existing website, search logs can help you work out what content you should be surfacing and where to avoid them having to search for it in the first place! Use the search logs as a starting point and run a tree test to check your thinking.

Educate stakeholders and team members who aren’t quite there yet — create a tree test and talk them through your process. They don’t know what they don’t know and part of our job as designers is to share our knowledge and take people along the journey with us.

FAQs are where lazy too-hard baskets go to die.

5. Creating an FAQs section

FAQs are where lazy too-hard baskets go to die. They are content graveyards that take up space and waste people’s time. You’re not helping your users by creating a pile of questions written in a way that you think mimics how they think and problem solve. All to do what? Stop them from calling you to ask for help? Help your users help themselves by designing your IA and content strategy properly in the first place.

FAQ sections are borne out of thought patterns such as “We’ve always had one” or “Websites are supposed to have them” and “How else are people supposed to solve their own problems?” Sometimes they’re created out of laziness and sometimes they come from genuine but misguided care for users. It might be that you work for an organisation or a client that isn’t quite ready to let go of it or they may believe that it truly does add value. Much like with the search engine shenanigans, it is our job as UX practitioners to educate and help others understand best practices and how to apply them. Mindset is crucial and it can be an uphill battle trying to affect this type of change! Take them on the journey and help them build empathy for users because a well thought out IA does not need an FAQs section. I’ve said it before and I’ll say it again — do your research, iterate your IA and test as often as you can.

There’s the first 5 common IA traps we all fall into — keep an eye out for the next 5 in Part 2!