# Benji Taylor Design Eval > 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. - Skill: `dvdarkin/benji-taylor-design-eval` (Agent Skill) - Install (CLI): `npx skillmds@latest add dvdarkin/benji-taylor-design-eval` - Raw SKILL.md: https://api.skillmd.com/api/skills/dvdarkin/benji-taylor-design-eval/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dvdarkin (https://skillmd.com/u/dvdarkin) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/dvdarkin/benji-taylor-design-eval --- # 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.