.jpg){kind=small}
This article continues on from Part 1: What is an information architecture. You can view the previous article here.
In summary, Part 1 introduces the information architecture concept for knowledge-management or document-management systems. It describes how an information architecture is positioned between context, content and your users. A well-crafted architecture makes possible other improvements, such as automation, enhanced navigation. search, personalised content, and more.
Information architecture components
To demonstrate how to define components within your information architecture, consider the following examples.
User groups
It is important to consider who will be using your KMS or DMS, and how users should be grouped or classified within your system. These user groups are necessary to restrict access to certain documents or information. They are also useful for enabling functionality based upon the user’s roles, memberships, projects or matters.
For example, you may wish to highlight relevant content to your users on your homepage according to their teams and active projects (see our case study exploring this example below). This functionality requires that your users have been allocated to at least one group from which relevant content can be gathered.
How you determine when a project, function, role or membership requires a new user group is unique to your KMS or DMS and entirely up to you. However, we suggest you create user groups for the following:
- Global → a company-wide group for all-employee communications.
- Teams / Department → e.g. Sales, HR, IT, Legal, Executive etc.
- Internal projects → e.g. digital transformation projects, content marketing projects etc.
- Clients → for existing clients and each new client.
- Events and committees → e.g. event-planning, social committees, governance committees.
Information visibility & hierarchy
A plan for information visibility and hierarchy requires you to empathise with your users. You consider what information your users want to view and when they want this information presented to them.
Your KMS should respect that different users will wish to see and interact with different information.
For example, information relating to the Sales department may be relevant to users from that department, but less so to users from other departments.
Additionally, you should present users with information and features ordered by importance to them. Users should access information and tools needed to complete their job with little effort.
Other information such as education material, company news or voting polls remain available, but should placed further down the page. This allows users that are comfortable with the KMS and curious about further information to dig deeper, without frustrating users who want their basic needs met.
Global navigation structure
A global navigation structure is a plan you will define early in your KMS or DMSs development. It documents how you will organise various sites, sub-sites, pages and sections within your KMS or DMS.
Typically your content will be structured either according to business group or business function. See Origami Connect article for advice on creating this structure.
A global navigation structure ensures that administrators and content contributors understand the correct location for new pages. The structure improves navigability for users who aren’t confident searching for content is an additional benefit. It also enables the possibility of targeting navigation quick links and content to users based on their teams and context.
When drafting your navigation structure you should avoid creating nested pages with deep hierarchies beyond 3-4 levels. Deep hierarchies are difficult for users to navigate and don’t align with modern Sharepoint’s ‘flat’ ethos. See Microsoft article and Sharegate article for further information on ‘flat’ navigation structures.
In our mouse-tracking studies, we found that only about 15% of users use the search box and these are mostly advanced users. Others heavily rely on navigation and links to discover and find information… - Origami Connect (link)
Local navigation structure & metadata
A local page navigation & metadata plan involves creating separate plans for different site types. This step is not always necessary, but can help increase consistency within your KMS or DMS.
For example, your plan might require that sites created for clients include pages displaying the client’s team members and their contact details.
Similarly, your plan might require that some sites contain a landing subsite and help subsite. Local navigation structures can be helpful if you are frequently creating new sites for internal teams or clients that use similar templates. Using this plan ensures that you provide a consistent and professional design and layout for your clients.
Additionally, your plans may detail Sharepoint lists that must accompany certain site types. These lists can be used to power other features — for example feedback boxes and polls, or quick link carousels. As an example, see Microsoft tutorial for connecting the Events webpart to a Sharepoint list.
You may also define metadata that is required for certain sites. For example, you may require that client sites are linked to specific matter / project numbers. This metadata can then be used to enable more powerful search, or to reduce ‘stranded’ information that lacks context.
Methods for defining KMS metadata in Sharepoint are explored in more detail below.
Information structure & metadata
Defining the metadata for information stored within your KMS or DMS has enormous benefit.
This metadata describes other stored data. Defining what metadata is needed requires you to review what information you will be gathering and storing, what information is needed for current features, and other potential future uses.
Your data’s type, shape and format should be included within your metadata definitions. These can be determined by answering the following questions:
- What is the data type? e.g. text, number, fixed-choice, free-text etc.
- Are users required to always complete the data field or is it optional? e.g. a description field may be optional whereas a date field may always be required.
- Can the data be collected automatically or does it require manual input from users? e.g. the user responsible for modifying data can be automatically collected by the KMS.
- Will users select data from data stored in another list or will it be entered new each time? e.g. project or client names may be stored in a central list for selection in other places.
- What validations apply to the data? e.g. min/max length of data or specific formatting for phone numbers.
Clearly defining your metadata at this stage will improve your KMSs data ‘hygiene’. Enforcing specific data types or requiring your users to complete certain fields before accepting input reduces ‘decision fatigue’ and ‘nudges’ users towards correctly entering data into your KMS (designing so-called ‘choice architecture’ — Choice Architecture and Digital Nudging: Guiding Online User Choices through Interface Design). This reduces the need to collect or clean this data in the future.
You should also be mindful that it requires less user effort to capture additional data at the time of entry versus sometime in the future. Though this has the caveat that only relevant, clean and structured data is useful for your future uses.
See Microsoft article and Medium article for further advice on defining your information structure & metadata.
⚠️ Case study example: Using AI to highlight relevant content in a KMS
This article is the second in TILT Legal's three-part series on developing information architectures (you can access Part 1 here). Stay tuned for Part 3 releasing next week where we explore a case study example that demonstrates how an information architecture can allow you to leverage AI in your KMS.