Static Data: The Product’s Rulebook ✦ No-Code DB Design #2

Hi, I’m Jian from ARCOA. 👋

In my previous post (Part 1), I discussed why designers need to understand databases and how to take the first steps in DB design. Now, it's time to build the actual skeleton of the application.

When people think of "databases," they often imagine user-generated content like profiles or chat logs—what we call "Dynamic Data." But before that data can exist, we need to build the playground where it lives. This is "Static Data."

1. What is Static Data?

Imagine your app is a board game. If the Users are the players and their input is the game pieces, then Static Data is the rulebook and the board itself.

• Dynamic Data: Data that constantly changes and accumulates (e.g., User Names, Chat Logs, Purchase History).

• Static Data: Unchanging data that defines the service's logic and standards (e.g., Category Lists, Membership Tiers, Scoring Logic).

In No-Code development, how robustly you design this static data determines whether your app can withstand complexity later on without collapsing.

2. Structuring: Breaking Down Categories and Logic

Let’s use a general "Card Recommendation" or "Benefit Provision" service as an example. As a designer transitioning to a builder, I structured the sheets (tables) like this:

• Category: The classification criteria (e.g., Food, Shopping, Transport).

• Benefit: The actual value provided (e.g., Discount rates, Reward points).

• Card: The entity that contains these benefits.

• Score_Logic: The rules for calculating points based on specific behaviors.

From UI Text to Data References As designers, we often treat categories like "Shopping" as static text layers in Figma. However, from a developer's perspective, these must be treated as References.

Instead of hard-coding the word "Shopping" everywhere, you reference the Shopping row from the Category table. This way, if you later decide to change "Shopping" to "E-Commerce," updating that single data point reflects the change across the entire app instantly.

3. Relationships: The Foundation of Automation

The most exciting part of designing static data is defining the Relationships.

• Category Structure: How do we design the hierarchy (Parent > Child > Sub-child)?

• Automated Combinations: If a Card belongs to Category A and has Grade B, can we automatically display Benefit C?

When these relationships are well-defined, the system handles the complexity. The operator simply inputs data, and the system determines, "This card belongs to the Shopping category, so I will apply the Shopping scoring logic."

"Clear static data reduces operational ambiguity."

 

4. Naming & Type Consistency: Applying Design System Habits

Just as we establish naming conventions in Figma like Primary/Btn/Large, consistency is vital for DB Field Names and Types.

• Naming: If you used category_name in one table, don't switch to img_text in another. Stick to a pattern like product_name.

• Type Consistency: If a field is for calculation, it must be a Number type. If you accidentally set it as Text, you might end up with a disaster where "10 + 10" becomes "1010".

This process is surprisingly similar to building a Design System. "Static data is the language that constructs the app's world." If the grammar is wrong, communication fails. If the data type is wrong, the logic breaks.

5. Conclusion: An Unshakeable Promise

Designing static data taught me one crucial lesson:

"Static data is an unshakeable promise. It is the language that constitutes the logic and trust of the app."

User data flows like water, constantly changing. Static data is the dam that channels that flow. Building a sturdy dam is the first real step in No-Code development.

In Part 3, I will discuss "Dynamic Data"—how we record and manage the traces users leave behind on top of this solid foundation.

✦ Designer’s Summary

If UI needs a design system,
product logic needs static data.

🔗 Series — Designer’s No-Code DB Design

Part 1 — DB Design: The Backside of UX
Part 2 — Static Data: The Product’s Rulebook (This post)
Part 3 — Dynamic Data: Designing User Footprints (Next)

Part 4 — Firestore Mapping: Connecting Static and Dynamic Data(Next)
Part 5 — Speaking in Data: A Designer’s Guide to Metrics & Insights