Objectives

Upon completion of this lesson, you will be able to:

  • define information architecture
  • contrast structured and unstructured information objects
  • build an information architecture
  • use tagging to improve findability
  • compare folksonomies and tagging systems
  • build navigable shared information repositories and environments

Overview

Information Architectures (IA) are critical to the construction of shared information spaces and usable digital information repositories. That includes, among others, websites, wikis, user interfaces, and reports. Of course, information spaces do not have to be digital, so information architecture design plays a critical role in the design of physical spaces such as exhibits, stores, or museums, just to name a few.

Think about it? Have you ever walked into an airport where you couldn’t find the toilet? Or visited an organization’s website and not be able to find their phone number or their opening hours? It is these kinds of “findability” problems that a thoughtful and planned information architecture should solve. In other words, IA is about “helping people understand their surroundings and find what they’re looking for” in physical and in digital spaces.

Knowing how to build an information architecture is important for the design of any shared information space and an essential skill for web designers, user interface designers, user experience designers, data scientists, and other data professionals. It’s importance is highlighted by the fact that it is included in many certification exams for data professionals, such as the Certified Analytics Professional (CAP) exam and the Certification in Business Data Analytics (CBDA).

Motivating Example

An information architecture is an organization mechanism. We use organizational patterns and mechanism in our daily lives and thus are, in fact, building or designing information architectures all the time, albeit with physical objects most of the time rather than digital or conceptual objects, and in physical spaces rather than shared digital spaces.

Take a look at the image below containing an assortment of objects. What are they? How would you organize them? Would you even want organize them? How would you decide to organize them? Before continuing to read, take a minute and reflect on how you would organize these tools.

There are clearly multiple ways we could organize this. An immediate question is: into how many “buckets” do we need to sort them? If we have only two holders for the tools, like jars or boxes, then we could organize by color, or by “tip shape”, i.e., whether the screwdriver has a “Phillips” head or a “Flat” head. How do we then organize within each bucket? By size or length of the screwdriver or by size of the head?

Of course, we could also organize by color (yellow vs blue) or by length (from longest to shortest) if we pin them onto a tool board rather than putting them into jars. Or we could organize from tall to short within each head category (Phillips vs Flat).

Of course, there are some “nonsensical” organizational groupings as well: by weight, by wear, by grip circumference, etc. So, how do we decide what the “correct” organizational architecture is? One common approach is to base the organization on how the objects (screwdrivers, in this example) will be used, i.e., how someone is going to “find the right screwdriver”. Findability is a common mechanism to drive the organization. In this case, a mechanic or carpenter (or, simply a “user”) would likely find the correct screwdriver in two steps: based on the screw type (Phillips vs Flat) and then based on tip size. It appears that the length of the screw driver correlates to the size of the head, so arranging them in “sorted” order from large to small can further increase findability of the right screwdriver.

This type of approach and these types of questions, and always considering findability and use cases first, are at the core of information architecture design. Now, if instead of designing a physical space, think about how you would organize a shared digital space; perhaps an ecommerce catalog for a store that sells screwdrivers.

Of course, if we were selling antique screwdrivers to collectors rather than new screwdrivers to mechanics, then the organization would very much differ. Think about what the information architecture would look like in that case.

Definition of IA

“Information architecture (IA) is the structural design of shared information environments; the art and science of organizing and labeling websites, intranets, online communities and software to support usability and findability; and an emerging community of practice focused on bringing principles of design, architecture and information science to the digital landscape.[1] Typically, it involves a model or concept of information that is used and applied to activities which require explicit details of complex information systems.” [1]

In the video below, Cicely Rose provides an overview of information architecture for the design of shared digital spaces such as websites.

The entry on Information Architecture on Wikipedia correctly points out that

IA has differing meanings and definitions in different areas of information systems design. It lists the following definitions:

  • “The structural design of shared information environments.”
  • “The art and science of organizing and labeling web sites, intranets, online communities, and software to support findability and usability.”
  • “An emerging community of practice focused on bringing principles of design and architecture to the digital landscape.”
  • “The combination of organization, labeling, search and navigation systems within websites and intranets.”
  • “Extracting required parameters/data of Engineering Designs in the process of creating a knowledge-base linking different systems and standards.”
  • “A blueprint and navigational aid to the content of information-rich systems.”
  • “A subset of data architecture where usable data (a.k.a. information) is constructed in and designed or arranged in a fashion most useful or empirically holistic to the users of this data.”
  • “The practice of organizing the information / content / functionality of a web site so that it presents the best user experience it can, with information and services being easily usable and findable (as applied to web design and development).”
  • “The conceptual framework surrounding information, providing context, awareness of location and sustainable structure.”

IA Design Process

The design of an information architecture has several steps which are generally carried out in this order, but the process is naturally iterative.

  1. identify the actors, i.e., the users that will likely interact with the shared information space
  2. identify the information that each actor must be able to find and the purpose of that information for them; these are the use cases
  3. express the use cases as short phrases in the form of a user story following the format: As a <actor>, I want to <state information or need>, so that <state purpose or goal>

Case Study

To better understand the design process with its tools and techniques, let’s consider an example. This will frame the process and ground the techniques with examples.

Ever since she first visited Germany as a child Alicia has been enamored with the beauty and architectural detail of the many castles, churches, and town squares in Bavaria. She is particularly fond of the churches in Bavaria built in the Baroque and Rococo, many of which were built in the 1400s and updated throughout these periods until the early 1800. Architects such as the Asam brothers all have their unique style. She wants to share her passion and the beautiful architecture by creating a web portfolio. Never having designed a website before, she needs help. Her friend Preetha is a web designers with a background in information science and she agreed to help Alicia get started. Preetha suggests that they start by designing an information architecture.

Use Cases as User Stories

The design process starts by identifying the user of the information space, aka the actors. Identification of the actors is part of information collection and requires working with subject matter experts (SME) who understand the information objects of that domain and the needs of the users of the information space. For our case study this is Alicia, although we might consider visiting similar websites for inspiration.

Actors

The most important actors likely include:

  • tourists
  • architecture students
  • mass attendees
  • members of the religious community
  • local government

It may not be feasible and perhaps not even possible to build an information space that meets the needs of all constituents, so Alicia has to limit her scope. She chooses to target tourists and mass attendees (i.e., people who want to attend church services offered by the parish located in a church). In the future, she might either add the needs of other users or build different websites for different user communities. So, we will have two actors: Tourist and Attendee.

Some information architects may build a UML use case diagram to capture the use cases, while others will forgo this step and immediately move to the next step of capturing the use cases for each actor.

Use Cases

Once the actors have been identified, we can move on to identifying the use cases for each actor. It is a collaborative activity with users, subject matter experts, and other stakeholders and is often conducted using brainstorming sessions, interviews, looking at similar information spaces, observation, and business process analysis.

Most likely, for our case, Alicia will use her own understanding of the domain or conduct brainstorming sessions with Preetha, conduct research, and perhaps observe what tourists and attendees do while in a church.

Let’s assume she has done the aforementioned and has come up with the following uses cases, expressed in the form of a user story.

User stories are short statements about a feature, written from a user’s perspective. A well-defined user story does not spell out the exact feature, but rather what the user aims to achieve, giving implementations teams the freedom to identify the most appropriate way to implement the feature. They are most commonly expressed in this form:

“As a [user/actor], I want [goal, action, or information need] so that [outcome, purpose, or reason].”

While user stories may seem like simple statements and be trivial to write, they turn out to be quite difficult to get right in practice. This is where qualitative research methods, such as observations, contextual interviews, and other ethnographic methods, are often employed by information scientists. Additional techniques include journaling to ask users to document their activities and capture their context, sketch experiences and write down perspectives. The design team then collaboratively selects the most relevant insights for the information architecture project and organizes them into a cohesive set of user stories often called the backlog.

For our case study, some of the user stories focused on information needs most likely would include the following:

  • As a tourist, I want to know when the church was built, so that I can identify its cultural period.
  • As a tourist, I want to know who designed the church, so that I can find other churches by the same designer.
  • As an attendee, I want to know whether a mass includes live organ music, so that I can choose which services to attend.

Surely there are many more. Commonly we have dozens and dozens of user stories and more emerge as the project is underway. Discovery of user stories is iterative and incremental, and the backlog is dynamic. Of course, there is not sufficient time to implement or address all of them, so we must organize the backlog by priority and go from high to low priority. The lower priority user stories will likely be out of scope when time is limited.

Personas

Some information architects may choose to build personas as a way to segment an actor. Think about it: we can think about a lot of different types of tourists, for example. To help understand the types of tourists we might get and their specific needs, we create personas for each group.

A persona is a fictitious “person” that embodies a group of users within a role. They are given a name, a demographic background, and a “story” – some user experience designers also add a photo to make them even more “real”. The personas are informed by market research and reflect the different needs of users within a role.

For example, we might consider the following personas for the user role Tourist:

Mark, a 25-year old backpacker from Australia. Mark is a 25-year old tourist from Australia who is visiting Germany for the first time. He treks across Germany and Europe by train and likes to visit cultural places that are not overrun by tourists. He knows how to use his mobile phone to find train schedules and places. He cannot read German but knows how to use Google Translate and also has a tablet.

Nina and Elfriede, two Catholic nuns in their 70s. Nina and Elfriede are nuns who enjoy visiting different churches throughout Europe and are particularly fond of organ pieces by J. S. Bach. In their spare time, they travel to particular churches where Bach’s music is played. Aside from church services, they enjoy attending organ concerts at churches, particularly when accompanied by a church choir.

These are just two examples of personas. Of course, there are more and a good information architect would consider several more to get a good understanding of a single user role. Again, the above are all “tourists”, so they are all instances of the actor Tourist, but they have somewhat differing needs for information. Understanding the personas helps sharpen the needs and ensures that the information architects personal opinions are not overshadowing the design of the information architecture.

Tools & Techniques

There are several techniques and tools that are helpful for developing an information architecture. The list below contains the most commonly used ones.

  • Brainstorming
  • Use Case Diagramming
  • Affinity Grouping
  • Card Sorting
  • Concept Mapping

The ensuing sections take a closer look at each technique. Note that not every techniques must be used and that some techniques are applied more than once to create a sound, useful, and relevant information architecture.

Brainstorming

Brainstorming is used to discover information objects, actors, needs of actors, and other information requirements through informal (but structured and facilitated) collaborative group sessions. A good facilitator is essential to the success of such sessions. Facilitation aids such as concept mapping, Ishikawa diagramming, or context diagramming are commonly employed during brainstorming sessions to increase their efficacy. Brainstorming is almost always followed up with more in-depth elicitation techniques such as interviews or observation.

Brainstorming is about generating ideas and thinking creatively. It is intended to exploit associative thinking in which one idea can lead to many other ideas. During the brainstorming session, the facilitator should record the ideas on a whiteboard, flip chart, software tool, index cards, sticky notes, or one of the diagrams below. Brainstorming Process Start a brainstorming session by defining the issue to be explored. Ask the session participants to brainstorm. Write their thoughts and insights on index cards or stickies and place them on a large table surface or stick them to a wall. Finally, group the insights into themes, i.e., concepts and ideas that are logically cohesive. This is one of the primary reasons why index cards work better compared to whiteboarding or a visual modeling with a computer-based tool – they can be moved around easily. At the end of the session, give each participant a set of votes which they can use to vote on what they consider to be the most important ideas. Prioritize the ideas and schedule action items for follow-up. Elaborate on the selected ideas through interviews and additional brainstorming sessions. Brainstorming Best Practices Sessions should be short (30-45 minutes) and have a small number of participants. Groups with more than 5 participants tend to not be effective. Don’t select more than 3 to 5 participants for a brainstorming session. If there are more, split the group into multiple subgroups. Focus on generating lots of ideas; no idea is bad and you should focus on quantity not quality. Don’t criticize ideas and encourage new ideas to be generated from existing ones, i.e., associate freely. If you see that a participant is dominating the discussion or that some participants feel intimidated by others, have the participants write their ideas anonymously on index cards and then pin them up for discussions. Read them out loud and debate them. Generate new ideas through verbal interaction or additional index cards. You can also create an electronic brainstorming chain by sending an e-mail to the first person in the brainstorming team with a seed idea to explore. He or she then comments on the idea and sends it on to the next person. The next person responds and sends it on again. This process continues until no further ideas are added to the e-mail chain. It is best to set goals during brainstorming sessions. Ask participants to come up with a specific number of ideas, or add some minimum number of additional ideas onto an existing concept.

Brainstorming Tools

There are a number of tools that can aid in organizing and focusing a brainstorming session. Among these tools are:

  • Mind Mapping and Concept Mapping
  • Ishikawa (or Fishbone) Diagramming for root cause analysis
  • Event Mapping to understand what event stiumulate a response in an information system or trigger a process
  • Context Diagramming to understand who interacts with a system and what information they furnish to the system or receive as output from the system
  • SWOT Analysis for business analysis of an organization’s strengths, weaknesses, opportunities, or threats

Use Case Diagramming

Use case diagrams are a useful diagramming tool in software requirements analysis and information architecture design. They help capture the interactions between shared information spaces and its intended users, providing a visual representation of how the information space will be used. Here’s how use case diagrams are used for this purpose:

  1. Identifying Actors: Use case diagrams start by identifying actors. Actors are entities that interact with the shared information space. These can be users, systems, or external entities that trigger actions within the system. By identifying actors, the information scientist can gain a clear understanding of who will interact with the shared information space.

  2. Defining Use Cases: Use cases represent specific functionalities or affordances that the shared information space needs to support. Each use case describes a particular way in which an actor interacts with the shared information space to achieve a goal such as wayfinding or locating some information objects. Use cases should be defined from a user perspective, focusing on what users need to accomplish with the shared information space.

  3. Describing Relationships: Use case diagrams show relationships between actors and use cases. These relationships help you understand how actors interact with the shared information space and which use cases they are involved in. There are several types of relationships in use case diagrams:

    • Association: A simple line connecting an actor to a use case, indicating that the actor is associated with that use case.
    • Extends: An arrow with a dotted line connecting a use case to another use case, indicating an optional or exceptional behavior that extends the base use case.
    • Includes: An arrow with a dotted line connecting a use case to another use case, indicating that the use case includes the behavior of the included use case.

  4. Visualizing System Functionality: Use case diagrams provide a high-level visual representation of the information space’s functionality. This visualization helps stakeholders, including designers and developers, gain a common understanding of the system’s behavior, features, and interactions.

  5. Prioritizing Requirements: By defining use cases and their relationships, you can prioritize requirements based on their importance to users and stakeholders. This prioritization guides the design and development process, ensuring that critical functionalities are addressed first.

  6. Iterative Refinement: Use case diagrams are not static; they can evolve and be refined as you gather more information and requirements. You can iterate on the diagram as your understanding of the shared information space deepens, ensuring that the information architecture aligns with the evolving requirements.

  7. Communication and Documentation: Use case diagrams serve as effective communication tools between stakeholders, bridging the gap between technical and non-technical team members. They also serve as valuable documentation that can be referred to throughout the project’s lifecycle. It is common to whiteboard use case diagrams rather than using tools.

The UML Use Case Diagram below, illustrates the use of use case diagrams to visually show the actors and the use cases that they require, i.e., in the case of an information architecture, the information they need and they need to find in the shared information space. Note how the diagram is drawn with a “hand drawing” font – this is useful to indicate to others that the diagram is still preliminary and in draft mode.

In short, use case diagrams play a crucial role in understanding requirements and defining use cases when designing an information architecture for a shared information space. They provide a visual and structured representation of how users and other entities interact with the shared information space, helping in the development of a clear and effective design that meets user needs and expectations.

Affinity Grouping

Affinity grouping, also known as affinity diagramming or affinity clustering, is a creative and collaborative technique used in various fields, including information architecture design, project management, problem-solving, and brainstorming, to organize and make sense of a large amount of information, ideas, or data by grouping related items together. This method is especially useful when dealing with complex and unstructured information or when trying to identify patterns, themes, or commonalities within a set of items. Here’s a comprehensive explanation of affinity grouping and how to use it effectively:

Steps to Perform Affinity Grouping:

  1. Gather Information: Start by collecting a diverse set of ideas, data points, sticky notes, or any other relevant information related to the problem or topic you are exploring. Ensure that the information comes from various sources or stakeholders to capture a broad perspective.

  2. Individual Brainstorming: If you’re working in a group, begin with an individual brainstorming session where each participant writes down their ideas or data points on separate sticky notes or cards. Encourage participants to be concise and use one idea per note.

  3. Sorting and Grouping:

    • Affinity Sorting: Lay out all the sticky notes or cards on a flat surface, such as a wall, whiteboard, or table. As a group or individually, start grouping related items together based on similarities, themes, or common characteristics. This is typically done by physically moving the notes to create clusters or groups.
    • Silent Sorting: In some cases, it’s helpful to have a silent sorting phase where participants group items without discussing them to avoid bias and promote diverse perspectives.
    • Discuss and Refine: After initial sorting, discuss the rationale behind each group and refine the groupings as needed. It’s essential to encourage open communication and debate to ensure that everyone understands the reasoning behind the groupings.

  4. Labeling Groups: Once the groups have been formed and discussed, assign a label or category to each group that accurately represents the common theme or concept shared by its members. These labels should be clear and concise.

  5. Create an Affinity Diagram: Organize the labeled groups into a visual affinity diagram. You can do this by drawing lines or using digital tools to connect the groups, creating a hierarchical structure if necessary. The diagram should provide a clear overview of the relationships between the groups.

  6. Analyze and Interpret: Step back and analyze the affinity diagram as a whole. Identify patterns, insights, and key takeaways from the grouped information. This step helps in gaining a deeper understanding of the problem, discovering opportunities, or making decisions based on the organized data.

  7. Generate Action Items: Based on the insights gained from the affinity grouping process, generate action items, recommendations, or strategies to address the problem or capitalize on opportunities. These action items should be actionable and specific.

Tips for Effective Affinity Grouping:

  1. Diverse Participation: Encourage diverse participation from stakeholders or team members to capture a wide range of perspectives and insights.

  2. Focus on Commonalities: When sorting, emphasize the commonalities and similarities between items rather than differences. This helps in identifying meaningful patterns.

  3. Iteration: Affinity grouping is an iterative process. You may need to revisit and refine the diagram as more information becomes available or as your understanding evolves.

  4. Facilitator: Having a skilled facilitator can help guide the process, manage discussions, and ensure that the grouping is done effectively.

  5. Use Visual Aids: Digital tools, sticky notes, whiteboards, or software can be useful for creating and documenting affinity diagrams.

  6. Keep It Open and Collaborative: Encourage open and collaborative discussions during the process to maximize the benefits of collective intelligence.

In short, affinity grouping is a powerful technique for organizing, analyzing, and synthesizing information or ideas into meaningful clusters. It promotes collaboration, uncovers insights, and helps in making informed decisions or solving complex problems. It’s a versatile tool that can be applied in various domains, from project management to design and innovation.

Card Sorting

Card sorting is a user-centered design technique used in information architecture (IA) and user experience (UX) design to help structure and organize information in a way that aligns with the users’ mental models and expectations. It involves participants, often end-users or stakeholders, organizing and categorizing pieces of content or information into groups based on their perceived relationships and similarities. Card sorting is a valuable method for developing effective navigation structures, sitemaps, and taxonomies in websites, applications, and other information systems. Here’s how it works and how it can be used in information architecture design:

How Card Sorting Works:

  1. Preparation:
    • Determine the scope and objectives of the card sorting exercise. What specific aspect of your information architecture are you trying to improve or design?
    • Create a set of content items, concepts, or topics that you want participants to organize. Each item is typically written on a separate card or digital equivalent.
  2. Recruit Participants:
    • Identify and invite participants who represent your target audience or user personas. The number of participants can vary but is usually between 5 and 30, depending on the complexity of the project.
  3. Card Sorting Sessions:
    • In a physical card sorting session, participants physically manipulate cards by organizing them into groups and providing labels for those groups.
    • In a digital card sorting session, participants often use specialized card sorting software that simulates the process electronically.
  4. Collect Data:
    • Record how participants group and label the cards. Note any comments or explanations they provide during the sorting process.
  5. Analysis:
    • Analyze the results to identify common patterns and groupings. You can use various techniques like affinity diagramming to make sense of the data.
    • Determine the frequency with which specific items are grouped together and the labels participants assign to those groups.
  6. Iterate and Refine:
    • Based on the insights gained from the card sorting exercise, refine your information architecture, navigation menus, or content categorization.
    • Test and validate your revised IA with users to ensure it aligns with their expectations and mental models.

How Card Sorting Benefits Information Architecture Design:

  1. User-Centered Design: Card sorting is a user-centric method that involves the direct input of users or stakeholders. This ensures that the resulting information architecture reflects how users naturally think about and categorize content.

  2. Improved Navigation: It helps in creating clear and intuitive navigation structures, which can lead to a better user experience and easier access to information.

  3. Content Organization: Card sorting helps organize and categorize content logically, making it easier for users to find what they are looking for.

  4. Reduced Cognitive Load: A well-structured information architecture reduces cognitive load by presenting information in a way that aligns with users’ mental models, making it easier for them to comprehend and navigate the system.

  5. Validation: It provides a valuable way to validate your information architecture with real users, ensuring that it meets their needs and expectations.

  6. Flexibility: Card sorting can be used at various stages of the design process, from initial concept development to evaluating and refining an existing structure.

  7. Data-Driven Decisions: The results of card sorting exercises provide valuable data that can guide design decisions, helping you create a more user-friendly information architecture.

In short, card sorting is a user-centric technique that plays a crucial role in information architecture design. It helps ensure that the organization and structure of information within a system are aligned with the way users naturally think and categorize content, ultimately leading to a better user experience.

Concept Mapping

A concept map is a diagram that depicts suggested relationships between information objects, including concepts. Concept maps are employed by instructional designers, knowledge engineers, technical writers, web designers, data architects, database designers, and many others to organize and structure information found during information discovery. They are commonly used in collaborative information discovery efforts, such as brainstorming sessions.

Lecture

Summary

Thoughtful and methodical design of an information architecture is an essential step in the design of a shared information space. This lesson provided a process for designing an information architecture using use cases, user stories, collaborative research methods, coupled with techniques such as concept mapping, card sorting, and affinity grouping.

All Files for Lesson 50.252

Errata

Let us know.