Mar 23, 2019
A few years ago, my son fell in love with a song on the radio. He kept on asking us to play the song for him.
The problem is: like me, he is on the Autism Spectrum. He isn’t always good at communicating.
He’s incredibly sweet and incredibly caring, but he wasn’t a very good singer.
He didn’t know what the song was called. He couldn’t sing it for us. He just called it the “nehbie decktur” song.
When we asked what song he meant, he would just repeat the same sound over — in a sing-songy way.
“Nehbie decktur”
If you’ve ever tried to Google something when you don’t have the right keywords, you know how hard it is to find information.
I searched and searched everywhere for that damned song.
I tried to get him to hum the song in one of the various tune-matching search engines. No luck.
Until one day, the song came on the radio and my son heard it.
That song was Rude by Magic!.
The part where they sing “Marry that girl”, in his mind, sounded like “Nehbie decktur”.
To this day, we still call that song Nehbie decktur.
When we design Information Architecture (IA), we often assume that people find content in one way.
If they know exactly what they’re looking for, they’ll search for content.
But if a user doesn’t know what keywords to use in their search query, it can be very difficult to find the content they need.
In this article, we’ll describe how we find content in different ways and how to design your Information Architecture to accommodate the various ways users find content.
When looking for content, we use one of 3 approaches:
We’ll describe each approach below.
Browsing allows users to find content through discovery.
Let’s use an example: Nancy the New Employee recently started at Contoso Inc.
She isn’t familiar with the organization structure, the department names, or even the company’s lingo. She can’t search because she doesn’t know what keywords to use.
Browsing isn’t only for new employees. It allows users to find content in an area of expertise that they aren’t familiar with.
For example, your company may reimburse eligible daycare expenses for employees. Your Human Resource professionals, who are subject of matter experts on all things HR, may call this Childcare support plan.
However, your employees probably look terms like daycare, babysitting, or pre-school. Unless your HR folks used those keywords in their content, your users won’t find what they need.
But if you have a SharePoint site that lists all benefits in one place (maybe grouped by life events, like getting married, having children, retiring, etc.), it will allow your employees to find the content they need without being experts in Human Resources.
To support browsing, make sure that users can access every piece of content by following links.
There shouldn’t be any secret stash of content anywhere that can only be accessed through search.
When users know exactly what they’re looking for, they use search. It is the fastest and most direct way to get to the content they need.
Microsoft’s own Overview of search in SharePoint Online is a good place to get started with search best practices, including:
There are a few other things to consider:
In our previous example our consumer, Nancy the New Employee, isn’t a Human Resource professional. She doesn’t know that the proper keyword should be childcare.
Unfortunately, the HR professionals (i.e.: the creators of content) use the proper terms in their documentation.
We can’t expect the content creators to start tagging every single document with every single keyword that users might be thinking of.
One way to design for Search that satisfies the needs of both consumers and creators of content is to use managed metadata, particularly synonyms.
For example, to create synonyms for childcare, you would follow these steps:
When users look for childcare or babysitting, they will find documents that also contain the word daycare.
Sometimes your consumers will use newer terms than your creators used. During the first H1N1 flu outbreak started making the news. My client’s SharePoint servers started getting queries for H1N1 with no results found. However, the company already had detailed documentation on flu prevention and preventing outbreaks.
By monitoring search queries (the No Result Queries by Day and No Result Queries by Month, in your Admin center’s Search > Search Reports are a good place to start), we were able to notice the increased number of searches for H1N1. After a bit of research, we found that all we had to do was to create synonyms for flu, influenza, “orthomyxovirus and H1N1**. Just like that, users were able to find existing content for** H1N1** they could not find the day before.
If you create custom SPFx web parts that use custom properties to store displayable content, your users may want to find the page containing your web part.
For example, I created a web part sample that allows users to create sequence diagrams and flowcharts using simple text. One of the web part sample, the Sequence diagram, exposes the text of the diagram as searchable by SharePoint.
In order to make the content of the web part searchable, I exposed the accessibleTitle and the accessibleText properties as isSearchablePlainText. (My web part creates an accessible equivalent of the diagram for users who use screen readers).
To do so, simply add a get propertiesMetadata method in your web part class which returns a list of property names and isSearchablePlainText: true.
protected get propertiesMetadata(): IWebPartPropertiesMetadata {
return {
'accessibleText': { isSearchablePlainText: true },
'accessibleTitle': { isSearchablePlainText: true }
};
}
If your property contains HTML text, you can also use isHtmlString: true in the same fashion.
The last way people find content is when the system finds content that the user has indicated they are interested in — either explicitly or implicitly — and returns that content.
This can be done explicitly by users creating Alerts or by Following a site.
But it can also be done by SharePoint recommending content on the SharePoint Home, SharePoint News showing aggregated news posts from sites the user belongs to or even Delve analyzing the user’s interests via emails, tasks, etc.
The important point here is that if you design your information to be “subscribable”, your users will find that information when they need it.
For example, if your company has offices in Toronto, Helsinki and Melbourne, you could create a single News site and post office news from all three offices on that site. But when someone posts news about the Helsinki office that is really intended for folks from the Helsinki office (“Freshly baked korvapuusti at reception!”), do we really want everyone in the company to get that news post?
Note: that’s probably not a good use of SharePoint news, but korvapuusti (a yummy cinnamon-bun-type-thing with pearl sugar on top) and coffee is worth broadcasting!
Until audience targeting is available in News (which was announced recently, but then went missing from the announcement), you could create 3 sites (one for each office), and post news in each respective site.
Only users who follow the Helsinki office will see the news about the cinnamon “ear buns” promoted to them, while the other two offices will be blissfully ignorant.
Heikki, if you’re reading this, I could use some korvapuusti right about now. Oh and some ruispala, kiitos.
Another way to create “subscribable” content is to break it into smaller elements.
For example, maybe I want to have a list of items listed somewhere that people would want to know right away if something new is added.
You could simply use the rich-text editing feature on a modern page and list all the items, but it will require users to actively subscribe to the page in order to get notified. If the page has other content on it, they’ll get notified every single time any part of the page changes.
The other option is to create that list of items in a Custom list. Your page can use the List web part to embed the list. Now your users can subscribe to that list to get notified.
I have barely scratched the surface of how to design your Information Architecture for browsing, searching, and subscribing, but I hope that I managed to convey that people don’t all find content the same way, and that taking some extra time to consider how people find content will help you design a better SharePoint.
As for me, I suddenly have a craving for cinnamon buns. I have to go make a batch for tomorrow morning! (Sugar-free, of course)
I hope this helps?