Onboarding for rarely used apps: designing for the once-a-year user
Most onboarding advice assumes a user who comes back every day: teach them the core loop in week one, and habit does the rest. A large class of software doesn’t work like that. People open their payroll portal to download a tax statement in February, their benefits system during open enrollment in November, and the admin console when a new hire starts. Each visit, they are a beginner again.
Who the once-a-year user is
- The employee in an HR, payroll or expense tool. They didn’t choose the software and don’t want to learn it. They want one document or one change.
- The occasional admin: an office manager or team lead who touches settings a few times a year and has to relearn the screen each time.
- The policyholder or account holder in insurance and banking portals, who visits when something happens.
What they share: high stakes, low familiarity, and no patience for a feature tour.
Why the usual playbook fails
Day-one tours are forgotten by day 300
Showing someone where “Tax documents” lives during onboarding in March is useless next February. Memory doesn’t last that long for a screen you saw once.
The UI changed in between
Rarely used apps still ship. Between two visits the navigation may have been redesigned, which makes help-center screenshots and recorded tours wrong at exactly the moment they are needed.
Search assumes you know the word
The user thinks “my W-2” or “the form for my taxes”. The app calls it “Year-end statements”. Keyword search and menu labels assume the user already speaks the product’s vocabulary.
Seasonal spikes swamp support
Everyone has the same question in the same two weeks. Open enrollment and year-end are when support queues explode, mostly with “where do I…” questions.
Design principles that work
1. Start from the task, in the user’s words
Put a visible “What do you need to do?” entry point on the home screen and accept plain language: “add my newborn to my insurance”, “change my bank account for salary”. Map it to the task, not to a menu name.
2. Guide in place, not in a help center
Every jump to a separate help page costs the user their context. Show the next step on the screen they are on: highlight the control and say what it does in one sentence.
3. One step at a time, across pages
Annual tasks are often multi-page: enrollment wizards, document centers, approval flows. Guidance has to survive page loads and keep the goal in mind until it is done.
4. Make it resilient to change
If guidance is a recording, it will be stale at the next visit. Prefer guidance that is derived from the current UI each time: stable hooks in your markup at minimum, live-page reading ideally.
5. Plan for the season
Before open enrollment or year-end, add a banner that links straight into a guided task. A button that calls a guide with a fixed goal (for example Wayhint.ask("download my 2025 tax statement") in Wayhint) removes the first question entirely.
6. Respect privacy by default
These apps hold salaries, health choices and account numbers. Whatever assists the user should not read field values, and site owners should be able to mark areas off limits. In Wayhint that is built in: input values are never read, emails and long numbers are masked in the browser, and data-guide-private hides an area’s text.
How to know it works
- Seasonal ticket volume for location questions (“where is…”, “how do I…”) compared with last season.
- Task completion rate for the two or three annual tasks that matter most.
- Time from landing to task done, for first visits of the season.
The once-a-year user will never become a power user, and that is fine. The goal is to make every visit feel like the first time went well. More on onboarding with Wayhint.