Simple. Iconic. Delightful.
Every interaction is purposeful, every surface trustworthy. We design experiences that earn attention and reward it.
| Principle | Alignment question | Description |
|---|---|---|
| Simple | Simple “Could my grandma use this without help?” | Designs must be immediately understandable. When there are two ways to do something, choose the simpler one. Users should never need prior knowledge, hidden tricks, or obsessive attention to navigate. Simple means clean, accessible, and predictable. Even with rich interactions or multi-mission flows, the path must stay obvious. |
| Iconic | Iconic “Is this something people would share or reference?” | Our work should be distinctive, high-quality, and instantly recognizable. We aim for designs that feel modern, confident, and relevant to our core audience—designs that make other designers quietly jealous. If a screen looks like it could belong to any competitor, it is not finished. |
| Delightful | Delightful “Is this genuinely fun and engaging?” | Interactions should feel enjoyable, not mechanical. Delight is not decoration. It is well-timed motion, playful feedback, and micro-moments that make users feel rewarded and engaged. It must never get in the way of speed or clarity. |
| Purposeful | Purposeful “Is this worth the user's time, or are we just manufacturing effort for no reason?” | Every experience must deliver clear, meaningful value. Time and effort spent by users must be worth it. We operate in a reward-driven ecosystem. Value must be obvious, immediate, and fair. If a flow feels like work, the reward does not justify it, or the benefit is not visible enough, we are wasting everyone's time. |
| Trustworthy | Trustworthy “Would a normal user trust this flow from start to finish, or does it feel like we teleported them into a different product?” | Users should always feel safe, oriented, and confident, even as they move across funnels. Our experiences span app surfaces, web, and hybrid transitions. The design must stay unified and reliable so users never wonder if they have been dropped into a sketchy third-party zone. Trust comes from consistency, smoothness, tone, and predictable behavior. |
“Could my grandma use this without help?”
Designs must be immediately understandable. When there are two ways to do something, choose the simpler one. Users should never need prior knowledge, hidden tricks, or obsessive attention to navigate. Simple means clean, accessible, and predictable. Even with rich interactions or multi-mission flows, the path must stay obvious.
“Is this something people would share or reference?”
Our work should be distinctive, high-quality, and instantly recognizable. We aim for designs that feel modern, confident, and relevant to our core audience—designs that make other designers quietly jealous. If a screen looks like it could belong to any competitor, it is not finished.
“Is this genuinely fun and engaging?”
Interactions should feel enjoyable, not mechanical. Delight is not decoration. It is well-timed motion, playful feedback, and micro-moments that make users feel rewarded and engaged. It must never get in the way of speed or clarity.
“Is this worth the user's time, or are we just manufacturing effort for no reason?”
Every experience must deliver clear, meaningful value. Time and effort spent by users must be worth it. We operate in a reward-driven ecosystem. Value must be obvious, immediate, and fair. If a flow feels like work, the reward does not justify it, or the benefit is not visible enough, we are wasting everyone's time.
“Would a normal user trust this flow from start to finish, or does it feel like we teleported them into a different product?”
Users should always feel safe, oriented, and confident, even as they move across funnels. Our experiences span app surfaces, web, and hybrid transitions. The design must stay unified and reliable so users never wonder if they have been dropped into a sketchy third-party zone. Trust comes from consistency, smoothness, tone, and predictable behavior.
Interaction Layers
Every feature is built from two distinct layers that work together to create cohesive, memorable experiences.
This is a Feature
An Engagement feature, a Mission flow, a Reward feedback
A feature is almost always made of a Delivery UX layer.
Grids, navigation, loading states, transitions
And a Signature UX layer
Gamification, moments, iconic interactions
The Signature Layer
Iconic & delightful
- Iconic, high-engagement interactions
- Differentiating mechanics (gamification, missions, moments)
- Where creativity and experimentation live
- Not composed from reusable blocks
The Delivery Layer
Simple, familiar & trustful
- Navigation, layout, containers, grids, loading states, transitions
- Consistency across very different Signature experiences
- Packaging, theming, structure
- Built for speed, reliability, and reuse
Variables
Our products serve hundreds of partners, each with their own brand. Chameleon is our token-driven theming strategy: a single, structured set of design tokens that powers every surface. Colors, spacing, radii, shadows, typography. Fully customizable, always consistent.
Theme presets
Grab from URL (alpha, AI not connected)
Token set
color / theme
color / primary-opacity
Live preview
스카이라인 피트니스
인스타 팔로우하기
모닝브루 커피
앱 다운로드하면
블루웨이브 트래블
카카오톡 채널 추가하면
Patterns
A unified library of interaction and visual patterns that define how every Buzzvil product looks and behaves. Rather than separating UX from visual, we treat them as one interconnected system. Everything lives in a single, browsable library.
The complete, browsable pattern library is maintained internally. Access is restricted to Buzzvil team members.
Interaction Patterns
Coming soonBefore any screen is drawn, we define how it behaves. Interaction patterns are the behavioral skeleton of every product surface. They govern how a user enters a flow, what happens while content loads, how feedback is delivered, and the physics behind every transition. This category also covers micro-interactions: the small, often invisible details (an icon that breathes, a counter that springs, a swipe that snaps) that compound into the feeling of a polished product. When these patterns are consistent, users stop noticing them. That is the goal.
UI Kit
Coming soonThe UI Kit is where interaction patterns become tangible. Every component exists to serve a specific behavioral purpose defined upstream. Atoms are the smallest units: a button knows how to communicate loading, disabled, and success states. Modules compose atoms into self-contained pieces like a campaign card or a reward row. Views orchestrate modules into full screens. The kit is built for Chameleon theming from the ground up. Every component accepts token overrides, responds to breakpoints, and adapts to platform conventions without losing structural parity.
Visual Language
Coming soonEvery visual asset we produce is designed to live inside a theming system. Icons, illustrations, and decorative elements are built with color structures that automatically adapt when a publisher's brand is applied. The same gift box rendered in four different palettes, each feeling native to its context. Typography, hierarchy, and imagery follow the same principle: parametric by default, so that visual consistency across hundreds of partner brands is a given, not an effort.
Conventions
The shared rituals, processes, and standards that keep our design system healthy and our teams aligned. These are not guidelines to interpret; they are agreements to follow.
Design Workflow
Every feature follows a structured path from exploration to production. The workflow integrates design review and handoff as formal checkpoints rather than afterthoughts.
- Discovery: problem framing, competitive audit, and user research synthesis.
- Wireframe: low-fidelity flows validated with product and engineering before any visual work begins.
- Visual design: high-fidelity screens built from the pattern library, using real tokens and components.
- Design review: weekly team critique and bi-weekly cross-team review. Changes to shared patterns require consensus from design leads.
- Handoff: annotated specs with token references, redlines, and interactive prototypes delivered in Figma. A handoff meeting is held before every sprint.
- QA: design-side visual QA on staging before release. Pixel-level checks against the spec.
Token Governance
Design tokens are the single source of truth connecting design and code. Their integrity is critical, so additions, modifications, and removals follow a formal process.
- All tokens live in a versioned JSON file synced between Figma and the codebase.
- New tokens require a proposal (name, value, rationale) reviewed by the design system team.
- Breaking changes (rename, removal, value shift) enter a deprecation window of at least one release cycle.
- Alias tokens (e.g. {theme/primary}) are preferred over raw values. Components should never hardcode hex or px.
- Token audits run quarterly to identify unused, duplicate, or inconsistent entries.
Naming Conventions
Consistent naming reduces cognitive load and makes the system searchable, scriptable, and predictable. Every artifact in the system follows the same rules.
- Tokens: kebab-case, semantic over visual. Use "primary" not "blue", "base-content" not "dark-text".
- Figma layers: kebab-case matching the component or token name. No "Frame 47" or "Group 12".
- Components: PascalCase in code, kebab-case in Figma. Name describes purpose, not appearance (e.g. RewardBadge, not RedCircle).
- Files & branches: feature/[scope]-[description] for branches, kebab-case for design files (e.g. mission-flow-v2.fig).
- Icons: [category]/[name]-[size] (e.g. navigation/arrow-left-24). Always include the grid size in the name.
Versioning & Changelog
Every release of the design system is semantically versioned so that consumers know exactly what changed and whether they need to act.
- Semantic versioning: MAJOR for breaking changes, MINOR for new tokens/components, PATCH for bug fixes and refinements.
- A public changelog accompanies every release, listing additions, modifications, deprecations, and removals.
- Figma library versions are tagged with the same version number as the code package for traceability.
- Deprecation notices are published at least one minor version before removal, with migration guidance.
- Release cadence: minor releases every two weeks aligned with sprint boundaries; patches as needed.