A useful brief explains the screen, the event and the response. You do not need a finished technical specification to start; share what is known and mark the remaining decisions clearly.
Written for: Startup founders, product designers and agencies preparing an inquiry.
Explain the product before listing animations
Describe who uses the app and the task the mascot should support. A learning companion, a fitness guide and a checkout assistant need different expressions and interruption rules. Include a product link, a few relevant screenshots or a prototype showing the actual placement.
Then describe your launch scope. Is this one onboarding screen or a character reused across the product? A single sentence about the intended experience is more helpful than a long collection of visual references without a product goal.
Describe events and responses in pairs
Instead of “make it happy, sad and interactive,” write “when the learner finishes a task, show a short acknowledgement, then return to idle.” Add what happens if the user leaves the screen or another event arrives immediately.
| Event supplied by the app | Expected response | Question to resolve |
|---|---|---|
| Screen becomes visible | Idle, possibly a welcome | Should the welcome repeat? |
| A lesson is loading | Quiet waiting behavior | How does it stop on failure? |
| A task completes | Success acknowledgement | Can it be interrupted? |
These are planning examples. The delivered file will have its own agreed control names, types and reset rules.
Identify artwork and platform constraints early
Say whether you have editable artwork, a flat reference image or only a character direction. Explain what is approved and what still needs design. If another designer owns the artwork, confirm that you can commission its adaptation and agree the required source access.
For platform details, name the framework, runtime version if known and target screen size. “Flutter on iOS and Android” gives the animator a starting point; an exact SDK and representative device allow a more concrete compatibility review. If the technical choices are undecided, write that rather than assuming every feature will be available.
Copy this app mascot brief
Use the template as a conversation starter. Leave unknown items as “to be confirmed.” Avoid pasting credentials or private customer data into a project inquiry.
An example of a scoped first inquiry
“We are building a learning app in Flutter. We have editable character artwork. For the first release, the mascot appears on the lesson-complete screen with idle and success behavior. It should return to idle after the reaction and stop when the screen closes. Speech is not required. We need the .riv export and named controls. Please review our screenshots and confirm scope, price and availability.”
This brief gives enough context for useful follow-up questions without pretending that every implementation decision is settled. A second release can be discussed after the first screen behavior is clear.
What happens after you send it?
I review the artwork, product flow and required behavior, then clarify the decisions that affect design, rigging or runtime delivery. The quote should identify included work, source rights, revisions, testing responsibilities and schedule assumptions.
Use the pricing examples as a starting point. If you already have a developer, ask them to review the event list before approval. For design and animation scope, the App Mascot service page explains the available delivery path.