Design Review

Design Principles & Critique

This skill grounds design feedback in the Bitwarden design team's Code of Conduct and the

30-60-90 maturity framework. The Code of Conduct and 30/60/90 framework originate from the

designer-agent-skills branch

of bitwarden/clients (authored by the design team) and have no separate Confluence canonical

— this skill is the authoritative source within Claude tooling. Critique the product, not the

designer. Feedback must be

actionable, stage-appropriate, and rooted in product goals — not personal preference.

> Cross-plugin dependency. This skill composes content-style-guide (at 60% and 90%

> stages) and using-figma (when the design lives in a Figma file). Both ship in the

> bitwarden-design-tools plugin, which is required alongside bitwarden-designer —

> install both for the full composition to work.

Step 1: Identify the stage

Before giving feedback, identify (or ask) what stage the design is at. The kind of feedback

that's useful depends entirely on this.

• 30% — a rough idea. The designer is exploring direction. Easy to pivot or throw away.

Looking for: ideas and impressions, whether this is something we should do, whether it's the

right direction, how to move the concept forward, go/no-go on the idea.

• 60% — a first draft of a set concept. Significant time has gone into this; direction

shouldn't change drastically without strong reason. Looking for: whether 30% critique was

addressed, visual/graphic feedback, feedback on interactive components, ways to expand the

concept.

• 90% — last check before development. Should already be tested with real users. No drastic

changes expected. Looking for: whether 60% critique was addressed, nitty-gritty grammar,

finalizing copy, final check on the minutiae.

If the user doesn't say the stage, ask. Don't give 90%-style nitpicks on a 30% sketch, and

don't suggest sweeping direction changes on a 90% design.

Step 2: Critique the product, not the designer

A good design meets its goals. A bad design does not meet its goals. Likes and dislikes

are irrelevant.

• Talk about strengths, not just weaknesses. Good critique empowers — understanding what

works helps decide what to keep.

• Separate like/hate from good/bad. Consider product goals over personal opinions.
• Ask questions instead of making assumptions. If something isn't clear, ask why a decision

was made.

• Don't try to design a better solution on the spot. Focus on what about the current design

isn't meeting its intended purpose. The designer can address it when they have more time.

Phrasing

| Instead of | Try |

| ---------------------- | ----------------------------------------------------------- |

| "Why did you do that?" | "What are you trying to achieve by doing x?" |

| "I don't like it" | "I'm not sure that x makes it clear to users they can y" |

| "Why don't we just…" | (skip — don't design on the spot; describe the gap instead) |

Step 3: Filter feedback through the Code of Conduct

The Bitwarden design team operates by five principles. Let them shape what to flag and how.

• We design proactively, not reactively. Lead with strategy, planning to innovate and

shape the product's future rather than just reacting to demand. Create space for

intentionality, so every designer can be thoughtful, detail-oriented, and proud of their

work. Flag missed opportunities for intentional, forward-looking design — especially at the

30% stage.

• We design with empathy, verified by insights. User voices guide decisions through

regular conversations, research, and data. Bring customers to the forefront of every

discussion, empowering partners in Product and Engineering to think customer-first. Every

feature shipped should be user-centered, tested, and proven. When a design choice is

unsupported by insight, surface it as an open question — not a flaw, but a gap worth closing

before 60%.

• We design with confidence and humility. Trust expertise while remaining open to being

wrong. Navigate ambiguity together, make clear decisions, and move forward — staying open

to changing course as more is learned. Even minor iterations can transform outdated

experiences into something to be truly proud of. Frame feedback as contribution to a shared

solution, not as a verdict.

• We work as a unified team. Collaboration with Product and Engineering should be smooth

and transparent. Design files should be clear, easy to navigate, and well-organized with

shared understanding. Operate with clarity, confidence, and care — trust is the foundation,

and everyone is encouraged to contribute their best. Flag ambiguity that will make handoff

painful.

• A year from now, we want a Bitwarden UI we're proud to put our names on — one that

earns the trust of millions because we designed it with the trust of each other. Hold

feedback to that bar.

Step 4: Evaluate content alongside visual design

At 60% and especially 90%, evaluate user-visible copy (button labels, headings, error

messages, empty states, helper text, etc.) against the content-style-guide skill — voice,

tone, sentence case, no ampersands, meaningful link text, gender-neutral pronouns, no spatial

language, and the rest. Treat content findings as first-class critique points, not afterthoughts.

Skip content nitpicks at 30% — direction, not copy, is the question at that stage.

Composing with other skills

• content-style-guide. Compose at 60% and 90% stages to evaluate user-visible copy

alongside visual design — voice and tone, sentence case, no ampersands, accessibility rules.

Skip at 30%, where copy is too early to critique.

• using-figma. When the design under review lives in a Figma file, compose to read the

context. Start with get_screenshot + get_metadata to orient; pull get_variable_defs

when tokens are part of the critique (off-system colors, inconsistent spacing).

Output format

Structure the critique as:

• Stage — confirm or ask (30% / 60% / 90%).
• Strengths — what's working and should stay.
• Questions — what isn't clear; what to ask the designer to clarify.
• Actionable feedback — specific, product-goal-anchored observations the designer can

address. Match the granularity to the stage. At 60%/90%, include content observations

tied to the content-style-guide.

Keep feedback specific. "The CTA hierarchy makes it unclear which action is primary" beats

"the buttons feel off." Tie each point back to a user or product goal where you can.