Turning My Workspace Into Data: An AI-Driven Practice of UI-Data Separation

9 0 0

Why I Built This Page

My desk has a Mac mini, a MacBook Pro, a NAS, a router, a couple of keyboards and mice. On the software side: VS Code, Obsidian, Claude Code, Codex, WorkBuddy AI, Gitea—more than twenty items in total.

These tools will be replaced. The M5 Pro will become the M6. The 256GB iPhone will become 512GB. Codex will iterate its version number. Someday a piece of software will simply stop being updated. But one thing won’t change: I need a record—telling myself (and telling AI) what I use, why I use it, and how.

So I built [My Workspace](https://www.icsteve.com/misc/index.html), a page that organizes all my hardware and software into a structured, searchable, AI-readable document.

Using DESIGN.md to Give AI “Design Taste”

When building this page, I hit a very practical problem: I knew what content I wanted, but I’m not a front-end designer. Layout, color, spacing, typography hierarchy—these things are faster to delegate to AI, but AI needs a design spec it can actually read.

That’s the value of [Refero Styles](https://styles.refero.design/). This site catalogs 2,000+ design systems from leading product websites, each accompanied by an AI-readable DESIGN.md file—containing colors, typography, spacing, and component specs that can be fed directly into Cursor, Claude Code, Codex, and other AI coding tools.

My approach: I found a design system called “Dimension” on Refero, grabbed its DESIGN.md, and used it as the design context for AI. Then, across multiple rounds of dialogue, I told the AI: “I want a workspace showcase page with a tool list on the left, a detail panel on the right, and support for bilingual EN/ZH switching.” The AI, armed with the color, typography, and component specs from DESIGN.md, built the page step by step.

I wasn’t writing CSS. The AI was, after understanding the design language.

Multi-Round Dialogue, Incremental Sedimentation

The actual process wasn’t a single prompt. It took several rounds of refinement:

Round one produced the basic framework, but the colors were too dark and the detail panel’s hierarchy was unclear.
Round two adjusted color contrast, card corner radius, and added gradient backgrounds.
Round three realized the data should be externalized—instead of hardcoding 26 tools’ details in the HTML, put them in a separate `data.json`.
Round four added bilingual support, with `lang.en` and `lang.zh` content for every entry.
Round five introduced an SVG icon system, with each tool getting its own brand-color gradient.

Each round wasn’t a rewrite—it was an incremental modification on top of the previous version. The content “sedimented” through dialogue, going from a vague idea to a concrete, deliverable structured document.

Architecture: UI and data.json, Separated

The final architecture is remarkably simple:

`index.html` — pure UI: layout, styles, interaction logic
`data.json` — pure data: 26 tools’ names, specs, descriptions, tags, icons

On page load, `index.html` fetches `data.json` and dynamically renders the list and detail panel. The two are fully decoupled.

This separation seems trivial, but it solves a very real problem: changing data doesn’t require touching UI; changing UI doesn’t affect data.

More critically: an AI agent only needs to read `data.json` to know what devices I use, what software I run, and what each item’s specifications are. It doesn’t need to parse HTML, understand CSS selectors, or dig through the DOM tree. One JSON file, all the information within.

Data Outlives Hardware

The Mac mini M6 will eventually become the M7. The iPhone 16 Pro Max will become the 17. Codex will switch to a new model generation.

But the record in this `data.json`—what I used in September 2026, what the configuration was, why I chose it—this snapshot doesn’t change. It’s a timestamp.

Six months from now, when I upgrade a device, I just update a few fields in `data.json`. Old data becomes history; new data layers on top. This file becomes my “tech equipment chronicle”—a machine-readable personal technology archive.

If an AI agent needs to understand my work environment—to recommend software compatible with my hardware, to assess whether a tool fits my workflow, or to remind me that a device’s warranty is about to expire—it just reads this JSON.

The AI Agent Perspective: Read Data, Not UI

This is the most forward-looking aspect of the entire design.

The traditional approach is to cram all information into HTML, where both humans and AI have to scrape content from a forest of tags. Now, UI is for humans; data.json is for AI. Each gets what it needs.

The structure of each entry in `data.json` is clear:

{
  "id": "macbook-pro",
  "category": "hardware",
  "number": "02",
  "lang": {
    "en": { "name": "MacBook Pro 14\"", "specs": [...] },
    "zh": { "name": "MacBook Pro 14\"", "specs": [...] }
  }
}

Any AI agent—Claude, ChatGPT, or whatever model comes next—can immediately understand: this is a hardware device, numbered 02, called MacBook Pro 14″, with the following specs. No web scraping, no OCR, no DOM parsing.

This is “AI-first” content architecture: not building for humans first and adapting for AI later, but designing two interfaces from the start—one for each type of “reader.”

Closing Thought

This page isn’t a complex project. One HTML file, one JSON, a design system reference, and a handful of conversations.

But its significance lies in this: turning personal technology assets from “fuzzy memories in the brain” into “structured data on disk.” Data outlives devices. Data outlasts version numbers. Data is more reliable than memory. And when you make your data AI-readable, you’re not just recording the past—you’re paving the way for future AI collaboration.

Next time your toolchain changes, try this: don’t just post about it. Save the data.

# Thoughts