“We need a friendly mascot for our app” is a good starting point for a conversation. It is not yet a brief that an animator and developer can estimate reliably.
Two characters can look equally simple in a screenshot and require very different systems. One might wave once during onboarding. Another might listen, think, speak, follow gaze targets, recover from an interrupted request, and run inside three different applications.
The difference is behavior, data, and delivery scope. Describe those early and you give the project a much better chance of arriving in a form your team can use.
This guide is for founders, product designers, and engineering leads commissioning an interactive Rive mascot or AI companion. It includes a copyable project brief and explains which decisions belong in it. The examples are fictional scoping examples, not claims about client work or fixed market prices.
Start with the product job
Before choosing expressions or colors, describe what the character helps the user understand or do.
An onboarding guide might explain progress and acknowledge completed steps. A support assistant might show whether it is listening or waiting for an answer. A learning companion might react to an exercise result without distracting from the lesson.
Write one sentence that connects the character to a user task. For example: “The mascot helps users understand whether their voice request is being captured, processed, or answered.”
Then name the screen or flow where that happens. A small companion beside a text field has different visual constraints from a full-screen character during a welcome sequence.
Avoid making engagement or conversion promises part of the animation specification unless you have a plan to measure them. The deliverable can communicate a state clearly; the effect on broader product metrics needs evidence from your product.
Describe one complete user journey
A list of states is useful, but a sequence reveals the transitions and interruptions between them.
Describe what happens from the user’s first action to the end of the interaction. Include one ordinary failure. For a voice assistant, the sequence might be: tap microphone, speak, wait, hear a response, interrupt, and retry after a network error.
That journey answers questions a mood board cannot. Does speaking stop immediately? Does a success gesture block the next action? What remains visible while the service is unavailable?
Keep the character’s role separate from the application’s role. Your app decides that a request succeeded. The character communicates the decision through animation.
If the character can initiate an action when tapped, specify what that tap requests and which application component handles it. A visual interaction is not automatically a completed business operation.
List states by meaning, not by personality
Words like playful, calm, or confident help art direction. They do not define a State Machine.
Give each state a product meaning and an exit condition. For example:
| State | Meaning | What ends it? |
|---|---|---|
| Idle | Ready for interaction | User begins a task |
| Listening | Audio capture is active | Capture stops or fails |
| Thinking | Waiting for the next result | Answer, cancellation, or error |
| Speaking | Output audio is playing | Playback ends or is interrupted |
| Success | Requested operation completed | Short acknowledgement finishes |
| Unavailable | Interaction cannot proceed | Retry or return to a usable state |
These are example states, not a requirement for every mascot. A simple onboarding character may need fewer. A complex companion may need additional behavior.
Rive’s State Machine overview explains how animation states and transitions form an interactive system. Your brief should supply the product meaning that the designer maps into that system.
Separate activity, expression, and attention
You may want the character to speak warmly, wait calmly, and look toward a relevant interface element. Those behaviors do not all need to become separate primary states.
Describe activity, emotion, and gaze as distinct concerns. This helps the specialist propose a manageable rig and control interface instead of multiplying every combination into another animation.
Specify whether gaze follows a pointer, a tap target, or application events. It does not require a camera unless you explicitly want camera-based tracking and have planned that separate feature.
Also describe the intensity of expression at the actual display size. A dramatic full-body reaction may work on a welcome screen but feel excessive beside a form field.
Ask to review the character in a realistic product frame early. A beautiful standalone animation can still be the wrong size, contrast, or energy for its intended interface.
Say what artwork already exists
Share the current source assets and explain what must remain recognizable: silhouette, proportions, palette, facial style, or accessories.
Mention whether the artwork is editable vector art, a layered illustration, a flat image, or only a concept reference. These starting points require different preparation before rigging.
If the character needs body turns, mouth poses, or expressions that are not visible in the original artwork, include that requirement. A single front-view image does not define every pose automatically.
Clarify which references are for style and which are actual assets you are entitled to use. The brief should not leave the specialist guessing whether a reference character must be copied or merely communicates a general direction.
Include ownership and editable-source delivery in the scope rather than waiting until the final export arrives.
Name every target platform
“Mobile and web” leaves important details unresolved. Specify Web, Flutter, React Native, or native platforms, and include the versions your developers already use when available.
Rive provides runtimes for multiple environments, but feature support and renderer choices can differ. Its runtime introduction is a useful reference for planning compatibility.
List where the mascot appears and how many instances may be visible simultaneously. A single assistant panel and a scrolling collection of animated cards are different integration tasks.
Mention offline requirements and asset delivery preferences. A bundled file, a remotely hosted file, and a remotely updated character system involve different release decisions.
You do not need to know every technical answer before contacting a specialist. Mark unknowns honestly and identify the developer who can resolve them during scoping.
Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready Rive systems for Web, Flutter, and React Native. View live work and request an estimate, or send your project brief on WhatsApp.
Define speaking requirements before requesting lip sync
“The character should talk” can mean several different deliverables.
A repeating talking animation can signal activity. An audio-level-driven mouth can respond to loudness. Timed viseme animation selects mouth shapes associated with speech sounds. These options differ in appearance and in the data the application must provide.
Say which speech system you use, whether audio is streamed, and whether timed mouth-shape or alignment data is available. Share a representative sample if you have one.
Specify the languages and voice behaviors that matter to the product. Describe how interruptions, silence, buffering, and playback errors should affect the mouth.
If you do not yet have timing data, ask the specialist to scope a fallback instead of assuming the .riv file will derive accurate lip sync from arbitrary audio on its own.
Keep speech generation, audio playback, timing data, and visual animation as separate responsibilities in the brief. That prevents an animation estimate from silently turning into an entire voice-platform implementation.
Ask for a public control contract
Your developer needs to know how application events drive the character.
Rive’s Data Binding system connects View Model data to scene properties. The official overview explains the relationship between a schema, instances containing values, and bindings.
You can describe the desired controls in plain language: current activity, expression, speech mouth shape, audio level, and gaze direction. The specialist can propose names and types.
Ask for defaults, valid ranges, and ownership rules in the final documentation. A property called progress should say whether it expects 0–1 or 0–100. An activity selector should enumerate every supported value.
This contract is valuable even if your founder-facing brief remains nontechnical. It tells the engineering team what they will receive and gives the animator room to improve the design without exposing every internal object to code.
Specify what “developer-ready” includes
Do you want an asset only, an integration example, or production implementation in your application? Name the boundary.
For an asset handoff, request the runtime .riv, editable project access or backup, entry-point names, control documentation, and runtime test notes. Rive distinguishes its runtime export from its editable backup export.
For an integration example, define the platform and the interactions it must demonstrate. For production implementation, list the repository, screens, application events, audio responsibilities, and acceptance process.
Avoid asking for a “complete handoff” without agreeing on its contents. Two people can use the phrase and imagine very different work.
The Rive mascot developer handoff checklist provides a more detailed technical acceptance structure for your engineering team.
Include accessibility and failure behavior
A mascot should support the interface without becoming its only source of information.
Describe the accompanying text and controls for important states such as listening, unavailable, or completed. If animation fails to load, users should still understand what they can do next.
Ask for a reduced-motion treatment. That might be a quieter idle pose or static character with ordinary text feedback. React Native’s AccessibilityInfo API is one example of a host mechanism for detecting motion preferences; the design still needs to specify the response.
Review the character beside text at realistic sizes and on narrow screens. Include the intended background colors so contrast can be evaluated in context.
Write at least one fallback acceptance criterion: “The user can complete onboarding if the character asset does not load.” It is simple, concrete, and easy to verify.
Explain the deadline and budget constraints
A useful budget discussion starts with priorities, not an invented universal price for a mascot.
Share a budget range and identify what is essential for the first release. New character design, complex rigging, multiple expressions, timed lip sync, platform testing, and production integration all affect the amount of work.
Separate the launch date from the date your developers need the asset. Engineering integration and acceptance need time after visual approval.
Name the decision-maker and the review process. If several people must approve artwork or behavior, make that visible before production begins.
When budget or time is constrained, ask for a staged scope. A small reliable interaction set is easier to evaluate than a long list of unfinished behaviors. Keep later additions compatible with the initial control contract where practical.
Copy this project brief
Use this template as a starting point. Unknown answers are acceptable; unexplained assumptions are harder to manage.
Product and website:
Target users:
What the mascot helps users do:
Screens and approximate display size:
Existing artwork and editable source:
Visual references and must-keep features:
Required states and one complete user journey:
Interruption, error, and retry behavior:
Platforms and current framework/runtime versions:
Number of simultaneous character instances:
Offline or remote asset requirements:
Speaking required: yes/no
Speech provider and streaming behavior:
Available viseme/timing data:
Gaze behavior:
Reduced-motion and asset-failure fallback:
Deliverables: asset / demo / production integration
Editable source and ownership expectations:
Developer contact:
Acceptance tests and approval owner:
Budget range:
Asset handoff deadline:
Product launch date:
Essential first-release features:
Optional later features:
Attach the relevant artwork and a short product walkthrough. A specialist should be able to understand the user journey without joining every internal planning conversation.
Review the proposal against the brief
When a proposal arrives, compare the deliverables and exclusions against your requirements. Check that the speaking approach, runtime targets, editable-source access, and integration depth are stated explicitly.
Ask how the result will be demonstrated before acceptance. A rendered video can approve appearance, but an interactive character also needs a runtime demonstration of its controls and transitions.
Use the same brief when comparing options. Otherwise, one estimate may include source access and multi-platform testing while another covers only an animation export.
Mascot Engine’s interactive character services cover Rive mascots, AI companions, rigging, State Machines, viseme lip sync, gaze controls, and developer-ready systems. A clear brief helps turn those capabilities into a scope that fits your actual product.
By Praneeth Kawya Thathsara, founder of Mascot Engine.
Need an interactive Rive character for your product? Mascot Engine creates app mascots, AI companions, State Machines, lip sync, and developer-ready systems for Web, Flutter, and React Native. View live work and request an estimate, or copy the brief above and send it on WhatsApp.
Top comments (0)