Using Emojis in SaaS Onboarding and In-App Status Messages
In SaaS onboarding, choose a status message from the result of the action, not from how encouraging you want the interface to sound. “Import started”, “Import complete”, and “Import failed” need different wording. An emoji may reinforce the state, but it should never be the only way to know whether data was saved.
The example below follows a fictional contacts import. It shows how the same task moves through several states, what text belongs in each, and when a checkmark or celebration would be premature. No conversion or retention result is implied.
Model the states before writing success copy
| State | Visible message | Available action |
|---|---|---|
| No file selected | Choose a CSV file containing Email and Name columns. | Choose file |
| Validating | Checking the file's required columns… | Wait; show cancellation only if actually supported |
| Validation failed | The Email column is missing. Add it and select the file again. | Choose another file |
| Importing | Import in progress. The result will appear here. | Do not offer a duplicate import action |
| Completed | Import complete. 120 contacts were added. ✅ | View contacts |
| Partial result | 112 contacts added; 8 rows need review. | Review skipped rows |
The counts are invented to illustrate the wording. A real interface must use the actual result. Do not show “120 contacts added” when the server has only accepted a job for processing. A request being accepted is not the same as the work completing.
Handle a partial result without a misleading checkmark
“Success 🎉” is inadequate when some rows were skipped. A partial result should name both what happened and what remains. Show the skipped rows or explain how to find them. If the user can retry, explain whether retrying the complete file would create duplicates or whether only failed rows should be resubmitted.
A neutral status is often better than forcing partial completion into a success or failure emoji. “112 added; 8 need review” gives the user a decision. A half-celebratory string of icons does not.
Preserve the next action after an error
For a missing column, identify the column and the recovery route. For an unavailable service, do not imply the file is invalid. For an unknown connection failure, do not promise that nothing was imported unless the system can confirm that.
Wrong diagnosis: Bad file ❌
Known validation error: The Email column is missing. Add a column named Email, then try again.
Uncertain connection result: We could not confirm the import result. Check the contacts list before starting another import.
W3C's error-identification guidance requires an automatically detected input error to be identified and described in text. That is a different responsibility from choosing a red error symbol.
Give empty states a useful first step
An empty contacts screen can say “No contacts yet. Import a CSV or add a contact.” It should not say “No results” unless the person actually ran a search that returned nothing. These two empty states need different recovery actions.
For a filtered list with no matches, keep the filter visible and offer “Clear filters”. For a first-use screen, offer the creation or import action. A rocket may fit a celebratory onboarding style, but the words must still identify which state the user is in.
Do not announce success before a browser action succeeds
The same rule applies to copying text. A copy button should wait for a successful clipboard operation before showing “Copied”. If the browser denies access, select the text and explain manual copying instead of leaving a false success message.
For web implementation details, the Clipboard writeText reference describes its asynchronous result and failure behavior. Keep that technical result separate from the fact that text may already have been inserted into an editor: insertion can succeed while clipboard copying fails.
This distinction is relevant to Mojitap itself. The tool can add an emoji to the editable text even when copying is unavailable. Its status needs to describe the completed action rather than treating both actions as a single guaranteed success.
Keep focus and status communication predictable
When a state changes, preserve the user's context. Do not move keyboard focus to a decorative celebration merely to make the update noticeable. Expose the relevant text update through an appropriate status mechanism and keep the next action reachable.
W3C's status-message guidance explains how such updates can be available to assistive technology without taking focus. Implementing a visible checkmark alone does not provide the same information.
Review the flow as a sequence, not as isolated sentences
Write the initial state, pending state, success state, partial state, and failure state on one page. Check the transitions in that order. Can someone distinguish “not started” from “still running”, and “failed” from “finished with exceptions”? Is each claimed result grounded in the event that actually occurred?
Only then add a small consistent visual vocabulary. A checkmark may accompany confirmed completion. A warning may introduce an action with consequences. A tip should look optional rather than like a required step. Leave the other states text-only when an emoji adds no useful distinction.
Use Mojitap for draft suggestions, not state detection: it does not know whether your import completed. For agent-written responses after a user reports a problem, use the customer-support message guide. For a message sent outside the app, use the notification guide.