Where to use a mascot in your app

The screens that want a character

A mascot is not decoration applied evenly across an app. It works on the screens where something is missing, waiting or finished, and it gets in the way almost everywhere else. Four places earn it reliably.

Empty states

The classic one, and the strongest. An empty list is a screen where nothing has happened yet, so there is no content competing for attention and a character has room to explain what should happen next. It also turns a moment that reads as failure into one that reads as beginning, which is most of what an empty state is for.

First run and onboarding

Someone meeting your product for the first time is the one moment they are willing to be introduced to something. A character here does work that copy alone cannot: it makes an unfamiliar interface feel like it was made by people. This is also the only screen where a mascot may reasonably be large.

Completion and streaks

Finishing something is when a person is most receptive to a bit of warmth, and the moment where a small celebration is proportionate rather than saccharine. A pose here should be doing something, not just standing pleased.

Loading

The one place a moving character is worth the bytes, because the alternative is a spinner and the user has nothing else to look at. Keep it short and keep it looping cleanly, since the whole point is that it can repeat without anyone noticing the seam.

The screens that do not

This is the more useful half, and the part most mascot advice skips.

Anything that costs the user money or data

A cheerful character on a failed payment, a billing error, or a delete confirmation reads as not taking the situation seriously. The user is anxious and your app is being whimsical at them. The rule is simple: if the screen exists because something went wrong in a way the user cares about, no character.

Ordinary errors are different. A 404, an empty search, a lost connection: these are mild, recoverable, and a character softens them usefully. The distinction is whether the person is worried, not whether the word error appears.

Anything on the critical path

Checkout, sign-in, a form someone is trying to finish. A character on these screens is an obstacle wearing a smile. Somebody in the middle of a task wants fewer things on screen, not more.

Screens people see constantly

This is the one that catches people out, and it has nothing to do with how the screen looks. A character on a screen someone opens fifty times a day stops being charming within a week and becomes furniture they are trying to see past. Charm has a half-life, and frequency is what spends it.

Frequency decides more than design does

The most useful question to ask about any placement is not whether it looks good. It is how often the same person will see it.

• Seen once, at first run: a character can be large and expressive
• Seen occasionally, on an empty state or a completion: a character is welcome, at a modest size
• Seen daily, on a dashboard or a nav bar: small and static at most, and usually nothing
• Seen many times a day: no character, and no animation at all

The same is true of movement. An animation on a screen someone hits constantly is not delightful, it is a delay they have learned to wait through. Reserve motion for the places where the user is already waiting, which in practice means loading, and occasionally a completion.

How many poses you actually need

Fewer than people expect. Most apps ship a coherent character presence with four, and the fourth is optional.

• A neutral, welcoming pose for onboarding and the store listing
• A waiting or searching pose for empty states
• A pleased pose for completions
• Optionally a sheepish one for mild errors

Generating thirty poses before you have shipped four is the usual mistake. Each one has to be placed somewhere real to be worth anything, and a screen that did not want a character does not start wanting one because you happen to have a pose spare.

Add poses when a screen asks for one, not in advance. That is also the cheaper order: you will discover the poses you actually need by building the screens, and half the ones you would have generated up front turn out to be for screens you never build.

Making them look like one character

All of the above only works if the character on your empty state is recognisably the same one on your success screen. If it is not, you do not have a mascot, you have a set of similar illustrations, and the user reads them as clip art rather than as your product having a personality.

That is a generation problem rather than a placement problem, and it is covered properly in the consistency guide. The short version: generate the character once, keep that render, and produce every later pose against it rather than describing the character again.