Information architecture: build your content a home

Information architecture describes the structure applied to information which enables users to effectively navigate through it to the content that they need.  

When your content is just piles of information, an information architect breaks everything down into separate building blocks of knowledge and then uses those building blocks to build a strong and beautiful structure that allows rapid comprehension and ease of navigation.  

What is information architecture in user experience? 

When a user interface is not intuitive, the user requires some guidance. This user guidance can take many forms, from tooltips to interactive tutorials. For most large systems, though, a documentation set is the cost-effective way of balancing user access to information with the effort required to keep the information up-to-date. 

Users are happiest when their product interactions are as frictionless as possible. If a user is seeking out documentation, they are likely already feeling some frustration, so any further friction in finding the correct information will only increase their frustration. 

If you can structure your information well, you can reduce the friction required for a user to find the relevant information and improve the user experience. A user in need can find the information that they seek, ideally in a way that makes the experience seamless.  

When a product is new and the user interface only has a few sticking points for users, a lightweight FAQ on the product website or included leaflet can be sufficient. 

FAQs can quickly become unwieldy, though, as more questions are answered. Unless the FAQ is well structured, a user can struggle to scan a long list of questions before they are able to find the relevant answers. 

How information is organised – Frequently asked questions 

Let’s set the scene with an example of an all-too-common scenario: 

Imagine that you have a product that came to market a couple years ago. In the early days after product launch, you had to field many support requests. Wanting to make life easier for users, your support manager put together a Frequently Asked Questions page with answers for the users. Since then, your product has matured, and you have more users. Your support team are now fielding more questions and more complex answers are required.  

You know that different documentation is needed but, in the meantime, the FAQ needs to be expanded with each new feature that’s introduced. 

Surveying the information landscape 

Your development team have been writing the answers for the FAQ on the website thus far and your sales team have been putting together white papers and website copy. Now that you’ve got information coming from different teams, you want to ensure that all your content is useful to your customers and that there’s a consistent tone of voice. Your product manager recommends that you hire an information architect to build a comprehensive set of documentation.  

The information architect needs to start by identifying who the stakeholders are and interviewing them about what information is required on your website. They need to know what sort of person requires information about your product, to better understand what information to provide.  

They start by asking a few questions about the users who will most likely be seeking help: 

1. Who will use the documentation?
   1. Are they a customer who will be interacting with your product?
   2. Are they an administrator who’ll be configuring your product for end-users?
   3. Who are the people most likely to ask questions of the support team?
   4. Who are the people who will be looking for sales materials?
2. How complex is the product?
3. What is your user’s pre-existing industry knowledge?
   1. Is there an established industry that your product is catering for, or do you need to teach your users from the very beginning? A product catering to a new segment will likely require more use cases for different features in order to understand the purpose of each feature.
4. What is your user’s pre-existing product knowledge?
   1. Will they be comfortable getting straight into detail or will they need to have higher-level concepts explained to them before they’re able to understand the content? Often, new users require more conceptual information for getting started, and progress to more detailed information about specific behaviour of the product as they want to make use of more advanced features.
5. How will your users be accessing the information?
   1. Will they be searching for answers from a printed manual which would need to be structured in a linear manner?
   2. Will they be relying on a search box in a help centre to deliver relevant content based on a keyword search?

Framing out the information 

After you’ve identified the types of information that your users need, it’s time to decide how to organise information. 

If you’re working with questions of an FAQ, you want to make it easier for your users to find the relevant question for them (and therefore the relevant answers). You first want to group related questions together. To find the relevant answer, your reader can read the group headings and then only needs to read the questions in that group.

To make it easier for your reader to find the correct grouping of questions, you would want to put the questions in an order that would make sense.  For example, you could mirror the user journey through the software in the ordering of your FAQ groups, so that your reader can find their question based on what stage in the customer journey they are at. 

An organised FAQ for an issue tracker might look like this:

New issues 

• How do I submit an issue?
• How do I include a screenshot?
• Can I get email updates on my issue?
• When will I get a response to my issue?

Open issues

• What’s the current status of my issue?
• When will I get a response to my issue?
• Can I update my issue?
• Can I get email updates on my issue?

Closed issues

• How do I re-open a closed issue?

Think of when you were in school and you needed to write an essay. My teacher, when I was in school, taught us that essays would use the following outline:  

1. Introduction paragraph
   1. Opening sentence
   2. Summary of arguments
   3. Transition sentence
2. First argument paragraph
   1. Argument introduction
   2. Supporting statement
   3. Conclusion statement
3. Second argument paragraph
   1. Argument introduction
   2. Supporting statement
   3. Conclusion statement
4. Third argument paragraph
   1. Argument introduction
   2. Supporting statement
   3. Conclusion statement
5. Summary paragraph
   1. Transition sentence
   2. Summary of arguments
   3. Call to action

By writing out the essay outlines in this way, I could write out my arguments and quotes onto cards and rearrange them until the outline was filled in. The information architecture creates a similar outline which you can use to put all your information in the best place.  

Your information architect uses a similar user journey structure as the FAQ to build out the help set: 

1 About the Issues feature
    1.1 New issues
    1.2 Open issues
    1.3 Closed issues
    1.4 Information for support users

Bricks of information 

After the overarching architecture has been decided, it’s time to put it to the test and populate the outline with the information that users need. In order to put your information where it will make the most sense, you need to first break down the information into relevant pieces. 

There are different ways of breaking the data into chunks. One of these is DITA, which categorises most technical content into concept, task, and reference types [Reference: http://docs.oasis-open.org/dita/dita/v1.3/os/part0-overview/introduction/about-the-dita-specification.html]. Each of these types looks at different aspects of the product but, together, they create a comprehensive picture of the product for the user.  

Concepts 

Concepts are, by their very nature, abstract. A concept provides all background information that the user needs to interact with a particular aspect of your product. This information might be industry background or use cases.  

To get started, you might list out separate features and parts of those features. You might then find you need to explain more high-level ideas to show how multiple features work together in the context of your product. 

With your issue tracking feature, these separate parts need to be explained: 

• Issue number
• Issue history
• Issue status
• Issue responses

Tasks 

The easiest chunks to identify for your issue logging feature might be the tasks, which are different ways in which the end user will interact with the feature. The actions that your end users can perform with the new feature are: 

• Log an issue
• View the issue history
• Respond to an issue query
• Mark an issue as fixed

There are other ways in which other product users will interact with this feature based on their roles. Your support users might be interacting with the feature with these additional tasks: 

• View the list of issues
• Filter the list of issues
• Prioritise the list of issues
• Change the status of an issue

The task content is used to walk your users through how to do something in your product. Your users can use these tasks as a reference to find out where in the system to perform an activity, follow along to do the activity, and to find links to relevant conceptual or reference information. 

Reference 

The reference information type would provide users with detailed reference information. Reference information is the type of information that is typically included in a table or in a term and definition list. A user would read through or search the table or list to find a value or definition that they need. While a small amount of reference information can be more convenient to include in a task, large amounts can be visually overwhelming and make it more difficult for the reader to navigate through a task.

You have the following reference information that your users want to refer to: 

• Descriptions of all the fields and options on the issue submission form
• Available filters for the list of issues with examples of the result
• Descriptions of issue statuses

Bringing it all together 

After you have your framing and your bricks, your technical writer can fill in the information architecture with the concepts, tasks, and reference information that your users need. 

Your information architect recommends that each page of the help includes information in the following order: 

1. Concept
2. Task
3. Reference

Not all of the pages will contain all of those content types. Based on the information units that need to be covered, your information architect has agreed the following documentation pages and their headings with stakeholders:

1. About the Issues feature
2. New issues
   1. Task – Log an issue
   2. Reference – Field descriptions on the issue submission form
3. Open issues
   1. Task – View the issue history
   2. Task – Respond to an issue query
   3. Task – Mark an issue as fixed
   4. Reference – Available statuses for issues
4. Closed issues
   1. Task – View the issue history
5. Information for support users
   1. Task – View the list of issues
   2. Task – Filter the list of issues
   3. Task – Prioritise the list of issues
   4. Task – Change the status of an issue
   5. Reference – Available filters for the list of issues

Your author can now confidently create the documentation, knowing that the information is what is required by the relevant audiences and is structured in a way that can easily be found.

In closing 

3di has decades of experience which we leverage to plan new documentation and restructure existing documentation. Contact us to help build your information a home.