Muse for Designers: More Ideas, Real Assets, Judgment Intact
A product designer's daily workflow with Muse: a sparring partner that argues with your comps, a feedback synthesizer that clusters messy input, and an

Design is two jobs sharing one desk. The first is thinking: what problem is this solving, what deserves to exist, where the bar sits. The second is making: the comps, the iterations, the feedback threads, the spec checklists before handoff. Muse is a poor replacement for the first and a strong assistant for the second, and it earns its keep on the third thing designers actually spend their hours on, which is the grind between thinking and shipping.
The posture here comes from Linear’s design team. Co-founder Karri Saarinen puts the hard part plainly: “The hard part of design is rarely generating the form. It is understanding the problem well enough to know what and how something should exist at all.” His team treats AI as exploratory probes that surface customer context and pressure-test directions, and guards against letting the tool collapse the search from idea to finished UI too early. That is the line this lesson runs on: Muse widens the search, preps the assets, and clusters the feedback. The designer decides what ships.
The short version
- Muse is your second chair: it argues with your comps, clusters messy feedback into themes, and preps asset checklists before handoff.
- Keep your brand guide in memory (palette, type scale, tone, the don’ts) so every output starts from your rules, not the model’s defaults.
- Demand multiple directions from every sparring round. The first output is a starting point.
- You set the bar. Taste, problem framing, and the final call stay with the designer, always.
The Setup: The Second Chair
The Second Chair is the name I give the whole arrangement, and I run it for a mid-level product designer on a small SaaS team who ships a feature every two weeks and sits in one design crit a week. Muse sits in the metaphorical second chair of the studio: close enough to argue, never in the driver’s seat.
The arrangement starts with memory. Muse holds the team’s brand rules as standing instructions: the palette with hex values, the type scale, the voice and tone notes, the explicit don’ts (no stock-photo smiles, no gradients on primary buttons). Every output then starts from the studio’s rules instead of the model’s defaults. When the brand rules change, update the memory the same day, so corrections compound instead of repeating.
The specialist pattern applies the way it does everywhere: one setup spars, one setup synthesizes, one setup preps. A single all-purpose setup blurs the jobs, and blurred jobs produce blurred output. Three narrow setups, each with a tight brief, stay sharp.
The Second Chair has three jobs, and each one maps to a prompt below.
For sparring, before a crit or after a rough comp, Muse plays the opponent. It asks up to five questions about the user and the constraint, argues against the current direction in concrete points, and proposes two alternative directions. The designer walks into crit already knowing where the weak spots are, which is most of what a good crit gives you.
For feedback synthesis, the input is the usual mess: app store reviews, support tickets, interview notes, the pinned comments on the Figma file. Muse clusters them into themes with counts and representative quotes, flags the themes that contradict each other, and names the question each contradiction raises. It proposes no redesigns. Deciding what changes stays with the designer. The customer support lesson runs the same move on a support queue.
For asset prep, before anything goes to engineering, Muse audits the files against the brand rules: text styles against the type scale, colors against the palette, spacing against the grid, and returns a one-line-per-issue checklist with frame names. It changes nothing and renames nothing. The designer verifies the checklist and fixes the files by hand, because handoff quality is a craft judgment, not a batch operation.
| Job | Muse does | You do |
|---|---|---|
| Design sparring | Questions the brief, argues against your direction, proposes two alternatives | Picks the direction, makes the comps, runs the crit |
| Feedback synthesis | Clusters input into themes with counts, quotes, and contradictions | Decides what actually changes |
| Asset prep | Audits files against the brand rules, returns a checklist | Verifies it, fixes the files, owns handoff quality |
The Copy-Paste Prompts
Prompt 1: The Sparring Round
Paste this after describing the screen or flow you are working on, or with a screenshot attached:
You are my design sparring partner. I am designing [screen, flow, or feature] for [product and user]. Before giving opinions, ask me up to five questions about the user, the constraint, and what I am trying to change. Then argue against my current direction in three concrete points: what could confuse a first-time user, where the visual hierarchy breaks, and what I should prototype first. End with two alternative directions, one paragraph each. Do not give me a verdict on my design; I make the call.
Prompt 2: Feedback Synthesis
Here is feedback from [app store reviews, support tickets, user interviews, crit notes, or Figma comments]. Cluster it into themes. For each theme, give me: how many mentions, one representative quote, and whether it points at content, structure, or visual design. Then list the themes that contradict each other and the one question each contradiction raises. Do not propose redesigns. I decide what changes.
Prompt 3: The Asset-Prep Audit
Run this on the files before every engineering handoff, with the palette and type scale pasted in:
Audit these design files against our brand rules. Palette: [paste hex list]. Type scale: [paste styles]. Grid: 8pt. Check that every text layer uses a type style from the scale, every color matches the palette, and spacing follows the grid. Return a checklist, one line per issue, with the frame name and what deviates. Change nothing, rename nothing, and do not touch the design itself. I will verify every line before fixing.
What Can Go Wrong: The Collapsed Search
The failure mode to watch for is the search collapsing to one. You ask for a direction, Muse returns a polished answer, and the polished answer quietly becomes the design. Exploration stops at one option instead of twenty, and the work converges on the model’s defaults instead of your judgment. Linear’s team names this one explicitly: they guard against collapsing the search process from idea to finished UI too early, because committing fast narrows the problem space before the problem is understood.
Build the fix into the process. Prompt 1 demands two alternative directions every time, which forces the search back open. And keep your own hand in the making: Linear’s product designer Isha Kumar uses AI selectively to explore edge cases or spin up quick prototypes, and keeps it out of her core creative loop, because prompting flattens the rhythm of thinking through making. The failure-modes lesson covers the wider pattern, and it applies here too: the more finished an output looks, the easier it is to stop thinking.
One more guardrail while you are here. AI-generated imagery converges on a house style fast, and every designer prompting the same tool drifts toward the same look. The fix is references: feed Muse your moodboards, your brand book, your past work, and name what to avoid. Defaults are the enemy. Your taste is the product.
Muse run this way does what a good second chair does: it makes the thinking wider, the feedback legible, and the handoff cleaner, while the designer keeps the only parts that cannot be delegated. Karri’s line for it, from Linear’s AI in design report: “The best designers produce clarity in problems that aren’t clear.” The tool widens the search. You still decide what deserves to exist.
“The tool widens the search. You still decide what deserves to exist.”


