A Case Study:
Implementing an Information Architecture Strategy

Project Overview

The purpose of this project was to improve the online banking platform and app for a Credit Union. I was the UX lead on this project collaborating with a UX Manager and other colleagues on various parts of the project.

The Credit Union’s banking app struggled with information hierarchy. The Credit Union experienced feedback from customers that included difficulty finding content and connecting different financing flows in the same journey. Additionally, many long-time customers were unaware of some features that the product provided. Along with the user issues, internal management of the product was difficult. Similar banking information was in multiple places making it difficult to document various experiences with similar functionality. The lack of an information architecture strategy was the result of these problems. The Credit Union’s product teams need clear information hierarchy direction to ensure that users’ experiences are organized in a logical and user-friendly way. An information architecture (IA) strategy project was set.

Challenge

At this point, very little user research on customers’ user needs has been conducted. Secondly, there wasn’t documentation on what products and services the banking app offered and what purposes the banking app needed to fulfill. Thirdly, the company's vision for the banking app was lacking. Most mission and vision documentation was at an organizational level. Existing vision documentation for the banking app was very broad and used generic words that did not have meaning individual product teams could use as a guideline. Lastly, the product’s evolution was mostly static for over a decade. Features were frequently added, but the core banking flows had not been re-evaluated. Creating an IA strategy would mean that it would be necessary to tackle three complex systems: context, content, and users. (Figure 1.6).

Figure 1.6 - Venn diagram of the three complex systems in IA.

Approach

1. Define the banking app's mission, vision, and value proposition.
2. Inventory the banking app’s current and future products and services.
3. Define users and their needs.
4. Develop an IA map hypothesis and supporting documentation.

Process & Research

Information architecture can be a difficult topic for individuals to fully understand. Often, if you say the words “information architecture”, website navigation or a site map will likely first come to mind for many individuals. While navigation is an important IA system that can assist with findability, it is not the definition of an IA strategy. (Figure 1.7) An IA strategy goes much deeper and is invisible in product design. IA provides semantic structures for organizing information in a logical and user-friendly way. An IA strategy can accomplish this by defining how concepts interact with different places at different times with pages, content, interactions, and behaviors.

Figure 1.7 - Visualizing the differences between navigation and information architecture.

Approaching an IA strategy meant getting more context on what the business wanted for the banking app. To facilitate this, a mission, vision, and value proposition statement was created. Using documentation that the business already had, provided direction for the statements. Working with product stakeholders, the definitions were created. With this context, it was then possible to inventory the banking app’s products and services to provide definitions for the product’s content.

While inventorying products and services may seem like an easy task, it isn’t necessarily so. Challenges that needed to be worked through included using consistent language and defining what was a product vs a service. These objects needed to be documented in a way that wasn’t unbearably granular, making it difficult to organize later down the road. Lastly, the current banking platforms’ inventory did not contain everything that was specified in the mission, vision, and value proposition. The missing products and services needed to be identified and documented. Defining primary and secondary purposes was also part of this work to set areas of focus for the vast amounts of information that needed to be presented. (Figure 1.8).

Figure 1.8 - Product inventorying templates.

The last complex system, defining users and their needs, was the most significant part of the project. The business had already designated a research project to better understand its customers’ user needs. This was an opportunity to make multiple efforts under one project. Defining users and their needs was discovered by using jobs-to-be-done methodologies (Figure 1.9) which uncovers customers’ needs and desired outcomes. This information was vital to capture IA user journeys and understand how users expect to interact with the product. Read the case study: Discovering User Needs with Jobs-to-be-done, to get a full deep dive into this process.

Figure 1.8 - Template of mapping journeys using the jobs-to-be-done methodology.

With significant data collected to understand the banking app’s context, content, and users, the next step was to define the IA strategy. Because IA is invisible, one way it can be communicated is by creating a map. The IA map can describe experience goals and user needs within the business’ product. While there are no set rules for what this map should have on it, the approach taken here shows the landmarks as user journey stages, pages, navigation, functionality, and other important information hierarchy details (Figure 2.0).

Figure 2.0 - Example of an Information architecture strategy map.

Determining what the map should look like requires thinking about all the complex systems together. First, the user journey was defined, and then all products and services were mapped to the journey stages. Different levels of information that the products and services provided needed to be defined at each journey stage. This was done using primary and secondary purpose definitions for each page and the primary and secondary navigations.

Once a map was constructed it was important to think about how this concept could be tested. The Credit Union’s product development process was an iterative, agile approach. Restructuring the banking app to a new information architecture in one phase would be costly and also high-risk. An iterative approach would allow for the IA strategy to be tested in smaller segments and also provide opportunities to uncover additional learnings early. As an example, the iterative process could look like defining design intents that align with the IA strategy and then progressive steps that lead up to the final vision (Figure 2.1).

Figure 2.1 - Example of an iterative plan to test an Information Architecture strategy.

Next Steps

The next step is getting alignment with project stakeholders to plan resources for the structural updates. This includes education on information architecture practices, explaining research results, and product development recommendations.

Retrospectives

What went well:

• The documentation and learnings gained from this project were able to help explain the reason for customer issues and how they could be improved.
• Using the jobs-to-be-done methodology was beneficial because it allowed for the learnings to be used across different projects and well into future projects.

Areas for improvement:

• Ideally, early on project stakeholders would have been involved throughout the process streamlining the next steps and implementation. However, due to business dynamics, it was only possible to involve them when it was in a delivery-ready state.