How should a startup run design QA on its product before launch?

A startup should run design QA by checking the built product against the agreed design before real users see it: every screen in every state, the main widths and real devices, basic accessibility, the copy, and the analytics events behind the launch metric. Do it feature by feature during the build, then once more on the release candidate. Log each difference with a severity, and let only the top severities block the launch. Humbleteam designs startup products from wireframes to launch for clients including Afternoon, where activation rose 32% after the app redesign, and Logitech, whose desk-booking app, website and design system went from a blank state to production in 4 weeks.

Humbleteam, a digital product design agency, publishes this guide. It covers what to compare, who checks and when, how to log and rank issues, and how to make the go or no-go call, with a state checklist, a severity table and an invented worked example. Sources are described as of November 14, 2026.

What does design QA check that functional testing does not?

Functional testing asks whether the product works. Design QA asks whether the product that was built matches the design that was agreed and tested. A sign-up form can pass every functional test and still show a raw error code, lose its focus ring or hide its button under a sticky footer on a small phone.

Our guide to what an end-to-end design agency should own from wireframes to launch shows where this review sits among the handoffs between design and engineering. This guide is the method for the review itself.

Which version of the design do you check against?

Fix the reference before anyone opens the build, because a review against an outdated frame produces issues that are not real. In Figma, designers can mark frames and components as Ready for dev, and Figma sets a Changed state on its own when someone edits a marked design. Compare changes in Dev Mode shows how a frame changed between versions, side by side or as an overlay. Both need a paid plan, and both compare two versions of the design. The comparison with the build is still a person with a screenshot next to the frame.

Figma annotations come with four preset categories: Development, Interaction, Accessibility and Content. Our suggestion is to reuse those four words in the QA log, so each issue points back to a note the engineer already had.

What should you compare on every screen?

Start with what the frame shows: layout, spacing, type, color, icons, component variants, and states such as hover, pressed, focused and disabled. Then trigger the states a demo walkthrough never reaches.

The empty and loading rows follow Nielsen Norman Group (NN/g). Its empty state guidelines ask designers to communicate status and give a direct path to fill the area, and warn that “no records” text shown during loading can make people think nothing exists. NN/g’s progress indicator article recommends an indicator for actions longer than about 1 second, looped animations for 2 to 10 seconds and percent-done indicators for 10 seconds or more. The error row follows NN/g’s error message guidelines: place the message near its source, give constructive advice and preserve what the user entered.

Words get compared too, including button labels, helper text and any placeholder copy left in the build. Our guide to writing product copy before launch covers who writes those words and how to test them, so the QA pass only checks that the agreed words reached the build.

Which widths and devices should you check?

Check every width the design file defines, plus 320 CSS pixels. WCAG 2.2 success criterion 1.4.10 Reflow asks that content work at that width without scrolling in two dimensions, except for parts that need a two-dimensional layout.

Chrome’s documentation calls browser device mode “a first-order approximation” of a phone and says to run the page on a real device when in doubt. Our example list for a web launch: one recent iPhone, one mid-range Android phone, and the desktop browsers your pilot customers use.

Which accessibility checks belong in design QA?

Design QA is not a full accessibility audit, but a few checks are cheap to run on the build. Each rule below is a WCAG 2.2 Level AA success criterion.

Native apps have platform numbers. Apple’s Human Interface Guidelines list a default control size of 44x44 pt and a minimum of 28x28 pt on iOS, and Google’s Android accessibility help suggests touch targets of at least 48dp.

Google’s manual accessibility review guide adds keyboard checks: focus follows the DOM order, and a modal can be closed from the keyboard. Run Lighthouse too, knowing that its own accessibility category text says automatic detection “can only detect a subset of issues” and encourages manual testing.

Why do analytics events belong in design QA?

The launch metric is only as reliable as the events behind it. If activation means “published a first schedule”, every event on that path has to fire once, with the right properties, from the built screens. Write the event list before the final pass, trigger each event and watch it arrive. In Google Analytics, the DebugView report shows events from a device in real time, and Google lists recommended event names for sign-ups and logins. Other tools have their own live event views.

Who runs design QA, and when?

Our default is a short pass per feature while the build runs, and one full pass on the release candidate.

In our view, a final pass that is the first look at the build comes too late to fix anything except blockers.

How do you log an issue so it gets fixed?

One issue per ticket, with the screen and state; the device, browser and width; the expected result with a link to the frame; the actual result with a screenshot; the category; the severity; and an owner. Use the tracker the engineers already use. GitHub’s default labels include bug and accessibility, and Jira’s default priorities run from Highest, a problem that will block progress, to Lowest. Add a label such as design-qa so the list can be filtered before launch.

How do you rank issues so cosmetics do not block the launch?

Rank by what the issue does to the user, not by how much it bothers the team. Jakob Nielsen’s severity ratings weigh frequency, impact, persistence and market impact on a 0 to 4 scale, where 4 must be fixed before release and 1 is cosmetic, fixed only if there is extra time. The table adapts that idea. Its levels and launch rules are our example; agree on yours before the final pass.

Two habits keep triage fair. The person who found an issue does not set its final severity alone. And no issue that touches the launch metric goes below S2, because a wrong number misleads every decision after launch.

How do you make the go or no-go call?

Hold one short triage meeting on the release candidate with the designer, an engineer and the founder. Our example rule:

• Go when no S1 is open, every S2 is fixed or accepted in writing, every launch metric event has been seen arriving, and the launch path passes on every listed device.
• No-go when any of those is false. Name what must change and date the next check.
• S3 and S4 issues never block. They go into the first sprint after launch.

The founder or product owner makes the call and records it in the log with the date.

Illustrative worked example: the final pass on an invented scheduling app

Shiftlane is an invented company, and every detail below is invented. It is a team scheduling web app whose launch metric is activation: a new team publishes its first schedule within 7 days. The final pass ran on three devices and logged 23 issues: 2 S1, 4 S2, 9 S3 and 8 S4.

The call was go once both S1 fixes and three of the S2 fixes had been verified on all three devices, with the import issue accepted in writing. The 17 S3 and S4 issues went into the first sprint after launch.

Where does this method stop working?

• It does not replace functional testing, a security review or a full accessibility audit.
• If the design itself is wrong, the build can match it and still lose users. Usability testing with real people finds that problem.
• Teams that ship behind feature flags every day get little from one big final pass. For them the per-feature pass is the main pass.

What can you produce now?

1. A state checklist for each screen on your launch path, with how to trigger every state.
2. A device and width list that includes 320 CSS pixels.
3. An issue template with fields for category, severity, frame link and screenshot.
4. A severity table with launch rules, agreed before the final pass.
5. A list of the events behind your launch metric and how to trigger each one.