Information Architecture

How to Structure Intranet Content: by Department or by Function

Use  SharePointNA Registration Discount Code : YARO

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.

The Issue

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:

In here, we see structure by department. Users are expected to navigate to a specific department and look for the relevant content there.

In here, we see structure by department. Users are expected to navigate to a specific department and look for the relevant content there.

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:

Above, the content is structured by the Function, so that users can navigate to the area of their interest and find relevant information there without needing to know which team is responsible for the content

Above, the content is structured by the Function, so that users can navigate to the area of their interest and find relevant information there without needing to know which team is responsible for the content

Structuring by Department

Proponents say:

  • 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

Issues:

  • 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 …

We also get this distribution graph below showing the path users navigated. This is a screenshot but we follow paths and see exactly how many users clicked on what and have they come to the right place right away or after some clicking.

information architecture test.png


This diagram above, shows that users equally tried Department Site (IT) and Business Services as their destinations but over 92% have clicked Business Services* as their first step/link in this particular test.

*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.

Sample Size

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.

Re-Testing

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“.

Conclusion

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.

Pre-built SharePoint intranet, tailored to your organization, in 3-6 weeks.

 
ypentsarskyy_2016_small.jpg

Yaroslav Pentsarskyy is the founder of OrigamiConnect, a rapidly growing service and product offering which enables organizations to get an intranet designed for them without starting from a blank page. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.

@spentsarsky

Moving from Fileshare to SharePoint? Key Strategies to Building Reliable Metadata

Summary: Moving away from Fileshare to SharePoint is one of the most painful exercises most organizations describe. With the structured approach, you can simplify this process to just few workshops and end up with rock solid, and easy to find structure. Avoid using existing folder names as your new SharePoint structure and simplify existing containers first before defining metadata.

Although we’re builders of intranet-in-a-box, we often consult on the SharePoint migration projects. One of the most common challenges in any organization using fileshare, is migrating this old structure to SharePoint. Even with a wealth of tools available in SharePoint around content findability, such as metadata and tags, you need input is required from your teams.
So, how do we go about it in just few simple workshops?

Pre-Work

First, you’ll need to bring the right people to the table.
Here are few guiding principles:

  • Understand which teams own content in your existing fileshare

  • Ideal group size is 4-6 stakeholders

    • Ensure people in the room are content owners, and members who can assign tasks and allocate resources for their team. This doesn’t have to be the same person, hence we recommend 4-6 people per team.

    • Ensure everyone in the room is likely to contribute for their area and not just listen in.

Content Audit

You have picked the right people, now onto the content audit.

First, why do we need content audit? Don’t we already know what content is in our fileshare?

Our experience shows the following:

  • Not everyone on the team knows everything about their existing fileshare structure

  • Much of the structure is obsolete, ad-hoc, with lots of catch-all folders

  • Every workshops we ran, had people discover something new about the content based on their peer’s input

Running the workshop (in person)

  • Request for participants to individually write down types of content their own and work with.

    • Give examples, such as: project status report, project plan, risks and issues etc. This will help ideas flowing

  • Ensure participants work individually.

  • Request each participant to share their individual types of content and let others ask questions

    • Keep other participants interaction only for clarifications, not brainstorming, countering, or questioning workflow or business flow. There will be separate activity to cover that :)

Remote participation

More often than not we work with hybrid teams where some participants are at the office and others are remote. There are facilitation techniques we use to accommodate this, which is a whole different topic, and with the right mix of technology and facilitation participants as as productive as in on-site meeting. The key to remote session is preparation and make sure everyone can contribute without feeling left out.

The Result

As a result you will end up with a sample structure like below. And by the way, with all the pre-work to get to this point will only take about 45 min with an experienced facilitator.

PMO Site Content.PNG

Defining New Content Structure

Now that we have all the content on the table and everyone has the context of what everything is, it’s time to shape this into a tree.

The task is to: group relevant content into logical groups or clusters and assign labels to each cluster. For example: [Contract Template], [Agreement Template], and [SOW Template] can be collectively put into category called [Templates].

Towards the end of this exercise you will end up with something like this, notice how various content types cluster around themes forming what we call SharePoint Content Type:

PMO Site Structure.PNG

At this point we spent only about an hour and 1/2 and already have a good idea how the new repository will look like. Next, we finalize the structure.

Selecting Metadata and Tags

With the metadata you can group content by any number of tags, virtually creating “folders” on the fly. With the folder, you get to navigate the structure in a fixed format.

Regardless of method you chose to structure your content, folder or metadata, using the output from the previous exercise, it’s easy to build the final structure.

Here are some guiding principles when tagging your content:

  • Use auto-tagging feature in SharePoint to tag content automatically when it’s dropped into a specific library or folder (if you chose to go with folders).

  • Avoid creating hierarchies deeper than 3 levels. For example: [Project Alpha] -> [Deliverables] -> [Fact Sheet] is a good example of 3 level hierarchy.

  • Avoid manual versioning and creating folders to manage those. For example, avoid: Contract_v3_final, instead rely on built in versioning features to version your content.

    • This may sound like nothing to do with the metadata but we often see people create folders for Draft/Final documents which affects content structure

  • Don’t confuse Metadata with a Document Type. This might sounds obvious but people make this mistake all the time. Consider this scenario:

    • Should [Balance Sheet] be a content type or the [Year]?

    • The correct way is [Balance Sheet] as a Content Type since and [Year] is a Metadata field.

      • NOTE: Content Types reflect entities around which rules are formed (archival, retention etc). Metadata, in this case [Year], is merely a descriptor/property of the entity.

    • As obvious as it is, many fileshare structures out there have the exact opposite in how folders are structured.

Metadata versus Content Type.PNG

Conclusion

When we follow this collaborative approach with the client we see huge increase in adoption and decrease in support. The tempting alternative of bringing structure from fileshare will bring old problems to the new environment. We have used this approach on number of projects over the years and refined it meticulously for the best results, so if you have questions about details - drop us a note!

What are some of the challenges you found when migrating from fileshare to SharePoint? Leave your comment below.

Tailored, pre-built, flexible SharePoint intranet.

 
ypentsarskyy_2016_small.jpg

Yaroslav Pentsarskyy is the founder of OrigamiConnect, a rapidly growing service and product offering which enables organizations to get an intranet designed for them without starting from a blank page. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.

@spentsarsky