Appearance
Design Guidelines
This section provides guidelines to help you make your extension clear and engaging.
Custom vs Stripchat Style
Extensions can and should have their own visual style. Creating a distinctive experience through your extension's UI is more important than matching Stripchat's interface exactly. Shared platform patterns such as animation, spacing, and other visual parameters are encouraged, but not required. This applies mainly to the user-facing part of the extension, including how it appears on stream.
✓ DO
A unique extension style for the user-facing part. The key is to rely on common sense and follow slot and category rules.
At the same time, using Stripchat UI is recommended for core interface elements such as model-facing settings, forms, and other utility-focused UI. This improves clarity for users and helps speed up development.
✓ DO
Reuse Stripchat's existing styles for model-facing settings.
✕ DON'T
Avoid custom-styled model-facing settings that break platform consistency.
A Bit of Common Sense
Practical UI tips and common do/don't examples to help you avoid mistakes and make your extension feel polished.
🎥 Stream is primary, extension is supportive
Always design with the stream context in mind. An extension should attract attention when needed, make the stream more engaging, and support monetization, but it should never feel more important than the stream or the model. It may briefly take focus during an interaction, but only for a moment.
👀 Minimize stream obstruction
Avoid covering the live stream whenever possible. The EXTENSION_SLOT_RIGHT_OVERLAY slot can take up a large portion of the stream, but that does not mean it should. This larger area exists so you can add supporting elements around the main block or place elements on a transparent background when needed. The main rule is simple: the stream should stay easy to watch.
Use the larger overlay area for supporting effects or transparent elements around the main content, not to block the stream by default.
✓ DO
Use the larger right overlay area for a result effect when needed, as long as the stream stays clearly visible.
✕ DON'T
Do not scale the overlay so much that it takes over the stream.
✓ DO
Let extra parts extend into the larger overlay area only when they support the main interaction.
✕ DON'T
Do not use the available space for a large opaque panel if the same action can be shown with much less obstruction.
🎯 Use one clear CTA and guide attention with emphasis
Keep one primary CTA in focus and use visual emphasis to guide the user’s attention. At any moment, it should be immediately clear what is happening and where the user is expected to click.
✓ DO
Keep one clear primary action and make supporting options feel secondary.
✕ DON'T
Do not give too many actions the same visual weight.
✓ DO
Keep the UI clean and easy to scan.
✕ DON'T
Avoid competing highlights that make it harder to understand where to click.
💡 "If it needs explaining, it shouldn’t need explaining"
Make the interface as self-explanatory as possible. Users should quickly understand what is happening and what they are expected to do, without relying on long instructions that most people will not read.
✓ DO
Let the interface explain itself through clear structure and obvious actions.
✕ DON'T
Do not rely on long instructions to explain how the interface should be used.
⚖️ Style should not overpower usability
A strong visual identity can make an extension more memorable and engaging, but it should never come at the expense of clarity. Users should still be able to quickly understand the interface, recognize the main actions, and use the extension without confusion. Style should support the experience, not replace usability.
✓ DO
Use a distinctive visual style without sacrificing clarity.
✕ DON'T
Do not let decoration overpower the interface and make actions harder to understand.
Motion for Extensions
Motion in extensions should support reactions, clarify interactions, and improve feedback without distracting from the stream.
Global Motion Rules
- One primary animation at a time
✓ DO
Keep the focus on one primary animation at a time.
✕ DON'T
Do not run multiple competing animations at the same time.
- Use motion to support state changes, reactions, and CTA highlights, not as constant decoration
✓ DO
Use motion to show that the dice can be clicked to roll.
✕ DON'T
Do not use decorative motion that pulls attention away from the main action.
- Keep loops subtle
✓ DO
Keep loops subtle and low-intensity.
✕ DON'T
Do not use loops that are too strong, distracting, or visually noisy.
- Stronger motion belongs in dedicated interactive areas
- Reduce motion near text-heavy UI
Timing
| Type | Duration |
|---|---|
| Standard reactions | Up to 1200ms |
| Win states | Up to 2500ms |
| Quick UI transitions | 150–300ms |
| Attention cues | Short and non-looping unless they indicate a live state |
Motion Types
| Type | Use |
|---|---|
| Smile Reaction | Light tip feedback and emoji-style reactions |
| Win Message | Win states and reward messages |
| Reward Burst | Tip rewards, unlock moments, and special triggers |
| Queue Accepted | Queued actions and confirmations |
| Device Activated | Toy and device activation feedback |
Motion by Slot
Different slots serve different purposes, so motion should behave differently depending on where the extension appears. For technical details about slots, see Slots. This section focuses on motion behavior and UI guidance.
Hover a slot to see its motion guidance
Decorative Video Overlay
✓ DO
Keep motion light and secondary to the stream.
✕ DON'T
Use strong motion that distracts from the stream or the model.
Right Overlay
✓ DO
Use short, spatially contained motion near the active element.
✕ DON'T
Let animation take over too much of the stream area.
Main section
✓ DO
Use motion to reinforce the main CTA, state changes, and result moments.
✕ DON'T
Animate multiple competing areas at the same time.
Movable Overlay
✓ DO
Use motion for confirmations, state updates, and control feedback.
✕ DON'T
Add decorative animation that competes with functional UI.
There is also a background slot. It is non-visual, so it should not use any visible motion. Its role is timing, slot coordination, and persistent logic.
Stripchat UI
As noted above, you can use Stripchat UI to speed up extension design work, especially for settings screens and other utility-focused interfaces.
The core style foundations, essential components, icons, and interface examples are collected in the 
Extension UI kit ↗.
You can duplicate it, add it as a library, or use it in any other way that fits your workflow.
What’s inside the UI kit
Components ↗
Pay attention to the Feedback ☝️ section. It is useful for keeping error, warning, info, and success states consistent across the platform.
Here’s a concise summary from the UI kit covering typography and colors.
Typography
Font family: Inter · Download font ↗
Fallback stack: Inter, system-ui, -apple-system, Segoe UI, Roboto, Helvetica, Arial, sans-serif
| Name & Preview | Size / Line Height Weight | Used for |
|---|---|---|
Display M | 40 / 52 / Bold | Large emphasis headlines, hero states, promo screens, and important empty states. Do not use in compact overlay slots. |
Heading L | 24 / 32 / Bold | The primary title of a screen, large card, modal, or major content block. Best suited for the main slot and larger sections. |
Heading M | 20 / 28 / Bold | Section titles, cards, widgets, and compact modals. This is the default heading style for most UI surfaces. |
Body M | 14 / 20 / Regular | Default interface text: descriptions, form text, instructions, standard messages, and card content. |
Body S | 13 / 18 / Regular | Secondary text: helper text, metadata, supporting copy, labels, and compact content in overlay and mobile interfaces. |
Caption M | 10 / 14 / Medium | Small utility elements: statuses, chips, counters, short labels, and tiny supportive text. Do not use for primary content. |
Colors
Here are the most essential color tokens to use in extensions.
See the Extension UI kit • Colors ↗ for the full palette.
| Background Colors | |||
|---|---|---|---|
| Usage | Dark | Light | Used for |
surface-1 | #262626 | #F7F7F5 | Primary surfaces and main content areas. |
surface-2 | #1A1A1A | #FFFFFF | Cards, panels, modals, and elevated containers. |
surface-3 | #3A3A3A | #F0F0F0 | Nested blocks, inset sections, and secondary containers. |
| Text Colors | |||
|---|---|---|---|
| Usage | Dark | Light | Used for |
primary | #F8F8F8 | #1A1A1A | Headings, primary labels, and key interface text. |
secondary | #DADADA | #404040 | Supporting text, descriptions, and secondary metadata. |
disabled | #7A7A7A | #A3A3A3 | Disabled text, unavailable actions, and inactive UI states. |
Support Platform Themes
The Extension UI kit ↗ includes examples of how interfaces and individual components look in both light and dark themes. The Colors section also shows which colors should be used for which purposes.
At the same time, you do not need to copy the kit palette literally. You can also use your own color tokens. The technical side of theme support is covered in Theming.
No Theme Awareness: What Not to Do
If you do not want to make the whole interface theme-specific, make sure it still looks appropriate in both themes. Avoid extremely bright accents and surfaces that are too dark or too light.
✓ DO
✕ DON'T
No Theme Awareness: Acceptable
More neutral, slightly muted colors often work well in both themes without feeling too intense.
ACCEPTABLE
ACCEPTABLE
Minimal Theme Awareness: Ideal Approach
In many cases, it is enough to adapt the main backgrounds and key text styles to the current theme, while decorative elements, game mechanics, or a game surface can stay the same in both themes if they still feel natural.
EXCELLENT
EXCELLENT
If your tokens and styles are set up correctly, nothing should unexpectedly break when the theme changes. Model-facing settings are the exception: they should always support both themes explicitly.
Visual Consistency Review
To maintain a consistent and high-quality user experience, the Extension Platform team reviews each uploaded extension for visual alignment with platform standards.
The Extension Platform team reserves the right to reject an uploaded extension if its UI is visually inconsistent with these guidelines or negatively affects usability.
This review is part of the standard quality process and is intended to protect a clear, trustworthy experience for both models and viewers.