Frictionless SaaS, Chapter 3: Signup Design - Stop Interrogating People Before They Can Use Your Product
This is the fourth post in the Frictionless SaaS blog series. Part 0 looked at the friction points before signup. Chapter 1 introduced silent churn. Chapter 2 gave us the SAFE Journey map and Time to Value. Now we walk into Part II — Onboarding Without Friction — starting with the single most over-engineered screen in SaaS: the signup form.
Every Field Is a Tax You Pay in Conversions
A user has decided to try your product. That is an extraordinary thing. They’ve clicked a link, scanned your landing page, made the judgment that you might solve their problem, and chosen to spend their limited attention on you instead of the other thirty tabs fighting for it. They’ve landed on your signup page, ready to give you a chance.
And then you ask them for their phone number.
And their company name.
And their job title.
And their company size, from a drop-down with eleven options.
And a checkbox confirming they’ve read a 4,000-word privacy policy.
And a CAPTCHA.
Every field you add to that form is a tax you are charging the user to access your product — a product they have not yet experienced, whose value they have not yet felt, whose trustworthiness they have not yet verified. Chapter 3 of Frictionless SaaS is about the fact that this tax is not free. It comes directly out of your conversion rate, and it compounds across every cohort you will ever acquire.
The Minimum Viable Signup
The central idea of this chapter is brutally simple:
Ask for the minimum information required to create an account. Nothing more.
What is actually required to create an account and let a user access your product? An email address and a password. That’s it. Everything else you’re asking for is for your benefit — your sales team, your segmentation, your customer success pipeline — not the user’s. And you are making the user pay for your benefit before they have received any of theirs.
The Minimum Viable Signup is email, password, submit. One text field. One password field. One button. Done. Your user is now in your product. Everything else you want to know — company size, job title, use case, team structure, industry — can be asked for inside the product, after they’ve felt real value. At that point, they’re no longer a stranger handing over data to a site they don’t trust. They’re an invested user helping you serve them better. The ask feels entirely different.
The numbers are not kind to long forms
The research on signup friction is unambiguous, and the book lays out the pattern clearly:
- Every additional field on your signup form reduces conversion by roughly 3–5%.
- Every additional step in your signup flow reduces conversion by roughly 5–10%.
- This compounds. A 7-field, 3-step signup isn’t a little worse than a 2-field, 1-step signup. It can be half as effective.
And yet almost every SaaS product you’ve seen has unnecessary signup friction. Why? Not because founders are careless. Because founders are afraid — afraid that if they don’t collect the information upfront, they’ll never get it. The irony is that they’re trading a guaranteed drop in conversion for a speculative lift in data completeness, and the math almost never works out in their favor.
The edge cases: verification and legal
There are a handful of genuinely unavoidable steps. Email verification is worth the one extra click because it keeps spam accounts out and confirms the address is real. Terms and privacy consent is required for legal compliance in most jurisdictions. The book’s position is that these are acceptable — but even here, you should minimize the friction. Instant verification links. A single checkbox, not a scroll-and-sign ritual. No forced password complexity rules that force users to invent and then forget a credential.
Everything else — display name, avatar, preferred language, theme choice, welcome tour — can wait.
The Progressive Commitment Model
“But we really do need to know what company they work at.” Fine. You can have it. Just not on day zero.
Chapter 3 introduces what the book calls the Progressive Commitment Model: a staged approach to collecting user information, where each new question is asked at the moment in the user’s journey where it feels natural rather than intrusive. The insight is the same one that makes freemium convert better than free trials: people are much more willing to commit in small increments than to commit all at once.
A sketch of how this looks in practice:
- Day 0, signup: Email and password. That’s the entire form.
- First login: Ask for a display name, optionally a profile picture. The user is already inside — this feels lightweight because it’s about them, not about you.
- After first value: Now ask for company name, company size, use case. They’ve felt the product work. They understand why you might want to know.
- After consistent use: Ask about integrations, advanced settings, team invites. The context justifies the question.
- At the upgrade moment: Ask for billing details, phone number, address. You’re taking their money; of course you need these.
None of these asks feels like an interrogation because each one arrives at the exact moment when the user would expect to be asked. You’re not questioning them. You’re guiding them through a progression. By the time you’ve collected all 15 pieces of information you originally wanted on day zero, the user doesn’t resent a single one of them — because each one showed up in a context where it made sense.
The counterintuitive result the book reports: teams that switch to progressive commitment often double their profile completion rate, even though they ask for less upfront. You get more data, not less, because users actually finish what they start.
The timing rules that separate this from annoying pop-ups
Done poorly, progressive commitment turns into a drip of nagging modals the user learns to dismiss. Done well, it feels invisible. Chapter 3 gets specific about the timing rules that make the difference — when an ask is too early, when it’s too late, when it’s the right moment in a user’s flow, and how to avoid asking for a new piece of information in every session. I’m deliberately not reproducing that part here, because the tactical discipline is where the chapter earns its keep, and it’s best read in full in the book.
A 10-Minute Audit You Can Do Today
Before you touch any code, do this:
- Open your own signup page in an incognito window.
- Count every field. Every checkbox. Every click. Every screen.
- For each one, ask: is this required to let the user experience the product for the first time?
- Everything that isn’t — every single thing — is a candidate for deletion or deferral.
Most teams doing this exercise for the first time find 60–80% of their signup form can be moved or deleted. That’s not a tweak. That’s a conversion lift hiding in plain sight.
In the next post we’ll continue through Part II with Chapter 4, which tackles the moment after signup — the first time a user lands inside an empty product and has to figure out what to do. That’s where activation is won or lost, and it’s the chapter most founders need most.
📖 Want the Full Signup Playbook?
This post gives you the shape of the Minimum Viable Signup and the Progressive Commitment Model. What lives in the book is everything you need to actually ship it: the Friction Equation for scoring individual form fields, the timing rules for progressive asks, how to handle the genuinely-tricky cases (B2B team signup, SSO, invite flows, regulated industries), and the onboarding blueprints in the rest of Part II that turn a clean signup into a high-activation first session.
If you’re serious about closing the gap between “they landed on our signup page” and “they’re a retained user,” the full framework is worth the read.
— Sho Shimoda
Based on Frictionless SaaS: Designing Products Users Discover, Adopt, and Never Leave (2026).
Sho Shimoda
I share and organize what I’ve learned and experienced.カテゴリー
タグ
検索ログ
Development & Technical Consulting
Working on a new product or exploring a technical idea? We help teams with system design, architecture reviews, requirements definition, proof-of-concept development, and full implementation. Whether you need a quick technical assessment or end-to-end support, feel free to reach out.
Contact Us