Information architecture: the invisible foundation

How you organise and label content determines whether people can find what they need - and whether they trust you enough to use it.

Depiction of two paths someone has around information architecture: clarity or chaos

What information architecture actually is

Information architecture is the art and science of organising content so that people can find what they need, when they need it, without getting lost or frustrated along the way.

It's not about making things look pretty. It's about making things make sense to the people who actually use your website.

Think of information architecture as the blueprint for how information connects, flows, and relates across your entire website. Just like a building's architecture determines how people move through physical spaces, information architecture determines how people move through digital ones.

Every content decision you make - from page titles to menu labels to how you group related information - is an information architecture decision. You're not just adding content; you're shaping how people understand and navigate your organisation's knowledge. And those people - the actual users - are the only judges of whether you've succeeded.

Start with users, not opinions

Here's the uncomfortable truth: everything you think you know about how your website should be organised is probably wrong. Everything your colleagues think they know is probably wrong. Everything your leadership thinks they know is definitely wrong.

Because none of you are the people desperately searching for childhood diabetes research at 11pm after their child's diagnosis. None of you are the healthcare provider trying to quickly find contact details for a specific study. None of you are the parent scanning your homepage for five seconds before deciding whether you're worth their time.

Users are the only reliable source of truth about what works and what doesn't.

Yet most organisations make website decisions based on internal politics, personal preferences, and what feels logical to people who work there. This is backwards. It's like designing a car based on what the mechanics think is important instead of what drivers actually need.

History is littered with companies that prioritised internal thinking over user needs. When Apple launched the iPhone in 2007, BlackBerry executives said "[the iPhone] had rapid battery drain and a lousy [digital] keyboard." BlackBerry executives were convinced that users wanted physical keyboards, longer battery life, and enterprise email integration - because that's what BlackBerry thought was important. They built what they assumed users needed based on their own internal logic.

Apple, meanwhile, had watched how people actually behaved with mobile devices. They saw users struggling with tiny keyboards, wanting larger screens for web browsing, and trying to do more than just email on their phones. Apple built for actual user behavior, not internal assumptions about what users "should" want.

BlackBerry went from 50% market share to less than 1% in five years.

Your website faces the same choice every day. You can organise it around what your teams think is important, or you can organise it around what your users actually need. Only one of these approaches has a sustainable future.

Every information architecture decision should start with one question: How do our users actually behave? Not how we think they behave. Not how we want them to behave. How they actually behave.

The mental model challenge: theirs, not yours

People don't arrive at your website with a blank slate. They come with expectations, assumptions, and mental models about how information should be organised - often based on their own needs rather than what your organisation wants to promote.

A parent looking for childhood diabetes research thinks in terms like "Is my child eligible?" "What's involved?" "How do I start?".

A parent of a child with autism seeking clinical services thinks "What help is available for my child?" "How long is the waiting list?" "What will this cost me?"

A teenager in a remote area who's heard about your organisation wonders "What do these people actually do?" "Is this relevant to someone like me?" "How do I get involved?"

A researcher from another institution looking for collaboration opportunities thinks "Who's running that autism genetics study I heard about?" "What's their methodology?" "How do I contact the principal investigator?"

They don't think in terms of what your organisation wants to highlight: "Our strategic goals," "Our award-winning team," or "Our new partnership announcement."

What your organisation thinks is important is irrelevant to users. They don't care about your strategic priorities, your funding goals, or your reputation-building efforts. They care about solving their problem.

Users arrive with urgent, specific needs. Your organisation has broader goals: showcasing expertise, attracting funding, building partnerships, demonstrating impact. These goals often conflict directly with what users actually need to find.

This doesn't mean organisational goals are unimportant - but they should never obstruct user needs. The most effective approach is to embed your strategic messages within user-focused pathways rather than competing with them for prominence.

For example: instead of featuring "Strategic Partnerships" prominently on your homepage, integrate evidence of your collaborative work within the "Find a Study" section where families actually look. Instead of creating a separate "Awards and Recognition" section that families will ignore, include relevant accolades within researcher profiles or study descriptions where they provide useful context about expertise and credibility.

Your organisational goals are best served when users can successfully accomplish their goals. A parent who easily finds and enrolls in your research becomes more trusting of your organisation, more likely to engage with you in the future, and more likely to contribute to broader organisational outcomes like donations or advocacy. A healthcare provider who quickly locates collaboration information is more likely to refer patients to your studies and recommend your institute to colleagues.

Effective information architecture bridges this gap by organising content around user needs first, then strategically placing organisational messages where they support - rather than interrupt - those user journeys.

Labels that guide users, not confuse them

One of the most powerful yet overlooked aspects of information architecture is labeling. Every page title, menu item, and section heading is a wayfinding tool that either helps people understand where they are and where they can go, or leaves them guessing.

Consider these two approaches to organising research participation information:

Internal perspective (what staff understand):

  • Research excellence showcase
  • Publications and outcomes
  • International collaborations
  • Centre capabilities

User perspective (what families actually need):

  • Find a study
  • Participation process
  • Support available
  • Contact researchers

The first set reflects how your organisation thinks about research. The second reflects how families approach research participation. Both are accurate, but only one serves your audience effectively.

Users don't speak your internal language. Good labels are specific enough to set clear expectations but written in terms that real people actually use. "Participation requirements" is clearer than "Eligibility criteria" for most families, even though both refer to the same information.

Stop using labels that make sense to you. Start using labels that make sense to the people who need to find information quickly.

Content relationships that support real user journeys

Information architecture isn't just about individual pages - it's about how those pages relate to each other and support the paths that users actually take through your content.

Some visitors want to understand your research focus before considering participation. Others already know they want to participate and need specific enrollment details. Still others are looking for contact information for a study they heard about elsewhere.

Your information architecture should support all these different approaches by:

  • Creating clear pathways from general information to specific details that match how users actually progress through decisions.
  • Connecting related content so people can easily find additional relevant information without having to restart their search.
  • Providing multiple entry points for different types of visitors and questions that users actually have.
  • Making next steps obvious at every stage based on what users actually need to do next, not what you want them to do.

Users don't care about your internal politics

As websites grow, there's a natural tendency for every department, researcher, and project to want prominent placement. Communications wants the latest media release featured. Individual researchers want their studies highlighted. Administrative teams want policy updates visible. Everyone believes their content deserves front-and-center treatment.

Users don't care about any of this.

When everything is a priority, nothing is a priority - and users pay the price. The homepage becomes cluttered with competing calls-to-action that serve internal politics rather than user needs. Navigation menus grow unwieldy with every possible option that someone internally thinks is important. Users become overwhelmed and leave without finding what they actually need.

This is organisational selfishness disguised as comprehensiveness.

Effective information architecture requires making difficult decisions about what matters most to your primary audiences - not what matters most to your internal stakeholders. You must be willing to organise secondary content in ways that support - rather than competes with - what users actually need.

The hierarchy of actual user needs (not assumed ones)

Not all visitors to your website have equally important needs, and not all content serves equally important functions. Successful information architecture acknowledges this through deliberate prioritisation based on real user behavior and organisational goals.

For a medical research institute, the hierarchy might look like this:

  1. Primary: Families looking for research participation opportunities, healthcare providers seeking collaboration, researchers looking for specific studies or contact information.

  2. Secondary: Media seeking expert commentary, potential employees looking for job opportunities, other institutions exploring partnerships.

  3. Tertiary: Administrative information like annual reports, policy documents, or organisational charts.

This hierarchy should be based on actual data about who visits your website and what they're trying to accomplish - not assumptions or wishful thinking. If you don't know what your users actually need, you need to find out before making any other decisions.

Practical prioritisation based on user reality

When facing competing demands for content prominence, use these questions to guide decisions:

  • Who is the primary audience for this content, and how often do they actually visit your website? If it's not one of your main user groups (based on actual data), it probably doesn't belong in primary navigation or homepage space.

  • What action do you want people to take after reading this, and how does that align with what users actually want to do? Content that supports both user needs and organisational goals should be easier to find than content that only serves internal purposes.

  • How time-sensitive is this information for actual users? Permanent information that users regularly need should get different architectural treatment than temporary announcements that primarily serve internal communication.

  • What happens to users if they can't find this quickly? Some information needs to be immediately accessible because users have urgent needs, while other content can live in deeper sections without causing real problems for real people.

  • Do you have any evidence that users actually need this prominently placed? If the answer is no, you're probably serving internal convenience rather than user needs.

The homepage: designed for users, not committees

Your homepage is often the first impression people have of your organisation's information architecture. It needs to quickly communicate what you do, who you serve, and how visitors can find what they need.

Homepage by committee is homepage by nobody. When everyone gets their pet project featured on the homepage, it becomes useful to no one.

Instead of trying to include everything on the homepage, focus on creating clear pathways to the information that users actually seek most often. This might mean highlighting current research opportunities for families while also providing clear routes to information for healthcare providers, researchers, or media.

A well-architected homepage acts like a good receptionist: it understands what different visitors need and guides them efficiently to the right place. It doesn't try to tell visitors about every service, every staff member, and every policy all at once.

User testing: the only validation that matters

The best way to test whether your information architecture works is to watch real people try to find real information on your website. Not your colleagues. Not your management. Real users.

Ask people outside your organisation to find specific information: "How would you find out if your 8-year-old could participate in our autism research?" "Where would you look for contact information for Dr. Smith's diabetes study?"

Pay attention to where they look first, what confuses them, and what path they take through your content. Their navigation patterns will reveal gaps between how you've organised information and how people naturally look for it.

User behavior trumps all internal opinions. If users consistently can't find something, it doesn't matter how logical the organisation seems to you. It's wrong.

How to gather user insights when you don't have data

Not every organisation has comprehensive website analytics or established user research processes. But that doesn't mean you can't understand your users. If you have a mailing list, participant database, or regular contact with your target audience, you already have access to the insights you need.

Start with your existing contacts. You very probably have mailing lists of families who have participated in studies or expressed interest in research. These people are your real users - use them.

Structured user interviews

Reach out to a representative sample of your contact list and invite them for brief sessions (30-45 minutes is usually sufficient). Aim for diversity: different age groups, different research areas, different levels of previous participation experience.

During these sessions:

  • Ask them to complete specific tasks on your website while you watch: "Find information about studies for children with autism," "Look up contact information for Dr. Smith's diabetes research," "Figure out if your 6-year-old would be eligible for any current studies."

  • Record what they actually do, not what they say they do. People often can't accurately describe their own behavior, but you can observe it directly.

  • Pay attention to hesitations and confusion. When someone pauses, asks "Where should I look?" or says "This doesn't make sense," you're seeing exactly where your information architecture fails.

  • Ask follow-up questions about their expectations: "Where did you expect to find that information?" "What would you call this type of content?" "What questions do you have after reading this page?"

Survey-based insights

If you can't organise in-person sessions, surveys can still provide valuable user perspective - but only if you ask the right questions.

  • Don't ask hypothetical questions. Instead of "What would you want to see on our homepage?" ask "The last time you visited our website, what were you trying to find?"

  • Focus on recent, specific experiences: "When you last looked for research participation information, what was the most frustrating part?" "What questions did our website leave unanswered?"

  • Ask about language and terminology: Show them two different labels for the same content and ask which makes more sense, or ask them to describe what they'd expect to find under different page titles.

Stratified sampling for representative feedback

Your user base isn't homogeneous. Parents of newly diagnosed children have different needs than those with years of experience. Healthcare providers approach your site differently than families. Make sure your research reflects this diversity.

  • Segment your contact list by relevant characteristics: type of condition, child's age, previous participation experience, professional vs. family user.

  • Recruit proportionally from each segment so your insights reflect your actual user base rather than just the most vocal or available participants.

  • Compare responses across segments to identify where different user types have conflicting needs - this will help you prioritise and create appropriate pathways for different audiences.

Recording and analysing subjective responses

User feedback often comes in the form of feelings and impressions that seem subjective but reveal important patterns when aggregated.

  • Document exact quotes: When someone says "I felt lost" or "This seemed really complicated," record their specific language. These emotional responses often indicate architectural problems.

  • Look for patterns across users: If multiple people describe the same section as "confusing" or "overwhelming," that's not subjective opinion - that's objective evidence of a user experience problem.

  • Track common terminology: When users consistently use different words than your internal language ("sign up" vs. "enroll," "join" vs. "participate"), you're seeing how real people think about your content.

  • Note what users expect to happen next: After reading a page, what do they think their next step should be? This reveals whether your content relationships match user mental models.

Making user insights actionable

The goal isn't to collect feedback - it's to improve your information architecture based on what you learn.

  • Prioritise changes based on frequency and impact: If 80% of users struggle to find the same piece of information, that's your highest priority fix.

  • Test your solutions with the same users: After making changes, go back to some of the same people and see if the problems have been resolved.

  • Document patterns for future decisions: Keep a record of common user language, typical pathways, and frequent pain points to inform future content and organisational decisions.

  • Share insights across your organisation: When stakeholders see direct quotes from users struggling with current organisation, it becomes much harder to argue for internal convenience over user needs.

Remember: user insights don't require expensive research tools or formal UX processes. They just require talking to real users about their real experiences with your content.

Data-driven architecture reviews and governance

Information architecture isn't a set-and-forget decision. As your organisation grows, as new research areas develop, and as user needs evolve, your content organisation needs periodic review and adjustment based on actual user behavior.

Schedule reviews on a regular cadence to assess:

  • What pages are people actually using? Your website analytics can show which pages get the most traffic and how users arrive on those pages. This is more reliable than any internal opinion about what's important.

  • What new content has been added and how does it serve actual user needs? Each new piece of content or initiative should be evaluated for how it fits into existing information architecture and whether users actually need it prominently placed.

  • What assumptions need testing with real users? Regularly validate that your organisation of content still matches how your audiences think about and seek information.

Good information architecture also requires ongoing governance - agreed-upon processes for how new content gets added, organised, and maintained over time with user needs as the primary consideration.

Establish clear guidelines for:

  • Who decides where new content goes and what criteria they use (hint: user needs should be the primary factor, not internal politics).

  • How often navigation and organisation gets reviewed to prevent gradual drift from user-centered design toward internal convenience.

  • What criteria determine content prominence (hint: user behavior data, not internal wishful thinking).

  • How to sunset outdated content that no longer serves user needs, even if someone internally thinks it's still important.

This might feel bureaucratic, but structure actually creates more freedom by ensuring that content decisions support user needs rather than internal politics or convenience.

Implementation: users first, always

When adding new content, ask yourself: Where would someone naturally expect to find this? What questions does this answer for real users, and what questions might it raise? How does this connect to other content that users actually need? What would someone need to know before and after reading this to accomplish their actual goals?

Use your CMS's organisational tools - parent/sibling relationships, menus, and internal linking - to create clear relationships between related content that serve real user journeys. Make sure page titles and headings accurately reflect what people will find on each page, using language that real users actually understand.

Remember that good information architecture is invisible when it works well. Users should be able to find what they need without thinking about navigation, or site structure. If they're thinking about your website's organisation, you've probably failed.

Check your understanding

Copy and paste this to ChatGPT when you're ready for feedback:

I've been completing some questions that have been presented to me as part of an SEO course. I'm currently answering questions for a section titled "Information architecture: the invisible foundation". Please check my answers and let me know if I've understood the key ideas correctly. My responses are below.

1. Which approach best balances organisational goals with user-centered information architecture?

  • Creating a prominent "Research Excellence" section on the homepage that showcases achievements, then providing clear pathways to participation information
  • Embedding evidence of expertise within user-focused sections like "Find a Study" while keeping organisational messaging secondary
  • Using the homepage primarily for organisational messaging but ensuring the main navigation clearly directs users to practical information
  • Alternating homepage features between organisational priorities and user needs based on current strategic initiatives

2. You're tasked with redesigning your organisation's website structure. Current analytics show that 60% of traffic goes to study participation pages, 25% to general information about your research areas, and 15% to administrative content like annual reports. However, leadership wants equal prominence for all content because "everything we do is important." How would you navigate this conflict between data-driven prioritisation and organisational politics, and what evidence would you use to support a user-centered approach?

3. Consider this scenario: Your user research reveals that families consistently use the term "join a study" while your organisation uses "research participation" throughout the website. Your communications team argues that "research participation" is more professional and accurate, while your legal team prefers it for compliance reasons. Analyse the competing priorities in this labeling decision and explain how you would balance user needs, organisational requirements, and professional standards.

4. A colleague suggests that watching users navigate your website is "too time-consuming" and that Google Analytics provides sufficient data about user behavior. Compare the value of observational user testing versus analytics data for information architecture decisions. In what situations might each approach be more valuable, and why is combining both methods more effective than relying on either alone?