Design Studio

Design Studio turns an interface challenge into a durable local project: three rendered concepts, a reusable style guide, component behavior, responsive layout choices, a runnable source-and-proof kit, and a static check of implementation source.

What it is#

Every project follows seven stages: Describe → Concepts → Style guide → Components → Layouts → Implementation → Build check. The stage engines and implementation compiler are deterministic local computations, so regenerating from the same inputs does not depend on a network model call. The Ask Drew handoff is separate: it sends a compact project summary into a Drew conversation through your configured model route.

The populated home is intentionally work-first. It lists saved projects, progress, QA runs, and ready-to-build status; the introductory hero appears only before the first project exists.

Describe the challenge#

Start with the screen or surface, who uses it, their primary task, and the tension the design must resolve. Optional controls capture tone, a seed colour, light or dark mode, density, and radius preference. Those choices are inputs to later stages, not decorative metadata.

Compare concepts#

The concepts stage produces three distinct directions with a name, thesis, colour palette, type pairing, density, shape, and motion approach. Each card now renders a small interface specimen using those values, so you can compare more than prose and swatches.

One direction may be recommended, but nothing advances until you choose a concept. Its typography, density, radius language, and primary colour flow into the style-guide generator.

Build a style guide#

The style guide turns the selected concept into tokens for semantic colours, display/body/mono type, a type ramp, spacing, radius, and motion. A live specimen renders controls, focus, hover, text, and raised surfaces from the generated values. You can copy the generated CSS token block for implementation.

Specify component states#

Name a component and its behavior—such as an asynchronous primary action, a destructive dialog, or a search field. The Studio returns a prioritized state matrix and renders small examples using the project’s style tokens. Multiple matrices remain selectable inside the same project.

The matrix focuses on behavior a developer needs to implement: focus, hover, loading or pending, invalid/error, disabled, confirmation, success, retry, undo, and recovery where relevant. The matrix is a specification; the later compiler can render it into a fixed prototype, but it does not become a framework-specific component library.

Plan responsive layouts#

After at least one component matrix exists, choose content type, maximum width, navigation approach, and small-screen priority. The Studio renders three layout strategies as desktop, tablet, and mobile wireframes. Select one to record the intended navigation and content-priority changes across breakpoints.

These are structural wireframes. They demonstrate hierarchy and adaptation; they are not high-fidelity prototypes and do not simulate production interactions.

Compile an implementation#

The Implementation stage compiles the structured project contract into a host-authored static prototype and portable build kit. It consumes the selected concept, semantic tokens, P0 component states, and responsive strategy—not pasted HTML, CSS, or JavaScript—and it makes no model or network call. If one of those four decisions is missing, the workbench names the blocker and keeps export and Plugin Studio handoff disabled. A generic audience or body-text contrast below 4.5:1 is reported as a warning.

The workbench runs the fixed generated prototype in an opaque iframe sandbox with scripts allowed but no same-origin access, host capabilities, or network connection. Stress controls let you inspect desktop, tablet, and mobile widths; default, hover, focus, loading, error, success, and disabled states; default, long, and empty content; and English or pseudo-localized copy. You can also inspect the decision trace, build graph, contract checks, and exact generated files.

A ready compilation contains index.html, style.css, app.js, token exports for CSS, JSON, and TypeScript, the normalized design contract, a README, a zero-capability plugin manifest, and a generated TypeScript contract test. The downloaded ZIP adds build-manifest.json; its SHA-256 fingerprint and per-file hashes bind the artifacts to the decisions that produced them. Changing the brief, selected concept, style system, component states, or responsive choice invalidates the old compilation and Build check.

Check implementation source#

Paste markup/component source and styles, or choose local source files under 2 MB. The markup side accepts HTML, JSX/TSX, Vue, Svelte, and SwiftUI-shaped source; the style side accepts CSS/SCSS/Sass/Less and JavaScript or TypeScript style sources.

The deterministic check scores evidence for:

• semantic structure and accessible names;
• keyboard and visible-focus treatment;
• important interaction states;
• responsive/reflow rules;
• reduced-motion handling; and
• drift from the project’s expected colour tokens.

Findings include severity, source evidence, suggested fixes, and line numbers when available. A high score means the supplied source passed these checks—not that the running interface is accessible.

Export & hand off#

The top-bar Export downloads the complete saved project as JSON. Copy CSS copies the generated style-guide CSS. A ready Implementation can also download its runnable source-and-proof kit as <project>-implementation.zip. Ask Drew returns to chat with the local project ID, current progress, selected concept, system name, source-check score, and open findings already summarized.

Open in Plugin Studio creates a draft from the generated index.html, style.css, and app.js. The seed requests no capabilities or network origins. It is not installed or published: Plugin Studio still runs its canonical preflight and requires review before any explicit install and enablement steps.

What it does not do#

• No Figma import, export, or live integration.
• No freeform vector canvas, screenshot analysis, or image asset generation.
• No automatic repository scan, repository write, or framework-specific production integration.
• The generated kit is a bounded static prototype and contract handoff, not a finished production application.
• No guarantee that a concept, token set, compiler check, or Build check score is correct for your users.