When applying data structure planning for the first time, we have organized the structures, screens, and priorities that are often encountered for non-majors. We have organized key standards, common mistakes, inspection points, and next actions in one place so that you can directly attach them to the actual planning and execution flow, so apply them right away.
Data structure planning is the main topic of this guide. If you are applying Data structure planning in a real project, start with the structure and checks below.
This article is organized based on the points that often get stuck when attaching data structure planning to actual work flow.
It is safer to check the current environment and official documents before actual application.
When non-majors talk about planning, they often suddenly feel burdened by the term data structure. This is because when words like database, table, and relationship come up, it feels like developer territory. However, you don’t necessarily need to know SQL when planning an app. The important thing is not to know a lot of technical terms, but to be able to think about what information should be stored in this service.
The easiest way to understand data structures
It’s much easier if you think of an Excel table. If there is member information, there will be fields such as name, email, and registration date. If there is a post, there will be fields such as title, content, author, and date of creation. In the end, data structure is more about organizing “what becomes a line and what items become columns.” Even with this sense, app planning is fully possible.
The first thing to distinguish between stored information and briefly visible information
Something beginners often miss is thinking that they need to save every screen element. But in reality, that’s not the case. Anything that will be needed again later, such as user-entered text, member information, and order information, must be saved. On the other hand, there are many cases where it is not necessary to save results or sorting status that are currently calculated and briefly displayed. Knowing this difference can help you reduce unnecessarily heavy designs.
If the data is distorted, the screen is also distorted.
Apps become complex because they often contain more data than the screen itself. For example, if user and administrator rights are different, but the information structure is lumped together, or if the relationship between posts and comments is not thought out in advance, editing becomes more difficult the later functions are added. So, at the planning stage, it is very helpful to first write down “What information is there, who creates it, who sees it, and when will it change?”
Starting with one ticket is enough
When first thinking about data structure, it is a good idea to draw a table for each service. First, divide only the large units such as the membership table, text table, and order table, and write only the essential items in each table. If you do this, you can ask the AI more accurately, such as “Please consider user information and order information separately.” Even without complex database knowledge, you can develop a sense of how to see chunks of information that need to be stored.
What non-majors need is not a perfect design, but questions
You don’t have to try to create the right answer from scratch. Instead, it would be a good idea to just ask the questions below.
-What information must be stored in this service?
-What information varies from user to user?
- Is there information that only administrators can see?
- What information is most likely to be modified or deleted?
As you answer these questions, you will gradually get a feel for the data structure. In the Vibe Coding era, AI can help implement technology, but ultimately, people must decide what information to handle. In the next article, we will continue to look at which automation functions should be included and to what extent in this organized structure.
Rather than feeling like data structures are scary, it’s much easier to think of them as a list of ingredients for a service. Just as a dish becomes blurry when ingredients are mixed, the screen and functions also fluctuate when data is mixed.
As an easy example,
For example, if you are creating an order management tool, think of it like Excel. The order table contains the orderer’s name, menu, quantity, and status, and the member table contains name and contact information. Just organizing what information is in one line and what columns are needed is enough to get a sense of data structure.
Quick checklist for Data structure planning
Use this checklist before you apply Data structure planning in an actual post or product flow.
- Is the first action obvious as soon as the user lands on the page?
- Are intermediate steps simple enough that buttons and explanations do not overlap?
- Does the result naturally lead to a next action instead of a dead end?
- Could you explain the structure again later without adding unnecessary screens?
Related posts
- AI plan: How to write a plan that works well for AI
- Automation function planning: How much automation should be included?
Things to verify before you apply it
- Tool UI and function configuration may vary depending on the time, so it is safer to check again based on the current version.
- Although this may work well for small examples, in projects with large existing code bases, the scope of modifications can quickly become large if the structure is not broken down first.
