#onboarding

Think about the last time you started somewhere new.

Not the interview. Not the offer letter. The actual first day.

Did someone introduce you to the team before handing you a stack of paperwork? Did anyone check in during week two when the initial excitement started fading? Did your manager sit with you at the end of the first month and ask honestly how things were going?

If the answer is no to most of those — you already understand why good people leave good companies inside the first ninety days.

Onboarding is not orientation. It is not a checklist. It is not a single welcome email with seventeen attachments.

It is the first real signal a company sends about who it actually is when nobody is trying to impress anyone anymore.

Week one should feel human before it feels administrative. Introduce the people. Set real expectations. Make day one something worth remembering for the right reasons.

Weeks two and three are where most companies go quiet. That silence is expensive. A new hire without a mentor, without early wins, without regular check ins is not finding their feet. They are making a decision.

Week four is where everything either clicks or quietly starts to unravel. Set goals together. Ask for feedback and actually listen to it. Make sure the person in front of you feels like they belong to something bigger than their job description.

Companies with structured onboarding improve new hire retention by 82%.

That number is not a coincidence. It is the result of treating the first thirty days like they matter as much as the hiring process that came before them.

The best part of any job in my opinion is the onboarding process. Not only does it tell me a lot bout the values of the company I am entering, but it also allows me to enter a bit of a "school mode" in my brain. Which helps me find my footing no matter how helpful the onboarding is to my actual job. Learning is something I'm good at and I know it, so for me it helps me to begin feel at ease in a completely new place and team.

I also like to privately in my mind analyse and compare how the onboarding looks. Like is it very streamlined, with a little webinar or mentoring, or is it more punk and just "learn on the go" thing. If it's streamlined, how does it correspond to the way those learned processes work in practice. Does the webinar or mentoring information actually help you do the job, or is theory and practice worlds apart. Is it actually punk and "learn on the go" or is it "learn by doing" with supervision and mentoring available. Exactly HOW available is the mentor...

We have worked on enough SaaS onboarding redesigns over the last few years that a pattern has become hard to ignore. The instinct on every project is to add new screens, new tutorials, new tooltips, new prompts. The reality on every project is that the biggest activation lift comes from removing screens, not adding them.

This is a counterintuitive observation when you say it out loud. A team that has spent weeks discussing how to "improve" onboarding is rarely thinking about subtraction. The brief is usually some version of "make it better", which implicitly assumes additive change. The product manager pitches a guided tour. The designer mocks up a more sophisticated empty state. The growth lead wants a personalized welcome screen. Everyone is proposing additions.

Photo by Akshar Dave🌻 on Pexels

What the Data Actually Shows

When we instrument a SaaS onboarding funnel and look at where users drop off, the biggest losses are almost always at the screens that were added recently. The original signup-to-first-action flow was usually short and direct. The accumulated additions are usually the source of the drop-off.

Across the projects we have run at 137Foundry, the pattern is consistent:

Original flow at product launch: signup, password, dashboard, first action. Four screens.

Flow after 24 months of additions: signup, password, email verification, team setup, profile completion, plan selection, tutorial overlay, settings preview, integration prompts, dashboard, first action. Eleven screens.

Activation rate after 24 months of additions: roughly half what it was at launch.

The team adding each screen had a reasonable argument. The email verification was for security. The team setup was for collaboration. The profile completion was for personalization. Each addition, in isolation, was defensible.

In aggregate, they killed activation.

The Mental Model That Helps

The mental model we use is to ask, for every screen, "if a user closes the tab on this screen, what fraction of them will come back?" The answer is almost always lower than the team assumes. Most users who close the tab during onboarding never come back. The cost of every screen between signup and first useful action is the percentage of users who drop off at that screen, multiplied by the lifetime value of those users.

This makes additions much harder to justify. The team adding the email verification screen is implicitly accepting that some percentage of acquired users will be lost to it. The percentage is rarely measured. When we instrument it and show them the number, they are usually surprised.

When Additions Actually Help

We are not anti-addition. Some additions help, and some do not, and the difference is measurable rather than aesthetic.

Additions that help: sample data on first login, defaults on first-action forms, inline-first-action patterns that compress multiple steps into one, contextual prompts that surface only when the user has shown intent for the related action.

Additions that do not help: forced tutorial overlays, pre-task configuration wizards, email-gated unlocks, multi-step team setup wizards before the first useful action, mandatory profile fields that the product does not strictly need.

The pattern: additions that reduce the path to first useful action help. Additions that lengthen the path hurt. This sounds obvious. In practice, almost every addition lengthens the path, because the path-shortening additions tend to be invisible (a default value, an inline form, a sensible sample dataset) while the path-lengthening additions tend to look like progress (a new screen, a new feature, a new prompt).

The Practice We Use

For every onboarding addition we propose to a client, we ask three questions before we agree to ship it:

Does this addition shorten or lengthen the path from signup to first useful action?

What percentage of users do we expect to drop off because of this addition?

What value does the addition produce that justifies the drop-off cost?

If the addition lengthens the path, the answer to question 2 is non-zero. The question becomes whether the value in question 3 justifies the cost. Most of the time, the answer is no, and we propose a path-shortening alternative.

Email verification is the classic example. It lengthens the path. Some percentage of users drop off because of it. The value (preventing fake signups, enabling password reset, complying with anti-spam rules) is real. But the value can usually be captured without forcing verification on day one. The user can use the product immediately, and verification is required only when they take an action that needs it -- inviting a team member, configuring billing, contacting support.

The same logic applies to most other "required" additions. Configuration that matters for the user's third or fourth action can be deferred to the third or fourth action. The first action almost never needs more than sensible defaults.

What This Looks Like in Practice

At 137Foundry, our onboarding work for clients usually starts with a screen inventory. We list every screen between signup and first useful action and assign each one a cost (the percentage of users who drop off at it) and a value (the function it serves). The work that follows is mostly about cutting screens whose cost exceeds their value.

This is unglamorous work. The output is not a beautiful new design system or a clever new feature. The output is a shorter flow that the team built in the first place but bloated over time. The activation rate moves. The downstream metrics move with it. Nobody puts "removed 4 unnecessary onboarding screens" on their portfolio site.

For the framework we use, the 137Foundry guide on onboarding drop-off walks through the systematic redesign process. The services we offer include onboarding flow audits for SaaS and B2B products.

External design references we keep coming back to: the Nielsen Norman Group research on activation funnels, the Smashing Magazine editorial archive on UX case studies, and the broader W3C accessibility guidelines which intersect onboarding design in ways that most teams underweight.

The Mindset Shift

The hardest part of this work is the mindset shift. Teams who have been adding to the onboarding flow for two years find it counterintuitive to subtract. The screens that we propose cutting were added by people who are still on the team and remember the meeting where they argued for each addition.

The conversation about cutting them has to be framed against the activation data. "We are not saying your screen was a bad idea. We are saying the funnel data shows it is costing more than it is producing. Here is the number." When the conversation is framed this way, the team usually agrees to cut. When the conversation is framed as a design preference, the team usually defends the screen and the cut does not happen.

The Compounding Effect

The teams that get good at cutting onboarding screens tend to stay good at it. The discipline becomes part of how they ship product. Every new feature gets evaluated against the activation funnel. The accumulation of cruft slows. The activation rate stays stable or improves over time.

The teams that do not develop the discipline tend to drift in the other direction. The onboarding flow gets longer. The activation rate falls. The team blames upstream acquisition channels for the rising cost-per-activated-user, when the real problem is the flow that has accumulated 24 months of "improvements".

We have worked on both kinds of teams. The first kind is more fun to work with. The work is sharper and the results are easier to see. The second kind takes a few months to acclimate to the data-first mindset, but once they do, the same pattern emerges.

Across the SaaS onboarding redesigns we have run at 137Foundry, five patterns come up over and over as the dominant sources of activation drop-off. Each of these is technically defensible in isolation. In aggregate, they explain most of the gap between signup rate and activation rate.

If a product team is wondering why activation is below industry benchmarks, the answer is usually one or more of these five.

Photo by Walls.io on Pexels

1. The Empty Dashboard

The user signs up, lands on the main dashboard, and sees nothing. No projects. No data. No model for what success looks like. The dashboard has a "create your first project" button at the top, but the button leads to a blank form that expects the user to invent something from scratch.

A meaningful percentage of users close the tab here. They did not sign up to invent a project; they signed up because someone told them the product would help them with work they were already doing. The empty dashboard is asking them to do work the product was supposed to do for them.

The fix is sample data on first login, defaults that get the user to a populated state in one click, or an inline first-task flow that does not require navigating through the empty dashboard. The Nielsen Norman Group has documented this pattern across many product categories.

2. The Configuration Wizard Before First Use

The user signs up to send invoices, and the product asks them to configure currency, tax settings, payment methods, business hours, notification preferences, and team structure before they can send anything. The configuration wizard has 8 to 12 steps. The user came to send an invoice, not to configure a SaaS product.

The configuration wizard is a leftover from the enterprise-software era when products assumed users would deploy them carefully over weeks before using them. The pattern translates poorly to self-serve SaaS, where the user has 5 minutes to decide whether the product is worth more of their time.

The fix is to defer every configuration question until the moment it actually matters for the task at hand. The user can send an invoice with defaults. If the defaults are wrong for this specific invoice, surface the configuration question inline on the invoice screen. The full settings page is for users who have already gotten value from the product, not for users who are deciding whether to.

3. The Forced Tutorial Overlay

The user lands in the product and immediately sees an overlay that walks them through every feature on the screen. Each feature has a callout box with explanatory text and a "next" button. The user has 7 to 12 callouts to dismiss before they can interact with the product.

The forced tutorial is one of the most reliably hated onboarding patterns. Users skip them, dismiss them, and -- in the worst cases -- close the product entirely rather than dismiss them. The information in the tutorial is rarely retained because the user has no context for why the features matter.

The fix is to make tutorials optional and contextual. A small "show me around" button that the user can click when they want a tour, paired with inline hints that appear only when the user is about to take a related action, outperforms forced tutorials on every metric we have measured.

Smashing Magazine has published case studies on tutorial overlay performance. The consistent finding is that optional tutorials with contextual triggers outperform forced overlays by 20 to 40 percentage points on retention metrics.

4. The Email Verification Wall

The user signs up, provides their email, and is told to check their inbox to verify before they can use the product. They do not check the inbox. They close the tab. They never come back.

Email verification has legitimate purposes -- preventing fake signups, enabling password reset, complying with anti-spam rules. The mistake is requiring verification before first use, which turns the verification step into a major drop-off point.

The fix is to allow immediate access to the product while making verification a prerequisite for actions that actually require it. Inviting team members, configuring billing, contacting support -- these can require verification. Using the product for the first time should not.

5. The Profile Completion Demand

The user lands in the product and is shown a profile completion form. Photo, job title, company size, role, phone number, country, time zone. The form is 8 fields. The user is told they cannot use the product until they complete it.

The profile completion form is almost always for the company's benefit, not the user's. The company wants demographic data for sales segmentation, ICP analysis, or marketing. The user wants to use the product. The mismatch produces drop-off.

The fix is to make profile fields optional and surface the questions over time as they become relevant. The product can get most of the demographic data through behavior rather than self-report. The fields that are genuinely necessary for the product to function (timezone for scheduling, role for permissions) can be defaulted to sensible values and surfaced only when the defaults break.

Photo by Kawê Rodrigues on Pexels

What All Five Have in Common

The pattern across all five: each one prioritizes something the team wants over something the user wants. Configuration, verification, demographic data, education, and structured setup are all team priorities. The user priority is "let me use the product".

When the team priorities are forced on the user before they can use the product, the user leaves. This is not a UX problem in the narrow sense; it is a prioritization problem. The team is signaling that their priorities matter more than the user's, and the user is responding by going elsewhere.

The fix in every case is to defer the team priority until the user has gotten value from the product. Once the user has experienced what the product can do, the team priority becomes negotiable. Configuration, verification, demographic data, education, and structured setup all become acceptable once the user has a reason to want the product to keep working.

How We Find These Patterns

The diagnostic process is straightforward. At 137Foundry, we run a free onboarding flow audit on SaaS products where we sign up from scratch and walk through every screen, take notes on where the friction appears, and produce a prioritized list of cuts and changes.

The pattern is consistent. Most products have 3 to 4 of the five patterns above. The audit identifies which ones are most expensive in terms of activation impact and proposes specific changes. The implementation work is usually 4 to 8 weeks, and the activation improvement is usually 10 to 30 percentage points.

For the framework behind the audit, the 137Foundry guide on onboarding drop-off walks through the redesign process. The services we offer include onboarding flow audits for SaaS and B2B products.

External design references we keep coming back to: the Nielsen Norman Group research on activation funnels, the Smashing Magazine editorial archive on UX case studies, the W3C accessibility guidelines on progressive disclosure, and the MDN UI patterns reference for the technical implementation patterns.

Closing Thought

The five patterns are not a comprehensive list of every onboarding problem we see, but they account for most of the activation drop-off we have measured across client projects. Teams that fix these five usually move activation by enough to make the redesign work pay for itself within a few quarters.

The harder part is institutionalizing the discipline. The empty dashboard, the configuration wizard, the forced tutorial, the email verification wall, and the profile completion demand all came from someone proposing them in a meeting and the team agreeing. Avoiding the next round of accumulation requires building the activation-first habit into how the team evaluates new product proposals.

hello and welcome!!! grab a sweet tea and make sure ur blood pressure is prepared for the cardiac canes <3

first off, vivi (@cynids) made this BANGER of a primer! she's the best her edits are awesome and u should follow her (esp for boots on the ground reporting about how badly our canes drive)

i honestly have only been on hockeyblr since the end of the regular season so i'm just gonna list some of my moots/followings that i think are OGs/have objectively correct canes opinions:

@canesbian, @jarvyparty, @pyotrkochetkov, @andreisvechnikov, @mysharkiee, @cellyblaker, @stormsies, @canesposting

Dein Onboarding: Die ersten Wochen entscheiden maßgeblich darüber, welchen Eindruck du beim Vorgesetzten und im Team hinterlässt. Dabei ist es wichtig, sich der bis zu sechsmonatigen Probezeit stets bewusst zu sein.

Wichtige Hinweise für einen erfolgreichen Start:

Sei pünktlich: Erscheine stets pünktlich zu Arbeitsbeginn und allen Meetings.

Beobachte zuerst: Höre in den ersten Wochen vor allem zu. Schlage gut durchdachte Änderungen erst nach drei bis sechs Monaten vor.

Namen merken: Präge dir die Namen und Funktionen deiner neuen Kollegen ein.

Interesse zeigen: Stelle bei Unklarheiten Fragen, aber dosiere sie gut.

Fehler sofort melden: In der Einarbeitung passieren Fehler. Melde sie direkt, um größere Probleme zu verhindern.

Vergleiche unterlassen: Vermeide Sätze wie: „Bei meinem alten Arbeitgeber wurde das aber besser gemacht.“

Netzwerken: Nutze die Mittagspause für einen privaten, aber zurückhaltenden Austausch.

Sachlich bleiben: Tritt nicht arrogant auf. Antworte und argumentiere immer sachlich.

„Double-Check“: Erledige Aufgaben stets präzise. Überprüfe deine eigene Arbeit gerade in der Probezeit vor der Abgabe immer gründlich.

Zuverlässig sein: Halte Termine, Fristen und kurzfristige Deadlines ein. Denke daran: Du befindest dich in einem Arbeitsverhältnis.

Initiative zeigen: Frage bei "Leerlauf" deine Kollegen nach Unterstützung oder neuen Aufgaben.

Flurfunk meiden: Halte dich aus Büroklatsch und internen Konflikten konsequent heraus.

Technische Einarbeitung: Nimm betriebliche Schulungen dankend an und eigne dir Fachwissen an.

Überstunden während der Probezeit und im Allgemeinen: Vermeide regelmäßige Überstunden, um nicht überfordert oder zu langsam zu wirken. Konzentriere dich auf deine eigentlichen Aufgaben. Mehr Fokus, weniger Überlastung: Lerne zu delegieren und sage auch schon mal ein Nein.