Product Design System

Simple. Iconic. Delightful.

Every interaction is purposeful, every surface trustworthy. We design experiences that earn attention and reward it.

Principles

The principles that guide our approach to design and development.

PrincipleAlignment questionDescription
SimpleSimple

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.
IconicIconic

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.
DelightfulDelightful

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.
PurposefulPurposeful

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.
TrustworthyTrustworthy

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

theme/primary#2563EB
theme/primary-content#FFFFFF
theme/base_100#FFFFFF
theme/base_200#F3F4F6
theme/base_300#E5E7EB
theme/base-content#18181B

color / primary-opacity

primary-opacity/12{theme/primary} · 12%
primary-opacity/24{theme/primary} · 24%
primary-opacity/56{theme/primary} · 56%
primary-opacity/72{theme/primary} · 72%

Live preview

섹션 타이틀NEW
더 보기 ›
LOGO

우리은행 인스타그램

인스타 팔로우하기

100P
LOGO

우리은행 페이스북

페이스북 좋아요하면

100P
LOGO

우리은행 채널 친구

카카오톡 채널 추가하면

100P
Default · section/module · 15 tokens

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.

01

Interaction Patterns

Coming soon

Before 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.

Loading & Skeleton StatesScroll BehaviorsNotifications & AlertsPause & AskNavigation & RoutingTouch & Gesture FeedbackMicro-interactionsMotion & Transitions
02

UI Kit

Coming soon

The 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.

AtomsModulesViewsResponsive & Adaptive
03

Visual Language

Coming soon

Every 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.

Visual HierarchyColor ApplicationTypography in ProductImagery & IconographyCross-platform Consistency

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.

01

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.
02

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.
03

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.
04

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.
Want to meet us over coffee?