DB Design: The Backside of UX ✦ No-Code DB Design #1

Hi, I’m Jian from ARCOA. 👋

Designing an app as a designer isn’t just about crafting beautiful screens. It’s about understanding how information flows — how data is stored, retrieved, and connected across the product.

I used to think DB design was solely a developer’s job. But building no-code apps myself completely changed that perspective.

DB design is the backside of UX design. 
Without understanding where data goes and how it returns, you can’t fully design the user experience.

This series shares how a non-developer designer approaches data thinking and practical DB modeling in no-code environments.

1. Why I Designed the DB Myself

When I first got into FlutterFlow and Firebase, I asked myself: “How much of the backend should a designer really know?” It turns out — quite a lot.

No code feels “easy” at first, but an app simply doesn’t work unless the data structure comes first.

A login button needs a user schema.
A results screen needs a log model.
A list view needs a collection to bind.
As a UX designer, I couldn’t ignore the data layer anymore.

In no-code, design decisions literally shape data structures.

 

2. Data Defines the Product’s World

For an app to behave consistently, you need two complementary types of data:

Static Data
The product’s rulebook — categories, scoring rules, configurations, constants.
These rarely change and define how the world of the app works.

Dynamic Data
User profiles, logs, records — the living traces of user behavior.
The two together make an app feel alive.

Static data builds the world.
Dynamic data tells the user’s story inside it.

🔍 Quick Example

Static data = category list, option list, calculation rules
Dynamic data = today’s logs, selections, or behaviors the user created

Keeping these clearly separated is essential for a stable no-code product.

3. In No-Code, DB Comes Before Screens

FlutterFlow looks like a visual UI builder, but every widget, action, and flow relies on Firestore collections and fields.

No schema → no bindings → no working screen.

Before drawing a single UI component, I spent days opening spreadsheets, naming fields, and mapping relationships. It felt less like drawing wireframes and more like creating a data-based UX flowchart.

 

🔍 Small Example

A single “Save” button requires:
(user_id → content → timestamp)
These fields must exist before you can bind them in FlutterFlow.

 

4. Data Became a New Language for Design

DB design turned out to be more than a technical task.

It is:

• translating the user journey into data structures
• giving shape to the emotional flow of the UI
• expressing user behavior through fields, values, and logs

It is absolutely a form of design work — just expressed in a different language.

Data is a designer’s new language for building depth in a product.

 

 

✦ Designer’s Summary

You can't design the experience if you don't understand the data.
Database design is the invisible structure behind UX.

🔗 Series — Designer’s No-Code DB Design

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

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