Feb 22, 2019
In my previous post on Information Architecture (IA) in SharePoint, I explained that you should build your IA on 3 dimensions.
I discussed how you should build the physical dimension around your authors, by creating sites, document libraries and — if you must — folders optimized for those who create and maintain content.
In this article, we’ll discuss the logical dimension of IA.
If the physical dimension is for authors, the logical dimension is for readers — those who consume your SharePoint content.
Authors are usually subject of matter experts on a given domain. For example, your Human Resources department people are experts in all things HR-related. They understand the subject, and they even use jargon that is specific to their domain of expertise.
In contrast, readers may not be subject of matter experts. They don’t care about how to maintain content — they just want to find the content.
And, unlike authors, readers don’t share a common knowledge of a domain of expertise. That means that every reader navigates through content using their own logic.
For example, your company has employee benefits. Your Human Resources department handle some of those benefits, while your Finance department handles other benefits. Maybe your IT department offers additional benefits (like providing phones and computers for home use).
The HR folks, Finance folks, and IT folks maintain information about the respective benefits their department offer. Based on what we learned earlier, you would build a physical IA that would allow each department to store documents where it makes sense to them.
To keep things simple, let’s pretend that you created three SharePoint team sites:
And let’s pretend that, on each of those sites, you created a document library called Benefits.
People from the Finance department can update benefits documents in the Finance team site. People from the HR department can do the same in their Human Resources team site, and so on.
Nancy, the New Employee is a fictitious person.
Everyone that has worked with me knows the I like to build personas to help gather requirements.
She’s a typical new employee. She’s excited, nervous, and eager to learn.
Nancy is fresh out of college. She joined as a Junior Accountant. She recently got engaged. Like most people of her generation, she wants to get recognized for her hard work, but she also wants a proper work/life balance.
One of the reasons she accepted her new job with your company is because of the amazing employee benefits it offers.
This is Nancy’s first real “grown-up” job. She’s never had real employee benefits before. She doesn’t know what to expect, or where to get started with taking advantage of her benefits.
Nancy doesn’t care what department offers what benefits. She doesn’t want to go through Finance, HR, and IT sites to learn about benefits.
She just wants a place the shows her everything related to benefits in a single, convenient location.
In other words: Nancy doesn’t care where the benefits documents are physically located, as long as they are available together logically.
Nancy’s Information Architecture needs as a reader are very different than those of an HR employee’s IA needs as an author.
That’s the difference between the physical dimension and the logical dimension.
The secret to building the ideal logical IA is to understand your users and their goals.
To do so, I always use a slightly modified version of the process I use for gathering Use Cases.
Here is the Use Case process:
graph LR A[Identify actors] --> B[Identify goals] B --> C[Define main success scenario] C --> D[Identify extension conditions] D --> E[Define recovery steps]
Here is the modified process for logical IA design:
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure]
Let’s discuss each step in details.
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure] style A fill:#f9f,stroke:#333,stroke-width:4px
I use the term actor instead of user because I don’t ever want people to get confused give me a list of every single person who logs on to SharePoint.
In a play, an actor can often play multiple roles. Many people can also play the same role (think: understudies).
So, in our IA design process, an actor is a person who plays many roles. Your actors can be real people, or they can be fictitious people that you create for the IA design process.
For example, Nancy the New Employee is a fictitious actor we’ll use to represent real new employees. We don’t want to have a list of every single new employee, we just want to use Nancy as a proxy for all the other new employees.
Keep going through until you find all your actors. Resist the temptation to move on to the next step. If you move on to the next step now, you’ll have an IA that suits one actor very well, but doesn’t work for others.
If you’re struggling to identify, here are some tips:
Your actors should almost be caricatures of your real users. Look for people in your company that are stereotypical users.
Find the worst and the best people in your organization.
I once did this exercise for one of the top 5 accounting firms in the world.
The Firm had many partners, who –rightfully so– ran everything.
Partners were often older men who were at the top of their profession.
Most of them were nice, but some of them were just grumpy old men.
Most of them didn’t trust computers and wanted their assistants to print everything for them.
We took the oldest, grumpiest partner we knew, and used him as an actor. Of course, we changed his name to Perry the Partner.
One trick is so easy it almost feels like cheating: find the opposite of an actor you already have.
You have a new employee actor, create an old employee actor — their needs are different. The new employee doesn’t know anything about the organization structure yet, the policies, the people. The old employee knows everyone in the company, knows every department, every policy, etc. They’ll look for information differently.
You have a grumpy old partner that doesn’t like technology actor, maybe you need a *younger partner who is technically savvy.
This is another trick I borrowed from capturing requirements: primary actors, and secondary actors.
Primary actors are the reason why your system exists. Without them, you wouldn’t need SharePoint. This one is obvious — that’s probably everyone you have identified so far.
Secondary actors exist because the system exists. In this case, secondary actors are people who support SharePoint, create content, etc.
But secondary actors could also be people who already existed, but whose jobs become more important because of your new system.
Remember Peter the Partner? He hates technology. He needs everything printed (which I disagree with, but that’s another topic). Who prints everything for him?
His assistant, Allison.
Don’t confuse Primary and Secondary as Important and Less important. For our IA, Allison the Assistant is just as important as Peter if not more. Without Allison, Peter won’t use the system.
I’m a big fan of evidence-based requirements gathering.
When you interview people to gather requirements, they tend to tell you what they think you want to hear. They talk about features instead of goals. They try to translate things in geek speak for you because that’s what they think you want to hear.
Evidence, doesn’t lie. It doesn’t change because you’re looking (although Quantum physics disagrees)
If you want to get a list of typical people who use the system, look for evidence.
What kinds of evidence are there?
Be careful: I have been in many organizations where the distribution groups and security groups combined outnumber the number of employees.
Remember we started this whole example about employees finding benefits.
What most HR professionals will tell you is that benefit needs for an employee tend to change around life events.
For example:
Not every employee will experience the same life events, but life events definitely help shape a person’s goals.
For example, Nancy recently got engaged. She will get married soon. She’ll be thinking about adding her husband to her benefits. She might want to change her last name.
After getting married, her next life event might be to get pregnant. She’ll want to find information about pregnancy leave, child care benefits, etc.
Please don’t send me angry emails about my antiquated views of the world or calling me sexist. I know that it isn’t always the case, and I agree with you. Those are the life event patterns HR professional often consider.
In our previous example, Perry the Partner is probably pondering his prospective retirement. (That’s a lot of “p”).
Life events can also be professional events. For example:
Many countries have (or will have) a legal requirement for accessibility. How do people who are visually impaired access your information? How about those who can’t use a mouse? What about people with cognitive impairments?
When I create my actors, I always create an actor with accessibility requirements. It may not affect our IA, but it will definitely impact our designs. But that’s a different post.
It depends on how different types of people you have. I tend to aim for 12 actors at most. Why? Because I’m lazy. If you aren’t lazy, feel free to do more than 12, but I’m not sure how much more value you’ll get.
If you’re up to it, create little posters with each one of your actors.
I usually create a fictitious profile, complete with picture, of each actor.
I post them around the team room so that everyone that works on my project sees the posters every day. They serve as a gentle reminder to our team that we’re building this for people, not computers.
I’ll often hear team members having discussions where they use our actors as if they were real people:
“Nancy will never know how to do this! Remember, she’s new, she doesn’t know what benefits are available to her yet!”
I bet you that if you talked to the people who worked with me on that accounting firm project, they’d remember Nancy the New Employee.
That’s the point of defining actors: we’re not building an IA in a vacuum. We’re building it for people (even if those people are fictitious).
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure] style B fill:#f9f,stroke:#333,stroke-width:4px
Now that you have your list of actors, you can define roles for each one of them.
We’re not talking about security roles here. We’re talking about purposes or unique traits that will affect their goals.
In our example, Nancy plays many roles:
“Why do we do all this work to define an IA?” you may ask. Or “Why identify actors just so that we can identify their goals”. Your actors are there to serve as a reminder that you’re building this for people.
If you define memorable actors for you and your team, your actors will become the litmus test for every design decision you make.
Roles help you identify goals in a way that helps you focus. Trust me, you’ll get a more complete list of requirements by listing goals on a role-by-role basis than you would if you just spewed a list of random goals for your entire system.
What if you get duplicate roles? It happens. You should try to create actors with distinct roles, but don’t stress about it. During this step, we often realize that we have duplicate roles and we combine multiple actors together, or trade roles between actors to make them more unique.
Once again, resist the urge to go to the next step before you complete this one.
Why?
If you move to the next step, you will not have any idea of the scale of effort involved in completing your IA. You will have an incomplete IA and no clue how much you didn’t accomplish.
Instead, your goal should be to have a complete list of roles. That way, you’ll know how much work is ahead of you and it will help you plan accordingly.
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure] style C fill:#f9f,stroke:#333,stroke-width:4px
For every role you identified, list the possible goals.
Complete this sentence “As a [role] I want to use SharePoint to ____”.
Notice that this step isn’t identify requirements. It is identify goals.
What’s the difference?
Every single engagement I take on, there will be at least one person who will insist that “search” or “searching” is a goal.
“Search” isn’t a goal. It is a requirement.
No one ever says “I think I’ll go to Google and search for something and do nothing with the results”.
You search because your goal is to find something.
So don’t write “Search”. Write “Find [something]”. How you find something is through search, but keeping the end goal in mind may help shape your IA differently.
Here are some tips:
For example, the new employee role might want to accomplish the following goals:
The bride to be role might want to accomplish these goals:
The junior accountant role’s goals might be:
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure] style D fill:#f9f,stroke:#333,stroke-width:4px
Once you have an extensive list of goals, you can consolidate it into common goals. You can also filter out the list of goals that are out-of-scope.
For every goal, try to answer this question: “How will users accomplish [this goal]?”. Or “What information do users need to accomplish [this goal]?”.
As tempting as it may be, I’ll resist the urge to list example information requirements.
Just think about every document, list, news, and people you may need to accomplish a goal.
“Wait a minute! Didn’t you say in a previous post that people are knowledge?”
Wow, I didn’t know you read that! Thank you! But no, people hold knowledge. Listing the people who know stuff is just information. Remember: I can write everything I know about a subject, it becomes information. You need to apply your own experience to make it your own knowledge.
graph LR A[Identify actors] --> B[Identify roles] B-->C[Identify goals] C-->D[Identify information requirements] D-->E[Define logical structure] style E fill:#f9f,stroke:#333,stroke-width:4px
I would love to be able to give you a magical formula to define your logical structure. Unfortunately, I don’t, because every IA is different.
However, I can give you some tips:
Define what success will be before you even start.
For example, I always start with 3 clicks or 30 seconds.
That means that every actor should be able to achieve their goals within 3 clicks on their landing page, or within 30 seconds.
As you build your logical IA, test it with goals you identified in the previous step and see if it meets your success criteria.
Let me be clear: in the physical IA, duplicating content is a no-no. You don’t want two physical copies of the same data because it will invariably lead to content getting out of sync.
Logically, I should be able to see content in multiple places.
Every user will navigate your IA differently, so why force them down a path that doesn’t make sense for them?
Think of a news post. It may physically be on an HR site, but it may show up logically on your SharePoint tenant’s root site news feed, in the user’s own news feed, in the HR site’s news feed, etc.
I can’t stress this enough. Build an IA that is centered around the users. Don’t try to copy your Org Chart.
If you need help getting started, try writing all the goals on individual index cards (or sticky notes).
Invite groups of actual users to review the goals and physically group the cards into groups that make sense to them. They can work together, or they can work individually. Tell them that they can to move other people’s cards too.
Then watch how they work.
See if people disagree or fight about where a particular goal should go. Make sure to remember any contentious points.
When they are finished, ask them to give each group of goals a name they would use to describe it.
Record the results and repeat with different user groups. You’ll be surprised to find some similar patterns, while some groupings will wildly vary across different user groups.
This will give you a good indication of how your users see your information.
IMPORTANT: Ask the users to do this. Avoid the we know better attitude.
I once conducted this workshop with folks from the IT department, then asked the actual users to do the same exercise. The results were wildly different. Embarrassingly so.
If you think you have defined your logical IA, try it with users.
Just as before, print some user goals on index cards or sticky notes. If you want to change things up, you can list some of the information you identified in the previous steps instead of goals.
Now draw your logical IA on a giant whiteboard or on different color index cards laid out on a big table.
Invite groups of users to read each user goal (or types of information), and to place each one where they think it belongs on your logical IA.
If they instinctively place the cards where you intended them to go in your logical IA, you’re doing great.
If they struggle, your IA needs more work.
Your physical IA is for authors. Your logical IA is for readers.
Build your logical IA with users in mind.
Remember that every user has a different perspective when looking for information.
In our next article, we’ll discuss the last dimension of IA: Metadata.