This is the last article in the series focusing on Information Architecture. The first article briefly described what Information Architecture (IA) is and the second article in the series touched on why IA is important. Today, I want to provide you with a high level overview of how to create an Information Architecture.
Entire books have been written on the subject of IA, many of which include how to information. This article, when finished, will likely be only a few pages. Consequently, the how to information presented here will be broad strokes. But fear not, though broad, they will be practical. To begin, let’s take a look back at the definition of IA I shared in the first article:
Information Architecture: Organizing information and creating solutions (browse and search) to facilitate intuitive access to content.
IA is all about findability.
What follows are five high level considerations for creating an effective Information Architecture:
1. Understand Context of Information and Requirements
The first step in developing an IA is to gain an understanding of the information that will be in the proposed solution and any IA related requirements (if they exist).
Is the IA you’re developing, for a collaboration portal or a premium content repository that serves a specific/critical function within the organization? Are you creating an IA for 6,000 files or for 6,000,000 files? For 100 GB or 10 TB? Where does the information exist today? How will the information be migrated into the new system? Which users will browse for information? Which users will search for information? Or, will the information be dynamically populated on pages based on the page the user is on or the organizational department the user is a part of? Who are the SMEs (Subject Matter Experts) that can help classify the information? Has a taxonomy of terms (controlled vocabulary) been developed that can be used to tag the information?
Start with developing a proper understanding of the information that will be in the proposed solution. At a minimum, you should seek to get answers to the above questions.
2. Align with Technology Lead
If you possess the acumen to understand the technical components of the proposed solution, you can yourself work through the technical details that affect the IA or vice versa, the IA components that may affect technology decisions. If you’re not technical, make sure you spend time getting the Technical Lead on your project up to speed on the IA requirements and design.
3. Create Taxonomy
This is where the lion’s share of an Information Architect’s work is done. Your taxonomy will be the primary deliverable you create and use as an Information Architect. Word, Excel and XMind are common tools used to create taxonomies. Over the years I have really come to appreciate the value of a good taxonomy. Three guidelines to keep in mind regarding good taxonomy are whether it has 50 terms or 50,000 terms, all the necessary terms for all of the information in the system should be included. Additionally, a good taxonomy captures the relationship between terms. These relationships are often expressed in hierarchical fashion. And, finally, your taxonomy should be easy to use and allow you and other consumers of your document the ability to easily recognize patterns and logical groups (of terms).
Acme Company Taxonomy Example – Identifying Patterns and Logical Groups
As you’re working with SME’s to identify terms you will start to see patterns or logical groups of terms in your taxonomy. You may begin noting these sections with colors, icons, notes, etc (or you can wait till your taxonomy is complete). As an example, the green nodes in my taxonomy example represent terms to be used in the global navigation and these same terms represent department sites. From my requirements I know that department sites will include custom branding (I should communicate this to my front end development team). The red star next to the Human Resources node indicates a “premium content area” – the HR Onboarding Portal where new users complete tasks, register information to be included in their employee profile, etc. Premium content areas (in my example) are branded and usually contain workflows or custom application development. The red nodes (Term A1-A10) will be lists and libraries (in my example, the underlying technology solution will be SharePoint).
4. Design Browse Solution
Using your taxonomy document, identify which terms will be used in the global, department, local, etc. navigations. As an aside as you identify terms and add them to your taxonomy, you will likely come across terms that are different but represent the exact same information. With SME help, determine the best term and record the other term as a possible synonym. Terms used in navigations should be descriptive enough to accurately represent the information the user will see upon clicking the link. In addition, they should be as short as possible to avoid UI design challenges.
Side note: A short and interesting article on links, browsing and search by Jared Spool, founder of User Interface Engineering, can be read here. Though the article is 10 years old, not much has changed.
5. Design Search Solution
If your requirements do not call for search to be tuned, implement or set up the basic configuration for your search application and you’re done.
If your requirements call for search “tuning,” the details of how that will be done will depend on the specific search technology you are using and your requirements. There will likely be three parts to your search tuning. First, research and discovery of how to best tune search prior to go-live. This is not a technical step, but rather understanding conceptually how search can be tuned to improve findability, i.e. understanding historical user queries, being aware of the most popular content and ensuring it is properly tagged and organized, the use of multiple tags (synonyms), scoping queries to specific parts of the search index, etc. This information can be referenced in your taxonomy document with the details of such modifications detailed in a separate document if needed. Next, technical configuration to tune search and then ongoing tuning based on user queries and other system or user related information.
In closing, IA is all about making content easily accessible. The reason people should care about IA is because information doesn’t organize itself…and poorly organized information systems can be costly. Developing a strategic IA can increase productivity, reduce costs, increase revenue and enhance the user experience.