benji-taylor-design-eval

name	benji-taylor-design-eval
description	Use when reviewing, critiquing, or auditing a product's design quality, UX, or interface decisions. Trigger on "is this well designed", "what's wrong with this UI", "how would a great designer evaluate this", or when the user wants principled design feedback on their own project.

Benji Taylor Design Evaluation

Overview

Structured design critique based on the principles Benji Taylor has articulated and demonstrated through his work on the Family self-custody wallet, Base (Coinbase L2), and X. Surfaces real tensions in a design and where it resolves or fails them -- not a scorecard with arbitrary numbers.

When to Use

• User asks to critique, review, audit, or score a product's design
• User asks "is this well designed" or "how would a great designer look at this"
• User wants to improve the design quality of their own product or feature
• Reviewing screenshots or mockups for design principles compliance

When NOT to use:

• Pure developer tooling (delight and fluidity have different meanings in CLI/API contexts)
• Enterprise software (progressive disclosure is often inverted by necessity)
• Flag and adapt if the product falls in these categories rather than skipping entirely

Quick Reference

Dimension	Core Question
Progressive Disclosure	Does complexity appear only when needed?
Fluidity	Does motion communicate state changes?
Simplicity/Fluidity/Delight	Are all three present, not just one?
Craft	Are edge cases designed with equal care?
Trust Through Clarity	Are high-stakes actions unambiguous?
Accessibility Without Depth	Can novices and experts coexist?

---

The Six Evaluation Dimensions

1. Progressive Disclosure

The principle: Fundamentals at your fingertips. Everything else appears as it becomes relevant. Never dump all features at once.

What to look for:

• Does the first screen show only what a new user needs?
• Are advanced features gated behind discovery (not hidden, but not foregrounded)?
• Is there a coherent mental model for what is always visible vs. what appears contextually?

Failure modes:

• Settings exposed before the user has done anything
• Feature parity between power and novice users baked into primary navigation
• Long lists of options when a single default would serve 80% of users

---

2. Fluidity as Semantic Communication

The principle: Motion is not decoration. It is a channel for communicating state changes, transitions, and the weight of an action.

What to look for:

• Do animations signal what just happened or what is about to happen?
• Are irreversible or high-stakes actions marked by a perceptible transition (not just a dialog)?
• Is there a consistent motion language, or is animation applied randomly?

Failure modes:

• Instant state changes with no transition for consequential actions
• Decorative animations that do not communicate anything about the system state
• Inconsistent timing -- some things animate, others snap

---

3. The Simplicity / Fluidity / Delight Triad

Each pillar resolves a specific failure mode, and all three must be present:

Pillar	Resolves	Test question
Simplicity	Cognitive overload	Can a first-time user orient themselves in under 10 seconds?
Fluidity	Experience fragmentation	Does the product feel like one continuous thing or a set of screens?
Delight	Emotional disengagement	Is there at least one moment where the product surprises the user pleasantly?

What to look for:

• Products often have one or two of these but sacrifice the third
• Simplicity without fluidity = sterile
• Fluidity without simplicity = overwhelming
• Delight without either = gimmicky

---

4. Craft as Competitive Positioning

The principle: Polish is not a finishing coat. It is a deliberate choice to slow down and do fewer things better, treated as a strategic differentiator rather than a luxury.

What to look for:

• Are typography, spacing, and color decisions consistent or ad hoc?
• Are edge cases (empty states, loading states, errors) designed with the same care as the happy path?
• Does the product feel like it was built by one mind or assembled from parts?

Failure modes:

• Empty states that are just blank with a spinner
• Error messages in default OS styling
• Inconsistent component behaviour across screens (button that works one way here, differently there)

---

5. Trust Through Clarity in High-Stakes Interactions

The principle: When an action is irreversible, consequential, or involves real-world assets (money, data, identity), the interface must make the stakes unambiguous -- before, during, and after.

This is Taylor's most hard-won principle from crypto product design. It generalises to any interaction where the user might regret an action.

What to look for:

• Is the user clear on what will happen before they tap Confirm?
• Are destructive actions visually distinguishable from non-destructive ones?
• Does confirmation feel like a ritual (i.e., a moment of attention), not just a speed bump?

Failure modes:

• Confirm dialogs with identical styling to regular dialogs
• Action labels that are vague ("Continue" instead of "Delete Account")
• No post-action feedback -- the user cannot tell if the action completed

---

6. Accessibility Without Depth Sacrifice

The principle: Making a product approachable for newcomers must not strip power from experienced users. The tension is resolved through layering, not simplification.

What to look for:

• Is the entry path clear for someone who has never used this category of product?
• Can a power user access advanced functionality without fighting through the simplified surface?
• Is the information architecture coherent for both audiences simultaneously?

Failure modes:

• Tutorial overlays that disappear and never return (no re-discovery path)
• Advanced features buried in settings rather than surfaced contextually
• Onboarding that oversimplifies to the point of being misleading about product depth

---

Output Format

Structure your evaluation as follows:

[Product Name] - Design Evaluation

Context: [One sentence on what the product is and who it is for]

For each of the six dimensions, write:

• Verdict: Passes / Partially Passes / Fails
• Observation: What you see in the product (specific, not generic)
• Tension: The underlying design tension this reveals
• Recommendation: One concrete change that would move it toward the principle (only if Fails or Partially Passes)

End with:

Strongest dimension: [which one and why] Most critical gap: [which one and why -- this is where design investment would have highest leverage] Overall character: [one paragraph on the product's design identity -- what kind of designer built this, what values are implicit in the choices]

---

How to Run This Evaluation

Input the evaluator needs (ask for what is missing):

• Product description or URL
• Target user (novice / power user / both)
• Key interactions to evaluate (if known)
• Screenshots or description of the interface
• Any known design constraints (platform, team size, timeline)

If screenshots are not provided: Evaluate based on the product description and any publicly available information. Be explicit about what is inferred vs. observed.