In-App Messages That Help New Users
A good in-app message feels like a helpful colleague leaning over to say "try this next." A bad one feels like a pop-up ad that blocks the button you were about to click. This guide shows you how to plan, write and time in-app messages that genuinely help new users get value from your product, without nagging them or burying them in tooltips.
Key takeaways
- Every in-app message should help a new user finish one specific task, not advertise a feature.
- Trigger messages by what users do, not by how many days have passed since signup.
- Keep copy short: one idea, one action, one obvious way to dismiss.
- Plan all your messages in one table so they never stack up or contradict each other.
- Review your messages every quarter and retire the ones nobody needs anymore.
If you have spent the holidays looking at signups that never come back, you are not alone. Late December is a natural time to look at the first few minutes of your product with fresh eyes. Many founders find that new users are not confused by the product itself. They simply do not know what to do next, and nothing inside the product tells them.
In-app messages fill that gap. They include tooltips, short banners, small modal windows, checklists, empty-state prompts and chat-style messages that appear inside your web or mobile app. This article focuses on the messages themselves: what to say, when to say it and how to keep the whole system tidy.
What makes an in-app message helpful
Helpful messages have three things in common. They are relevant to what the user is doing right now, they are short enough to read in a glance, and they lead to a clear next step. If a message fails any of these tests, it becomes noise.
Relevant to the moment
A tooltip about exporting reports is useless to someone who has not created a report yet. Relevance comes from context. Ask yourself: what has this person just done, and what is the most natural next step? The message should answer that question and nothing else.
Short enough to skim
People do not read in-app messages, they scan them. Aim for a headline of a few words and one or two short sentences of body text. If you need a paragraph to explain a feature, the feature probably needs a help article or a better interface, not a longer pop-up.
One clear action
Give each message a single primary button that does something useful, such as "Add your first client" or "Connect your calendar." Pair it with a quiet way to dismiss, like "Not now" or a close icon. Two competing buttons make people hesitate, and hesitation is what you are trying to remove.
Pro tip
Read every message out loud as if you were sitting next to a new customer. If it sounds like something you would actually say to a person, keep it. If it sounds like a billboard, rewrite it.
Choose the right message type for the job
Different formats suit different moments. Matching the format to the job is one of the simplest ways to make your messages feel less intrusive.
- Tooltips. Small pointers attached to a specific button or field. Best for explaining one control the first time someone sees it.
- Banners. A thin strip at the top or bottom of the screen. Good for non-urgent information, such as a reminder to finish setting up an account.
- Modals. A window that sits on top of the page and needs a response. Use them sparingly, for example to welcome someone on their very first login or to confirm an important choice.
- Checklists. A short list of setup tasks that ticks off as the user completes them. Helpful when your product needs a few steps before it becomes useful.
- Empty states. The message that appears where data will eventually live, such as an empty project list. This is prime real estate, because the user is already looking at it.
- Chat-style messages. A small message from a named person on your team. Tools such as Intercom offer this format; check current features, pricing and privacy policies before you choose a tool.
As a rule of thumb, start with the least intrusive format that will still be noticed.
Plan your messages around the first win
Before you write any copy, decide what the "first win" is for a new user. This is the moment someone gets real value for the first time. For a scheduling tool it might be the first booked appointment. For an invoicing tool it might be the first invoice sent. For a design tool it might be the first finished file exported.
Once you know the first win, work backward. List the few actions a user must take to get there, then decide which of those actions people tend to skip or get stuck on. Those are the places where a message earns its spot.
- Name the first win. Write it as one sentence: "A new user has succeeded when they have..."
- List the steps to reach it. Keep this to the essential actions, usually 3 to 5.
- Find the sticking points. Watch a few session recordings, read support tickets or ask a handful of recent signups where they paused.
- Assign one message per sticking point. Pick the format, the trigger and the action for each.
- Decide when each message stops. A message should disappear once the user completes the related action or dismisses it.
- Write the copy last. With the plan in place, writing becomes far easier and more focused.
Common mistake
Launching a long product tour that walks through every menu on the first login. Most people click "Skip" within seconds, and the few who finish rarely remember much. Short, well-timed messages tied to real actions almost always do more good than one big tour.
Trigger by behavior, not by the calendar
Many teams schedule in-app messages by time: show this on day 1, that on day 3. The trouble is that users move at very different speeds. A fast user sees a message about something they already did, while a slow user gets a message about a feature they are nowhere near ready for.
Behavior-based triggers fix this. Instead of "day 3," use rules such as:
- Show when the user has created their first project but has not invited anyone.
- Show when the user opens the reports page for the first time.
- Show when the user has logged in twice without completing setup.
- Hide when the related action has been completed.
Even a simple flag in your database, such as "has_created_first_invoice," lets you show or hide a message at the right time.
Set frequency limits
Decide on a ceiling for how many messages a user can see in one session. A common rule of thumb is no more than one interrupting message, such as a modal, per session, with tooltips and empty states allowed as needed. Write this rule down so every person on the team follows it when adding new messages.
Write in-app copy that people actually read
The writing is where most in-app messages win or lose. Here are the principles that make the biggest difference.
- Lead with the benefit. "Get paid faster: send your first invoice" works better than "Introducing our invoicing module."
- Use the user's words. If your customers call them "jobs," do not call them "work orders" in your messages.
- Be specific about the action. "Add a client" is clearer than "Get started."
- Keep the tone warm and calm. Avoid exclamation marks on every line and avoid guilt, such as "You still haven't..."
- Make dismissing easy and respectful. "Maybe later" is friendlier than a tiny gray X that is hard to find.
- Check accessibility. Make sure messages can be closed with a keyboard, work with screen readers and have enough color contrast.
AI writing tools such as ChatGPT, Claude, Gemini or Grammarly can help you draft several variations quickly. Treat their output as a first draft: edit for your product's voice, check every claim and keep the final copy short. Check each tool's current features, pricing and privacy policies before you paste in any customer information.
Hypothetical example
Priya runs a small booking app for hair salons. New salon owners kept signing up, adding a single service and then leaving. She noticed that the first win was really "first booking received," and that people stalled before sharing their booking link. She removed a five-step welcome tour and added two messages instead: an empty-state prompt on the bookings page that said "Share your booking link to get your first appointment," with a copy-link button, and a tooltip on the link the first time it appeared. Within a few weeks, more owners shared their link in their first session.
Build an in-app message plan template
Keeping all your messages in one table stops them from piling up. It also makes it easy for a new team member to see what already exists before adding something new. Copy this template into a spreadsheet or your team's knowledge base. The rows below are made-up examples.
| Message name | Format | Trigger | Stop when | Headline | Primary action | Owner | Last reviewed |
|---|---|---|---|---|---|---|---|
| Welcome | Modal | First login | Seen once | Welcome, let's set up your workspace | Start setup | Product | Example: January |
| First client | Empty state | Client list is empty | First client added | Add your first client | Add client | Product | Example: January |
| Invite teammate | Banner | First project created, no invites | Invite sent or dismissed twice | Work faster together | Invite a teammate | Growth | Example: January |
Measure, review and retire messages
An in-app message is never really finished. Products change, menus move and features get renamed, so a message that was helpful in March can be confusing by September.
What to look at
Keep your review simple. For each message, check whether people click the primary action, whether they dismiss it quickly, and whether more users reach the first win after it went live. You do not need perfect data. A rough picture, combined with a few conversations with real users, is usually enough to decide what to keep.
When to retire a message
Retire a message when the interface now makes the next step obvious, when the feature it explains has changed, or when almost everyone dismisses it. Fewer, better messages are kinder to users than a growing pile of tips.
Respect privacy and consent
If your messages rely on tracking user behavior, make sure your privacy notice explains it clearly. In the UK and EU, consent rules can apply to certain kinds of tracking and to marketing messages, and rules vary elsewhere too. This is general information, not legal advice, so check with a qualified professional if you are unsure what applies to your product. Keep in-app messages focused on helping people use the product, and save promotional offers for channels where users have agreed to hear from you.
Your in-app message checklist
- Write down the first win for a new user in one sentence
- List the 3 to 5 steps needed to reach it
- Identify where new users get stuck or stop
- Choose the least intrusive format for each sticking point
- Set behavior-based triggers and clear stop conditions
- Agree on a limit for interrupting messages per session
- Write short, benefit-led copy with one primary action
- Test every message on desktop and a real phone
- Record every message in your message plan table
- Book a quarterly review to update or retire messages
Frequently asked questions
How many in-app messages should a new user see?
There is no magic number, but fewer is usually better. Focus on the handful of steps that lead to the first win and add a message only where people get stuck. If you find yourself planning a dozen messages for the first session, simplify the product flow instead.
Should I build in-app messages myself or use a tool?
Simple tooltips and empty states are easy to build in your own code. A dedicated tool can help if non-developers need to edit messages often or you want targeting without code changes. Compare a few options and check current features, pricing and privacy policies before committing.
What is the difference between in-app messages and emails?
In-app messages reach people while they are using your product, so they are ideal for guiding the next action. Emails reach people when they are away, so they suit reminders and updates. The two work best together when they never repeat the same message at the same time.
Can in-app messages annoy users?
Yes, if they interrupt too often, appear at the wrong time or are hard to dismiss. Behavior-based triggers, a per-session limit and an easy "not now" option keep messages helpful rather than irritating.
Related reading
The bottom line
In-app messages work best when they act like a friendly guide pointing to the next useful step. Define the first win, place a short, well-timed message at each sticking point, trigger it by what the user does and stop it as soon as the job is done. Keep every message in one plan so they never pile up.
Use the quiet days between the holidays to map your first win and audit the messages you already have. Cutting two confusing pop-ups and adding one helpful empty state could be the easiest product improvement you make all year.
