— Week 1 —

Positioning × Toolchain Setup × First Knowledge Base Skeleton

Starting from your first impression of AI output — skipping abstract frameworks to run live prompts first. Log where the AI drifts; these notes form next week's core material.

01
— paradigm shift

From Producer to Curator: The Designer's Role in AI/UX

AI can generate UI, flows, and prototypes — but generation is not design. The designer's core value shifts from crafting polished screens to judging what to keep, what to change, and why. This course does not teach prompt tricks; it turns your design judgment into durable, machine-readable knowledge assets.

Core Thesis
Your existing design assets are the best starting point for a knowledge base. There is no standard answer here, only the right answer for your context. You leave after four weeks with a running operational system, not another slide deck.
02
— tool chain

Toolchain: Antigravity × Pencil × Stitch

The course toolchain divides into three distinct roles: Antigravity Agent handles generation and agent setup, Pencil handles HTML↔Figma assembly and refinement, and Stitch runs AI variant exploration. We complete setup and verification this week.

Antigravity Agent
generation × agent config
AI generation engine + agent configuration. Houses the Week 4 Design Agent. Reads wiki context to produce UI candidates.
Antigravity IDE
development environment
IDE workspace. Manages wiki directory structure, skill sets, design tokens, and agent context configurations.
Pencil
html ↔ figma bridge
Assembles and refines design system components from AI-generated HTML. Two-way HTML → Figma bridge to reach production mockups.
Stitch
ai variant exploration
Platform for Week 2–3 variant exploration across all three paths: prompt→UI, screenshot→UI, and document→UI.
03
— first contact

First Prompt→UI: Establishing a Baseline Impression

Run a full screen with default prompts. The goal is not perfection, but getting a raw impression of AI output: spotting where it drifts, what you would fix, and what trade-offs you notice. These observations become the input for Week 2's knowledge base.

Pedagogical Note: We deliberately hold back UICrit here. Letting learners rely on raw instinct first before benchmarking against UICrit in Week 2 creates a much deeper impression: discovering what your instincts caught versus what they missed builds real judgment faster than memorizing rules upfront.

04
— observation notes

Observation Notes: AI Output vs. What I Would Do

Record three things: (1) what AI generated, (2) what you would change, and (3) why you want to change it. The third point is most critical — it externalizes implicit design judgment into structured context that agents can parse.

Week 1 Deliverables
a.
Verified toolchain environment (Antigravity Agent/IDE + Pencil + Stitch)
b.
Observation notes (observation.md) logging the gap between AI outputs and design judgment
— Week 2 —

UI Audit Standards × First AI Variants

Audit your Week 1 output using Google Research's UICrit, then run the first two AI variant paths in Stitch — measuring how much variance screenshots actually eliminate.

01
— research-based audit

UICrit: From Google Research to Your Audit Standards

UICrit is an open-source dataset published by Google Research at UIST '24 — featuring 3,059 expert critiques across 983 mobile UIs. We filter this into four core dimensions as our audit foundation. We avoid prescriptive guidelines like Material or HIG because we need an evaluative framework (auditing user intent), not a prescriptive one (auditing styling conventions).

dimension 1
Information Architecture
UICrit · Information Architecture
Page hierarchy, grouping logic, and navigation structure that allow users to predict the next step.
hierarchy grouping navigation
dimension 2
Accessibility
UICrit + WCAG 2.2
4.5:1 contrast ratios, focus order, keyboard navigation, screen reader compatibility. Pairing UICrit commentary with WCAG technical benchmarks.
contrast focus screen reader
dimension 3
Progressive Disclosure
UICrit · Progressive Disclosure
Does information density scale with the user's task stage? Dumping all options at once makes AI outputs look superficially complete but practically unusable.
layering defaults complexity
dimension 4
Interface Copy
UICrit · UX Copy
Button labels, error states, and empty state messaging — where AI most frequently outputs "correct but useless" text. Copy requires product context to work, which is why document→UI narrows variance most on this dimension.
labels errors empty states tone
Why Not Material Design
Material Design is prescriptive — it mandates rounded corners and 8px grid spacing. UICrit is evaluative — it asks whether this grouping helps the user complete their task. Auditors need evaluative frameworks to write substantive contradiction reports rather than complaining that something isn't Material style.
02
— audit your own output

Audit Week 1 Output with UICrit

Benchmark your Week 1 observations against UICrit's four dimensions. Where was your intuition right? What did you miss? Filter 10–15 relevant criteria from the UICrit dataset to author audit-criteria.md — the first audit spec in your knowledge base.

Author the product context document (product-context.md) in parallel: product definition, target users, tone of voice, prioritized use cases. Together, these two files form the skeleton of your wiki.

03
— variant path 2

Screenshot→UI: Mobbin × Notion Desktop Reference

Use Notion desktop screenshots downloaded from Mobbin as visual references to run screenshot→UI in Stitch. Observe which dimensions converge and which continue to drift compared to Week 1.

04
— side-by-side comparison

Two Variant Groups Side by Side: Prompt vs. Screenshot

Path 1
Prompt→UI
text prompt only · week 1
Pure text prompts without visual references or product context. AI hallucinates freely. Outputs diverge widely across all dimensions — unstable IA, generic copy, random styling.
Variance Range
Path 2
Screenshot→UI
visual reference · week 2
Adding Notion desktop screenshots anchors the visual layer. Visual layout stabilizes (layout, spacing, component styles match reference), but IA logic and UX copy still drift — because screenshots carry no product context.
Variance Range
Path 3
Document→UI
wiki-assisted · week 3
Completed in Week 3. Feed the wiki (audit-criteria + product-context + decisions) into Antigravity. Context layer stabilizes — yet the right tail persists. Narrowing variance is not eliminating it.
Variance Range
Pedagogical Takeaway
Screenshots narrow visual variance, but contextual variance requires a structured wiki to converge. That is Week 3's core work: not making AI blindly obedient, but writing design judgment into machine-readable formats so output variance falls within your acceptable review threshold.
Week 2 Deliverables
a.
audit-criteria.md: 10–15 audit criteria filtered from UICrit
b.
product-context.md: Structured product context specification
c.
Side-by-side comparison of two AI variant paths (prompt vs. screenshot)
— Week 3 —

Document→UI × Wiki Integration × Design System

The third path: feeding your wiki into AI. Compare all three variant groups side by side to prove that narrowing variance is not eliminating it — then extract a starter design system from top elements.

01
— variant path 3 · the wiki-assisted path

The Third Path: UX Document→UI

Feed the Week 2 wiki (audit-criteria.md + product-context.md) plus course reference HTML files into Antigravity / Stitch. This is the most context-rich path: the AI receives visual references + product context + audit criteria simultaneously.

02
— the variance gradient · lived experience

Auditing Three Variant Groups Side by Side: The Variance Gradient

Place all three outputs side by side and run audits using your UICrit subset. This is the pivotal teaching moment: document→UI outputs show clear convergence (correct IA, aligned tone, working progressive disclosure), but remain imperfect — the right tail still exists.

1
Prompt→UI
week 1 · baseline
Widest variance. Kept as the baseline control group. High divergence across all four dimensions.
2
Screenshot→UI
week 2 · visual ref
Visual layer converges. IA and copy still drift — screenshots contain no underlying context.
3
Document→UI
week 3 · wiki-assisted
Context layer converges. Right tail persists — narrowing variance is not eliminating it.
→
Learner Takeaway
the insight
Hands-on proof: the wiki's value is narrowing variance, not eliminating it. When outputs drift, audit standards catch the flaws.
Managing Variance
Learners produce three distinct curves: prompt (widest), screenshot (middle), and document (narrowest, yet still variable). They don't need lectures warning that outputs drift; they have seen it live. What they need is knowing what to do when drift happens — the two convergence steps below provide the answer.
03
— convergence · design system

From Variants to Design System: Converging Tokens × Components × Patterns

Extract top-performing elements across the three variant sets and assemble a starter design system in Pencil. Focus on three clean layers: Design Tokens (color, typography, spacing), Components (buttons, inputs, cards), and Patterns (navigation, forms, empty states). Log every convergence decision in design decision records.

04
— wiki gap repair

Wiki Gap Repair: Design Decision Records

Side-by-side auditing exposes wiki blind spots: some criteria are too vague ("clear IA" is useless; specify "primary navigation capped at 5 items, secondary items collapsed by default"); some product context was missing (tone stated "professional" but omitted "explain one extra step for novice users"). Patch exposed gaps back into wiki/decisions/.

Design Decision Records (decisions/) are the highest-value wiki assets: they answer why a pattern was chosen over alternatives. In future iterations, agents read not just "use this", but "use this because of X constraint" — enabling sound extrapolation in novel scenarios.

Week 3 Deliverables
a.
Audit comparison report across three AI variant sets (HTML format, evaluated against UICrit subset)
b.
Updated wiki repository (audit-criteria.md + product-context.md + decisions/)
c.
Starter design system (tokens / components / patterns assembled in Pencil)
— Week 4 —

POC Delivery × Design Agent × Showcase

Polish the wiki into a deliverable package. Build your first Design Agent. Complete a full iteration cycle — from feature request to final audit. Showcase one POC archetype.

01
— wiki as deliverable

Wiki Consolidation: From Notes to Deliverables

Four documents form your complete LLM wiki bundle: Product Context (product-context), Audit Criteria (audit-criteria), Design Decisions (decisions), and Design System (design-system tokens + components + patterns). Focus on closed-loop cross-referencing: agents reading any single file can follow links to resolve the other three.

02
— your first design agent

Your First Design Agent: Context × Skill Set

Configure an agent in Antigravity IDE: its context = your wiki, and its skill set = audit criteria + design system tokens refined in Weeks 2–3. This is not a generic bot; it is a specialized Design Agent calibrated directly by your domain judgment.",

03
— full loop

The Full Loop: Feature → Agent → Candidate → Audit

Execute a full closed loop: new feature arrives → agent reads wiki to generate candidates → audit against UICrit criteria → decide to modify artifact, update wiki, or accept trade-off. This concludes the four-week arc: evolving from manual prompt testing in Week 1 to an integrated agent + wiki + audit operating model.

1
Feature Intake
new requirement
A defined scenario requirement serving as input for the POC.
2
Agent Generation
wiki-informed candidate
Design Agent reads wiki context and skill sets to output UI candidates.
3
Audit Judgment
audit × decision
Run audit via UICrit subset. Choose one: modify artifact / update wiki / accept trade-off.
4
Wiki Writeback
close the loop
Log decisions back into the wiki. Knowledge base becomes more complete. Compounding cycle begins.
04
— poc showcase

POC Showcase: Three Archetype Spectrums

Learners pick one POC archetype to present. Deliverable format is HTML (including design system tokens). All three archetypes hold equal standing, addressing distinct organizational roles.

type a
Screen-level Critique
Benchmark: design_review_IC.html
Screen-by-screen design critique. Each screen features UICrit dimension tags, issue diagnosis, and remediation notes. Focuses on craft: palette, spacing, component selection, copy quality.
→ Best for IC Designers
type b
Business-risk Framing
Benchmark: design_review_Manager.html
Framed around commercial and operational risk: "what consequences does this design create, which stakeholders are impacted, and what is remediation cost?" UICrit standards packaged into risk severity matrices.
→ Best for Senior Designers / Leads
type c
Wiki-driven Layer Inspector
Benchmark: layer-inspector.html
Showcases structural mappings between wiki and UI. Layer inspector interface: left pane displays wiki structure (audit-criteria, decisions, tokens), right pane shows corresponding UI components with interactive cross-referencing.
→ Best for Design Engineers / Systems Designers
Week 4 Deliverables (Final)
a.
POC HTML (with embedded design system tokens), chosen from the 3 archetypes
b.
Complete LLM Wiki package (product-context + audit-criteria + decisions + design-system)
c.
Design Agent configuration (context wired to wiki, skill set wired to audit criteria & tokens)
— Teaching Kit —

Teaching Kit × Tools × Reference Examples

Complete inventory of course materials, tools, and reference artifacts. Provided kit assets and learner-prepared prerequisites separated clearly.

01
— course materials

Course Materials Inventory

Material Format Used For Source
UICrit Audit Subset .csv Week 2 · Audit criteria formulation Google Research · UIST '24 (Curated)
Notion Desktop Reference Screens Images Week 2 · Screenshot→UI Mobbin exports
V4 Course HTML C1–C3 .html Week 3 · Document→UI reference layer Course curriculum
design_review_IC .html Week 4 · POC Archetype A BitePal Settings Design Review
design_review_Manager .html Week 4 · POC Archetype B BitePal Business Risk Framing
layer-inspector .html Week 4 · POC Archetype C Design Wiki POC v3
02
— tool chain

Toolchain Overview

Tool Role Active Weeks
Antigravity Agent AI generation engine + Design Agent configuration W1–W4 (All)
Antigravity IDE Workspace · wiki management · skill set · agent context W1–W4 (All)
Pencil HTML↔Figma bridge · design system assembly and refinement W3–W4
Stitch AI variant exploration (prompt / screenshot / document→UI) W1–W3
03
— deliverable timeline

Weekly Deliverables Timeline

Week Deliverable Format
W1 Tool environment verification + observation notes observation.md
W2 Wiki skeleton + two-group AI variant comparison audit-criteria.md + product-context.md
W3 Three-group audit report + updated wiki + starter design system HTML report + markdown wiki + Pencil assembly
W4 POC HTML + complete LLM wiki package + Design Agent configuration HTML (with design tokens) + full wiki bundle
04
— core thesis

Core Course Theses

The Variance Gradient
Three paths (prompt→UI, screenshot→UI, document→UI) establish a variance gradient. A knowledge base does not eliminate variance; it narrows variance into a manageable review range. Learners validating this live in Weeks 2–3 is the load-bearing pillar of the course.
Evaluative > Prescriptive
UICrit + WCAG are evaluative frameworks — they ask "does this design help users complete tasks?", not "does this follow a specific company's UI guide?". Designer audit criteria should rest on empirical research rather than vendor style dogma.
Wiki as Interface
The wiki is not static human documentation — it is the interface between human designer and AI agent. Product context, audit criteria, design decisions, and tokens cross-reference to give agents complete situational awareness. Wiki is the interface; Agent is the worker.