By Mehdi HassanWhat is good signup flow UX for a SaaS product?
Good signup flow UX gets a motivated visitor from "Sign up" to inside the product with as few decisions as possible. The signup form isn't where you learn about the user, qualify the lead or sell the plan. It's a door, and the best doors are short.
The pressure to add fields usually comes from inside the company. Sales wants company size, marketing wants the referral source, and product wants the use case. Each request is reasonable alone, but together they turn a quick form into a slow one. The fix isn't to ignore those needs. It's to collect the answers later, when the user has a reason to give them. Our SaaS onboarding UX guide covers how signup fits into the whole first session.
Which fields should a sign up form ask for?
A sign up form should ask only for the fields needed to create the account and deliver the first result. For most B2B SaaS products, that's an email address and either a password, a magic link or an SSO button. Name can come next, and almost everything else can wait.
Field | Ask at signup? | When to ask instead |
|---|---|---|
Work email | Yes | Required to create the account |
Password | Only if you don't offer SSO, magic links or passkeys | At signup, or never |
Full name | Optional | First screen inside the product, or from SSO |
Company name | Usually no | When creating the workspace, pre-filled from the email domain |
Role or job title | No | Onboarding survey, if it changes the experience |
Company size | No | Onboarding survey or enrichment tool |
Phone number | No, unless it's core to the product | Before a sales call or when enabling SMS features |
How did you hear about us? | No | A skippable question after activation |
Use one rule for every field: if the product can't work without it right now, ask. If it can, wait. Where you can infer the answer, such as a company name from a work email domain, pre-fill it and let the user correct it. For more on validation, defaults and multi-step forms, see our form design guide for web apps.
What order should a registration flow follow?
A registration flow should go from the lowest-effort step to the highest, with value as early as possible. The usual order is choose a method, confirm identity, create or join a workspace, then reach the first useful screen. Questions and setup come after that, not before.
Choose a sign-in method
Show SSO buttons first for B2B (Google, then Microsoft), then an email field. Don't make users pick between "Sign up" and "Log in" if you can detect which one they need from the email.
Confirm identity
SSO confirms it for you. For email, send a magic link or a short code, or accept a password and verify the address in the background.
Create or join a workspace
If someone from the same company domain already has a workspace, offer to join it or request access. Otherwise create one with a pre-filled name.
Land somewhere useful
Put the user on a screen where they can start the core task: a template, sample data or the first empty state with a single clear action.
Ask questions only if they change things
If you need to personalize, ask one to three skippable questions here. Our guide to onboarding survey design covers which ones earn their place.
Should you use magic links, SSO or passkeys?
Use SSO as the main option for B2B products, magic links or one-time codes as the email fallback, and passkeys as an upgrade once users are in. Each method removes the password problem in a different way, and each has a failure mode you need to design for.
Method | Best for | Watch out for |
|---|---|---|
Google or Microsoft SSO | B2B tools where most users have a work account | Personal Gmail accounts creating a separate workspace from their team |
Magic link | Low-frequency products and simple consumer apps | Links opened on a different device, corporate email scanners clicking links first |
One-time code by email | Users on mobile or switching devices | Codes landing in spam; needs good deliverability |
Passkeys | Returning users on modern browsers and devices | Explaining what a passkey is; recovery when a device is lost |
Email and password | Users who expect it, and as a universal fallback | Reset flows, weak passwords, credential stuffing |
SAML or enterprise SSO | Larger customers with an identity provider | Usually a paid-plan feature; setup is an admin task |
Passkeys are built on the Web Authentication standard, documented on MDN's Web Authentication API page. The UX lesson is to offer them after signup ("Sign in faster next time with a passkey") rather than making them the only door on day one, because many users still don't know what they are.
Implementation notes for magic links and codes
Magic links fail in two predictable ways. First, some corporate email security tools open links to scan them, which can consume a single-use link before the user clicks it. Second, users often request a link on a laptop and open it on their phone. Both are easier to handle with a short numeric code the user types into the tab they started in, or with a link that confirms the original session rather than logging in whichever device opens it.
Also design the waiting screen. Tell users which address you sent to, offer to resend after a short delay, offer to change the address, and give a fallback such as "Use a password instead". If the email doesn't arrive, the product looks broken, so authentication email deliverability (SPF, DKIM and DMARC) is part of signup UX.
What is progressive profiling in SaaS signup best practices?
Progressive profiling means collecting user details over time, at the moment each one becomes useful, instead of all at signup. It's one of the most reliable SaaS signup best practices because it keeps the form short while still giving sales and product the data they need.
- Ask when the answer pays off right away. "What's your team size?" lands better on a pricing or invite screen than on the signup form.
- Use enrichment where it's appropriate. For work emails, a data enrichment service can often fill in company size and industry without asking at all. Say so in your privacy policy.
- Ask one thing at a time. A single question in context beats a five-field form, even if the five fields are optional.
- Never ask twice. Store every answer and pre-fill it everywhere it reappears.
If sales needs to qualify users before a demo, put that form on the demo request path, not the self-serve signup. Mixing the two makes both worse. Our guide to PLG website design covers how the marketing site should split those paths.
How should signup errors and edge cases work?
Signup errors should explain what happened and offer the next action in the same message. Most signup failures come from a handful of cases: an existing account, a mistyped email, a blocked domain and an expired link. Design each one deliberately instead of showing a generic error.
Situation | What to show |
|---|---|
Email already has an account | "You already have an account. Log in instead?" with the email pre-filled |
Likely typo in the domain | "Did you mean name@gmail.com?" with one-tap correction |
Personal email on a work-only product | Explain why a work email is needed, and offer a way to contact sales |
Expired magic link | Explain it expired and send a new one with one click |
Teammate's company already has a workspace | Offer to request access, with the admin's name if policy allows |
Validate fields inline as the user moves on, not on every keystroke. Keep the user's input when something fails, and never clear a filled form. Password rules belong next to the field before the user types, not in an error after they submit.
How do you know if your signup flow is working?
Your signup flow is working when most people who start it finish it, and when the people who finish reach the first useful screen quickly. Track each step as its own event so you can see exactly where users drop. A funnel with only "visited signup" and "created account" can't tell you which step to fix.
Measure the time from landing on the signup page to the first meaningful action inside the product, not just account creation. That number connects signup to time to value, which is what actually predicts retention. Then watch what happens right after signup; a short onboarding checklist is often the next lever. Want a second pair of eyes on your signup flow? Book a free 30-minute call.
