Overlabels for Designers

Overlay design has constraints that web and product design don't usually train for: the background is literally a video game, an IRL camera walking through a sunlit park, a cooking stream, or a moving cycling shot. Every text field is variable-length, and every animation has to be expressible in CSS. Mockups that look pristine in Figma can fall apart the second a username goes from "Jasper" to "xX_LongUsername2024_Xx", or the streamer switches from a dark dungeon to a blown-out outdoor scene where the horizon is pure white. This page is the pre-flight checklist.

1. The two surfaces: static and alert

An Overlabels overlay is two distinct surfaces, with different constraints. Designing them as one thing is the most common mistake.

Static overlay

The always-on layer. Camera frames, follower counters, donation goals, current game or location, recent supporter, GPS speed, subathon timer. It sits on the screen for hours. Live values mutate inside it.

Design constraint: nothing in the static overlay should ever distract from what the streamer is actually doing - whether that's playing a game, walking through a city on an IRL stream, cooking, or just chatting on a webcam. No looping animations that pull the eye. No flashing. No high-contrast motion at the edges of the safe area. Subtle drift, breathing, or pulse-on-event is fine. A 4-second loop that draws attention every 4 seconds for 6 hours is not.

Alert overlay

The one-shot layer. Fires when an event arrives (a follow, a sub, a raid, a Ko-fi donation). Animates in, holds for a few seconds with the event data on screen, animates out, vanishes.

Design constraint: alerts are supposed to draw attention. They have a lifecycle (enter, hold, exit) and a duration (typically 4-8 seconds total). The hold phase needs to be readable in a second or two by a viewer who looks up at it after the streamer reacts. Animation can be loud; copy cannot be wordy.

2. The background is unknown

The overlay sits on top of whatever the streamer is showing - dark dungeon, sunlit IRL street, white starting-soon screen, a cycling horizon that swings between pavement and overblown sky. A design that pops against gameplay can fall apart mid-broadcast when the camera steps into noon sun.

Standard strategies for "readable on any background":

• Contrast plates - semi-transparent dark or blurred panel behind text. Most common professional move.
• Text stroke - 2-3px outline. Cheap, slightly ugly at small sizes.
• Drop shadow - soft, 8-16px blur, low opacity. Lifts text off anything.
• Backdrop blur - backdrop-filter: blur(8px) behind a tinted panel. Modern, expensive on low-end GPUs.

Designer deliverable: mock against four backgrounds - dark game, sunlit-overblown IRL, night-time IRL, and pure white. If the design holds in all four, ship.

3. Every text field is variable-length

Live data fields are not fixed-width. A username can be 3 characters or 25. A donation amount can be $1 or $1,000. A donation message can be empty or 200 characters of emoji and exclamation marks. A follower count can be 12 or 12,000,000. The same overlay slot has to accommodate all of these without breaking.

Strategies:

• Truncate with ellipsis for fields that have a hard layout slot (donor message in a 1-line alert).
• Allow vertical growth for fields that should never be cut (donation message, raid greeting). Design the panel to expand downward.
• Right-align numbers so the digit count visually grows leftward into space you reserved.
• Auto-shrink font size for hero text fields (subathon timer, big counter) where the value can grow by orders of magnitude.
• Test against the worst case. Mock up the alert with the longest realistic donor name and message. If it survives, ship.

4. Fluid layout, not pixel-perfect

The reference resolution is 1920x1080. But OBS scales browser sources, streamers run different DPI, and a "fits perfectly at exactly 1920" design tends to look fragile at 1280 or wrong at 2560. Design in a way that survives:

• Think in flex and grid, not absolute pixels. Mock at 1920x1080 but specify spacing as ratios or rems where it matters ("16px gap between item and label" rather than "label at x=842").
• Anchor to corners, not coordinates. "Top-right, 32px from the edges" implements cleanly. "x=1856, y=32" implies pixel-positioning that doesn't survive scaling.
• Use SVGs and vector decoration. A raster decoration at 1920 looks fuzzy when OBS scales the source to 2560. SVG stays crisp.
• Set explicit safe areas. Twitch overlays the chat sidebar on theater mode (and Twitch streamers' webcams often live in known zones). Identify safe areas in the design and avoid putting critical info in them.

5. Animation lives in CSS

Overlabels overlays don't run JavaScript (this is a deliberate security and shareability decision - see "The constraint is the feature" on the For Creators page). All animation runs through CSS keyframes, transitions, and transforms. That has consequences for what a designer can spec.

Things CSS does well:

• Transforms (translate, scale, rotate, skew) - GPU-accelerated, butter-smooth
• Opacity fades, color transitions, blur
• Keyframed loops with custom easing curves (cubic-bezier)
• Stagger via animation-delay, mid-anim pauses via easing tricks
• Reactive animation: a transition that fires whenever a Control changes value (which means a donation can drive a pulse without anyone writing code)

Things CSS can't do, that a video tool can:

• Per-particle physics (sand, water, smoke - too expensive in CSS)
• Procedural shape morphing beyond what SVG path-morphing allows
• True 3D scenes with lighting (CSS 3D is fake-3D plane stacking)
• Frame-perfect synchronization with audio

Lottie is supported. If a designer wants a complex vector animation (a celebration burst, a coin shower, a custom logo reveal), exporting to Lottie via After Effects + Bodymovin and dropping the JSON in is fine - Overlabels includes the lottie-web player. Note: lottie.host's upload UI was absorbed into lottiefiles.com, so new uploads go through there or tiiny.host. Existing lottie.host URLs still work.

Designer deliverable for animation: a video reference of the desired motion (Lottie export preferred, or a quick screen-recording from After Effects / Figma's prototyping mode), plus timing and easing notes ("400ms ease-out, then a 2s hold, then 600ms ease-in"). The implementer translates those notes into CSS keyframes. Without the timing notes, the implementer is guessing.

6. What to deliver

A handoff that lets an implementer translate the design into Overlabels HTML/CSS without follow-up questions. In rough priority:

A Figma file (or equivalent)

Frames at 1920x1080 for each surface (static overlay, each alert variant). Layers named meaningfully - "donor-name", "amount-pill", "icon-coin" - not "Rectangle 47". Components used for repeated elements. If the file is messy, the implementer prices in cleanup time.

Multiple states per surface

Show the static overlay at minimum once with realistic short content and once with worst-case long content. Show each alert at minimum its short and long state, plus the entry / hold / exit moments annotated. Empty states matter too - what does the "latest donor" panel look like before anyone has donated this stream?

Color tokens

A small palette of named colors (primary, accent, success, warning, surface, surface-elevated, text, text-muted) with hex values. The implementer puts these into CSS custom properties so every component pulls from the same source. Don't sprinkle 47 hand-picked hex values across the design.

Typography spec

Font family, weight, size (rems preferred), line-height, letter-spacing, and the actual font file or Google Fonts URL. Be explicit about fallbacks for users who block third-party fonts. If the font doesn't have a free web license, flag it now - that's a license-check moment, not an implementation decision.

Asset exports

SVG for icons and decorative shapes, exported with optimized paths and sane viewBox. PNG (transparent) for raster art that genuinely needs to be raster (a textured logo, a painted illustration). WebP is fine for photographic content. Not JPGs with hard backgrounds. Not flattened final renders of the whole UI

• those are mockups, not assets.

Animation references

One short video per animated element showing the desired motion at the desired timing. Lottie JSON if the animation is complex. Annotated timing notes ("400ms ease-out enter, 2.5s hold, 500ms ease-in exit") for everything. Without these, the implementer estimates - which is fine, but the streamer ends up with motion the designer didn't intend.

A list of which fields are live data

Mark every text element as either "static copy" or "live data". For live data, name the source ("Twitch follower count", "latest Ko-fi donor", "GPS speed"). The implementer maps these to the right Overlabels Controls and template tags. The Integration Presets page is the catalog of every available live data field.

7. What not to deliver

• A single flattened PNG of the overlay. Looks great, useless for implementation.
• Mockups with placeholder Lorem Ipsum. Use realistic strings: real-length usernames, real donation amounts, real game titles or IRL category labels.
• Pixel-fixed coordinates. "Position label at x=842, y=560" is not implementable in a fluid layout. Specify in spacing relationships ("16px below the avatar, left-aligned with the donor name").
• Animation specs without timing. "It pulses" is ambiguous. "200ms scale 1.0 to 1.05 ease-out, 200ms back to 1.0 ease-in, on every donation event" is implementable.
• Fonts that aren't web-licensed. If the designer specifies a $300/seat foundry font, the streamer either pays the license or the implementer substitutes a Google Font and the design drifts. Catch this at design-review.
• Designs that only work on one background. If the mockup is on a dark game and the streamer's next stream is a sunlit IRL walk - or even just a different scene in the same broadcast, like an IRL streamer stepping out of a shaded alley into noon sun - the overlay falls apart in real time.
• Adobe After Effects projects with no Lottie export and no video reference. The implementer can't open the .aep, and CSS animation is not video animation. Lottie or video, not project files.

8. Working with the implementer

The implementer (the streamer themselves, or someone they hired to translate the design into Overlabels) needs three things to start: the Figma file, the asset exports, and the live-data field list. Everything else can be questions during the build.

What goes well:

• The designer is available for a 30-minute review when the implementer has a working draft.
• Naming in the Figma file matches naming in the implementer's CSS (the donor-name layer becomes the .donor-name class).
• The designer accepts that some pixel-perfect details are going to flex when the design meets real data and real backgrounds, and is willing to iterate on those moments rather than fight them.

What goes badly:

• The designer disappears after handoff and the implementer has to make every micro-decision alone.
• "That's not what I designed" is the only feedback after a draft, with no specifics.
• Animation that wasn't specced in the design becomes scope creep mid-implementation ("oh, can it also do this").

9. Deep dives

The technical pages a designer might want to skim, to see what their design will be implemented against:

• For Creators - the system overview. What Overlabels is beneath the HTML/CSS surface, including the no-JS rule and why it exists.
• Integration Presets - the catalog of every live data field across Twitch, Ko-fi, Streamlabs, Fourthwall, BMAC, and Overlabels GPS. Useful for marking "this is live data" in a design handoff.
• Controls - the seven mutable value types the streamer can adjust live during a stream.
• Expression Controls - how live data turns into derived values that drive design states (a goal-progress percentage that drives a fill-bar width, for example).
• Formatting Pipes - how raw values become locale-aware display strings. A designer specifying "currency, two decimals, EUR" in a mockup maps to a one-line pipe in the implementation.