Prox OS Design Operating System
Prox OS is not a Figma-first SaaS project. It is a text-first, system-first,
Position
Prox OS is not a Figma-first SaaS project. It is a text-first, system-first, AI-native, craft-aware operating system for solo founders, community software, personal data, and future AI agents.
This does not mean "no design" and it does not mean "no designers." It means the design source of truth must be readable, runnable, reviewable, and connected to the product system. Static mockups can help, but they should not become the primary operating layer for a browser OS, app registry, agent workflow, and platform roadmap that change through code, docs, and AI-assisted iteration.
Operating Principles
| Principle | Meaning | Practical rule |
|---|---|---|
| Text-first | Product intent, constraints, status, and acceptance are written before visual polish. | Start from docs, prompts, task graphs, and app narratives before opening a blank canvas. |
| System-first | Design work should strengthen tokens, components, app contracts, Storybook, and roadmap. | A UI decision should become a reusable rule when it repeats. |
| AI-native | Prompts, specs, examples, screenshots, and reviews are part of the design workflow. | Make design context explicit so AI tools can assist safely. |
| Craft-aware | Specialist craft still matters for brand, motion, illustration, deck polish, UX research, and complex prototypes. | Bring specialists into clear artifacts, not vague tool rituals. |
Source Of Truth Layers
| Layer | Source of truth | Used for |
|---|---|---|
| Product truth | Docs, roadmap, app narratives, user stories, acceptance criteria | What should exist, why it matters, what is out of scope. |
| Design truth | Design principles, tokens, component anatomy, layout grammar | How Prox OS should feel and behave across surfaces. |
| UI truth | Storybook stories, real React components, visual references | Implemented component communication and regression review. |
| Delivery truth | Code, app registry, routes, release notes | What actually ships in the OS runtime. |
| External asset truth | Canva exports, launch images, decks, social media assets | How the story is presented outside the runtime. |
| Specialist draft truth | Figma files and prototypes when specialist design work requires them | Complex flows, high-fidelity prototypes, or designer collaboration. |
Tool Doctrine
Canva Pro
Canva is for selling the story, not defining the runtime UI.
Use Canva for:
- launch imagery;
- social cards;
- pitch deck polish;
- website hero mockups;
- app store screenshots;
- badges and simple brand assets;
- founder-facing marketing visuals.
Canva-derived decisions should be translated back into docs, tokens, component rules, or launch asset inventories when they become reusable.
Figma
Figma can be a specialist workspace, not the default operating system.
Do not default to Figma when:
- the project is still in solo founder or tiny-team mode;
- React, Storybook, tokens, and screenshots are faster than static mockups;
- the surface is a docs app, pricing app, Hola app, Join Us app, or other page that can be iterated directly in code;
- there is no formal designer review loop;
- a mockup would slow delivery without becoming a code-facing source of truth.
Use Figma when:
- a professional brand system needs exploration;
- a complex interaction prototype is required before implementation;
- a multi-screen or mobile flow needs review;
- a paid product designer is collaborating;
- usability review needs high-fidelity artifacts;
- design system variables and tokens need specialist exploration.
Figma deliverables should be converted into design rationale, token changes, component rules, Storybook examples, and implementation notes.
Storybook
Storybook is the UI truth layer once a component or pattern exists.
Use Storybook for:
- real component communication;
- visual regression references;
- implemented design review;
- app state showcases;
- component anatomy;
- token validation;
- contributor onboarding.
Important UI patterns should eventually include stories for default, loading, empty, error, dense, responsive, and edge states when those states apply.
Markdown And Deck-As-Code
Markdown decks keep narrative close to product docs. See deck-as-code.md and ../decks/deck-workflow.md.
Screenshots And Visual Regression
Visual review should connect real routes, Storybook stories, screenshots, and design docs. The first baseline lives in visual-regression-baseline.md.
Prompt-Driven Design System
Prompt-driven design becomes chaos when prompts are private, unscoped, and not translated back into the repository. Prox OS should treat prompts as an input format, not as the final source of truth.
The desired loop:
Founder intent
-> distilled docs / design brief
-> tokens / component rules / Storybook states
-> real UI
-> screenshots / visual review
-> release notes / roadmap statusThe repository should preserve distilled decisions, not raw prompt streams.