Tag

Information architecture

Browsing

Introduction

Information Architecture (IA) is the structural design of shared information environment (source: Wikipedia).

In this series on Information Architecture, we discussed how a bad IA can affect your SharePoint success.

If your SharePoint users can't find the information they need quickly, they'll get frustrated.

In our first article, we explained why trying to create an IA that has only one dimension leads to creating the lowest common denominator IA instead of giving your users the best-of-breed experience they deserve.

Our second article explained how you should build an IA on 3 dimensions. We described how the physical IA should cater to authors. If you don't create an IA that allows your authors to place content in the right place, you'll end up with messy, unstructured data. Yes, it is data, not information, because it loses all meaning.

In the last article, we looked at the logical IA. While the physical IA caters to your authors, the logical IA should cater to your readers.

But there is one more dimension to consider: the metadata dimension.

The metadata dimension

The metadata dimension of IA helps the system deliver information for specific purposes.

For example, imagine that the HR department has a document library for their HR policies. Before employees can see the latest version of a policy document, they must be approved.

Marie the HR Manager is responsible for approving HR policy documents.

When she launches SharePoint, her HR site tells her how many documents are waiting for her approval.

If Mary clicks on a document waiting for her approval, it takes her directly to the document. From there, she can approve or reject the updated policy document.

SharePoint does not keep documents waiting for Mary's approval in a separate physical location. Yet, from Mary's perspective, SharePoint appears to bring all documents waiting for her approval in one convenient place for her.

In other words, the physical location of her documents doesn't change. SharePoint uses the metadata to identify which documents need Mary's approval. SharePoint then presents the documents in a separate logical location.

That's what creating the metadata IA is all about: making sure that your documents have the metadata they need to support specific goals.

You might say "Ok, I get it, so we just use the goals we identified when we [designed to logical IA]( (https://tahoeninjas.blog/2019/02/22/information-architecture-in-sharepoint-the-logical-dimension/) and create the metadata we need to support it?"

Well, yes ...and no.

(Remember, I'm a consultant. The answer is always "It depends")

Progressive Disclosure

In user experience (UX) design, there is a design pattern called Progressive Disclosure. It is a strategy for managing information complexity by gradually (or progressively) revealing more information as users indicate they wish to see more.

In other words, show only the information that is necessary at every point of interaction.

By reducing the amount of unnecessary information you show to users down to the essential, you make it easier for users to make sense of that information.

You see this all the time when using SharePoint. For example, the More button in the document library toolbar is a form of progressive disclosure. We don't need to show every single option in the toolbar. We only need to show the most common options. If users tell us they want to see more choices, we reveal more options.
Progressive Disclosure Example with the More menu

The News web part in SharePoint works the same way. When you go to a team site or communication site, you see the latest news. If users want to see more news, they can use the See all link, in the upper right corner.
SharePoint News

Summary, List, Details

When designing your metadata IA, you should consider creating the metadata structure required to build progressive disclosure in your design.

An easy way to do this is to present the information in 3 distinct views:

  • Summary
  • List
  • Details

We'll describe each view below.

Summary

As you evaluate every actor goal, ask yourself:

What is the least amount of information that this actor will need to meet their goal.

Another way to ask this question is:

How do I summarize the information this actor needs to meet their goal quickly

In our example, Mary the HR Manager needs to know quickly when documents need her approval.

We don't need to show her every single document. We just need the documents that have not been approved yet.

Keeping this in mind, we don't even need to show the Size, or Date Created. We probably only need the document's Title, Date Modified, and Modified By.

When building a summary view, consider providing the user information that will help them prioritize their tasks. For example, we can show Mary the list of documents that have been waiting for her approval the longest. Or, we can show the list of documents by how recently they were submitted for approval.

Every summary view should allow users to do at least two things:

  • Get the full information about an item in the summary (a.k.a. the Details view)
  • Get the full list of items (a.k.a. the List view)

Both are discussed further below.

How do I sort my summary view?

Almost every client engagement I work on, there is at least one business stakeholder who insists that their summary view of [whatever] must be sorted alphabetically -- from A to Z.

Their argument is usually "people need to be able to find [whatever] quickly. Sorting by alphabet is the fastest way to let them find it".

It may be a good approach for a list view of [whatever], but the summary view should boil it down to what matters now.

Instead, consider showing the list of latest [whatever]. Sorted in reverse descending date (i.e.: newest first). Doing so will allow repeat visitors to see the newest [whatever]. If they scan down the list, they may eventually see an item that they've seen before and assume that they have seen everything below that item.

Consider the alternative: users have to scan through the entire list of [whatever] to see if there is anything new.

How many items in my summary view?

There are no set rules for the number of items to show in a summary view. Luckily, there are brilliant people who have done some research on this.

The first rule is known as Miller's Law. In summary:

The average person can only keep 7 (plus or minus 2) items in their working memory.

Miller's Law is often misinterpreted. It doesn't mean that you should only present 7 (+/- 2) items only. If you need to present more, consider chunking the information into groups of 7 (+/- 2) items.

The second rule is Hick's Law. Hick's law says:

The time it takes to make a decision increases with the number and complexity of choices.

In other words: the more choices you give people, the longer it takes for them to make a decision.

So, when I build a summary view, I try to limit it to 7 +/- 2 items.

Sometimes I show 5, sometimes I show 7, and rarely I'll show 9 items. If I need more than 9 items, I'll always try to group the items into subsets of 5-9 items.

The more information I need to present with each item, the fewer items I'll show in my summary view.

Doing so will ensure that every user can make sense of the entire list and that they will make a decision quickly.

List

The list view allows users to view all items, possibly without filters or restrictions.

But don't think that you can just create a All items or All documents view and be done with your list view.

Keeping your user's goals in mind, you should design one or more list views to help your users accomplish their goals quickly without having to scan through the entire list of items.

For example, I'll often create views like:

  • Latest [whatever]
  • My [whatever]
  • [Whatever] waiting for my approval
  • [Whatever] by approval status
  • [Whatever] about to expire

...and the list goes on.

As with the summary view, you need to consider what metadata you'll need to support each list view.

Every item in the list should provide users with a link to the Details view for that item.

Details

The details view should provide all the information needed on an item so that users can achieve their goals.

Most often, the details view for a document is really the document itself -- because, most often, the user's goal is to read the document.

Sometimes, you need a different details view. For example, let's say we want to allow executives to do a second-level approval for expenses that approved by managers who report to them.

Instead of showing the full document, we'd need to show the expense summary, amount, manager's approval, and approval date. The view would probably make it easy to approve the expense without having to open it.

Keeping in mind progressive disclosure, and providing users with Summary, List, and Details views of information will help your users make decisions quickly and accomplish their goals.

Implicit metadata

If you're planning an IA to migrate a network file share to SharePoint, heed this warning:

Don't simply relocate document. The location of a document in a file share is a form of metadata that you may lose if you relocate documents.

That's implicit metadata.

Let's say that your file share contains legal cases for case management purposes. You have a folder for every case your company has ever processed.

Because of the large number of cases your company processes every year, there is a folder for every year in your file share. Cases are then placed in their respective folders, according to when you received the case.

Your company gives each case a unique number, e.g.: CA123456. To ensure privacy, case numbers do not convey any information about who the case parties are.

To make things even easier for your users to work through open cases only, your network file share groups every year folder into an Open cases, Closed cases, and Pending approval.

The folder structure looks as follows:

  • Cases
    • Open case
      • 2017
        • CA123456
          • CA123459
          • CA123464
        • ...
      • 2018
        • CA133456
          • CA123559
          • CA121464
          • ...
      • 2019
        • CA233456
          • CA323359
          • CA124464
          • ...
    • Closed cases
      • 2017
        • ...
      • 2018
        • ...
      • 2019
        • ...
    • Pending approval
      • 2019
        • ...

Because the documents you want to migrate are in a network file share, there may not be a lot of metadata -- if any -- for your documents.

But if you look carefully, the location of each document provides implicit metadata about each document: the status of the case, the year the case was received, and the case the document belongs to.

If you migrate your file share to SharePoint, you need to consider a way to apply the implicit metadata to each document.

You might say: "If I keep the same folder structure, I won't lose the implicit metadata". Sure, but what happens when users are looking for a document and use search? The only way they will be able to see that implicit metadata about every document in their search results is if they look at the document location for every. single. document.

Conclusion

As I have hopefully conveyed in today's post, you need to consider your metadata IA structure to support your users' goals.

The metadata dimension also needs to support both the physical and logical IA.

In my next post, I will explain how to put all this theory together using SharePoint's capabilities.

For More Information

Introduction

"One size fits all" doesn't work for Information Architecture.

Especially not in SharePoint.

In a previous post, I discussed a lot of bad SharePoint implementations are due to bad Information Architecture.

As a general rule, if your users complain that they can't find the information they need, it is most likely because your Information Architecture (IA) needs tweaking.

Your IA may have been great when it was first implemented. But things change.

Your customers' needs change, and your business needs to change to adapt -- if you want to stay in business.

When your business changes, your IA should change as well.

In this article, I'll discuss how to avoid the "One size fits all" approach for IA, and how it should constantly evolve.

IA does not equal the Org Chart

The first instinct when building an IA is to mimic your company's Org Chart.

That would be good... if your company suddenly became sentient and started browsing your SharePoint site. If Contoso Inc became a living thing, it would feel right at home navigating an IA that looks like its Org Chart.

But you don't build IAs for companies.

You build them for people.

Your SharePoint users are those who will need to find information. They're the ones that need to be able to get to the stuff they need to do their jobs.

So, here is my bold statement:

Information Architectures need to be User-centric, not Organization-centric.

Now many of you are probably saying: "Do you expect us to build different navigation for every single person in my company?"

Ideally, yes! But it isn't as simple as that.

And how do you fit different navigations for every user in your IA? Won't it get too complicated to make sense?

Limitations of file structures

In the olden days, when people tried to build IAs for network file shares, there was only one dimension to work with. The folder structure.

With folders, if you want to create a folder structure that caters to different types of people, you don't have a lot of flexibility.

Let's take an example: employee benefits.

Most organizations offer various types of employee benefits. Here are some examples:

  • Health care
  • Retirement
  • Workplace flexibility
  • Wellness program
  • Tuition reimbursement

The Human Resources department handles some of the benefits above. Finance department handles some others.

When creating the folder structure, you want to give a place for our HR folks to share benefits information. Things like brochures, forms, standard operating procedures (SOPs), etc.

But you don't want people from the Finance dept to mess with HR's files. And you don't want HR people to mess with Finance's files.

So you create another folder for the Finance department to share information about the benefits they take care of. Another folder with brochures, forms, SOPs, etc.

But how do employees find information about benefits if all you have is a file folder structure? They need to know that there are files in both the HR and Finance department benefits folders.

That's the problem with using a file folder structure. If you don't want to duplicate documents, you need to put them in one place.

So you end up creating the lowest common denominator structure that will cater to most people.

But what if you could use more that one Information Architecture?

To be continued

As it turns out, your SharePoint Information Architecture has 3 different dimensions! That's 3 different types of Information Architecture at your disposal.

In our next article, we'll discuss the 3 dimensions of Information Architecture in SharePoint.

Introduction

2 words.

That's all people see when they scan links and headlines on your pages.

11 characters, on average.

That's all you get to attract people's attention on your SharePoint site.

That's what a Nielsen Norman Group study found when they studied how users read online content.

Why should you care?

Let's take the SharePoint news list for Contoso:

What you think they see

I'm sure you'll agree that every news article on the list above is important. Right?

Now, if people really see the first 11 characters of a headline, let's show what they actually see when they scan the news articles:

What they see

Hmmm, doesn't make much sense, does it?

The average length of Fortune 1000 company names is 14 characters long. Even if you don't work for a Fortune 1000, chances are your company name takes valuable space in headlines.

That's attention-grabbing space you could use to get your employees to pay attention to.

In this article, we'll discuss how to create news that will make your employees pay attention to.

Don't read further!

My mentor at McKinsey & Co once gave me the definition of communicate:

To communicate is to convey a message that results in a change in behaviour.

If you don't get the desired change in behaviour, you're making noise. You're not communicating.

This article assumes that you want to write news and headlines because you want a change in behaviour:

  • Start doing something they haven't been doing.
  • Stop doing something they have been doing.
  • Change their perception of things.
  • Raise their awareness.

If you don't care about changing behaviours, you don't need to read this article. You can post a comment to say how great this article was and I won't tell anyone.

Otherwise, read on!

Readers don't give a F

In another study, Neilsen Norman Group found that when people read online content, they read in a F-pattern.

That is: when reading online, people take some time to read the first few items in a list. As they continue to read through the list, they read less and less.

Eyetracking
Eye-tracking study, source: Nielsen Norman Group

Eventually, they scan through the left side of the list.

That's when they only see the first few words of a list item. They'll see a little more if you use shorter words, and less if you use long words.

They don't actually count 11 characters and stop reading.

Also, the F-shaped pattern is not the only reading pattern. There are others.

One thing is clear: people scan content when they read.

The importance of microcontent

Microcontent is a type of content that consists of short text fragments. You find microcontent in page titles, headlines, email subjects, etc.

In SharePoint, the News web part is a bunch of microcontent.

Microcontent is often shown out of context. For example, the aggregated news in your SharePoint start page, or in search results.

Microcontent helps readers when they scan. It lets them decide what they should click on.

Microcontent also helps readers search and save. They may find your news through search results and open each result in a new tab. Or they may add the links to their favourites. When they come back to your links, you need to provide them with context.

Whatever they do, you need to write your content so that it makes sense for users.

Elements of a news article

Every news article in your SharePoint site should consist of two microcontent elements:

Headline (or Hede)

The short text that grabs the user's attention. SharePoint uses the title of your news article as the headline.

When you write headlines, you should consider the following tips:

  • Use plain language: resist the temptation to be fancy. Even highly-educated users want succinct information that is easy to scan.
  • Remove non-essential words: to improve scanning.
  • Keywords at the front: to catch people's attention.
  • Follow a convention: write headlines in a consistent manner. It will help your users guess the rest of the sentence. Even if they only read the first 11 characters.
  • Use numerals: if you have to use numbers in your headline, don't write out the number. Write 2 instead of Two. It takes less valuable attention-grabbing space.
  • Don't be clever: be meaningful.

Consider skipping these words:

  • The
  • A
  • To

Even better, skip these words too:

  • Announcing
  • Introducing
  • Exclusive
  • Special
  • And any other made-up jargon that tempts you

Lead (or Lede)

The one or two paragraphs below the headline.

If the headline's job is to attract attention, the lead's job is to convince the user to click on the article.

They should be:

  • Useful: Be specific and provide facts to get your users interested.
  • Urgent: Provide a sense of urgency to push your users to read the article. Now company policy? Give them the deadline to adopt it.
  • Unique: fight information overload. Make it easy for your readers to know if they have already read this article.
  • Ultra-specific: use real numbers, real names and real ideas.

Most important: resist the temptation not to write a lead. Tell users what's in it for them.

Links are promises

Remember that links are promises. Every time a user clicks on a link, they expect that whatever page they go to will match what they clicked on.

Every time you break a promise by taking a user somewhere different than what they clicked. When you do, you chip away at their trust.

If you want people to use SharePoint, it needs to become a trusted and authoritative source of information. Every time you break users' trust, you lose credibility. People will stop going to SharePoint to find information.

You should allow your users to confidently predict what they'll get if they click. Do not be misleading or promise too much.

Don't click here

Whatever you do, don't use "Click here" in your headline or lead. That's soooo 1995!

Other than being uncool, here are reasons why you shouldn't use "Click here":

  • It isn't informative: when people scan your content, hyperlinks tend to grab attention. If your hyperlink doesn't say anything useful, chances are that users won't spend the time to find out if the link is worth their ti,e.
  • Not action-oriented: remember how we said that to communicate is to [get] a change in behavior? This is your opportunity to tell people what you expect them to do.
  • Insulting: people know what links are. They know what to expect. If you tell them to "Click here", you tell your users that you don't trust their intelligence.
  • Accessibility: Users who are visually-impaired often rely on screen readers. When navigating a web page using a screen reader, it will often read out the hyperlinks. You end up with a screen reader that says "Click here, click here, click here...".
  • Crappy search results: Remember that people scan search results as well. If all your headlines contain "Click here", you're making it more difficult to find results.

How to create a SharePoint news item with a headline and a lead

Enough theory. Let's create a news article!

  1. From your SharePoint site, select New followed by News post
    New | News Post
    (optionally, you can select Add from the News web part, then News post)
    Add | News post
  2. From the New Page page, enter the headline where it says Name your news post.
    New your news post
  3. From the toolbar at the top, select Page details
    Page details
  4. In the Page details pane that opens, enter your lead in the Description field. Do. Not. Skip. This.
  5. Write your content.
  6. When done, select Post news (or Save as draft if you aren't quite ready to publish).
    Post news

Enjoy your new news article!

How to create a link to a news article

Sometimes you just need to link people to news that are hosted somewhere else. You don't need an article, you just need a link.

Here's how to do this:

  1. From your SharePoint site, select New followed by News link (or Add|News link from the News web part)
    New | News link
  2. In the News link pane, enter the URL in the Link field. Make sure to include the https:// (or http://) prefix.
    News link pane
  3. SharePoint will attempt to verify the link and retrieve the news link's headline and lead. Make sure to update the Title and Description field with your headline and lead
    News link details
  4. Select Post.

Conclusion

SharePoint News is an awesome new feature of SharePoint modern sites.

If you want your employees to read your news, make sure your headlines attract attention.

In this article, I focused on headlines and leads. I did not discuss other aspects of the news. That's for another article.

I hope this article will help create news that will improve your SharePoint experience!

For more information

Introduction

When I tell people that I do most of my work with SharePoint and Dynamics 365, I'll often hear something like:

Oh, we have the SharePoint at work. It sucks!

To which I usually respond something like:

Oh, I just remembered! You're boring, and I'm leaving!

(...and then blame my autism for being so blunt).

Other times, I take the time to explain that SharePoint is actually a great product. They have seen a bad implementation of it.

But how bad can an implementation of SharePoint be? How hard is it to install SharePoint? And if you use SharePoint in Office 365, what's your excuse?

The answer is that the installation of SharePoint is not wrong. It is the content inside of SharePoint that lacks proper structure.

For example, let's look at Excel: when you launch Excel, you get a blank worksheet with empty columns and rows.

You don't blame Excel. You don't say "Excel sucks!".

You start putting your data in, write some formulas, and format some cells. Then you get value out of Excel.

The key is to put your data in Excel in a way that makes sense. Putting all data about an item is on the same row. Arranging the data into columns, so that you can sort, group, and filter the data in a way that you can make sense of it.

If you feel fancy, you can even format the data into tables, highlight cells, or create charts.

That's how you get value out of using Excel; By giving it some structure.

SharePoint works the same way: it starts with a (mostly) blank canvas, and you get to add your content.

But if you don't take the time to structure your content, you end up with a mess.

If you allow other people to create content without proper governance, you get a bigger mess. People can't find content, and whatever they find is often old, wrong, or duplicated.

That's what Information Architecture (IA) is all about. IA is designing a structure for your information so that users can use your site and find the content they need.

This is the first in a series of articles discussing various aspects of IA within SharePoint.

By the end of this series, I hope to prove that SharePoint doesn't suck -- maybe your IA does?

Data, Information, Knowledge

People often confuse the terms data, information, and knowledge and use them interchangeably.

Data, Information, Knowledge

Information and library scientists say that we should not confuse data, information, knowledge. They are very different. This is something called the DIKW Pyramid.

To build a better IA, you need to understand the difference between those terms.

Data

  • Data are the facts of the world.
  • Data has no meaning, it is a description of things.
  • We perceive data with our senses

For example, if you kept track of every time I refuelled my car and how much it cost, that's all you have. But that in itself has no meaning.

Information

When you take data and put it in context, it starts having meaning.

For example, if you look at the data you collected earlier in the context of time and dates, you may notice a pattern. You may notice that I refuel my car every Mondays and Fridays. That means that I probably commute for my work (because I empty a full tank in 5 days) and that I travel on the weekend (because I use the same amount of fuel within two days)... or maybe that I should buy a new car because that's a lot of refuelling!.

See what happened here? We took data that had no meaning in itself, added some context (time and date) and got information.

In order words:
Data + Context = Information

Knowledge

Knowledge consists of what we know. We start with information, then add our own experience, beliefs, rules of thumbs. It becomes our knowledge.

In other words:
Information + Experience = Knowledge

If I take everything I know and write it down, it becomes information again. Someone else has to use their own experience to make it their knowledge.

Unfortunately, we can't store knowledge in computers (yet).

Sample scenario

If you dump stuff in a SharePoint site, without structure. you create data.

I know, I know, I said that documents are information. If people can't make sense of the content in your site, it becomes data because it has no meaning.

If you want your content to have meaning, you need to put it in context.

For example, let's imagine the following scenario:

  • You keep a list of customers in SharePoint somewhere
  • You have a document library containing customer contracts, proposals, and specs.
  • You have a list of customer-related projects, with status reports, deliverables, etc.
  • You have an RSS feed web part somewhere that has industry news, customer news, etc.
  • There are account managers in your organization who each own one or more customers.
  • You have a list of which account manager has what customer
  • You have a list of experts and their industry expertise
  • Your customers work across many industries

You experience the following problems:

  • Your site users complain that they can't find the documents they need.
  • Account managers send the wrong versions of proposals
  • You find many copies of the same document, with file names containing _finalversion, _final_final, and _thisisreallythefinalversioniswear
  • Users don't know about the RSS feed web part, or they don't use it.
  • People find it difficult to find the right experts for a given industry.

One of the ways that you could re-arrange the information would be to put it in the context of customers.

For example, imagine if you had a place for every customer. For now, let's call it a site, but that's not the point of this exercise.

Every site would have the same information:

  • Customer information
  • Customer documents
  • Links to customer projects
  • An RSS feed that shows news about the customer, the customer's competitors, and their industry.
  • A contact card for the account manager
  • Contact cards for experts in the customer's industry

Somewhere else, you would have a list of all customers with a link to their individual sites.

Finally, every account manager would see a My Customers web part. The web part would show them their list of customers and links to their customer sites.

Here is a potential usage scenario:

Andrew is an account manager. He logs in to the SharePoint first thing in the morning.

Andrew is about to visit his customer and wants to see what's going on. He clicks on the customer's name in the My Customers web part to get the customer's site.

On the customer's site, he can review the status of the latest proposal and project status.

As he's getting to leave, Andrew looks at the RSS news. He notices that the customer's competitor is in the news for declaring bankruptcy. It may impact the proposal Andrew prepared.
Andrew wants to make sure is not affected.

Andrew looks at the list of experts and sees that Edward is an expert in the customer's industry. He sees that Edward is currently online and available. He chats with Edward to understand the impact of the competitor's news. Edward explains how Andrew should change the proposal.

Andrew makes the changes to the proposal. When he leaves for his customer meeting, he does so knowing he is well prepared.

This scenario is actually derived from an implementation I built many years ago. It uses the same data that already existed, but by putting it in the context of a customer, it has meaning for its users.

By putting the customer list in the context of each user, it helps account managers. They can get to their customer information with fewer clicks.

Adding a list of industry experts makes it possible to get in touch with the people with knowledge.

What it means

Add context

The secret to creating content that has meaning (information) is to give it context. Otherwise, it is data.

To avoid data overload -- and useless SharePoint content -- make sure that you put data in context.

Add links to people

You can't store people's knowledge in SharePoint. But if you provide links to people -- who have the knowledge, you will make it easier for your users to reach experts.

Personalize

Personalization is not adding the person's name on the top of the page and say Hello, [user]. That's useless -- I know my own name (except, maybe on Mondays)!

Think of personalization as putting data in the context of a user. What does the user care about? What information do they need to do their jobs?

For example, one of my clients had offices across the world, with head offices in Toronto. Every day, users would log in to the SharePoint and would see announcements like this:

  • "IMPORTANT: Parking structure will closing this weekend"
  • "Pastries in the lunchroom"
  • "Cafeteria menu for today is chilli!"
  • "CEO to announce new deal today"

You think that people in Honduras cared about the parking lot closures or the pastries in the lunchroom? No! They do care about the CEO announcing the new deal, though.

People in the head office got value out of the announcements (chilli day was always popular). Everybody else in the company -- those who made money for the company -- felt as if they were less important. They felt the news didn't matter to them.

As a result, most people outside of the Toronto offices didn't read the news. To them, the news became data, not information.

The fix was simple: create corporate news for everyone, and office news for each office, then roll them up as News. Combine corporate news with news related to the user's office. That way, every user could see all the news that matter to them.

If someone wanted to see news for other offices, they could visit the site for that office. The default behaviour was to show people the news in the context of their office.

Conclusion

People often confuse data, information, and knowledge. Content without context has no value. It becomes data -- noise that they have to filter through to get to what matters to them.

Information architecture strives to take all data and create context. It makes it information and gives it meaning.

You will find that by adding a little context to your content.

What if dictionaries contained all the words in the English language, but in random order? They would be useless.

Searching for a word would need you to scan the entire dictionary before you could find it.

It would be frustrating.

If you met me and I told you that I write dictionaries for a living, you would probably say:

Oh, we have dictionaries at work. They suck!

In our next articles, we'll discuss specific ways to create an information architecture. We'll focus on creating an information architecture that makes sense for users.

We'll also discuss how you can use SharePoint to create targeted content. You know, stuff that matters to users.

I hope this helps?

For more information

The DIKW Pyramid, Wikipedia