Usability testing vs QA testing: what solo builders actually need

People argue about usability testing versus QA testing as if you had to pick a department. You do not have a department. You built an app with Claude Code, Lovable, Base44, or Cursor, and you are about to send a link to a real person. You need a thin slice of both, and you need it in one evening.

This guide splits the two questions so you stop mixing them up, then puts them back together into the pass a solo builder can actually run. QA asks: did the step complete, and did anything break? Usability asks: could this visitor tell what to do, without your memory? A good session answers both. A vague "test" answers neither.

If you remember one line, remember this. A button that works and cannot be found is a usability bug. A button that can be found and does not work is a QA bug. Both block the launch. They get different sentences in the fix prompt.

The QA question

QA, for your purposes, is a check that the product does the thing and does not fall over. You can answer it without opinions.

Examples that are QA:

• The signup request creates an account, or it shows an error on the page when it does not.
• The page returns a real page, not an error status.
• A script does not throw in the console on the public path.
• Saving an item still shows the item after a refresh.
• A link in the header opens a page that loads.
• The layout is not wider than the window.
• Fields that submit data have labels connected to them.
• Images that mean something have text alternatives.
• The page has a title and a heading, so the person knows where they are.
• A slow public page is noticed, because a door that takes too long is a broken door even when it eventually opens.

None of those require taste. They are true or they are not. A report can list them with severity. A high severity item stops the job or throws. A lower one is a missing title, a missing heading, or a rough edge that did not stop the click. You fix high severity before launch. You schedule the rest. You do not pretend a console error is "just QA" and ship it on the signup page.

QA is also regression. The AI editor will break a step that worked. QA in a solo project means you have one job you can rerun after each large prompt. If that job used to complete and now does not, you have a regression. You do not need a thousand cases to catch the regression that matters. You need the same case, run again.

What QA does not tell you: whether a stranger understood the words. A form can save perfectly and still say "Instantiate your workspace entity." The save works. The person leaves. That failure is the other question.

The usability question

Usability, for your purposes, is whether a specific visitor can tell what to do next and can finish the job without your hints. It is not whether the app is pretty. Pretty is a third thing, and it can wait.

Examples that are usability:

• The first screen's next step is obvious to someone who did not write the headline.
• The button text matches the job. "Submit" on a page about booking a tutor makes people hesitate. "Book this tutor" does not.
• The empty state says what is missing and offers the first action.
• The visitor does not have to know a gesture, a hidden menu, or a name you use internally.
• Errors are sentences. "Try again" with no hint is a usability bug even when the request is the thing that failed.
• The path is short enough that a less comfortable visitor does not get lost. Comfort level belongs on the persona for this reason.
• After success, the screen proves the success. A silent refresh that "worked" feels like a failure.

You judge usability by watching, not by voting. One visitor who cannot find the price is a fact. You do not need a panel. You need to see where they paused, what they tapped, and whether they reached the goal. A session replay is the watch. Screenshots are the stills. Your own memory is the unreliable narrator, because you already know the path.

Usability testing does not mean a lab, a mirror, or a script full of tasks you copied from a textbook. For a solo builder it means: pick a person who is not you, give them one job, do not help, and see if the words on the screen were enough.

A useful usability note names the missing cue. "They scrolled past the hero twice and then opened the footer" tells an editor to move the action. "The vibe is off" tells an editor to restyle at random. Keep the first kind. The fix prompt guide shows how to turn that note into a patch.

What you actually need before a launch

You need both questions answered for one job, on a phone width and on a laptop width, starting signed out. That is the whole program.

In practice the list is short.

• A stranger can tell what the first screen wants them to do. Usability.
• That action runs, and a broken action says so on the page. QA.
• Signup can be finished, and the account is real. Both. Finding the form is usability. Creating the row is QA.
• The first job inside the app can be finished from an empty state. Both again.
• The narrow window does not hide the action or scroll sideways. QA for the overflow, usability if the action is technically on the page and still impossible to understand.
• You watched one stuck path and one successful path, so you know the difference. That watching is usability. The pass or fail is QA.

You do not need a bug tracker with custom fields, a test-case repository, or a weekly triage meeting. You need the report from this pass, the fix prompt, and a second run. If you later connect a tracker you already use, such as Jira, that can hold the same findings. It is optional. The prompt in Claude Code or Cursor is enough to fix the issue this week. GitHub Issues, Slack, and the rest can wait until you want them. They are not the test.

You also do not need to choose a philosophy. Some teams split "QA" and "research" into different jobs so that neither happens on a small project. You are the whole team. Ask both questions every time you run the job.

The pre-launch checklist is this slice written as lines you can tick. The first guide is why the slice comes before you invite a friend. Use those when you want the steps. Stay here if you are still unsure which name to give a bug.

What to skip without pretending you tested

Skipping is fine when you know you skipped it. These are the skips that do not belong in a solo launch.

A forty-page test plan. You will not run it. Write the one job instead.

Automated unit tests for every component, as a substitute for the signed-out pass. Tests can be wonderful and they do not click the public page as a stranger. If you have them, keep them. Do not let them replace the session.

A redesign based on a feeling that the app "looks simple, so it is usable." Simple and confusing coexist. The proof is a visitor who finishes.

A survey. "Would you use this?" does not find the unlabeled field. Ask a real person to try the job after the session is clean. Opinions before that are about the pitch, not the product.

Pixel comparisons across ten devices. The mobile guide explains the two widths that matter. More devices are a later hobby.

Load testing, security audits, and compliance programs. Real topics, wrong week, unless you already take money or sensitive data at a scale that demands them. A broken signup still comes first. If you do take payment, test the payment path yourself. Do not confuse that with the practice visitor, who will stop before paying.

Skipping the console because the page "looks fine" is not on this list. That one is a QA item. Look, or use a session that records it.

One run that answers both

You can answer both questions with the same three visitors. That is the point of running people, not only checkers.

Paste the URL. Draft three visitors. Edit the goals so each one can pass or fail: sign up and see the account, find the price or the way to start, follow the main button into the first job. Set at least one device to a phone. Accept once. Each visitor gets a real browser. They can click and sign up like a new customer. They will not pay, send a text, message a real person, delete an account, or change a password that is already in use.

While they run, the session records the QA facts on its own. Pages that return errors. Console errors. Slow opens. Broken links. Missing titles, headings, and labels. Images missing alt text. Layouts that overflow the window. Those land in the report with screenshots and severity.

The same visit answers the usability question, because a visitor with a goal either reaches it or gets stuck. Stuck on a page that loaded fine is often usability: the next step was unclear, the button did not look like the goal, the empty state was mute. The replay is where you see the pause, the wrong tap, the scroll past the control. The screenshot is the still of that moment. The verdict, reached or stuck or unclear, is the QA-style result. The path is the usability evidence. You need both halves of the report. Reading only the finding titles will miss a visitor who "reached" the goal by a confused route you would not accept. Watching only the replay will miss a console error that will break the next prompt.

The fix prompt is where you tell the editor which kind of fix you want. For a QA failure, "what should happen" is the working step and the visible error. For a usability failure, "what should happen" is a cue a specific visitor can follow. The prompt from the report includes the visitor, the goal, and the findings. Add a sentence if the findings are QA and your replay showed a usability problem the titles did not capture. "The page loaded, and the visitor still never tapped Start, because it sits under three screens of quotes. Move Start above the quotes." That sentence is usability, and it belongs in the same paste. The editor should keep the design except for that move. Then you run the goal again.

This is as much process as a solo builder needs. It is also as little as you can get away with. One job, both questions, a record, a prompt, a second run.

How to label a finding in your notes

When you are unsure, use this test.

Can you describe the failure without mentioning a person's confusion? "The create request returns an error and the page stays silent." That is QA. Fix the request and the message.

Does the mechanics succeed while a named visitor still cannot finish? "The pricing page exists, and the visitor who was looking for the price never opened it, because nothing on the home page says price." That is usability. Add a visible way.

Does it do both? "The form has no labels, so the visitor typed the password into the email field, and the create request failed." The missing label is usability and QA at once. The failed create is QA. Your prompt should mention both, with the label first if the bad input caused the error.

Severity follows the job, not the category. A usability bug that stops signup is severe. A QA bug on a page nobody needs for the first job can wait. Do not keep a separate backlog for "UX" that you never open. If it blocks the three goals, it is this week's prompt. If it does not, write it down in one line and return after launch.

Share the language with yourself so the next prompt stays clean. Tag your note "QA" or "usability" in the first line of the prompt. Claude Code and Cursor do not need the tag, and you do. It stops you from asking for a new visual system when the request failed.

A worked evening

Made-up course app, so the labels are obvious. You built it in Cursor. The job is "sign up and open the first lesson."

The phone visitor signs up. QA: the account is created. Usability: the next screen says "Dashboard" and the lesson is inside a menu named with your internal word, "Modules." The visitor gets stuck. The page did not error. The replay shows them opening Help, then Account, then stopping. You write a usability prompt: on the first visit, show a button called "Open the first lesson" on the dashboard. Fence: do not rename the data model, only the words and the button the visitor sees.

The laptop visitor hunts for a price. QA: the pricing route returns an error. That is not a wording problem. You write a QA prompt: the footer link /pricing should load the page you already wrote, not an error. The replay shows they found the link. They could tell what to do. The site failed the tap. Different prompt, different fix. Do not combine it with the lesson button. Two prompts, two reruns.

The third visitor follows "Start learning" and hits a console error on the lesson page that leaves a blank player. QA again. The screenshot is a blank box. The prompt quotes the console line from the report and asks for a visible message if the player cannot load, plus a fix for the throw. You do not ask whether the player is pretty.

By the end of the evening you have run both kinds of test and you have not adopted a framework. You have three goals, a handful of labeled prompts, and a second run of each. That is what solo builders need from usability testing and from QA. The names are there so you write the right sentence. The session is there so you do not have to be the stranger and the checker at the same time.

Questions people ask