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.
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:
| Status | Meaning | Fix priority |
|---|---|---|
| ๐ด Critical | Likely causing user confusion or conversion loss | Fix before showing to investors or new users |
| ๐ก Warning | Reduces quality perception or adds friction | Fix in the next sprint |
| ๐ต Notice | Polish-level improvement | Fix 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
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


