GDL — UI Mockup QA Review

Google Drive Lead Management  ·  Adversarial UX Critique  ·  8 Mockups  ·  May 2026

Executive Summary

# Mockup Critical Design FP Candidates Status
1 Customer Dashboard 5 8 1 FAIL
2 Leads Management 3 6 1 FAIL
3 Bulk Actions Modal 3 5 0 FAIL
4 Drive Import ⚠in-progress 6 5 1 FAIL
5 Email Verification 5 5 0 FAIL
6 Campaign Compose ⚠72% 4 5 1 FAIL
7 SMTP Settings ⚠placeholder 3 4 1 NEEDS-REVIEW
8 Admin Overview 4 6 0 FAIL
1
Customer Dashboard
3.2.2-customer-dashboard-mockups/dashboard.html
FAIL
STATIC MOCKUP — not a live app
⚠ Iframe is a fixed-size preview of a static HTML mockup; interactive elements are non-functional.
🔴 Critical Issues 5
No CTAs to key actions — Dashboard has no "Import Leads" or "New Campaign" buttons. Monitoring dashboards may intentionally route actions to sub-pages, but a B2B SaaS dashboard should surface primary actions.
Breadcrumb is decorative — "Home / Dashboard" shows no functional Home link. A breadcrumb that doesn't navigate is worse than no breadcrumb (misleading affordance).
Topbar title is context-blind — "Dashboard" stays fixed regardless of active sidebar section. User loses orientation when drilling into sub-pages.
Leads table is display-only — No bulk checkboxes, pagination controls, or row-level action buttons. Can't act on data from the dashboard itself.
Campaign rows show zero metrics — Open rate, click rate, bounce rate all missing. Campaign performance is the core value prop; empty metric cells give no signal.
🔸
FP Candidate — "No CTAs on dashboard": Monitoring dashboards in mature SaaS often keep actions on sub-pages (e.g. Datadog, Mixpanel). This may be an intentional IA decision rather than an oversight. Recommend confirming with product spec before treating as a bug.
🟡 Design Issues 8
"VERIFIED" chip overstates deliverability — Implies inbox placement, not just SMTP syntax validation. Misleading if the check is lightweight.
"NEW" chip has no temporal context — Created today? This week? No tooltip or relative time shown.
Stats row lacks a time period label — "1,247 Total Leads" — this week, this month, or all time? Unknown. Needs a scope label.
Leads table has no filter controls — No search bar, status filter, or column sort indicators.
No "Add Lead" button visible — Manual lead entry path is missing from the primary view.
Sidebar nav items have no pending-count badges — Standard SaaS pattern (e.g. "Inbox (3)") for items needing attention.
Notification bell shows red dot, no tooltip — Red dot with no explanation is alarming and uninformative.
Draft campaigns have no edit/schedule path — No affordance visible for resuming or editing a draft from the dashboard card.
No empty states designed — What does the dashboard look like for a brand-new tenant with no leads or campaigns?
Verdict FAIL — 5 critical UX issues including non-functional breadcrumb, display-only data tables, and missing campaign performance metrics. 1 FP candidate on dashboard CTAs. Design lacks empty states, time-period context, and nav badges.
2
Leads Management
3.2.3-leads-mockups/leads.html
FAIL
STATIC MOCKUP — not a live app
⚠ Iframe is a fixed-size preview of a static HTML mockup; interactive elements are non-functional.
🔴 Critical Issues 3
Duplicate "Status" and "Verified" columns — Identical values in every row. 17% of table width is wasted on redundancy. These are two different semantic concepts being collapsed into one display.
No empty / loading / error state designs — Critical missing state for any data-driven view. User has no guidance for loading, empty search results, or API failure.
Delete action has zero friction — Single click permanently deletes a lead with no confirmation dialog, no undo path. Data loss risk is high in a B2B context where lead records have business value.
🔸
FP Candidate — Status/Verified correlation: In a static mockup, all rows showing "Active / Verified" and "Active / Unverified" is likely just copy-paste data. The real concern is whether these two columns should exist side-by-side in the actual design — which is an IA/UX question, not a mockup fidelity question.
🟡 Design Issues 6
"Add Lead" button is far right (Fitts's Law) — Primary action placed in the bottom-right corner of a wide table requires maximum mouse travel. Should be top-left near the table header.
"Bulk Actions" is not discoverable — Button hidden until a row checkbox is selected. Users won't know bulk selection exists without prior exposure to the pattern.
Amber chip for "UNVERIFIED" may read as warning — Amber/yellow in UI convention often signals a warning or attention state. For a neutral status, this may cause unnecessary concern.
Pagination says "1–20 of 1,247" but shows 8 rows — Pagination metadata is hardcoded independently of visible rows. Indicates the mockup wasn't reviewed for internal consistency.
"Verify" sidebar nav item is ambiguous — Unclear whether this links to a verification queue page or triggers an inline action. The IA intent is not obvious.
Status and Verified columns are perfectly correlated — In the mockup data, every Active lead is Verified and every row shares the same pattern. Suspicious from a data真实性 standpoint; makes the table hard to read.
Verdict FAIL — 3 critical issues: redundant columns, missing state designs, and zero-friction delete. Design issues compound usability (Fitts's Law violation, non-discoverable bulk actions, inconsistent pagination metadata). 1 FP candidate on column correlation.
3
Bulk Actions Modal
3.2.4-bulk-actions-mockups/bulk-actions.html
FAIL
STATIC MOCKUP — not a live app
⚠ Iframe is a fixed-size preview of a static HTML mockup; interactive elements are non-functional.
🔴 Critical Issues 3
"Delete Leads" has no confirmation step — Single click = permanent data deletion. No intermediate confirmation, no "are you sure?" dialog. In a B2B app with business-critical lead data, this is a data safety failure.
No visual hierarchy between destructive and safe actions — Delete, Verify, and Export are styled identically. Users cannot distinguish dangerous from benign operations at a glance — the most critical accessibility requirement for bulk-action modals.
"Verify Emails" gives no feedback on next steps — No spinner, no redirect indication, no queue message. User fires 3 API calls and gets no confirmation of what happened or what happens next.
🔸
No FP candidates confirmed — The accessibility and data-safety issues here are genuine. Even as a mockup, the absence of a destructive-action confirmation modal and the lack of visual hierarchy are real design gaps that need addressing before dev.
🟡 Design Issues 5
No disabled states for inapplicable actions — If a lead is already verified, the Verify button should be disabled with a tooltip. If already deleted, the row shouldn't appear. No disabled states shown.
Cancel is an <a href="#">, not a <button> — Semantic HTML failure. Anchors with href="#" cause scroll-to-top behavior, are not keyboard-focusable by default, and carry wrong ARIA semantics.
Close button (×) fails accessibility — 22px tap target is below the 44×44px WCAG 2.1 AAA touch target minimum. No aria-label or aria-pressed attribute.
No keyboard focus states visible — Mockup shows no :focus-visible styling. Any interactive modal must show clear keyboard navigation states.
Backdrop click behavior undocumented — Does clicking the backdrop close the modal and cancel the action? Standard modal behavior, but not shown or documented in the mockup.
Verdict FAIL — 3 critical issues around destructive-action safety (no confirmation, no visual hierarchy, no feedback). 5 design issues including semantic HTML failure (anchor as button), accessibility tap-target violation, and missing keyboard focus states.
4
Drive Import — In-Progress State ⚠
3.2.5-drive-import-mockups/import.html
FAIL
STATIC MOCKUP — ⚠ shows in-progress state, not initial load
⚠ This is an IN-PROGRESS import mockup. Progress bar and import state are intentional. Issues flagged are inconsistencies in the in-progress state itself.
🔴 Critical Issues 6
Numbers are internally inconsistent — Preview header says "3 rows found" but progress bar says "195 of 300 leads imported". These should be the same number at the same point in the workflow. Conflicting numbers erode user trust immediately.
No "Start Import" button visible — Import appears to auto-start after column mapping. Auto-triggering a data import without an explicit user confirmation is dangerous — a mis-mapped column would import corrupt data silently.
"Ready to map" badge shown despite all columns already mapped — Badge should only appear before mapping starts, not after all 4 columns are mapped. Appears to be a state-management inconsistency in the mockup.
"Fetch CSV" has no loading state — Preview table appears instantly with no loading indicator. A large CSV could take several seconds; no spinner or skeleton is a broken affordance.
"5 errors" with no row-level detail — Errors shown only as a count. No indication of which rows failed, what the error types are (missing email? malformed URL? encoding issue?), or how to resolve them.
Progress bar is hardcoded CSS, not JS-driven — The bar shows a static width. In a real implementation, a failed import would still show a full-width green bar. Can't be verified as correct behavior from this mockup.
🔸
FP Candidate — Progress bar visible: Since this is explicitly an in-progress state mockup (not initial load), the progress bar being visible is intentional. However, the internal inconsistency (3 rows vs 195 of 300) undermines the state it claims to represent.
🟡 Design Issues 5
Column mapping arrows are decorative text — Not interactive (no hover, no click). In a real mapper, users need to re-assign a column if the auto-detection was wrong. No affordance for changing a mapping.
All mapping dropdowns show only one option — Looks pre-filled rather than a real choice. If auto-mapping is the intended UX, it should be visually distinct from a manual dropdown.
No invalid URL error state shown — If a Drive share URL is malformed, there's no validation message. Only the "5 errors" count is shown, disconnected from the specific field that failed.
Sidebar "Verify" nav item could mislead — Users might think "Verify" on the sidebar refers to Drive URL verification, not email verification. Ambiguous in the context of this page.
No step indicator for multi-stage flow — Connect Drive → Select CSV → Map Columns → Import. Users have no progress context for where they are in a 4-step workflow.
Verdict FAIL — 6 critical issues. The most serious: internally inconsistent numbers (3 rows vs 195 of 300), auto-starting import with no explicit confirmation, and error reporting with no actionable detail. 5 design issues around interaction affordances and workflow progress context. 1 FP on progress bar visibility.
5
Email Verification
3.2.6-email-verify-mockups/email-verify.html
FAIL
STATIC MOCKUP — not a live app
⚠ Iframe is a fixed-size preview of a static HTML mockup; interactive elements are non-functional.
🔴 Critical Issues 5
"Verify All Leads" (355) has no confirmation — One click fires 355 API calls. No confirmation dialog, no "you are about to verify X leads" summary, no undo. A misclick could queue hundreds of verification requests.
Stats (355/892/24) exist with no drillable lead table — Numbers are displayed as summary cards but are not clickable filters. The user sees "24 uncertain" with no path to inspect which 24 leads are uncertain and why.
Verification modal appears untriggered on page load — A modal overlay is shown without any user action. This is aggressive UX — users expect modals to be triggered by a deliberate action, not served on arrival.
No workflow continuity after marking one verified — What happens to the other 354 leads? Does the user need to repeat the action? Are they auto-queued? No next-step guidance.
"Uncertain" status is undefined — No explanation of what "Uncertain" means, what criteria produced it, or what action a user should take. Entire status category is opaque.
🔸
No FP candidates confirmed — The untriggered modal, zero-confirmation bulk verify, and undefined "Uncertain" status are genuine UX failures that would be confusing to real users regardless of the static-vs-live nature of the mockup.
🟡 Design Issues 5
Stat cards have cursor:pointer but aren't clickable — Interactive affordance without interactivity. Users will try to click and find nothing happens. Either make them clickable filters or remove the pointer cursor.
"Disposable email check" label is ambiguous — "Disposable email check" could mean "checking if an email is disposable" or "checking for disposable emails." "Domain check" or "Disposable domain detection" would be clearer.
Green-only icons have accessibility risk — All status indicators are green (ticks, badges). For red-green colorblind users (~8% of males), green and red are difficult to distinguish. Needs icon shape or label redundancy.
"Cancel" button label is too vague — In a queue workflow ("verify 355 leads in the background"), "Cancel" doesn't clarify whether it cancels the entire operation, just the modal, or just future queued items.
No empty state designed — What does this page look like when there are no leads to verify? No guidance for new users or fully-verified tenants.
Verdict FAIL — 5 critical UX failures: untriggered modal, zero-friction bulk verify, opaque "Uncertain" status, no drill-down on stats, and no post-verify workflow continuity. 5 design issues including non-functional pointer cursor, ambiguous labeling, and colorblind accessibility risk.
6
Campaign Compose — Mid-Send at 72% ⚠
3.2.7-campaigns-mockups/campaign-compose.html
FAIL
STATIC MOCKUP — ⚠ shows campaign at 72% send, mid-send state
⚠ Campaign is mid-send (642/892). Hardcoded name "Tobias" and attachment reference are intentional in this mockup. PAUSE/CANCEL controls are absent.
🔴 Critical Issues 4
CTA contradicts send progress — Button says "Send Campaign to 892 Recipients" but 642/892 are already sent. After sending 72% of a campaign, the button should say "Resume Campaign" or "Cancel Campaign" — not re-send to all 892.
Hardcoded personal name in subject + body — Subject: "Your analysis is ready, Tobias". Body: "Hi Tobias,". With merge fields absent from the UI, 892 recipients will see "Tobias" in a mass email — a serious personalization failure.
Email body references attachment but no attachment field exists — "I've attached the full breakdown" with no attachment input in the form. Either remove the reference or add a file attachment field.
"SENDING" badge styled as .badge-draft — Active send state uses a gray/muted badge that visually matches a draft. An actively-sending campaign should be visually distinct from a paused draft — this is a critical state-confusion risk.
🔸
FP Candidate — Send button + progress bar simultaneously visible: Since the mockup explicitly shows a mid-send/resume state, having both a Send button and a progress bar simultaneously may be intentional (e.g. "Resume" is the action, progress bar shows prior work). However, the CTA label "Send Campaign to 892" instead of "Resume Campaign" undermines this interpretation.
🟡 Design Issues 5
"Disposable / invalid" shows "—" instead of 0 — When a count is zero, display "0" not an em dash. Dash implies "unknown" or "not applicable," not "none." Misleading in a data table.
355 unverified leads excluded with no explanation — Leads were silently excluded from the send. No warning banner, no filter toggle, no override option. The user may not realize 28% of their list was dropped.
No pause / resume / cancel controls for in-progress campaign — The mockup shows a mid-send state with no visible controls to actually pause, resume, or cancel. A campaign compose UI that can reach a send state must expose these controls.
No preview or test send before mass send — No "Send Test Email" button, no "Preview" mode. User must commit to the full list without validating how the email renders in a real inbox.
Breadcrumb "Dashboard / Campaigns" doesn't reflect compose state — When a user is composing a new campaign or resuming a send, the breadcrumb doesn't indicate that context. "Dashboard / Campaigns / New Campaign" or "Dashboard / Campaigns / Sending..." would be appropriate.
Verdict FAIL — 4 critical issues: CTA/progress contradiction (wrong label for resume state), hardcoded personal name in mass send, body/attachment mismatch, and send-state badge styled as draft. 5 design issues including silent exclusion of unverified leads, missing pause/cancel controls, and no test send. 1 FP candidate.
7
SMTP Settings ⚠
3.2.8-smtp-config-mockups/smtp-settings.html
NEEDS-REVIEW
STATIC MOCKUP — ⚠ 26-bullet password is an intentional placeholder, not a bug
⚠ Password dots are an intentional design placeholder (not a bug). "Connected via SendGrid" and success banner are shown on initial load — no connection has been tested yet.
🔴 Critical Issues 3
"Connected via SendGrid" status shown before any test — Connection status badge appears on initial page load before the user has entered credentials or run a test. False positive "connected" state misleads the user into thinking setup is complete.
Success result banner permanently visible pre-test — Green success banner is shown before the user has tested anything. Success states should only appear after a successful action, not as a default layout element.
No failure state variants shown — What does the UI look like when authentication fails? When connection times out? When credentials are rejected? These are essential states for an SMTP configuration flow and none are shown.
🔸
FP Candidate — 26-bullet password placeholder: The password field showing 26 dots is explicitly noted as an intentional placeholder design, not a bug. Do not flag this as an issue in any QA report — it misrepresents the mockup's intent.
🟡 Design Issues 4
No clear test-before-save flow — "Test Connection" and "Save Settings" appear as alternative actions rather than a sequence. The user should be required to pass a connection test before Save becomes active — not offered both as equal options.
SendGrid-specific hint becomes wrong for other providers — The provider hint field is SendGrid-specific. If the user switches to Mailgun or AWS SES, the hint becomes misleading. Help text should be provider-conditional.
Form layout breaks 2-column grid at From fields — "From Name" and "From Email" are split differently from the Address fields above, breaking the established grid. Inconsistent column structure across a short form looks unintentional.
TLS toggle subtext is technically imprecise — "Uses TLS on port 465" is not accurate: port 465 uses SMTPS (implicit TLS), while STARTTLS on port 587 upgrades a plain connection. The subtext conflates two distinct protocols.
Verdict NEEDS-REVIEW — 3 critical issues: false-positive "connected" status shown pre-test, permanent success banner before any action, and missing failure state variants. The 26-bullet password is an intentional placeholder — not a bug. 4 design issues around test-before-save flow, grid inconsistency, and technical TLS imprecision.
8
Admin Overview
3.2.9-admin-mockups/admin-overview.html
FAIL
STATIC MOCKUP — not a live app
⚠ Iframe is a fixed-size preview of a static HTML mockup; interactive elements are non-functional.
🔴 Critical Issues 4
"System Health OK" is static but implies live monitoring — Health card appears to show real-time system status but is a static card. An admin seeing "OK" with no last-checked timestamp will assume it is current. If this is polled, the polling interval and stale-data behavior are undefined.
Customer table shows 5 of 24 with no pagination controls — "Showing 5 of 24 customers" with no "View All" or pagination controls. Either expose navigation or show the full list. A hidden 19 customers with no access path is a data-visibility failure.
Suspend and Reactivate buttons are visually identical — Both use the same button style with only a text label difference. In a high-stakes admin context, mis-clicking between suspend and reactivate (potentially on the wrong customer) is a serious operational risk.
No tenant context when drilling into customer detail — If an admin drills into a customer view, there's no breadcrumb or header indicating which tenant they're operating in. Multi-tenant admin UIs require constant tenant context to prevent cross-tenant errors.
🔸
No FP candidates confirmed — The identical suspend/reactivate buttons are a genuine safety concern in a multi-tenant admin context. The static health card's misleading "live" appearance is also a real design problem.
🟡 Design Issues 6
Stats use "this month" while logs use "2 min ago" — inconsistent time frames — Cards show monthly aggregates while the activity log shows relative timestamps. Admin has no unified time context; two different time frames on the same page creates cognitive dissonance.
"Export CSV" scope is ambiguous — Does it export the 5 visible customers? All 24? The currently filtered subset? In an admin context, bulk export of the wrong scope could be a data governance issue.
"Admins" and "Settings" icons are identical SVGs — Two different nav items with the same icon. Users cannot distinguish them by icon alone — a significant discoverability and orientation problem in a nav sidebar.
Trial badge uses amber on white — too muted — Amber (#fbbf24) on a white background has insufficient contrast (~2.9:1) failing WCAG AA for normal text. Needs either a darker amber, a different color, or a darker background context.
Lead count column shows raw numbers with no trend indicator — A table of 5 customers showing lead counts (e.g. "1,247") with no sparkline, delta arrow, or trend vs. last month. Raw numbers without context are hard to act on.
No search or filter on customer table — With 24 tenants, an admin needs at minimum a text search to find a specific customer without scrolling. Missing search is a significant usability gap at scale.
Verdict FAIL — 4 critical issues: static health card implying live monitoring, hidden 19 customers with no pagination, visually identical suspend/reactivate buttons (misclick risk in multi-tenant context), and no tenant context in detail views. 6 design issues including duplicate nav icons, ambiguous export scope, and insufficient badge contrast.