Muse Spark Model Taste

Turning design judgment into model behavior.

I want creators to change what AI makes without losing what already works. Model Taste turns that expectation into criteria for evaluating and improving model behavior.

I led Model Taste for Muse Spark across Web UI, gaming, and 3D, owning design-quality evaluation and the post-training pipeline. My scope also covered data curation, labeling, and delivery standards. Researchers developed the underlying model.

5–10 minute walkthrough · Prompts, creator workflows, and model improvement across games, web, and multimodal visual coding.

Focus: Model-output quality, evaluation, post-training
Product: Muse Code · Muse Spark
Role: Design Lead [DRI] for Model Taste — Muse Spark
Responsibilities: Model UX, design-quality evaluation, post-training pipeline, data curation strategy, labeling standards, and engineering/vendor quality across Web UI, Gaming, and 3D
Source: Muse Code · Official product context

Muse Spark for Muse Code — building and previewing a cinematic website

An A/B winner isn’t a
design-quality verdict.

My direction for Model Taste: define what a good experience needs to do, then evaluate the result against that context.

A preference vote tells us which option someone favors. The oracle connects that judgment to six design criteria, working behavior, and evidence from use.

Why this goes beyond A/B

Choose a scenario

Follow the improvement loop

Play all eight steps, or select a step to explore its decision.

After the loop · Revised example

Try the result

Ready to exploreTry the result, or play its improvement loop.

Why this step matters

Inspect the oracle

Six criteria, weighted for this task.

Tune the priorities

Adjust the balance. Priorities total 100%.

CriterionPriorityRating

Revised ratingsRatings stay fixed as priorities change.

What good looks like

Weighted score—

A weighted summary of the example’s ratings.

Ratings run from 0–4. A higher score cannot override a failed requirement.

Behavior check

Works in this demo

Controls and reservation preview work. The $249 price is clear, and motion can be paused. No reservation is submitted.

View the output

Authored examples, ratings, and weights; no live model run or measured Muse results. Try the revised examples: inspect a saved record, change a visit time, or explore the speaker.

My methods

How the loop evaluates and learns

Start with what better means for the selected scenario, then inspect the evidence needed to guide the next revision.

What better means for a product launch

Design direction. Use expressive interaction to explain FIELD and make the $249 offer clear.

Behavior to verify. Confirm that product controls and the reservation preview work, including when motion is paused.

What preference comparisons can tell us

Preference isn’t proof. A winner can still fail the task. Model judges may favor answer order or length. Six criteria make the decision easier to inspect, but need calibration.

A/B tests measure impact. After offline checks, use randomized product tests to measure real outcomes, with clear metrics and guardrails.

The task sets priorities. Banking may need more precision than a workplace inspiration tool. Choose priorities for the task, not the market label.

How the oracle stays calibrated

Check the essentials. Verify the task, constraints, keyboard and mobile access, and saved choices. Fix failures before trusting a score.

Ground every rating. Use clear examples for the 0–4 scale. Cite the evidence and leave unknowns unscored.

Keep checks independent. Compare versions with the same rubric, test on held-out cases, and check regressions. Experts approve changes to criteria and weights.

Make feedback usable. Record the task, behavior, severity, and rationale. Give teams reviewed examples of good results, failures, and edge cases.

The Model Taste problem

Creative intent has to survive generation.

A game must stay playable through edits. A website must make its controls understandable. A visual reference must become a coherent interaction. Design makes those expectations concrete enough to evaluate.

01 · Specify intent

Prompts set the goal.

Golden prompts describe the experience, constraints, and what must survive a revision.

02 · Observe behavior

Workflows expose failures.

Follow model decisions and harness actions through tools, edits, recovery, and the final result.

03 · Target improvement

Evidence guides the change.

Route failures to prompts, harness design, or training data. Verify gains on held-out tasks.

My design decisions

From intent to evidence.

Explore the demos, prompts, and design decisions behind the experience.

01Preserve intent through edits

Outcome: an isometric game with visible movement, combat, and health feedback.

Game development · public demo

02Define quality for each task

Outcome: an interactive Photon Sphere page where the controls visibly change the scene.

Web development · public demo

03Ground evaluation in real use

Outcome: a scrolling lodge website with room rates and a booking calendar, built from the drone footage.

Multimodal visual coding · actual input and prompt

01 · Lodge fly-through video input · 6s

Muse Code prompt requesting a smooth scroll-through lodge page with copy, room rates, a booking link, and a calendar widget. — 02 · Text prompt

Original prompt

I have a drone fly through video here and would like to make a smooth scroll-though landing page, it needs to have proper copy since i want to make an ads of the lodge, can you help me do that? scroll through needs to feel as smooth as possible. Build the website into an ads of the lodge with room rate at the bottom. Write tasteful copies and add book link at the end. In the end add embedded calendar widget to request booking. Stop before you are trying to serve and give me the commands.

03 · Generated lodge site, room rate, and booking calendar

04Turn design judgment into usable data

Outcome: a conversation that carries the home-repair context through buying parts, setting up cameras, and planning the next steps.

Context carried through a task ●

05Turn failures into training examples

Trace a missing calendar to the right fix.

“In the end add embedded calendar widget to request booking.”Original prompt

Clear request, working tools—same failure.

Capture a recovery

Pair the failure with a verified correction.

Goal: Original request
Failure: Missing calendar
Recovery: Calendar and rate restored
Checks: Requirements verified

Illustrative lodge exampleCo-training approach ●

06Check that the improvement holds

Review the revision, then test it independently.

Earlier

Lodge booking

Dates

Calendar missing

Room rateOriginal rate

Revision

Lodge booking

Dates

1112131415161718192021222324

Room rateChanged

Restore the rate

Calendar fixed. Rate changed.

After both checks pass, use the same clean starting state.

Illustrative lodge exampleEvaluation methodology ●

Muse Code & Muse CLI

Taste has to survive iteration.

Model Taste connects product design to model development: define what matters, locate why it fails, and turn the evidence into better prompts, workflows, and training signals.

Connect with me for a walkthrough of the full Muse Code and Muse CLI UX case study.

Request case study

More selected work ●