How to create user personas for testing your AI-built app

A persona, for testing, is a stand-in for a visitor you are not. It is not a poster on a wall and it is not a marketing story. It is a short brief that tells a test what to try, on which kind of screen, with how much patience for confusing software.

If you built your app with Claude Code, Lovable, Base44, or Cursor, you are the wrong person to improvise that brief in your head. You will test the path you just wrote. A written persona keeps the test honest. This guide shows how to create three of them, how to edit a draft instead of starting from a blank page, and how to send each one through your app in a real browser.

The point of the brief is a decision. After the session you should be able to say "this visitor finished" or "this visitor got stuck here." If the persona is too vague for that sentence, it is not ready.

What belongs on the card

Keep the card small. Five fields are enough, and they match what a serious test actually uses.

• Name. A name makes the report readable. "Maya got stuck on /signup" is easier to scan than "Visitor 2." The name does not need to be clever.
• Role. One line about why they showed up. "First-time visitor," "comparing options," or "ready to try it" is a role. "Busy mom of three who loves pilates" is a story. Use a role that changes the job.
• Goal. One sentence with a finish line. "Sign up and reach a screen that shows the account" can pass or fail. "Explore the app" cannot.
• Comfort with software. Call it low, medium, or high if you want a scale. Low means they need an obvious button and plain words. High means they will open a menu, but they still should not need your private notes.
• Device. A phone or a laptop is the split that matters first. A phone-width window catches sideways scroll and tiny tap targets. A laptop window catches a layout that only works when it is wide.

You can write those five lines on paper. You can also let a tool draft them from the public page and then edit. Editing is faster and, for a solo builder, usually better. A blank page invites you to invent a character. A draft invites you to correct a goal.

Write the finish line as something a screenshot can show. "The header contains the email they typed" is checkable. "They feel welcomed" is not. Persqo judges a signup goal by looking for a welcome, a note about email, an account screen, or a path that looks like the inside of the app. If your success screen says something else, put those words in the goal so a human reading the replay can judge it even when a keyword would miss.

Goals that can pass or fail

The goal is the only field that decides the session. Spend your time there.

A testable goal names the action and the proof:

• "Sign up on the home page and land on a screen that shows the new account."
• "Find the pricing page, or find the sentence that says what it costs."
• "Use the Start free button and get past the first screen."
• "Add one item and see it in the list."
• "Open the sample project and find the share button."

A goal that cannot fail wastes the run. "Look around and see if anything is confusing" will always be a little true. "Check the design" will produce opinions, not a stuck page. "Make sure it works" hides which job you mean.

Match the goal to a button a stranger can see. If the page says "Join the waitlist," the goal is to join the waitlist and see a confirmation, not to "create a workspace" that your prompt mentioned and the page never shows. Test the product that is published, not the product in your head.

Give the three goals different jobs. If all three say "sign up," you will learn signup three times and learn nothing about the price or the main path. A useful trio for most AI-built apps is: sign up or start, find the price or the plan, and follow the primary button. If your page has no price, change the second goal to the next real task, such as "find how to contact a human" or "find an example of the finished work."

Write the goal the way you would write a task for a contractor who has never seen the product. Include the proof. Leave out your reason. "Sign up and see the email in the header" is a task. "Sign up so we can validate retention" is a strategy. The browser can do the task.

Where solo builders usually drift

A few habits make personas pretty and useless.

The life story. You add an age, a city, a job title, and a quote. None of it changes the click. The session still needs a goal. Cut the biography back to a role.

The persona who is you. "Power user, knows every shortcut, uses a laptop, goal: do the advanced export." That test protects your favorite path. Include one visitor who is less comfortable than you, on a phone, trying the first run.

The persona who wants everything. "Sign up, invite a team, connect billing, and export a PDF." That is four tests wearing one name. Split them. Run the first job until it passes, then add the next job as a new goal.

The invented detail. Do not put a phone number, a price, or a company name on the card unless it is already on your page. A test should not carry facts you made up. If the price is not public, the goal is "find whether a price is shown," not "confirm that it costs a number you hope to charge."

The frozen card. Your app changes every time you accept a prompt. A persona from last week may describe a button you renamed. Read the goals again after a large edit. Update the words so they match the page a stranger sees today.

The crowd. Five personas feel more serious than three. They also take longer to read, and the fourth goal is often a rewording of the first. Three distinct jobs will teach you more than seven similar ones. When those three pass, you have earned a fourth.

Draft from the page, then edit

You do not have to invent the first draft. Persqo reads the public page you paste and drafts three visitors. It looks at the title, the words on the page, and the buttons. A button that says sign up, start, try, join, or register pushes one goal toward signup. A button about price or plans pushes another goal toward pricing. Another visitor follows the main action the page is already showing.

Each draft has a name, a role, a goal, a comfort level, and a device. The devices are often a mix, such as a phone, a laptop, and another phone. Comfort is often a mix too, so one visitor needs the obvious path and another will tolerate a menu. The exact names depend on the page. Read them as a proposal, not as a verdict.

Then edit, in this order:

1. Read each goal out loud. If you cannot picture the last screen, rewrite the goal.
2. Check that the three goals are different jobs.
3. Check that one of them matches the job you care about this week. If it does not, replace it.
4. Check the device. If you have never looked at the app on a phone, keep at least one phone visitor.
5. Accept once. After you accept, the browsers run those goals. Changing your mind mid-run is how you end up with a report about a goal you no longer mean.

Accepting once is a feature, not a limitation. It stops you from nudging the test toward the path you already like. If the draft is wrong, fix it before the run. If the run teaches you that the goal was wrong, edit and run again. Do not edit the story after you have seen the result and pretend it was the plan.

The same draft step is the right moment to delete fluff. If a role says something the page cannot support, simplify the role to what the visitor is here to do. The report will quote the role back to you inside the fix prompt. A clear role makes that prompt easier to paste into Claude Code or Cursor.

A worked example on a tutoring page

This is a pattern you can copy. It is a made-up tutoring page, not a customer story.

The page headline is "Find a tutor for this week." The buttons say "Browse tutors" and "Sign up to book." There is no price on the home page. There is a link called "How pricing works" in the footer.

A weak set of personas would be three students with different hobbies, all with the goal "see if the site is trustworthy." You would learn nothing you can fix tonight.

A useful set looks more like this:

• A first-time visitor on a phone, low comfort, goal: "Sign up and reach a screen that shows the account."
• A visitor comparing options on a laptop, medium comfort, goal: "Find how pricing works and read what it costs, or see that the cost is not listed."
• A visitor who is ready to try it on a phone, higher comfort, goal: "Use Browse tutors and open one tutor."

You can write that set yourself. On Persqo, the draft will often land near it, because the page has a signup-style button, a pricing link, and a clear main action. Your edit might only be the finish line on signup: you add "and reach a screen that shows the account" so a toast that says "welcome" and then dumps the visitor back on the home page does not count as success in your own notes. The replay will still show the truth either way. A sharper goal makes your own reading faster.

When the sessions run, each visitor gets their own browser. The signup visitor can fill the form and submit it like a new customer. The test address is visitor@example.com, so you may see that account in your database. The visitor will not pay, send a text, or touch someone else's account. If booking ends on a payment page, the visitor stops before paying. You still learn whether they could reach a tutor and start to book.

The report lists problems with screenshots. You watch the session replay for the visitor who got stuck. The fix prompt names that visitor, the device, the goal, and the findings, ready to paste into Claude Code or Cursor. If the tutor cards overflow the phone, that finding belongs to the phone visitor, which is why the device field was worth filling in. The mobile guide explains what a phone-width session can and cannot show.

What the session does with the card

It helps to know which fields change behavior, so you do not obsess over the ones that do not.

The goal changes where the visitor tries to go. A signup goal points the session at buttons like sign up, register, start, or try, and at email fields. A pricing goal points it at price and plan language. A goal about the main button follows that action. The session also notices broken pages, console errors, missing page titles, missing headings, images without alt text, unlabeled form fields, slow opens, and layouts that scroll sideways.

The device changes the window. A phone visitor uses a phone-sized window for the whole visit. A laptop visitor uses a wide window and is also checked at a phone width, so a sideways scroll is harder to miss. This is a real browser sized like a phone. It is not a pile of physical devices. For the first pass, the size is the bug you are hunting.

The comfort level is part of the brief the report and the fix prompt carry. It reminds you, and the editor, who the screen failed. A missing label is a bigger problem for a low-comfort visitor than a collapsed advanced menu. You still fix the label. The field keeps you from dismissing it as "only a power user would care," when the visitor on the card was never a power user.

The name and the role show up in the report so you can tell the three sessions apart. They also show up in the fix prompt: "Fix the public site for a visitor like this, with this role, on this device." That is why a plain role is better than a joke. The editor will read it.

After you accept

Let the three sessions finish. Then read in this order.

1. Did each visitor reach the goal, get stuck, or end without a clear result?
2. For a stuck visitor, open the screenshot and the replay before you read every small note.
3. For an unclear result, tighten the goal and run that one again. An unclear result is often a fuzzy finish line, not a mysterious bug.
4. Copy the fix prompt for the issue that blocks a goal. Paste it into Claude Code, Cursor, Lovable, or Base44.
5. Run the same persona again after the patch.

Watch the replay once even when the goal was reached. Reaching the goal means the finish line showed up. It does not mean the path was calm. You may see the visitor open the wrong menu first, or scroll past the button you thought was obvious. That is the usability half of the test, and the session replay guide shows what to look for without turning it into a novel.

Keep the cards. The next time you ship a prompt that touches the first screen, run the same three goals. Personas are reusable because the jobs are stable even when the pixels move. If a button label changes, update the goal's words and keep the job.

If you want a broader list of jobs beyond these three, use them as the top of the pre-launch checklist. Do not invent ten personas to match ten checklist lines. Reuse the three visitors and point their goals at the next unchecked line when the first goals pass.

A blank card you can fill in tonight

Copy this and fill it for your app. If a line does not change a click, delete it.

• Visitor A. Role: first visit. Comfort: low. Device: phone. Goal: sign up and reach a screen that proves the account exists.
• Visitor B. Role: comparing options. Comfort: medium. Device: laptop. Goal: find the price, or find out that the price is not on the public page.
• Visitor C. Role: ready to start. Comfort: high. Device: phone. Goal: follow the main button and finish the first real task.

Paste your URL, compare the draft to this card, and edit until the goals match. Then accept once. You have created personas the useful way: short, different, and possible to fail.

Questions people ask