Information Architecture

If Content is King, then How Do You Help it Rule Your Intranet?

Use  SharePointNA Registration Discount Code : YARO

Summary:
In January of 1996, Bill Gates published the essay titled “Content is King” on the Microsoft website. The article was written with internet in mind, but intranet is no exception to the principles shared. If your users are not able to find what they’re looking for, it might as well not even be there.

Luckily, with these 4 techniques to guide you, your intranet can be transformed to surpass your own expectations.


1. Perform Content Audit with Relevant Groups

Successful intranet is used daily.

Your employees have many options to get to what they’re looking for, and they will choose the easiest one. Unfortunately, without even realizing it, some of these options are can result in costly mistakes in the form of misinformation, errors, and reworks.

Help your users by making the most relevant and accurate content available all in one place.

The best place to start is to gather your key intranet stakeholders in one room and determine the most frequently accessed content in their groups.

Be sure to include the following stakeholders:

  • Communications (and Marketing)

    • Provide content about the company in general: news, events, corporate information, templates, etc.

  • Human Resources

    • Provide content for employees: benefits, careers, learning and development, social and engagement channels, etc.

  • Operations (Business Units)

    • Provide content related to business functions: safety, operations, business resources, polices and procedures, knowledge bases, etc.

Among other stakeholders be sure to also include:

  • Project Management/ Sponsors, to ensure buy-in on decisions.

  • Information Technology (IT), to ensure compliance and technical agreement and ownership of the solution.

This process can be completed in no more than 1 to 2 workshops with everyone in attendance and participating.

We gather content in a series of guided Content Audit exercises, where participants get to contribute their content ideas and gradually refine them into relevant buckets and categories, to determine which resources are the most valuable


2. Eliminate Content with No Owners

Less is more

A proverb coined in an 1855 Robert Browning poem, it has been used since then as a reminder that simple and clear designs are the most effective. This holds true for intranet design as well.

This isn’t just a proverb either, many human behavior studies indicate that readers prefer content that is simple, concise, and reliable. The easier it is to read the content the better.

No one has ever complained that something is too simple to understand, and when it comes to the content on the intranet it also means:

Remove any content that won’t have an owner at the time of launch

During your Content Audit workshop your stakeholders will come up with brilliant ideas that don’t fit anywhere. Don’t stress!

You don’t have to throw everything that doesn’t fit away. Some ideas can be kept on the drawing board and when the time comes, where someone agrees to own the area or content, those ideas can be revived and put on the intranet.


3. Group Content by Function

Transform your content into structure.

You’ve got the content and it’s relevant to your audience, now how do you transform it into an actual structure?

The key is to determine functional themes emerging from the content.

Here is a fraction of the unstructured content map from one Content Audit workshop.

unstructured content.JPG

Here are the guiding principles and questions to ask when determining your functional themes:

  • Who is the content for?

    • Is it for a specific team member or anyone in the company? This question will help you determine whether the content belongs on the outer loop for everyone to access or the inner loop for members of specific teams.

  • Why are they looking for the content? What’s their end goal

    • to get informed/ research?

    • to participate/ engage with work community?

    • to complete a specific business task?

  • Are they in ‘Business’ or ‘Employee’ frame of mind?

    • Is resource related to them as an employee or business related

Let’s use [Links to ADP] (a third-party benefits and payroll portal) from the above map as an example.

  • Who is the content for?

    • Anyone in the company. So, this belongs on the outer loop. Even though a specific team, such as payroll, may use it the most frequently, everyone is going to need access.

  • Why are they looking for content?

    • To complete a specific task, such as “I need to check my paystub”.

  • Are they in Business or Employee frame of mind?

    • This falls into both categories. For the average employee this resource is for personal use, but for payroll this resource is for business use.

The result would be a new functional content area:

[Employee Resources] with potential sub-area for [Benefits].

Next, the process is repeated for the rest of the content, resulting in structured content similar to this:

structured contemt.JPG


4. Structure Groups by Function

Successfully grouped content is half the battle. What’s left is organizing the content so that it resembles a tree, this layout can then be used to build your site navigation and metadata.

Consider

  • The user’s intranet journey

    • Users on their “employee” journey are in a different frame of mind than users trying to complete a business task. Ensure your structure reflects that with the appropriate labels.

  • Keep your top functional links to seven or less. Don’t forget, less is more!

    • Links beyond seven start to become repetitive and makes it harder for the user to start their journey.

      • In our behavioural tests, users began to make comments like: “I didn’t know where to start,” “I was bouncing between 3 options for each question asked,” or “options were very vague.”

  • Don’t duplicate content.

    • In our behavioural test, sometimes we see users expecting to access the same content from 2 places. In this case, we create a link in less prominent area (according to behavioral results) and keep the original content in more prominent area.


We’re here to help

Intranets built with the above Content Audit approach report higher adoption and employee satisfaction.
In our behavioral analytics, we see comparative results indicating how much faster users are at finding information and how much less navigation they require to access it.

We’d be happy to help you get started with an objective consultation.

Pre-built Office 365 intranet tailored to your organization.

 
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

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