Designpixil

Designpixil ยท saas-design

The SaaS UI Design Checklist: 50 Checks Before Launch

50 checks to run on your SaaS product before launch: information hierarchy, onboarding, dashboards, empty states, mobile, and copy. Ready to use.

Anant JainCreative Director, DesignpixilยทLast updated: June 2026

This is a specific, opinionated checklist, not a generic design principles overview. Every item corresponds to a real pattern that either adds or detracts from the quality signal your product sends to users and investors.

Work through it on your highest-traffic screens first. Score it honestly. Fix the ๐Ÿ”ด items before anything else.


Section 1: Marketing Homepage (10 checks)

  • ๐Ÿ”ด The above-the-fold headline clearly states what the product does and who it's for, in one sentence, without jargon
  • ๐Ÿ”ด A visitor who has never heard of your product can describe it accurately after reading only the headline and subheadline
  • ๐Ÿ”ด There is one clear primary CTA above the fold, not three competing buttons
  • ๐ŸŸก The first social proof element (client logos, testimonials, or usage metric) appears above the fold or within the first scroll
  • ๐ŸŸก The primary CTA copy describes what happens when you click, "Start free trial" or "Book a demo," not "Get started"
  • ๐ŸŸก The homepage answers "who is this for?" explicitly, by name or description of the target user
  • ๐ŸŸก The pricing is either shown directly or a "Pricing" link is clearly visible in the navigation
  • ๐Ÿ”ต The page loads in under 3 seconds on a standard connection
  • ๐Ÿ”ต Social proof includes named testimonials with attributable companies, not just anonymous quotes
  • ๐Ÿ”ต The mobile view of the homepage is tested and functions correctly

Section 2: Onboarding Flow (10 checks)

  • ๐Ÿ”ด New users can reach their first meaningful value moment in under 5 minutes
  • ๐Ÿ”ด Every step in the onboarding has a clear, single action, not "fill out your profile, connect your integrations, and invite your team"
  • ๐Ÿ”ด Empty states at each step explain why there's nothing there and what to do about it
  • ๐Ÿ”ด The first screen inside the product (post-signup) shows a clear first action, not a blank dashboard
  • ๐ŸŸก A progress indicator shows users how far through onboarding they are
  • ๐ŸŸก The onboarding can be skipped or deferred for users who want to explore first
  • ๐ŸŸก Inline help or tooltip text explains unfamiliar concepts without requiring users to open documentation
  • ๐ŸŸก Error messages in onboarding forms explain what went wrong and how to fix it, not just "invalid input"
  • ๐Ÿ”ต Email verification is not required before users can access the core product
  • ๐Ÿ”ต Users who abandon onboarding mid-flow receive a follow-up email with a link to resume

Section 3: Core Dashboard (10 checks)

  • ๐Ÿ”ด The most important metric is visually dominant, larger, bolder, or more prominently placed than secondary metrics
  • ๐Ÿ”ด The dashboard has a clear primary action, something the user should do or can do from this view
  • ๐Ÿ”ด Empty states are designed, not blank containers, and explain what actions will populate them
  • ๐Ÿ”ด Every chart has a clear label that explains what it shows and what the X/Y axes represent
  • ๐ŸŸก Charts use the simplest chart type that communicates the information, bar charts for comparison, line charts for trends, single numbers for point-in-time metrics
  • ๐ŸŸก The time range or filter context is always visible, users should always know what period the data represents
  • ๐ŸŸก Loading states use skeleton screens or shimmer, not blank containers with a spinner
  • ๐ŸŸก Role-based differences (what admin sees vs. user sees) are tested and correct
  • ๐Ÿ”ต The dashboard is usable at 1280px (standard laptop), 1440px (desktop), and 375px (mobile) widths
  • ๐Ÿ”ต "No data" states distinguish between "no data yet" and "no data matching your current filters"

Section 4: Typography and Visual Hierarchy (8 checks)

  • ๐Ÿ”ด The page can be scanned (without reading carefully) and the most important information is still clear
  • ๐ŸŸก There are no more than 3 font sizes used on any single screen
  • ๐ŸŸก Body text is at least 14px (ideally 16px) and has adequate contrast against the background
  • ๐ŸŸก All text in the product is dark enough to pass WCAG AA contrast standards
  • ๐ŸŸก Heading hierarchy is consistent: page titles use one style, section headers another, labels another
  • ๐ŸŸก No text is in all-caps except for specific labels where it's intentional (status badges, short metadata)
  • ๐Ÿ”ต The type scale (size ratio between heading levels) is consistent across all screens
  • ๐Ÿ”ต Link text is distinguishable from surrounding body text without relying on colour alone

Section 5: Components and Consistency (8 checks)

  • ๐Ÿ”ด Every button type (primary, secondary, destructive) looks the same throughout the product
  • ๐Ÿ”ด Destructive actions (delete, remove, revoke) are visually distinct from constructive actions
  • ๐ŸŸก Form inputs look the same across all forms in the product
  • ๐ŸŸก Error states on inputs show the error message adjacent to the input that caused it, not at the top of the form
  • ๐ŸŸก Toast notifications and banners (success, error, warning, info) are visually distinguishable from each other
  • ๐ŸŸก Modal dialogs are used for confirmations and contextual actions, not for displaying large amounts of content
  • ๐Ÿ”ต Hover states exist on all interactive elements that have them on desktop
  • ๐Ÿ”ต Focus states are visible on all interactive elements for keyboard navigation

Section 6: Copy and Messaging (4 checks)

  • ๐Ÿ”ด Error messages describe what happened and what the user should do next, not just that something went wrong
  • ๐ŸŸก Button labels use active verbs that describe the action: "Save changes," "Delete project," not "OK" or "Submit"
  • ๐ŸŸก Confirmation dialogs describe the specific consequence of the action before confirming it
  • ๐Ÿ”ต The product uses consistent terminology, the same feature is called the same name everywhere

Scoring Your Checklist

Count your passes, warns, and fails by category:

StatusMeaningFix priority
๐Ÿ”ด CriticalLikely causing user confusion or conversion lossFix before showing to investors or new users
๐ŸŸก WarningReduces quality perception or adds frictionFix in the next sprint
๐Ÿ”ต NoticePolish-level improvementFix when you have capacity

The minimum bar before a fundraise or enterprise demo: All ๐Ÿ”ด items passing. Aim for 80%+ of ๐ŸŸก items passing.


If your product is scoring below 70% on this checklist and you want a systematic plan for how to fix it, book a free 30-minute design review. We'll run the audit on your specific product and give you a prioritised list of what to fix first.

Frequently Asked Questions

When should I run a SaaS UI design checklist?+

Before any significant product launch or redesign, after each major feature addition, and as a quarterly review. Most valuable immediately before a fundraise or sales push, when you need to know whether the product looks credible enough to show to investors and enterprise prospects.

How long does a UI design audit take?+

A focused review of 3โ€“5 key screens takes 60โ€“90 minutes. A comprehensive audit of a full product takes 2โ€“4 hours. The goal is to identify the highest-priority issues, not achieve a perfect score. Five critical issues fixed is worth more than 40 minor issues documented.

What's the most important section for a pre-revenue SaaS?+

The marketing homepage and onboarding sections. Pre-revenue, these two screens determine whether you can attract and activate users. A rough dashboard is forgivable at pre-revenue stage; a marketing site that doesn't communicate what the product does will silently kill acquisition.

Should I use this checklist myself or have a designer run it?+

Both. Run it yourself first, then have a designer run it independently. Designers catch issues that founders normalise after seeing the product every day, the button that's almost the right colour, the spacing that's almost consistent, the copy that almost says what it means.

What score should I aim for before a fundraise?+

85% or above, with no critical (๐Ÿ”ด) items outstanding. Investors aren't doing a systematic design audit; they're forming a gestalt impression. A product with 0โ€“5% of checks failing reads as polished and intentional. A product with 15% failing looks slightly rough in ways that are hard to articulate but easy to feel.

Related reading: Why Your SaaS Looks Vibecoded (And How to Fix It) ยท SaaS Dashboard Design Best Practices ยท SaaS UI Audit for B2B Products

Our work

Task management
AI analytics dashboard
Transdyne / Healthcare transcription saas
View more work

Work with us

Senior product design for your SaaS or AI startup.

30-minute call. We look at your product and tell you exactly what needs fixing.

Related

โ† All articles