Back to list

Kaizer Design System:
A Decision-First Framework

A decision-first design system that guides users toward clarity without trapping them — built on Hick's Law, semantic tokens, and Tailwind-ready architecture.

MY ROLE

Product Designer

MY ROLE

Product Designer

MY ROLE

Product Designer

TIMELINE

2025 - Current

TIMELINE

2025 - Current

TIMELINE

2025 - Current

STATUS

In Development

STATUS

In Development

STATUS

In Development

Preview

Problem

My previous design system was a collection of components without conviction.

Multiple border radius values. Inconsistent spacing, only using primitive values. Naming conventions that were a pain to filter when developing.

When I started building a food discovery app designed to reduce decision fatigue, I realised the irony: my own design system was creating decision fatigue for me.

I needed to rebuild from first principles — not just to solve my immediate problem, but to create a framework I could deploy across future products.

BEFORE

AFTER

The Philosophy

"Guide decisions, preserve agency, earn trust through craft."

This single line governs every design choice in the Kaizer system. It means:

Guide decisions — Every interface should help users arrive at the right choice through progressive narrowing
Preserve agency — But never trap them. The user always retains freedom to choose differently
Earn trust through craft — Deliver enough visual refinement that friction points simply don't exist

Core Principles

1. Progressive Reduction
"Start broad, end certain."
Every flow progressively reduces options until the right choice becomes obvious. Never present full complexity upfront — reveal it through interaction.
Grounded in: Hick's Law — decision time increases logarithmically with the number of choices.
Litmus test: Does each step in the flow reduce what the user needs to consider?
In Practice:
Most food discovery platforms dump thousands of restaurants on a map and expect users to filter their way to a decision. That's not curation — that's delegation.
The app I'm building takes a different approach: learn your preferences over time, then surface just five restaurants per meal. Not fifty. Not twenty. Five.
The design system supports this by enforcing a hard rule: never present more than five options without grouping, hierarchy, or progressive disclosure.
1. Preserved Agency
"Guide, never trap."
Recommendations accelerate decisions, but the user always controls the final choice. Every guided path must have an exit. Every default must be overridable.
Grounded in: Autonomy principle (self-determination theory); Postel's Law — be liberal in what you accept, conservative in what you output.
Litmus test: If the system recommends X, can the user easily choose Y instead?
In Practice:
When Onz recommends a restaurant and the user taps "Let's go," we navigate them there. But they're never locked in.
They can choose any of the remaining four recommendations. They can pivot to a nearby restaurant they spot along the way. The system guides — it doesn't dictate.
I also made a deliberate decision to remove the search bar entirely. On most apps, search is a safety net. Here, it would undermine the core promise. If users can search the entire web, we've failed to curate.
That's not restraint for its own sake — it's design conviction.
1. Earned Aesthetic
"Polish signals trust."
Every visual detail should feel intentional. Beauty emerges from clarity, not decoration. If an element doesn't aid comprehension, remove it.
Grounded in: Aesthetic-Usability Effect — users perceive beautiful interfaces as more usable and are more forgiving of minor issues.
Litmus test: Remove a visual element. Did you lose meaning or function? If not, it shouldn't have been there.
In Practice:
Early designs featured four brand colours: peach, orange, red, and brown. It felt vibrant but chaotic — too many elements competing for attention.
I stripped it back to just red and peach, with neutral supporting tones. The result: a calmer interface that lets content breathe.
1. Progressive Reduction
"Start broad, end certain."
Every flow progressively reduces options until the right choice becomes obvious. Never present full complexity upfront — reveal it through interaction.
Grounded in: Hick's Law — decision time increases logarithmically with the number of choices.
Litmus test: Does each step in the flow reduce what the user needs to consider?
In Practice:
Most food discovery platforms dump thousands of restaurants on a map and expect users to filter their way to a decision. That's not curation — that's delegation.
The app I'm building takes a different approach: learn your preferences over time, then surface just five restaurants per meal. Not fifty. Not twenty. Five.
The design system supports this by enforcing a hard rule: never present more than five options without grouping, hierarchy, or progressive disclosure.
1. Preserved Agency
"Guide, never trap."
Recommendations accelerate decisions, but the user always controls the final choice. Every guided path must have an exit. Every default must be overridable.
Grounded in: Autonomy principle (self-determination theory); Postel's Law — be liberal in what you accept, conservative in what you output.
Litmus test: If the system recommends X, can the user easily choose Y instead?
In Practice:
When Onz recommends a restaurant and the user taps "Let's go," we navigate them there. But they're never locked in.
They can choose any of the remaining four recommendations. They can pivot to a nearby restaurant they spot along the way. The system guides — it doesn't dictate.
I also made a deliberate decision to remove the search bar entirely. On most apps, search is a safety net. Here, it would undermine the core promise. If users can search the entire web, we've failed to curate.
That's not restraint for its own sake — it's design conviction.
1. Earned Aesthetic
"Polish signals trust."
Every visual detail should feel intentional. Beauty emerges from clarity, not decoration. If an element doesn't aid comprehension, remove it.
Grounded in: Aesthetic-Usability Effect — users perceive beautiful interfaces as more usable and are more forgiving of minor issues.
Litmus test: Remove a visual element. Did you lose meaning or function? If not, it shouldn't have been there.
In Practice:
Early designs featured four brand colours: peach, orange, red, and brown. It felt vibrant but chaotic — too many elements competing for attention.
I stripped it back to just red and peach, with neutral supporting tones. The result: a calmer interface that lets content breathe.
1. Progressive Reduction
"Start broad, end certain."
Every flow progressively reduces options until the right choice becomes obvious. Never present full complexity upfront — reveal it through interaction.
Grounded in: Hick's Law — decision time increases logarithmically with the number of choices.
Litmus test: Does each step in the flow reduce what the user needs to consider?
In Practice:
Most food discovery platforms dump thousands of restaurants on a map and expect users to filter their way to a decision. That's not curation — that's delegation.
The app I'm building takes a different approach: learn your preferences over time, then surface just five restaurants per meal. Not fifty. Not twenty. Five.
The design system supports this by enforcing a hard rule: never present more than five options without grouping, hierarchy, or progressive disclosure.
1. Preserved Agency
"Guide, never trap."
Recommendations accelerate decisions, but the user always controls the final choice. Every guided path must have an exit. Every default must be overridable.
Grounded in: Autonomy principle (self-determination theory); Postel's Law — be liberal in what you accept, conservative in what you output.
Litmus test: If the system recommends X, can the user easily choose Y instead?
In Practice:
When Onz recommends a restaurant and the user taps "Let's go," we navigate them there. But they're never locked in.
They can choose any of the remaining four recommendations. They can pivot to a nearby restaurant they spot along the way. The system guides — it doesn't dictate.
I also made a deliberate decision to remove the search bar entirely. On most apps, search is a safety net. Here, it would undermine the core promise. If users can search the entire web, we've failed to curate.
That's not restraint for its own sake — it's design conviction.
1. Earned Aesthetic
"Polish signals trust."
Every visual detail should feel intentional. Beauty emerges from clarity, not decoration. If an element doesn't aid comprehension, remove it.
Grounded in: Aesthetic-Usability Effect — users perceive beautiful interfaces as more usable and are more forgiving of minor issues.
Litmus test: Remove a visual element. Did you lose meaning or function? If not, it shouldn't have been there.
In Practice:
Early designs featured four brand colours: peach, orange, red, and brown. It felt vibrant but chaotic — too many elements competing for attention.
I stripped it back to just red and peach, with neutral supporting tones. The result: a calmer interface that lets content breathe.
1. Progressive Reduction
"Start broad, end certain."
Every flow progressively reduces options until the right choice becomes obvious. Never present full complexity upfront — reveal it through interaction.
Grounded in: Hick's Law — decision time increases logarithmically with the number of choices.
Litmus test: Does each step in the flow reduce what the user needs to consider?
In Practice:
Most food discovery platforms dump thousands of restaurants on a map and expect users to filter their way to a decision. That's not curation — that's delegation.
The app I'm building takes a different approach: learn your preferences over time, then surface just five restaurants per meal. Not fifty. Not twenty. Five.
The design system supports this by enforcing a hard rule: never present more than five options without grouping, hierarchy, or progressive disclosure.
1. Preserved Agency
"Guide, never trap."
Recommendations accelerate decisions, but the user always controls the final choice. Every guided path must have an exit. Every default must be overridable.
Grounded in: Autonomy principle (self-determination theory); Postel's Law — be liberal in what you accept, conservative in what you output.
Litmus test: If the system recommends X, can the user easily choose Y instead?
In Practice:
When Onz recommends a restaurant and the user taps "Let's go," we navigate them there. But they're never locked in.
They can choose any of the remaining four recommendations. They can pivot to a nearby restaurant they spot along the way. The system guides — it doesn't dictate.
I also made a deliberate decision to remove the search bar entirely. On most apps, search is a safety net. Here, it would undermine the core promise. If users can search the entire web, we've failed to curate.
That's not restraint for its own sake — it's design conviction.
1. Earned Aesthetic
"Polish signals trust."
Every visual detail should feel intentional. Beauty emerges from clarity, not decoration. If an element doesn't aid comprehension, remove it.
Grounded in: Aesthetic-Usability Effect — users perceive beautiful interfaces as more usable and are more forgiving of minor issues.
Litmus test: Remove a visual element. Did you lose meaning or function? If not, it shouldn't have been there.
In Practice:
Early designs featured four brand colours: peach, orange, red, and brown. It felt vibrant but chaotic — too many elements competing for attention.
I stripped it back to just red and peach, with neutral supporting tones. The result: a calmer interface that lets content breathe.

Token Architecture

Kaizer uses a two-tier token system that separates raw values from their semantic application:

Primitive: Raw values (colours, numbers) ~ red-500: #EB4848
Semantic: Purpose-based references ~ color-primary: {red-500}

Tier

Purpose

Example

Primitive

Raw values (colours, numbers)

red-500 ~ #EB4848

Semantic

Purpose-based references

color-primary ~ {red-500}

This architecture means a single change to a primitive value cascades correctly through every semantic reference — no hunting through files to update colours manually.

Design-to-Dev Handoff

A design system only works if it actually gets built.

Kaizer is structured around Tailwind CSS naming conventions — the same mental model developers already use. Spacing tokens, colour scales, and component variants all mirror the implementation layer.

// Colours map directly to Tailwind
colors: {
  red: {
    50: '#FEE9E9',
    500: '#EB4848',
    600: '#D13838',
    700: '#B32D2D',
  },
  peach: {
    100: '#FCE7D2',
    500: '#E54F1A',
  }
}

// Spacing uses the same scale
spacing: {
  1: '0.25rem',  // 4px
  2: '0.5rem',   // 8px
  3: '0.75rem',  // 12px
  4: '1rem',     // 16px
}

Current Status

Kaizer is a modular design system framework designed to be deployed across different products while maintaining philosophical and architectural consistency.

The first production implementation is currently powering a food discovery app in active development, with a live waitlist. Every component, every flow, every principle is being validated against real user needs.

The system is designed to scale — the next project will inherit the same foundations, adapted with its own themed implementation.

More like this

Flexible Gym Access, Zero Friction

2025 - Current

Flexible Gym Access, Zero Friction

2025 - Current

Flexible Gym Access, Zero Friction

2025 - Current

CISSA Onboarding Experience

2024

CISSA Onboarding Experience

2024

CISSA Onboarding Experience

2024

Got questions?

I’m always excited to collaborate on innovative and exciting projects!

E-mail

weikaikhoo@gmail.com

Schedule a call

Got questions?

I’m always excited to collaborate on innovative and exciting projects!

E-mail

weikaikhoo@gmail.com

Schedule a call

Got questions?

I’m always excited to collaborate on innovative and exciting projects!

E-mail

weikaikhoo@gmail.com

Schedule a call

Kaizer Design System: A Decision-First Framework

Kaizer Design System: A Decision-First Framework

Kaizer Design System: A Decision-First Framework

Preview

Problem

BEFORE

AFTER

The Philosophy

"Guide decisions, preserve agency, earn trust through craft."

Core Principles

Progressive Reduction

Preserved Agency

Earned Aesthetic

Progressive Reduction

Preserved Agency

Earned Aesthetic

Progressive Reduction

Preserved Agency

Earned Aesthetic

Progressive Reduction

Preserved Agency

Earned Aesthetic

Token Architecture

Design-to-Dev Handoff

Current Status

More like this

Got questions?

Got questions?

Got questions?

Kaizer Design System:
A Decision-First Framework

Kaizer Design System:
A Decision-First Framework

Kaizer Design System:
A Decision-First Framework