The Signup Flow: Friction That Filters and Friction That Kills
Every signup field and step trades signups for information. Some friction filters for fit; most just taxes. This guide classifies the steps in a small SaaS signup - work email, verification, company details, plan choice, card - and sets the order that keeps the motivated and loses the rest kindly.
The short answer
Ask for the least you need to create a usable account, in the order the visitor can bear: email and password (or social sign-in) first, verification handled without breaking momentum, everything else - company details, team size, use case - asked inside the product, where the visitor has something to show for answering. The notorious conversion killer is demanding a card for a trial that markets itself as free; if the model needs the card, say so at the offer, not at step three. Friction that filters (a question that routes the trial correctly) can stay; friction that merely feeds your database goes.
Classify each step: needed, routing, or rent
Walk the flow and label every element. Needed-to-function: credentials, and the one or two facts the product cannot start without. Routing: questions whose answers change the trial (which template, which integration first) - these can earn their place if the visitor sees the benefit immediately. Rent: fields collected because sales or habit wants them - company size, phone number, 'how did you hear' - charged against completion for no visitor benefit. Rent fields move to onboarding or to the post-activation profile, where completion is no longer at stake.
Verification without the cliff
Email verification is necessary hygiene and a classic abandonment cliff: the visitor leaves to find the email, the moment cools, the tab closes. Soften it where your risk model allows: let the trial start and verify in parallel, with a persistent, polite reminder; make the verification email arrive fast, from a recognisable sender, with one clear button; and handle the expired-link case gracefully. Measure the verify-completion rate as its own step in the funnel; it is routinely the largest single drop in small SaaS signups and the least discussed.
The card question, answered at the offer
Requiring a card for a trial has real arguments: fewer junk trials, smoother conversion to paid. It also costs signups and, handled silently, trust. The bench rule is about placement, not ideology: the requirement belongs in the offer text wherever the trial is promoted - homepage, pricing page, ads - in the same sentence as the trial's length. A visitor who learns about the card at the final step experiences it as a trap regardless of your intentions, and traps convert once. If you test card versus no-card, read activation and paid conversion, not signup counts: the no-card flow should win signups; the question is what it does downstream.
Do not make them choose a plan before they have seen the product
Forcing a tier decision at signup asks the visitor to price a product they have not touched. Default the trial to the plan most new customers belong on, state that it can be changed any time, and let the plan choice happen at conversion, informed by actual usage. Where tiers differ by audience (individual versus team), a routing question ('Just me, or a team?') is legitimate friction that improves the trial. The distinction is whether the question serves the visitor's next ten minutes or your pricing architecture.
Instrument the flow step by step
Report the signup flow as its own mini-funnel: started, credentials completed, verified, first session begun, activated. Drops get diagnosed per step, and fixes are aimed at the step, not at 'the signup rate'. A flow fixed this way improves steadily; a flow judged as one number gets redesigned in panics. Keep a test account path for your own monthly walk-through - sign up as a stranger, on a phone, and feel the flow your numbers describe.
Social sign-in and the expectations it sets
Offering sign-in with an existing account (a search or workplace identity) removes the password field and its reset risk, and for many small SaaS it lifts completion meaningfully. It also sets expectations: the user assumes one-click return, so the sign-in button must be as prominent on the login page as it was at signup, and the account created should never demand a password it never set. For team products, note the boundary: the day an employer mandates their own identity system, your social sign-in is a migration question. Neither is an argument against offering it; both are arguments for recording which accounts use which method, so the future migration is a list, not an archaeological dig.
Sources and evidence on the record
- CXL, CXL blog - practitioner writing on testing method, research process and optimisation programme discipline.
- Nielsen Norman Group, articles - usability research on reading behaviour, forms, response times and navigation.
Evidence basis: Method guide. Any figure quoted is attributed to a named published source listed below; worked examples are labelled illustrations with round numbers, not measurements. Applies when: Any SaaS with a self-serve signup