gstack Design Review: Rate Your Design 0-10

Most software ships with design that's good enough. Not great — good enough. The edges are a bit rough, the empty states are generic, the error messages are technical, the loading states are missing, the mobile experience is an afterthought. Not broken, just not done.

The reason isn't usually lack of care. It's lack of systematic attention to the dimensions of design that matter. When you're building fast, you optimize for "does it work?" not "is it excellent?"

gstack's Design Review phase changes this. It rates every design dimension on a 0-10 scale and doesn't consider the review complete until you're hitting 9s and 10s across the board.

The Design Review Mindset#

Before the scoring framework, the mindset: a 7 is not acceptable.

This sounds harsh. But consider what a 7 actually means: it works, it doesn't confuse users, and it would pass a basic usability test. It will not delight anyone. It will not be mentioned in a positive review. It will not make someone choose your product over a competitor's.

10-star design isn't about beautiful aesthetics or expensive design systems. It's about:

• The user knows exactly what to do without reading instructions
• The UI communicates what's happening at every moment
• Error states are helpful and recoverable, not technical and confusing
• The product feels responsive and alive, not slow and static
• Edge cases are handled gracefully, not ignored

Every dimension of this is testable. That's what the 0-10 scoring framework does.

The Design Dimensions gstack Reviews#

gstack's Design Review covers multiple dimensions, each scored 0-10:

Clarity (Does the user know what to do?)

• Is the primary action obvious?
• Are secondary actions clearly subordinate?
• Is the hierarchy of information clear?
• Would a new user understand this screen in 5 seconds?

Feedback (Does the UI communicate what's happening?)

• Do loading states exist and communicate progress?
• Do success states confirm the action completed?
• Do error states explain what went wrong (not just that something went wrong)?
• Do destructive actions require confirmation?

Consistency (Does it feel like one product?)

• Are spacing, typography, and color used consistently?
• Do similar components behave consistently?
• Are interaction patterns predictable?

Edge Cases (What happens when things go wrong?)

• Empty state: what does the user see before they have any data?
• Error state: what does the user see when something fails?
• Loading state: what does the user see while waiting?
• Overflow state: what happens with very long text, many items, etc.?

Mobile (Does it work on small screens?)

• Is the touch target size appropriate?
• Is the layout responsive, not just "it loads on mobile"?
• Are there interactions that don't translate to touch?

Performance Perception (Does it feel fast?)

• Are skeleton screens used for loading content?
• Are interactions immediately responsive?
• Is there optimistic UI for frequent actions?

Accessibility (Can everyone use it?)

• Are contrast ratios sufficient?
• Is keyboard navigation functional?
• Are interactive elements clearly labeled?

How the 0-10 Scoring Works in Practice#

In gstack's Design Review, the AI reviews your actual design (via screenshot, design file, or live application) against each dimension.

For each dimension:

• 9-10: Excellent. Intentional, well-executed, handles edge cases.
• 7-8: Good. Works well in the main case, minor gaps.
• 5-6: Adequate. Functional but not thoughtful. Noticeable gaps.
• 3-4: Poor. Confusing or incomplete in key areas.
• 1-2: Broken. Would cause significant user frustration.

The review doesn't stop when you're at 7-8. It continues until you understand what 9-10 would look like and have a plan to get there.

Critically: the review also proposes specific improvements for each dimension that scores below 9. It doesn't just say "loading states are missing" — it says "add a skeleton screen that matches the shape of the loaded content, showing 2-3 lines for text fields and a rectangle for the image, animated with a subtle shimmer."

A Real Design Review Example#

Here's what a Design Review might produce for a new contact form in a CRM:

Clarity: 6/10 Issue: The form has 12 fields visible at once. Users scanning the form can't tell which are required vs. optional. Improvement: Show only the 4 essential fields by default. Add "Add more details" accordion for optional fields. Mark required fields explicitly.

Feedback: 4/10 Issue: No loading state when submitting. Success state navigates away without confirmation. Error states show raw API error messages. Improvement: Add spinner to submit button during submission. Show a success toast "Contact created" before navigating. Replace API errors with human-readable messages ("Please enter a valid email address" not "validation_error: email format invalid").

Edge Cases: 5/10 Issue: Empty state when no contacts exist shows a blank table. Error state if contact creation fails shows a generic error. No duplicate detection. Improvement: Empty state with illustration and "Add your first contact" CTA. Specific error messages. Warning if an email address already exists in the system.

Mobile: 7/10 Issue: Form is usable on mobile but not optimized. Fields require zooming to fill on smaller screens. Improvement: Increase form field height to 48px minimum. Ensure input types match field type (email keyboard for email fields, phone keyboard for phone fields).

Implementing these specific improvements moves each dimension from 4-7 to 8-10. The design went from "functional" to "good."

When to Run Design Review#

Design Review is most valuable:

• Before engineering begins on a significant UI feature (review wireframes/mockups)
• During engineering, when a UI component is first functional
• Before any major release with significant UI changes
• When user testing reveals confusion or friction

Design Review is less useful:

• For backend-only changes
• For very small UI tweaks (adding a button label)
• As a replacement for actual user testing (it's a substitute when user testing isn't available, not a superior alternative)

Building Design Excellence Habits#

The long-term value of gstack Design Review isn't any single review — it's the habits it builds.

When engineers and product managers run Design Review consistently, they start to internalize the dimensions. They start thinking about empty states when they design forms. They write better error messages because they've reviewed bad error messages many times. They add loading states because they've seen the score drop from 8 to 5 when loading states were missing.

The Design Review makes the implicit explicit, repeatedly, until it becomes automatic.

Frequently Asked Questions#

Does gstack Design Review require a dedicated designer to run?#

No. The AI runs the review. For engineering teams without a designer, Design Review provides the design perspective that would otherwise be absent. For teams with a designer, it provides a systematic framework that complements the designer's judgment.

Can Design Review evaluate design files (Figma, Sketch) before implementation?#

Yes. Attach the design file or screenshot to the gstack Design Review phase. Reviewing designs before implementation is more efficient than reviewing implemented designs — it's cheaper to change a Figma component than a React component.

What if the design review scores a component low, but there's no time to fix it before the deadline?#

Document the gap. Create a task to address it after the release. Track design debt the same way you track technical debt. A component that consistently scores 5/10 on Feedback is a known debt item with a specific improvement plan.

How do Design Review scores relate to real user outcomes?#

Design Review scores are a leading indicator, not a guaranteed outcome. A component scoring 9/10 on Clarity will generally produce less user confusion than one scoring 5/10, but there's no guaranteed correlation. User testing remains the gold standard for validating design effectiveness.

What's the most commonly overlooked design dimension?#

Empty states. Most designs are created assuming there's data to display. The empty state — what new users see before they've added anything — is often generic or missing entirely. This is the first thing a new user sees. It's also often the last design that gets attention.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →