by John Ng
on Jan 02, 2020
This article is about how 'Information Architecture' brings clarity to your organization/ projects and how will clarity allow businesses to build product that scales.
As a standard part of the UX process, designers create information architecture when building products. Defining every avenue and path that users can take through an app or website, information architecture is much more than just a sitemap to show what page leads where.
Similar to building architects using a blueprint to construct every part of a house, from physical structures to more complex inner workings like electrical and plumbing, information architecture describes the hierarchy, navigation, features, and interactions of a website or application. And just as blueprints are the most valuable document for an architect to use in the construction of a building, information architecture can be the most powerful tool in a designer’s arsenal.
However, developing one isn’t as simple as putting a list of features together and mapping out how they work — let’s investigate the process.
Information architecture (IA) is, like a blueprint, a visual representation of the product’s infrastructure, features, and hierarchy. The level of detail is up to the designer, so IA may also include navigation, application functions and behaviors, content, and flows. There is no set limit to the size or shape of IA; nevertheless, it should encompass the generalized structure of the product so anyone (theoretically) should be able to read it and understand how the product works.
We’ll use the blueprint reference often because the purpose of both documents is nearly identical. Just like a blueprint, IA provides designers (as well as product development and engineering teams) a bird’s-eye view of the entire product. Having a single document that delivers a simple and understandable representation of how the application or website works is vital for developing new features, updating existing ones, and for seeing what is possible considering the existing product.
With IA available, it becomes significantly easier to make key decisions for new features and implementations, to understand timelines for product changes, and to follow user behavior through multiple processes.
Let’s dive into a basic video to see how an IA is built.
As part of the UX process, IA design follows very similar patterns to flowcharting: Add shapes and connect them with lines in an organized fashion to a single document. The challenge when building IA is in understanding how your app or website actually works from the user’s perspective, and how to organize that information into a readable, legible format.
There are two major requirements for actually constructing IA: organizing it through a visual hierarchy (that is, a hierarchy of features, functions, and behavior) and creating a legend for displaying different types of features, interactions, and flows. With a standard flowchart, the shapes follow specific requirements (rectangles are processes, diamonds are decision points, etc.); however, following that nomenclature isn’t a requirement.
In other words, the most important factors to building your IA are where individual components of the architecture are placed (hierarchically), and how they’re labeled and displayed.
The most challenging aspect of creating a new information architecture is almost always in constructing it hierarchically. It’s a common misconception that IA must be built “from the top down.” That’s almost always more difficult to do unless it’s an existing product, such as in the video above.When building IA from scratch, unless your website or application is following a standard format, drawing out anything after the top level is very difficult. It’s like asking a mechanic to build a car from the top down instead of in parts. Each piece has to be constructed in advance with its own research, time for design, and development. The same is true with IA.
Displaying visual hierarchy is a valuable asset to IA, not only because it provides better context for the reader, but also generalizes key regions of the product. If your app’s most significant feature is ordering a ride (a la Uber or Lyft) which can be done from the homepage, then that page will have the most touchpoints and the most value to the product. The same will be true for the visual hierarchy.
Sitemaps come in handy for understanding hierarchy since they organize pages numerically (such as 1.0 Home, 2.0 Payment, 2.1 Add Pay Method, etc.). Or consider the example in the image below for Nisai website.
Even without those parts available, the structure is such that we can understand how to navigate the website through the IA alone. That stops when we reach an application within the website — it doesn’t have to.
Aside from hierarchy, the architecture above does another thing well: It displays every engagement point uniquely as needed through a simple legend and a few key phrases. The legend denotes page and content type, and it signifies variations between colors of shapes. This is important because, though Nisai’s site appears fairly simple, the IA only goes three levels deep. Each page stack in rectangle denotes an application, so the processes within each of those boxes aren’t included in this document.