Summary: Structuring information by department may seem like an easy solution, but the research shows that’s not how users expect to find things. In fact, in our own tests, we see that over 92% of users look to find information by Function before considering otherwise. Read more to see how we measure this.
In our design workshops, Information Architecture structuring takes a front seat in intranet design. In most cases, we dedicate 3 separate workshops to brainstorm and refine IA with business users. In almost every case, there is a difference in opinion between participants whether to structure the site by Function or Department.
During those brainstorming sessions, when we sort all the content, we usually see two predominant opinions.
Some say that navigation should be structured by Function, and others claim, by Department.
Here is what I mean by structuring content by Department:
Here is the example of the same structure by Function. The labels here such as [Business Services], [Employee Services] and for illustrative purposes and we tailor those to your organization’s Functional areas:
Structuring by Department
Everyone knows who’s content is who’s so it’s easier to assign permissions and find content
It’s traditional and simple, no brainer, HR stuff goes under HR, IT stuff goes under IT and so on
If we use functional or generic labels such as Business Services, users might find it confusing whether some content is business related or employee related
New employees may not know which content is authored by which department
Example: Would an Expense Form live under HR or Finance? What about “Submit Travel Request“ - HR or Finance? How about “Templates and Samples” - this doesn’t seem to have a department
Content ownership sometimes changes by department especially when departments are renamed, merged or some subtle responsibilities change
Example: Emergence of “Health & Safety” department, which didn’t exist before and some related “Health” content existed on HR site.
How to categorize content authored by multiple departments? For example: “Policies and Procedures” are commonly owned by HR, Legal, Finance, and perhaps even Communications teams? Should then each department have a separate location for policies? What if you need to search across?
The data says …
(and we tested it)
Despite opinions raised in workshops, the sample size in a typical workshop is too small to make an accurate judgement. Typical intranet workshop has 6-8 stakeholders and your typical intranet can have anywhere from few hundred to few thousand users.
The best solution is to verify your information architecture with a tree test.
How does it work?
We usually build a practical scenarios such as “Users would expect to navigate to IT department site to find latest systems outage information“.
Then we give users our navigation tree and ask them to “find the systems outage information“.
The test contains few more scenarios - we try to make it less than 10.
Since we’re using automated tools to run the test, we get interesting metrics, including:
What’s the first node in the tree users clicked on when asked for a particular scenario question
Going back to our example of IT systems outage, if they clicked on the Functional node, it gives us quantifiable result of the first thought of where this information should be
How direct was their navigation when asked for a particular scenario
This tell us how much of back and forth did they have to do before settling on an answer. Did they go down a correct path right away or did they have to back track few times
The more direct their navigation, the clearer are the labels which is good
What was nominated as a correct answer
… and was that answer correct
How long did it take for users to find the answer they consider correct
Longer times indicate lack of clarity
Many more …
*Business Services is a label we gave to our Functional structure, so the test gives us quantifiable answer that users mostly search for information by Function rather than Department.
Mixing the Structure
Based on the test above you can see that small percentage of users still choose alternative path for a scenario.
Depending on the quantity you get in your scenario, you may consider creating links from highly ranking alternate nodes to the actual source.
For example, if you notice that 15% of users click on IT Site to find the outage information, perhaps have a quick link or a widget which will quickly point users to the source or give them a snapshot of what they’re looking for.
If you chose to do so, ensure that you’re not duplicating the data and instead linking to the source.
It’s always best to have larger sample size when testing your Information Architecture tree. Definitely consider sending it to 10% of the company or more, if possible. Don’t limit the test only to people in the workshop since they’re biased.
In our testing, we test the IA structure, next day after brainstorming, and then collect and analyse results for next day to finalize the tree. As a result we get confirmed data in a mater of 2 days.
After you ran the first test, you might be tempted to make adjustments and re-test. This doesn’t work as well due to bias since your users have learnt something about the IA tree from the first time and the results would not be accurate.
There is also a factor of diminishing returns.
We recommend forming tests around specific scenarios and only testing those scenarios so that you get the answer as to using variant A or B.
Can SharePoint Online hub sites help with IA structure?
SharePoint Online has a concept of the Hub sites allowing all of the intranet sites to be flat and tie them together in what’s called a Hub Site.
The idea is that site structure is then fluid and can be changed at any time to meet particular requirements.
So does this help?
Simply put, no.
If you make structure changes too frequently on a live site, users will be more lost than if you haven’t figured out the structure correctly in a first place, and let users get used to it.
Imagine the scenario where during the first month expense forms are under HR and next month, they’re under Expenses, then under Rewards & Benefits and finally moving to Employee Services.
The change would be overwhelming for users and you’ll hear a lot of “I can’t find anything on here“.
Despite the simplicity of structuring the content by department, try to avoid this practice and structure by function. If in doubt or hear differences in opinions, run a tree test and let results guide you.
What are some of the challenges you have seen when structuring content o the intranet? Drop a comment below, we’d love to hear from you.
Yaroslav Pentsarskyy is the Director of Product at Origami. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.