We talk a lot about building intranets that actually work for people — tools that help them do their jobs, not hold them back. But getting to that point isn’t just about shiny design or ticking off a features checklist. It starts much earlier, often in the weeds of structure, language, and logic. And that’s where tree testing comes in.
Recently, we began working with King’s College London as part of their ongoing journey to rebuild and modernise their intranet. One of the first steps in that process was conducting a tree test — and it was a vital one. Here’s how Dr Christine Shukis-Brown, Deputy Director, Communications & External Affairs at King’s College London, put it:
“Tree testing helped us move beyond assumptions and start building an evidence-based picture of how employees expect to find things. It gave us insight into the strengths and weaknesses of our current structure and language — something we might otherwise have not seen clearly.”
This kind of work — digging into real behaviour, making space for evidence, and setting a solid foundation — is what we love most. It’s the messy middle of an intranet project, where you get your hands dirty, test what’s really going on, and start turning guesswork into insight.
Here’s a look at what’s involved, and five key lessons we’ve learned from our tree testing experiences with King’s and other clients.
What Is Tree Testing?
Tree testing is a usability technique we use to evaluate how easily employees can find information within a site’s structure — without the help of design, search, or visual cues.
Participants are given tasks and asked where they would go in a stripped-back menu tree to complete them.
It helps us understand whether the labels make sense, whether the hierarchy is intuitive, and where people get stuck. It’s a way of isolating the information architecture — the “bones” of the intranet — to see if it can stand on its own.
Why Do We Do Tree Testing?
It’s easy to assume that if an intranet is “broken,” there’s no point testing it — just tear it down and start again. But that’s exactly when tree testing becomes most valuable.
It gives you evidence, not assumptions, about where things go wrong. That makes it far easier to build a business case, prioritise improvements, and gain stakeholder support.
It also gives us insight into how employees think. Where do they expect to find things? What terms make sense to them? And, crucially, it gives us a benchmark — a “before” snapshot — so we can measure progress when the new structure is in place.
Another important benefit is the opportunity to actively engage employees in the process. Tree testing — especially when paired with pre- and post-study questions — creates space for people to share specific examples and experiences. This helps us capture not just the what and where, but also the why. That context humanises the data and makes it relatable.
It also makes employees feel heard and part of the journey, rather than just passive recipients of a finished product. When people feel included in shaping the change, they’re far more likely to feel invested in it. That sense of ownership can make a real difference to adoption and engagement when the new intranet goes live — because employees don’t just see the change, they can see themselves in it.
Design Better SharePoint Intranets
Our SharePoint Design Guide for Internal Communicators walks you through how to create stand-out SharePoint sites – including our learnings from activities like tree testing.
5 Things We’ve Learned from Tree Testing
Tree testing has been part of our approach with several clients, and while every organisation is different, the themes are surprisingly consistent. Here are five things we’ve learned that we think every intranet team should know.
1. Language Is Just as Important as Structure
We often think the main challenge is “where” things sit in the navigation — but just as often, it’s what they’re called.
If your employees don’t recognise the words in your menus, they won’t know where to click. Ambiguous or internal-facing labels (like “Shared Services” or “Operations”) can lead to confusion, hesitation, or wrong turns.
One of the quickest wins from tree testing is identifying labels that need to be simplified, clarified, or changed altogether. A small tweak in language can lead to a big improvement in findability.
2. Memory ≠ Usability
We see this a lot: long-serving employees “know” where things are — but not because the structure is intuitive. It’s because they’ve memorised the quirks over time, bookmarked what they need, or asked a colleague.
This might work for them, but it’s a red flag for everyone else — especially new starters or infrequent users. Good IA shouldn’t require insider knowledge. Tree testing helps us see where people expect to find things, not just where they’ve learned to look.
3. Deep and Complex Structures Slow People Down
If employees have to click through four or five layers just to submit an expense claim or report a broken light, something’s gone wrong.
Tree testing helps us visualise that depth and see where it’s tripping people up. Employees are far more successful when information is accessible within a few clear steps.
Flattening menus, grouping content by common tasks, and reducing duplication can make a huge difference in how efficiently people can navigate the intranet.
4. Search Isn’t a Safety Net
In many intranets, search is seen as a fallback — if employees can’t find it through navigation, they’ll just search for it.
But tree testing removes search from the equation, and that’s when we see just how much people rely on it — sometimes out of frustration. And when search isn’t reliable (which, let’s face it, is often), it compounds the problem.
You can’t fix everything with search. A good structure is the foundation. Search should complement it, not compensate for it.
5. Consistency and Cohesion Are Non-Negotiable
Fragmentation is a common issue — with content scattered across intranet pages, SharePoint sites, and external links. Add in inconsistent styling and duplicate headings, and employees are left wondering if they’re even in the right place.
Tree testing helps surface this lack of cohesion. It gives us clues about where employees feel lost or unsure, so we can design structures that feel unified, consistent, and logical.
What Comes Next?
Tree testing isn’t glamorous. There’s no flashy UI or instant gratification. But it’s one of the most useful, grounding steps we take in our intranet projects — and one of the most collaborative too.
It helps clients see their content through the eyes of their employees. It challenges assumptions. It gets people talking about structure and language in a way that’s real and actionable.
If you’re planning a redesign, or even just feeling like your intranet isn’t working the way it should, I’d encourage you to start here. Ask the questions. Run the tests. Let your employees show you where things break down — and where they make perfect sense.
Because better experiences don’t start with design. They start with understanding.
Make Sure Everyone Can Navigate Your Intranet Easily
Tree testing reveals where users get stuck — our accessibility checklist helps you fix barriers for all employees. Download it to create a more inclusive intranet.
Build an Intranet Your Team Will Actually Use
No guesswork here — our Art of the Possible session shows how SharePoint, Viva, and M365 can create a smoother, smarter digital workplace designed around your people.
Additional FAQs
What exactly is tree testing, and why should we use it for our intranet?
Tree testing is a method where you present users with a text-only version of your navigation menu (just the category labels and hierarchy) and ask them to complete find-it tasks. You track where they click, whether they pause or backtrack, and how successfully they reach the target. It’s particularly useful in the intranet context because it helps you validate whether both your structure and wording make sense to people—not just those who are familiar with internal jargon
At Silicon Reef, we use tree testing early in the project to identify confusing labels or depth-related bottlenecks before design visuals are built, saving time and improving findability from the ground up.
How many layers deep should our intranet navigation go?
A good rule of thumb is to keep navigation shallow—ideally no more than three levels deep. When intranet menus stretch four to five levels, user success drops, and navigation becomes slow and frustrating. Tree testing makes this painfully clear by showing where people get lost or pause.
Silicon Reef often finds that flattening navigation—grouping items by task and reducing hierarchy depth—boosts findability and speeds up tasks. That said, every organisation is different. We recommend running a quick tree test iteration, fixing depth-related issues, and then retesting to hit the sweet spot between clarity and comprehensiveness.
Can tree testing replace card sorting—or do we need both?
Tree testing doesn’t replace card sorting—they serve different purposes. Card sorting helps you discover how users mentally group content (a generative method), while tree testing evaluates whether your proposed structure actually supports findability (a validation method).
Many of our clients benefit most from running card sorting first to explore content grouping, then refining and validating the hierarchy via tree testing. At Silicon Reef, using both tools in sequence helps us confidently design intranets that feel intuitive and work reliably—rather than relying on guesses or assumptions.
How often should we re-run tree testing once our intranet is live?
It’s wise to treat tree testing as an ongoing health check rather than a one-off activity. Information architecture can go stale as content evolves or employee language shifts, so rerunning quick benchmark tree tests every few months helps catch emerging confusion early.
At Silicon Reef, we recommend scheduling light tree-test sweeps quarterly or during major content updates—this lets you spot labeling drift, navigation bloat, or broken findability before they become real pain points. Plus, small regular improvements often have a much stronger cumulative effect than rare big overhauls.
What outcomes can we expect after running tree testing on our intranet?
Tree testing yields rich, actionable data: you get quantitative metrics like success rates, time-to-find, and backtracking patterns—and qualitative insights into where employees get confused. This helps isolate poorly performing labels, overly deep structures, or scattered content. In practice, that means you can reorganise navigation, simplify wording, or merge redundant areas before employees even experience the problem.
Silicon Reef often sees substantial lift in task success rates after just one round. Plus, by involving employees in the process (via pre- and post-test questions), we gather context around “why” users struggle. That makes the results not just data-driven, but deeply human-centred—and helps our clients build intranets people actually use.
