You need to draw the IA (information architecture) correctly.

I've drawn the IA, but... why are developers confused and users lost?

As a junior planner, I became quite confident in creating IA (Information Architecture) documents at one point. At that time, our company drew IA in Excel. We distinguished GNB (main menu) and LNB (sub menu), adjusted indentation according to Depth, and organized it neatly by attaching screen IDs. When I walked into a meeting with the IA I drew one day, I was filled with quiet confidence.

However, just five minutes into the meeting, that confidence shattered. Developer K, who I usually got along with well, frowned and threw the first question.

"M, I read the IA well. But what's the difference between the 'Event' screen in section 5-2 and the 'Promotion' screen in 3-4? Do we need to create a separate database table, or are they just named differently?"

While I was stammering, saying "Um... just a moment...", designer C raised their hand as well.

"I'm also confused, as there is a 'Notice' under 'Customer Service', and it's a different screen from the 'Notice' inside the 'New Information' menu in the GNB, right? But both are in a list form... I think users might get confused; was this intended?"

I had clearly created a comprehensive list, but I had no thoughts regarding the structure, relationships, and terminology. I lacked deep consideration of how users would perceive this service and how developers would effectively design with this structure. Eventually, the meeting ended with the devastating remark for planners: "Please redo the IA."

Many junior planners often make similar mistakes to mine. They rush to fill the IA thinking of it merely as a list of screens or menus that will be part of the service. However, IA is not that simple of a document. Today, I want to discuss what the true role of IA is, what conditions a good IA must meet to make both users and developers happy, based on my experiences of failure.

Part 1. Are you still drawing IA like a sitemap?

IA (Information Architecture) is literally a blueprint of information. Usually, we can find our way to the infant care room or food court in a large shopping mall without getting lost, thanks to clear signs and logical spatial arrangements all around. A good IA serves the same purpose for our services.

Many people get confused, but the sitemap is just one of the outcomes of IA; it is not IA itself. While a sitemap shows a flat list or map of what menus exist, IA is a much more three-dimensional and strategic blueprint that defines why each piece of information needs to be there (Why), what relationships it maintains (Relation), the paths of movement (Flow), and how it should ultimately be labeled (Labeling).

The real reasons why IA is important can be summarized in three main points. If you miss these three, you'll definitely incur significant costs later.

1. A blueprint for creating services for users: "Why is this service so hard to use?" If users complain like this, 90% of the time, it originates from the IA. What if users have to click three or four times to find the function they want? They’ll quickly get frustrated and think, "Ugh, I'm annoyed; I need to use something else," and they’ll drop out of the service. A good IA serves as a blueprint that allows users to clearly understand their current position within the service and reach their desired destination with minimal effort (this is referred to as low cognitive cost).
   
   

2. A common language for the team: As in my experience, if a planner calls something ‘promotion’ but the developer understands it as ‘event’, and the designer designs it as ‘discount event’, what happens? This isn’t just an annoying situation; it incurs real costs. As the team grows, it is common for designers to redesign, and developers to modify the established components and API integration code. Even one word change in the planning document can waste a day's worth of a developer’s effort, which is more common than expected. IA serves as a common language and blueprint that ensures all teams (planning, design, development, marketing, operations) communicate using the same structure and terminology. When IA is clear, unnecessary questions like, "Where does this screen attach?" disappear, and everyone can draw the same picture and generate synergy.
   
   

3. A framework that keeps the service continually expandable: “PM, we need to open the premium membership feature next month; where should we put this menu?”

Services grow like living organisms, and features inevitably get added. If the IA framework is not sturdy at this time, new features will be forced into locations that have nothing to do with the existing menu structure. Suddenly, membership benefits are put inside settings menus or my page starts bursting with more than 20 submenus. A good IA should serve as a flexible and expandable framework that considers not just the immediate functionalities but also those to be added in 1-2 years. A strong framework can prevent devastating disasters where the entire structure has to be overturned every time a single function is added.

Part 2. Signs that my IA has failed: The three characteristics of bad IA

So what should we watch out for? What does a bad IA look like that leads projects astray? Open the IA documents you are currently working on or have drawn before and diagnose yourself calmly.

(1) Labeling (naming) is arbitrary. This is the most common and most fatal mistake. We create names not with words that users can easily understand but according to what we want to call, or how we refer internally.

Bad Case: Some GNB menus are labeled 'My Information', but the buttons in the submenus say 'Go to My Page'. There’s also a link titled 'Account Settings' in the footer. Whether these three constitute the same function or different ones will start to confuse not only users but also the team members reading this document. Additionally, some menus are titled 'Requirements', but users pause and think, “Who is demanding what from whom?” This may just be terminology we use within the team, but users do not precisely know what that term means.

Why?: Users act with a clear objective of “I need to change my password.” In this case, inconsistent names increase users' learning costs and cause significant confusion. "Should I go to 'My Information', or 'Account Settings'?..." If hesitation compiles, or if they wonder, "What menu do I need to go to for changing my password?", trust in the service breaks down.
Trap for new planners: In the early stage of planning, it’s easy to become so caught up in listing screens, menus, and function lists that you overlook defining the exact names of each screen, menu, or function. Problems also begin when you mix the terms each department uses (e.g., marketing team, operations team, etc.) into your planning document.

(2) The structure is too deep (Deep Depth). This is a structure where you have to endlessly click 'show more' or delve into menus to find desired functions.

Bad Case: In an e-commerce app, checking 'Delivery Status of My Order' requires over 45 clicks like: My Page > Shopping Information > Order/Delivery Management > Recent Order Details > Detailed View > Delivery Status.

Why?: There’s something known as the "3-Click Rule". This classical law states that if users cannot reach their desired information within three clicks, they are likely to abandon the service. While it's not an absolute rule in today’s complex services, it indicates the importance of regulating depth. A more crucial concept is 'Information Scent'. Users need to sense from the names (links) of each step's menu that, “By clicking this, I will get the information I want” to easily move on to the next stage. When IA’s depth is too great or labeling is vague, this scent inevitably becomes faint, leading users to feel lost, and sadly abandon the service.
Trap for new planners: There’s a tendency to try and fit as many functions as possible into seemingly relevant top-level menus. This sometimes results in a distorted structure where over 30 functions are squeezed into one settings menu at a depth of 3-4.

(3) Grouping criteria are unclear.

This is the worst case, where the very criteria for dividing menus are incorrect.

Bad Case 1 (Overlap): The 'Notice' menu is located under 'Customer Service' and also under the GNB menu 'New Information'. If the difference between the two is not clear, users will be confused.
Bad Case 2 (Provider-Centric): Instead of using criteria that users understand (e.g., 'Shopping', 'My Information', 'Customer Support'), the menus are divided based on the company's internal organization (e.g., 'Marketing Team Events', 'Operations Team Notices', 'CS Team Inquiries'). Users have no interest in our company's team structure.

Why?: The foundation of good IA is the 'MECE (Mutually Exclusive, Collectively Exhaustive)' principle. Simply put, it means that it should have a structure that is 'mutually exclusive (without overlap) and wholly exhaustive (without omission)'. Anything belonging to Group A should not belong to Group B, and all information should belong to either A or B. If this principle falls apart, users will wonder, "Where on earth is what I'm looking for?" and will only search for the search bar. To be honest, in such services, no matter how much you search, users cannot find the information they seek (I often find this to be the case in banking or card apps).

Part 3. Three Conditions of 'Good IA' that developers love and users admire

Now that we know the characteristics of bad IA, flipping those can define the conditions of good IA, right? Beyond merely reversing, I will provide you with concrete know-how that makes developers admire during meetings and allows users to feel, "This app is easy to use."

(1) Clear and consistent labeling (Good Labeling) Good IA uses easy and intuitive words from the user's perspective and thoroughly consistent terminology.

How-to: Start with a Glossary. Before beginning the IA design, invest time in Excel, Google Sheets, or Notion to create a Glossary. It doesn't need to be grand. You might think you’re wasting time while being super busy, but in the long run, it will save you time.

Step 1 (Collection): List all nouns (e.g., posting, product, user) and verbs (e.g., register, edit, purchase) that will be used in our service.
Step 2 (Definition): With team members (especially developers, designers, marketers), define the terms you will use (e.g., unify as 'user'. Do not use 'member', 'user', 'customer', etc.).
Step 3 (Sharing): Pin this glossary in the project channel and make sure everyone agrees to follow it.
This simple promise can unify terms in planning documents, design guides, and even in variable names of the developers’ code, saving dozens of hours of communication costs later.

(2) Shallow and Wide Structure (Shallow Depth) Good IA does not hide important information and allows users to access it with minimal effort.

How-to: Maintain information scent while reducing depth.

Instead of blindly following the "3-Click Rule", check whether “Can users proceed to the next step anticipating what might be presented?”
A practical way to reduce depth is to use a mega menu. This is where when you hover over the GNB, the LNB and its submenus are displayed in one glance, helping users quickly grasp the structure and jump straight to what they want.
Another method is to utilize dashboards, as seen in 'My Page'. It offers quick access to functionalities like 'Order History', 'Coupon Box', 'Edit My Information', arranging them on one screen in order of what users look for the most.

(3) Mutually Exclusive Grouping (Good Grouping) Good IA adheres to the MECE principle (it should be exclusive and exhaustive) and, above all, groups information based on the user's thinking rather than the provider's perspective.

How-to: Don’t trust your instincts; conduct card sorting. You need to get rid of the illusion that the logic in your head aligns with the user's logic. The best method is to use card sorting techniques that involve actual users (or at least colleagues) to ask them directly.

1. Preparation: Write down all functions and pieces of information to be included in the service on post-its or digital cards (e.g., FigJam, Miro).

2. Execution (Open Card Sorting): (Useful for new services) Hand these cards to 5-10 users and ask them to, "Group the ones you think are similar and give each group a fitting name."

3. Execution (Closed Card Sorting): (Useful for improving existing services) The planner predefines GNB menus (groups) and requests users to classify the cards into the most suitable groups.

4. Analysis: Through this process, you may gain powerful insights, such as, "Oh, users are grouping 'Coupons' and 'Points' into a group called 'My Benefits', not 'Payment Information'," or "Many users are grouping 'Events' and 'Notices' together more than I expected."

Part 4. IA is not a 'static document,' but a 'living blueprint.'

Another mistake many planners make is to draw IA once during the project's initiation and stamp it complete, only to never look at it again. However, once the service opens and users start using it, IA enters the management realm.

Validating with data: After the service opens, you should check through tools like Google Analytics (GA) to see where users are getting lost (high bounce rate pages), which menus are most frequently used, and what terms users predominantly input in the search bar. If users cannot find 'Delivery Status' and keep searching for it in the search bar, that’s a strong signal that there is an issue with the position or labeling of the 'Delivery Status' menu.
Continuous updates and version control: When such data or new business requirements (e.g., adding new features) arise, IA should be revised. At this point, it should not be a matter of ignoring the existing structure and adding layers but checking, “Will the principle of existing grouping break with this feature addition?” Furthermore, when updating the IA document, always manage versions like IA v1.1, IA v1.2 and clearly share the changes with team members (Change Log).

In conclusion: Instead of a perfect blueprint, create an evolving blueprint.

IA is the starting point of planning and the most important promise connecting both users and team members. Drawing a perfect IA from the start is almost impossible. However, if you remember the three criteria discussed today, 'Consistent Labeling', 'Shallow Depth', and 'Clear Grouping' and continuously refine them, you will certainly create a great service where neither users are lost nor team members are confused.

Do not think of IA as homework that needs to be done all at once. Approach it with the mindset of drawing a blueprint that evolves continually alongside users. Before long, you will become a capable planner, gaining trust not only from users but also from your team members.

[Action Items for Junior Planners]

Create a 'Glossary' right now: Pick 10 frequently mixed words (e.g., user/member, posting/content, register/save) from the project currently in progress and organize them in a Google Sheet. Then share it in the team Slack channel and suggest, "Let’s decide on official terms for our project together!"

Try mini card sorting with colleagues (Invest 1 hour): Write down the core 20 features of the service you are planning on post-its. Then, offer to buy coffee and ask three colleagues (it’s better if they’re from different teams) if they could "group similar items together?" Just comparing how different their grouping is from yours can yield tremendous insights.

Check the '3-Click' of competitor apps: Choose one of the apps you frequently use or a competitor app, define three core goals of the user (e.g., check delivery status, change password, participate in events), and test how many clicks each requires, recording your findings. This process of retracing why it was designed that way will shift your perspective on IA.

manyfast.io