To avoid creating a project plan that angers developers

Avoiding a Proposal That Frustrates Developers

Let me share an experience from my junior days. It was a proposal review session that I had prepared with great ambition. I nervously showed the screen designs (wireframes) that I had diagrammed overnight to my mentor and team leader. "When the user clicks this button, they will move to this screen..." I thought it was a perfect flow, flowing smoothly. However, after explaining for a while, my team leader slightly furrowed her brows, stopped me, and asked.

"M, I appreciate your explanation. But about the 'Payment Completed' popup you just showed us, on which screen does it appear? The product detail page? Or the cart page? And if the user closes that popup using the confirm button, do they go back to the previous screen or to the order history page?"

In that moment, my head went blank. In my mind, it was such an obvious flow that I had just thrown in a single box labeled in the IA (Information Architecture). As my response became vague with "Um... that would probably be...", questions started pouring out as if they had been waiting for me to hesitate.

"Why is this screen labeled 'My Info' at the front of the proposal but 'My Page' in the wireframe at the back? They are the same screen, right?"

"What does this list look like when there are no search results? Is it just an empty screen?"

I thought I had drawn every screen perfectly, but the design about how these screens connect to each other, the rules they follow, and what exceptions they have was completely messed up. The meeting that day resulted in directions to reorganize the proposal from the beginning and encouragement from my team leader and mentor (which included the team leader scolding my mentor with, "What were you doing while this person is like this?" and my mentor's grilling with, "What on earth are you relying on to work like this?"). I returned to my place, sighed, and thought, 'I am such a fool. Why couldn’t I think of these things?'

Many junior planners may have had similar experiences. Often they think of IA as just a menu list or a sitemap, only to realize they incur exorbitant communication costs when development and design begin. Today, I want to share some concrete and practical tips on how a bad IA can lead the entire team into the abyss of overtime, and how to create an 'IA for communication' that ensures everyone's happiness.

1. "My Page? My Info? Profile?" A Simple Naming Mistake Creates Hell

The most common and easiest mistake is naming things arbitrarily. Depending on the mood during planning, or just intuitively, one screen can be called My Page, while another specification document might call it My Info. It could have been an assumption that "everyone understands it," or simply a missed thought.

But developers and designers are not mind-readers who can decipher the planner’s intention. To them, 'My Page' and 'My Info' can represent entirely different screens with completely different data structures or components. Below is a hypothetical situation, but one that occurs very often.

Designer: "M, I’m sending you the design mockup for the 'Edit My Info' screen you requested. Once you hit the complete button, we've linked it to the 'Profile' screen as you mentioned!"

Me (PM): "Ah, thank you for your hard work! But after completion, please redirect to 'My Page' instead of 'Profile'."

Designer: "Huh? Oh... yes, understood. I'll modify the navigation structure and send it over to you."

(A little later, a developer sends a message via Slack)

Developer: "M, looking at the design mockup, after completion it goes to 'My Page', but the planning document I received said it goes to 'My Info' screen, so I've set the API integration that way. Aren't 'My Page', 'My Info', and 'Profile' all different screens? Which is correct?"

Can we calculate the costs that arose from this minor inconsistency? The designer had to revise the flow of the prototype they had already prepared, and the developer had to revisit the routing parts of the well-structured code. What was supposed to take two days ended up taking a full four days, and a subtle atmosphere of distrust flowed among team members with remarks like, "The planning is in chaos again."

This is a significant issue that clearly detracts from the quality of the proposal. To prevent such problems, it is essential to create a 'Terminology Document' early in the project. It doesn’t need to be grand. Just make a simple table on Google Sheets or Notion and define every term used in our project in detail with the team members.

Once the criteria are set, everyone—from the proposal to the layer names in the design guide, to the variable names of the developer—will use the same language. Ambiguous conversations like "Remember that one thing..." will disappear, allowing for precise communication akin to a well-orchestrated orchestra.

2. The Magic of Screen IDs that Prevent Statements Like "Uh... the second button from the left on the third screen"

As the scale of a project increases, the number of screens can grow to dozens or even hundreds. In such cases, describing screens verbally becomes a truly dreadful task. "You know the second tab screen that appears when you click the filter icon in the product list..." At that moment, the person listening is already lost in confusion. It’s like describing: "Turn left at the third-largest intersection in Seoul, where a red brick house is located."

What is needed at this time is a clear addressing system called 'Screen ID'. The rules can vary from team to team, but generally, it is common to logically assign numbers and abbreviations according to the structure of the service.

• Major Categories (Depth 1): HOME, PD(Product), MY(My Page), CS(Customer Service) 

• Subcategories (Depth 2): List(01), Detail(02), Registration(03) 

• Microcategories (Depth 3): Tab(-01), Popup(-PO-01), Bottom Sheet(-BS-01)

By assigning addresses according to these rules, you get the following.

• PD-01: Product List Screen

• PD-02: Product Detail Screen

• PD-02-01: 'Review' tab on the Product Detail Screen

• PD-02-01-PO-01: Popup that appears when the 'Write a Review' button is pressed on the 'Review' tab of the Product Detail Screen

Assigning unique IDs to all screens and major components (popups, bottom sheets, etc.) from the IA phase dramatically improves the quality of collaboration. Let’s see how conversations change on Jira or Slack.

Before: "Hey developer, there’s a popup for writing reviews on the product detail page. There’s a bug where the app crashes if the star rating isn’t selected before submitting."

After: "Hey developer, there’s a crash due to a Null value on the [PD-02-01-PO-01] screen when the star rating isn’t filled. Please check ticket JIRA-247."

The latter method is clear to anyone and makes tracking history easier. There’s no need to waste 30 minutes sending a screenshot and giving additional explanations to the question, "Which screen are you referring to?".

3. Preparing for the Developer's Common Question: "What does it look like when there's no data?"

Planners generally visualize a 'Happy Case' scenario where everything is perfectly filled. The product list is full of wonderful products, and my coupon drawer is filled with usable coupons. However, developers are the ones living on the other side, filled with all kinds of edge cases. They would immediately ask the following questions upon reviewing the planning document:

• "What happens to this list when there's no data? (Empty State)" 

• "What does the screen look like during the 1-2 seconds loading data? (Loading State)" 

• "What do we show the user if the internet suddenly cuts off or there's a server error? (Error State)" 

• "What happens to users who are not logged in when they access this screen? (Authentication State)"

If these state definitions are missing, developers will either handle it however they please (which can lead to bad results) or have to ask the PM again each time. This is a gap in planning and a waste of predictable communication costs. A good IA should not merely be a list of screens, but a comprehensive document that defines 'all possible state values that the screens can have.' When writing the IA, organize the state along with each screen like this.

• PD-01 (Product List Screen) 

- Default State: The product list is displayed in a 2xN grid format.

- Loading State: A skeleton UI in grid format is displayed for 1.5 seconds. 

- No Data State (when no search results are found): A message saying, "Unfortunately, there are no search results," is displayed along with a list of 'popular search terms' at the bottom. 

- Error State: A message saying, "There was a problem with the network and we couldn't fetch the products," is displayed along with a 'Retry' button. Clicking the button will re-call the API. 

- Authentication State (for non-logged-in users): The screen appears normal, but clicking the 'Add to favorites' button displays a toast popup saying, "This feature requires login" and directs the user to the login screen.

What do you think? By defining all possible scenarios in advance, developers can create screens with significantly higher completion without any questions. Most importantly, there’s an added bonus of hearing, "Wow, this PM is really meticulous. It's comfortable to work with them."

In Conclusion: A Proposal is a Tool for Communication, Not an Instruction Manual

We often think of a proposal as a one-way document that explains and communicates the outcomes I created to others. But what if we changed our perspective just a little? A proposal is not just an instruction manual, but a minimum agreement for conversing in a language similar to that of designers and developers, aiming towards a common goal—a tool for communication.

In that sense, IA should not simply be a flat map listing menus, but the most important 'foundation blueprint' for the building our team is constructing together. An IA that contains consistent terminology, clear addresses, and definitions for all possible situations will dramatically reduce countless meetings and unnecessary rework, becoming the most powerful weapon to enable team members to trust each other and focus on the truly vital 'value of the product.'

Action Items for Junior Planners:

Create a Terminology Document Right Now: Pick out 10 words that are commonly mixed up or are in use but you don’t exactly know the meaning of from the ongoing project and organize them in Google Sheets. Then share it in the team’s Slack channel suggesting, "This will be our official language for the project moving forward! Feel free to share your thoughts!" Everyone will welcome it.

Try Adding Screen IDs to My Proposal: Open the most recent proposal you wrote and assign IDs only to the screens that pertain to the core flow of the user (e.g., registration~login~main screen). Then use that ID to explain in the next meeting. You'll notice a change in your teammates' reactions.

Capture Empty Screens of Competitor Apps: Right now, open your phone, and type in a word that no one would search for into the search bars of three apps you frequently use (like 'Lotte Giants 2025 Championship Probability'). Then capture and analyze what screen is shown when there are no search results (Empty State). Check whether they only display a 'no results' message or if they guide to other actions. Just by doing this, the depth of your planning will change. 

manyfast.io