Firestore Mapping: Building Your Product's Neural Network ✦ No-Code DB Design #4

Hi, I'm Jian from ARCOA. 👋 

In Part 1, Part 2, and Part 3, we explored why database design matters, how static data builds the product's rulebook, and how dynamic data captures user behavior.

Now it's time to bring both worlds to life — by mapping them into Firestore structure.

Your spreadsheet is just a blueprint.  
Firestore is where that blueprint becomes your product's neural network.

1. Firestore Mapping: From Spreadsheet to Structure

Designers naturally organize data in spreadsheets — rows, columns, simple tables. But Firestore doesn't work like Excel. It's hierarchical, not flat.

To move from spreadsheet to Firestore, you need to understand the basic mapping rules — and then design relationships on top of them.

⭐ The Simplest Mapping Rules

Spreadsheet	Firestore
Sheet	collection
Row	document
Column	field
Repeating values	subcollection

That's it.

If you understand these four concepts, you can design an entire Firestore structure as a designer.

2. Field Type Mapping: Watch Out for These

Firestore is flexible — but strict about types. When using FlutterFlow, type mismatches are the most common source of errors.

Here are the real-world mistakes I encountered most often:

Array (List) — Why Use Semicolon (;)?

• coffee;bakery;convenience

Excel doesn't have an "array" concept. So you need to combine multiple values into one cell using semicolons.

FlutterFlow's Content Manager or CSV Importer will automatically convert this into an Array type.

Boolean — true/false Only (No Capitals)

• TRUE × 
• True × 
• true ○

The #1 mistake designers make.
Boolean values must be lowercase. Remember: `true` or `false`.


Null Values — Leave the Cell Empty

• "-" 
• "null" 
• "N/A"

All of the above are treated as strings, not null.
To input a real null value, leave the cell blank.

Timestamp — Auto-Recognized

• 2025-11-28 
• 2025-11-28 23:00:00

Both formats are converted to Timestamp automatically.
No need to manually format — Firestore handles it.

3. Firestore Structure Design: Building the Neural Network

Firestore isn't just a place to store data. It's the central nervous system connecting global state, pages, and user actions.

I recommend designing your Firestore structure in three layers:

Global Collections (App-Wide Reference Data)

Static data that applies equally to all users

• category_master 
• card_master 
• emotion_master 
• score_logic 
• settings

User Root Collections (Per-User Data)

Stores basic user info + custom user-specific data

• users/{uid} 

Example:

• users/{uid}/cards/{card_id} 
• users/{uid}/history/{log_id} 
• users/{uid}/requests/{req_id}

Mixed Collections (Global + User-Based Data)

Generates lots of data, but easier to integrate with third-party analytics tools than splitting by user

• search_log 
• action_log 
• recommend_snapshot

4. ID Design Philosophy: Why LOG_ / REQ_ / ACT_?

In Firestore, Document IDs aren't just "identifiers." They're navigation keys for finding data. That's why Document IDs should be short and clear.

• LOG_20251120_001
• REQ_20251120_CARD
• ACT_CLICK_FILTER_M

This naming convention enables:

• Faster search speed
• Faster debugging during development
• Faster data comprehension for non-developers
• Tool consistency (Excel ⇄ FlutterFlow ⇄ Firebase)

5. Subcollection Structure Example: Why Firestore is Powerful

The moment designers understand subcollections is usually when they fall in love with Firestore.

• users/{uid}/cards/{card_id}

• users/{uid}/requests/{req_id}

• users/{uid}/history/{log_id}

User-specific cards, history, and requests are automatically organized like a folder structure.

This means:

• Clear data separation per user

• Clear analysis units

• Clear relationship structure

• High scalability

Static and dynamic data are organized in Firestore in a way that's visually intuitive.

✦ Designer's Summary

If static data built the world, 
Firestore is the neural network that brings it to life.

🔗 Series — Designer's No-Code DB Design

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

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