How do interaction designers understand information architecture?

[[120858]]

Any product has an information architecture, which can be complex or simple. When discussing in this article, I roughly divide information architecture into two types for illustration. One is a relatively simple information architecture, such as most ToC products, WeChat, QQ Music, Tencent Video, etc.; the other is a relatively complex information architecture, such as most ToB products, operation and maintenance products, customer relationship management systems, business support systems, etc. I call the first type a "light architecture" product, and the second type a "heavy architecture" product.

Light-architecture products need to provide users with a simple and clear information architecture, making it easy for users to use and providing a smooth experience. Light-architecture products should not make users lost, nor bring too much learning cost. They should be usable and efficient for a large number of ordinary users. Light-architecture products can be focused by doing subtraction.

Re-architected products need to provide a fully functional and rigorously structured information architecture so that users can use each function through the operation process. Such an architecture will bring a certain learning cost, and some re-architected products even require training for users. The user group of re-architected products is generally more focused. It is difficult for re-architected products to focus by doing subtraction, but it requires reasonable integration and flexible layout of massive functions to focus on core user scenarios. Therefore, for re-architected products, the information framework is more difficult and more important.

My design work in the company includes both light-framework products and heavy-framework products.

The advantage of designing a light-frame product is that it is easy and enjoyable, and users are generally easy to empathize with, and even the user is you. The difficulty lies in breakthroughs and innovations.

The benefit of designing a re-architected product is that it is a good opportunity for interaction designers to hone their interaction skills. The more complex the information architecture, the higher the requirements for interaction design and the better the training effect. The difficulty lies in that re-architected products require a thorough understanding of the business, and the threshold for business understanding is high. Massive functions cannot be streamlined. Users are unfamiliar groups and user research support is needed to understand users. The complex information structure makes interaction design difficult, error-prone, and laborious. Designing a re-architected product requires a very high overall view.

Below, I will use the classification of information structures in the book "The Elements of User Experience: User-Centered Product Design" by Jesse James Garrett as a dimension to talk about the role of these structures in the information architecture design of user experience design, and will give some real examples to discuss how to use these structures to help thinking.

1. Hierarchical structure

“In a hierarchy, nodes have parent/child relationships with other related nodes. Child nodes represent narrower concepts and are subordinate to parent nodes that represent broader categories. Not every node has children, but every node has a parent, and so on up to the parent node of the entire structure. The concept of hierarchical relationships is very easy for users to understand, and software tends to work in a hierarchical way, so this type of structure is the most common.”

This is the most common way. Tree diagrams, family trees, etc. all follow this route. This route is quite in line with nature. I believe most designers have used this structure, so I won’t discuss it in detail in common scenarios. What I want to focus on here is a balanced use of hierarchical structures.

What is balanced usage?

This is something I came up with recently... First of all, we know that the hierarchical structure can bring two design ideas.

The first one is from top to bottom. Start from the main vision of the product and then break it down into each functional feature step by step.

The second method is from bottom to top. Start with the features that are valuable to users and work your way back to the soul of the product.

If you read my previous thoughts on the design process, these two approaches are two-way approaches at the strategic level and scope level.

The first one is easy to understand. The strategy sets a general direction, the management communicates and guides, and the executive layer outputs it. The tasks are broken down step by step until the task volume is clear and product results are obtained after execution.

The second type is widely used in re-architected products. For example, a ToB product made for China Telecom customer service must first understand the task flow, operation flow, and required module set of the customer service staff's daily work, and then work backwards to organize them into functional modules one by one, and then work backwards to form a system.

I've been working on a product re-architecture recently, and I've used the second method quite a lot. It's a bit brain-consuming, but hey, I got an A+ in my graduate game theory class, so I'm not afraid. lol

Both approaches have flaws.

Let me give you a recent design example of a re-architected product. First of all, the strategic level of the product has been confirmed. In other words, top-down is a reasonable approach. However, the product is too complex and has many functional features, and the span of cooperating departments is large. At this time, it seems that bottom-up is the right solution.

The problem arises. If we decompose from top to bottom, there are too many functions and features at the bottom layer and they are not logical to use, which leads to disorder. If we work backwards from bottom to top, the functions and features have a combination logic, but at the top layer, it is difficult for the soul of the product to match the direction set by the initial strategic layer.

What should we do? Take a look at this picture again:

I call the first point of the strategic layer, the highest parent node, the general; and the numerous functional characteristics of the bottom layer are called soldiers. The current problem is that when the general issues orders, the soldiers are in disarray; when the soldiers organize themselves, the general cannot accept the result. So I think we should use the points between the highest parent node and the bottom node, which I call captains. The captain organizes the soldiers to form a team with a combined force. The captain is responsible to the general, and the combined forces at the captain level are integrated to finally complete the synthesis of the army's combat effectiveness.

This is my thinking process for the balanced usage. It doesn't work from top to bottom, and it doesn't work from bottom to top, so we start from the middle. We confirm the massive functional features with the system architect, and then test our target users through user interviews, so that they can recognize and group the massive functional features. At this time, a middle-level structure verified by the system architect and the target users is determined. At this time, the "captain" has been generated. At this time, think about the positioning of the product characteristics and soul at the strategic level, and push the reasonable middle-level structure. At this time, another group of "captains" are also generated, who can achieve the requirements of the strategic level (parent node). Then the two groups of "captains" begin to merge, starting from the middle, making adjustments and compromises to the top and bottom, and finally get a unified information architecture. The focus of this result is the "captain" of the middle-level structure. This middle-level structure can meet the requirements of the strategic level upward and meet the realization of the massive functional features of the bottom layer downward.

Problem solved.

One point that interaction design needs to improve is to solve complex information structures. The process and results of solving complex information structures will directly affect the design execution and design influence of interaction designers.

2. Organic structures

“Natural structure doesn’t follow any consistent pattern. Nodes are connected one by one, and there’s no strong sense of classification. Natural structure is great for exploring a series of topics where the relationships are unclear or evolving. But natural structure doesn’t give users a clear sense of where they are in the structure. If you want to encourage a sense of free exploration, such as with some entertainment or educational sites, then natural structure might be a good choice; however, if your users need to rely on the same path to find the same content next time, then this structure might turn the experience into a challenge.”

This model is increasingly used in ToC products (especially gaming and entertainment products). It is in line with the browsing form of light-frame products.

There is a classic dimension for distinguishing user scenarios: task-based and browsing.

Task-based characteristics: completing tasks quickly, accurately, and efficiently, such as checking the arrival time of a certain flight.

Characteristics of browsing: fragmentation, ample time, strolling, divergent, unfocused, and attention-attracting, such as aimlessly browsing Weibo and reading Zhihu.

Natural structure is very suitable for the browsing form of light-structured products. First, for heavy-structured products, such as ToB products, if users need to browse and guess to use product features to complete tasks, the results will definitely be bad and users will be frustrated; second, ToC products generally have two forms. If it is not task-based, it is very likely that users are bored and need to enter the browsing mode.

Of course, there are very few ways to design completely natural structures (I don’t know if the recently popular secret counts).

Most ToC products should be task-oriented and browsing-oriented in parallel. Therefore, the natural structure should be considered in conjunction with other information structures.

For example, Tencent Video. The natural structure should definitely be considered in terms of binding the hierarchical structure. When a user enters a video product, one possible way of using it is that the user already has a clear idea in mind, looking for American movies to watch in 2014, so the user enters the category selection, selects movies, selects American movies, selects 2014, and then browses. This can be regarded as thinking in terms of hierarchical structure first and then natural structure.

If a user is drinking tea at home and wants to watch a video, but has no purpose and opens the video product, then they are browsing, and this is when the natural architecture creates value. The user browses illogically on the homepage, clicks on a TV series on the homepage, looks at the details, is not interested, clicks on the next TV series from the recommendation of the TV series, is not interested again, then thinks of the star of the TV series and thinks of a TV reality show he is currently performing, and then browses the variety show.

Each product has different emphasis on hierarchical structure and natural structure. For example, in the case of e-commerce products, most people go to Tmall with a clear purchase purpose, so task-based operations are more important. But are there users who have no purchase purpose at all and just want to spend some money or find discounted products on Tmall? Of course there are, but they are probably not as many as the first type of users.

Therefore, in information architecture design, I think natural structure will be an important consideration, because we designers must always remember that users are not rational, and their operations and ideas are often random. However, natural structure is not the only one, and other information frameworks such as hierarchical structure, linear structure, matrix structure, etc. must be coordinated and constrained to make the overall information architecture of this product complete, usable, and effective.

3. Sequential structures

“Linear structure comes from the offline media you are most familiar with. The flow of language is the most basic type of information structure, and the devices for processing it are hardwired into our brains. Books, articles, audio and video are all designed to be a linear experience. On the Internet, linear structure is often used on a small scale, such as a single article or feature, and on a large scale for applications where the order in which content is presented is critical to meeting user needs, such as educational materials.”

The linear structure is easier to understand. It is more common in help documents, product storytelling, etc. I won’t describe it in detail.

Here I want to emphasize that linear structure is another way to practice interaction design logic. One extreme is complex information architecture (hierarchical, natural, matrix, etc.), and the other extreme is linear structure. How to tell a story in a coherent way without jumping and interweaving, and to make the idea clear in one line is not a simple thing.

Therefore, interactive design needs to practice two extreme ways of describing information architecture. One is a complex information architecture, which is full of levels, jumps, supplements, and intersections; the other is a minimalist linear architecture, where one main line tells a story, even a complex story.

4. Matrix structure

“A matrix structure allows users to move between nodes along two or more ‘dimensions’. Since each user need can be associated with an ‘axis’ in the matrix, a matrix structure often helps users with ‘different needs’ find what they want in the same content. For example, if some of your users really want to browse products by colour, while others prefer to browse by size, a matrix structure can accommodate both. However, if you expect users to use this as a primary navigation tool, matrices with more than three dimensions may be problematic. It is simply impossible for the human brain to visualise these movements well in four or more dimensions.”

This structure is very easy to understand. What I want to say here is that the KPI evaluation method of most design teams now is a matrix structure. On the one hand, they are responsible to the business line and use design to support the commercial success of the product; on the other hand, they are responsible to the design line and use design professional experience to support the team's professional influence and skill growth.

How designers balance this matrix structure management method is one of the keys to their growth.

After a designer has finished a product, he must think back from the information architecture layer and think about what kind of innovation and adjustment have been made to the product information architecture and what value has been created. Don't just stick to the specification of interface elements and the solution of design details. Because information architecture is the best foundation for the overall view of interactive design.

Link to this article: