
Product Designer @clickhouse
New York, USA
Joined March 2007
- Tweets1.7K
- Following1.4K
- Followers569
- Likes2.7K
James Burke retweeted
Designers, skipping the data model is becoming harder to defend.
Pretty UI can’t fix confused data.
If the system does not know what something means, the interface will struggle to explain it.
If the product cannot show where a claim came from, trust breaks.
If everything is treated as equally true, uncertainty gets hidden instead of designed.
AI tools make this easier to miss.
You open Lovable, Bolt, Replit, Claude Code or another builder.
Suddenly there is an app.
Then a login flow.
Then a database.
Now you are deciding:
- What should be saved?
- What belongs together?
- What can change?
- What can be inferred?
- What the product is allowed to trust?
You may not call that data modeling.
But that is what it is.
I’m starting a series called Data for Designers because I keep running into this while building Cartewei, a menu intelligence project around NYC restaurants.
At first, it looked like a scraping problem.
Find the menu.
Parse the PDF.
Extract the dishes.
Capture the prices.
But the deeper problem is meaning.
Is this menu current?
Is this dish the same as last month?
Can this price be trusted?
What source did this claim come from?
You’re not just designing screens.
You’re designing what the system understands.
Strong design starts with a strong model of the world.
You don’t need to be a database engineer.
Just care enough to ask what the data means.
Designers, skipping the data model is becoming harder to defend.
Pretty UI can’t fix confused data.
If the system does not know what something means, the interface will struggle to explain it.
If the product cannot show where a claim came from, trust breaks.
If everything is treated as equally true, uncertainty gets hidden instead of designed.
AI tools make this easier to miss.
You open Lovable, Bolt, Replit, Claude Code or another builder.
Suddenly there is an app.
Then a login flow.
Then a database.
Now you are deciding:
- What should be saved?
- What belongs together?
- What can change?
- What can be inferred?
- What the product is allowed to trust?
You may not call that data modeling.
But that is what it is.
I’m starting a series called Data for Designers because I keep running into this while building Cartewei, a menu intelligence project around NYC restaurants.
At first, it looked like a scraping problem.
Find the menu.
Parse the PDF.
Extract the dishes.
Capture the prices.
But the deeper problem is meaning.
Is this menu current?
Is this dish the same as last month?
Can this price be trusted?
What source did this claim come from?
You’re not just designing screens.
You’re designing what the system understands.
Strong design starts with a strong model of the world.
You don’t need to be a database engineer.
Just care enough to ask what the data means.
My teammate at last week's hackathon wasn't human.
At the Self-Improving Agent Hack at Datadog (packed event in the same Midtown building as the NYT), I sat down next to Stephen. He introduced his engineer: an OpenClaw bot named Sven.
My favorite part: the landing page. I built a pipeline generating AI character portraits → video of authors with books, all on white backgrounds using @floraai
Testing @conductor_build this weekend. I immediately am appreciating not staring at multiple instance of Claude code that feel janky inside Cursor or VS Code.
Cool Spotify x Github mashup by @graphite. Get your year in code. year-in-code.com/user/lifesi…
I save so much time since moving brand ideation into Flora.
▸ Drag in refs, prompt + remix into new concept images
▸ Take stills ➜ video in a click for ads or screen animation very helpful in quickly exploring brand expression.


