Kambi
Spark

Version 1.2.0

© 2025 Kambi Group plc

Designing with Spark

Designing with Spark means creating back-office interfaces using a unified system of tokens, MUI components, patterns, and guidelines. Spark provides a consistent, scalable environment where every design aligns with the real production implementation.

This page helps designers understand how Spark enables efficient, predictable workflows. It explains how Spark integrates with UXPin Merge, why the system uses MUI components without modification, and how tokens and patterns guide every design decision—ensuring work is always system-first, realistic, and production-aligned.


What Spark Includes for Designers

UXPin Merge (Design Tool)
  • Provides the same React components used in production.

  • Displays real states, props, behaviors, and interactions.

  • Includes Spark MUI, Spark Tokens, and Spark Helpers (Splitter, AppLayout).

MUI Library

Spark uses the latest MUI and MUI X components without modification.
Designers must use the exact MUI components provided in the Spark MUI library.

Design Tokens

Color, typography, spacing, elevation, and motion tokens are exposed directly in UXPin.
Always use tokens for all element properties—never raw values.

Spark Theme

Ensures visual consistency across all back-office applications.
Applies synchronized typography, color, density, and spacing tokens.

Design Patterns

Patterns define expected workflows such as filtering, forms, tables, navigation, and content layout.
They reduce decision friction and ensure consistent user experiences across apps.

Design Checklist

A structured set of criteria covering usability, accessibility, consistency, content, navigation, and performance.
Helps teams identify issues early and maintain design quality from exploration to implementation.


Core Principles of Spark

Designing with Spark means working within a system of pre-defined building blocks rather than creating isolated or custom solutions. This approach ensures designs are scalable, maintainable, and aligned with engineering and production realities.

System Principles

Spark is built around a few guiding principles that ensure consistency, efficiency, and developer alignment:

  • Design within the ecosystem – avoid detached screens; start with patterns before layouts.

  • Prioritize clarity, consistency, and repeatability – always apply tokens, not custom values.

  • Leverage component variants – use defined variants rather than creating visual deviations.

  • Follow patterns first – predictable, reusable patterns solve common workflows effectively.

Consistency & Efficiency

Spark reduces decision fatigue so designers can focus on usability. Achieve this by:

  • Using component variants exactly as defined.

  • Applying spacing, color, and typography tokens consistently.

  • Following established design patterns for common workflows.

  • Avoiding custom visuals that cannot be implemented with MUI.

Token-first approach: Tokens define Spark’s visual language for spacing, typography, color, elevation, and motion. They ensure consistency across applications and remove the need for manual styling.

Pattern-Driven Design

Start with patterns to guide component selection and page composition, for example:

  • Data-entry workflows → Form patterns

  • Comparison pages → Table or Card patterns

Patterns provide predictable, reusable solutions for recurring design challenges and ensure components fit seamlessly into the ecosystem.

Designer–Developer Alignment

Spark keeps designs and code perfectly synchronized:

  • All components in UXPin are real MUI components sourced from the same repository developers use.

  • Prototypes reflect true production behavior.

  • Designers should understand basic CSS and layout behavior.

  • Accurate prop usage improves handoff and produces reliable JSX code.

Strict Use of MUI Components

A core rule in Spark is using MUI components and their defined variants:

  • Avoid creating new component designs.

  • Minor customizations are allowed only via MUI props or slots.

  • Request a Helper only when a recurring, system-wide need cannot be solved with MUI, such as Spark’s AppLayout or Splitter.