UX Review Guide for SaaS

# UX Review Guide for SaaS

This guide provides a systematic approach for auditing User Experience (UX) in commercial SaaS applications, rooted in heuristic evaluation and modern design systems.

## 1. Heuristic Evaluation Framework

Based on Nielsen's 10 Usability Heuristics, adapted for modern B2B/B2C SaaS.

### 1.1 Visibility of System Status
**Principle**: The system should always keep users informed about what is happening.
- [ ] **Feedback**: Progress bars for long-running tasks (>1s).
- [ ] **State**: Clear loading skeletons or spinners on data fetch.
- [ ] **Confirmation**: 'Toasts' or 'Snackbars' for successful actions (e.g., "Saved successfully").
- [ ] **Location**: Breadcrumbs or highlighted nav items indicate "Where am I?".

### 1.2 Match Between System and Real World
**Principle**: Speak the user's language, not the developer's.
- [ ] **Jargon**: Use business domains terms (e.g., "Customer") not DB terms (e.g., "Entity").
- [ ] **Icons**: Use universally recognized symbols (e.g., Trash for delete, Gear for settings).
- [ ] **Flow**: Workflows match real-world business processes.

### 1.3 User Control and Freedom
**Principle**: Users make mistakes; give them an "Emergency Exit".
- [ ] **Undo/Redo**: Supported for complex editing.
- [ ] **Cancel**: Long operations can be aborted.
- [ ] **Destructive Actions**: "Archive" preferred over "Delete"; or strict confirmation dialogs.

### 1.4 Consistency and Standards
**Principle**: Don't make users wonder if different words/situations mean the same thing.
- [ ] **Visuals**: Buttons, inputs, and fonts follow a Design System.
- [ ] **Verbs**: Consistent terminology (e.g., don't mix "Edit" and "Modify").
- [ ] **Patterns**: "Save" button always in same location (e.g., top-right or bottom-right).

### 1.5 Error Prevention
**Principle**: Prevent problems from occurring in the first place.
- [ ] **Constraints**: Date pickers prevent invalid dates.
- [ ] **Validation**: Inline validation before form submission.
- [ ] **Defaults**: Smart defaults populate fields to reduce effort.

### 1.6 Recognition Rather Than Recall
**Principle**: Minimize the user's memory load.
- [ ] **Suggestions**: Auto-complete for search/inputs.
- [ ] **History**: "Recently Viewed" or "Last Edited" lists.
- [ ] **Context**: Help tooltips explains complex fields without leaving the page.

### 1.7 Flexibility and Efficiency of Use
**Principle**: Accelerators for power users, clarity for novices.
- [ ] **Shortcuts**: Keyboard hotkeys (Command+K, Command+S).
- [ ] **Bulk Actions**: Select-all and batch edit capabilities.
- [ ] **Filters**: Advanced filtering for large datasets.

### 1.8 Aesthetic and Minimalist Design
**Principle**: Every extra unit of info competes with the relevant units.
- [ ] **Whitespace**: Standardized spacing scales; breathing room.
- [ ] **Hierarchy**: Visual weight matches importance (H1 > H2 > Body).
- [ ] **Noise**: Remove non-essential decoration.

### 1.9 Help Users Recognize, Diagnose, and Recover from Errors
**Principle**: Error messages should be plain language and suggest a solution.
- [ ] **Clarity**: "Payment Failed: Card Expired" vs "Error 500".
- [ ] **Action**: "Update Card" button provided in the error state.
- [ ] **Style**: Error states clearly visible (Red borders/text).

### 1.10 Help and Documentation
**Principle**: Help should be easy to search and focused on the user's task.
- [ ] **Contextual**: "?" icons near complex settings.
- [ ] **Docs**: Searchable knowledge base linked from app.
- [ ] **Onboarding**: Empty states guide the "First Action".

## 2. Scenario-Specific Audits

### 2.1 Onboarding & Activation
**Goal**: Time-to-Value (TTV) minimization.
- [ ] **Signup**: Single-Sign-On (SSO) or Magic Link preferred.
- [ ] **Welcome**: "Get Started" checklist or tour.
- [ ] **Empty States**: Use empty states to educate (e.g., "Create your first Project").

### 2.2 Forms & Data Entry
**Goal**: High data integrity, low friction.
- [ ] **Labels**: Top-aligned for faster scanning.
- [ ] **Required**: Explicitly mark optional fields (or just required ones).
- [ ] **Types**: Use specific input types (email, tel, number) for mobile keyboards.
- [ ] **Autosave**: Drafts saved automatically.

### 2.3 Data Tables & Lists
**Goal**: Manage density and findability.
- [ ] **Density**: Choice of comfortable vs compact view.
- [ ] **Sorting**: Clickable headers.
- [ ] **Pagination**: Clear page controls or infinite scroll with markers.
- [ ] **Sticky Headers**: Headers remain visible on scroll.

### 2.4 Mobile Response
**Goal**: Functional parity on smaller viewports.
- [ ] **Tap Targets**: >44px for touch.
- [ ] **Columns**: Grids collapse to single-column stacks.
- [ ] **Navigation**: Hamburger menu or bottom tab bar.

## 3. Accessibility (a11y)
- [ ] **Contrast**: WCAG AA standards (4.5:1 ratio).
- [ ] **Nav**: Fully navigable via Tab key.
- [ ] **Alt**: Images have descriptive alt text.
- [ ] **Focus**: Visible focus rings on active elements.

## 4. Performance (Perceived)
- [ ] **Skeletons**: Layout shifts minimized during load.
- [ ] **Optimistic UI**: Interface updates immediately (assuming success) before server confirms.
- [ ] **Lazy Load**: Images/Components load only when needed.

## 5. Audit Report Template

```markdown
# UX Audit Report: [Feature/Flow]

## Summary
* **Score**: [A/B/C/D]
* **Key Issue**: [One line summary]

## Detailed Findings

### P0: Critical Usability Blocks
1. **[Issue Name]**
   * **Violates**: [Heuristic, e.g., Visibility of System Status]
   * **Observation**: [What happens]
   * **Recommendation**: [Fix]

### P1: Friction Points
1. **[Issue Name]**
   * ...

### P2: Polish Opportunities
1. **[Issue Name]**
   * ...
```