Ruthvik Panchakshari

Seattle, Washington

Ruthvik Panchakshari

Seattle, Washington

Ruthvik Panchakshari

Seattle, Washington

Live

Tuner Design System: Building a foundation for scale

I organized and expanded Tuner’s existing visual assets into a reusable system of foundations, tokens, components, and patterns, giving design and engineering a shared structure for building the product consistently as it grew.

CLIENT

Zero Motorcycles Inc. | Scotts Valley, CA

75+

reusable components

recurring pattern groups

500+

screens supported

Timeline

Jun 2025 · Present

Updated August 2026

My Role

Product Designer

Platform

Windows Desktop Application

Responsibilities

Design System

Token Architecture

Component Design

Interaction Patterns

Collaborated With

Director, Product Experience

Product Manager

Software Engineering

Customer Experience (CX)

Quality Assurance

Director, Product Experience

Product Manager

Software Engineering

Customer Experience (CX)

Quality Assurance

01 / CONTEXT

The product was growing faster than its interface system.

Tuner already had colors and some components, but there weren’t shared rules for how they should be used. As new workflows were added, similar interactions were being solved in different ways, making the product harder to keep consistent as it grew.

02 / Audit

Before building a system, I needed to understand what already existed.

I reviewed the existing colors, components, and recurring interaction patterns to understand what could be reused, what needed structure, and where similar UI was being handled differently.

It helped me separate reusable foundations from one-off decisions and showed me where the system needed the most definition first.

I reviewed the existing colors, components, and recurring interaction patterns to understand what could be reused, what needed structure, and where similar UI was being handled differently.

It helped me separate reusable foundations from one-off decisions and showed me where the system needed the most definition first.

THE STARTING POINT

Existing Tuner UI / Asset Audit

Placeholder — replace with final visual

View larger ↗

03 / foundations

Consistency started with giving the visual language a structure.

Tuner already had an existing color palette, but the values weren’t structured for consistent reuse. I organized them into orange and neutral scales with clearer usage roles, giving components a shared foundation to build from.

COLOR FOUNDATIONS

View larger ↗

04 / tokens

I gave colors a clear role in the interface.

I organized the palette into primitive and semantic tokens. Primitive tokens stored the raw color values, while semantic tokens defined where those colors should be used across backgrounds, text, borders, and states. This made updates easier to apply consistently across components.

TOKEN ARCHITECTURE

Token Architecture

Primitive → Semantic → Component

View larger ↗

05 / COMPONENTS

Reusable components had to account for real product states.

I turned recurring interface elements into reusable components with defined states and variants, then expanded them as new workflows exposed missing states. This kept the library evolving with the product.

COMPONENT STATES

Component States

Placeholder — replace with final visual

View larger ↗

06 / PATTERNS

Recurring interactions needed shared patterns.

Reusable components handled individual UI states, but recurring workflows still needed consistent behavior. I grouped repeated interactions into six pattern families so the same behaviors could be reused across Tuner instead of solved again in each workflow.

Testing showed that different diagnostic flows were asking the same screen to do too much — collect evidence, surface support, trigger actions, and interpret results. As more flows were added, I needed a model for how the diagnosis itself should behave, not another one-off screen.

RECURRING PATTERNS

Recurring Pattern System

Placeholder — replace with final visual

View larger ↗

07 / ADOPTION

The system evolved as I used it in real product work.

I used the design system while building active Tuner workflows, which exposed missing states and patterns that weren’t obvious in isolation. Those gaps were added back into the library, so the system improved through real product use rather than being treated as a separate deliverable.

FROM SYSTEM TO PRODUCT

Tuner Product Application

View larger ↗

08 / IMPACT

A shared system for building Tuner more consistently.

The system grew to 75+ reusable components and six recurring pattern groups, supporting 500+ product screens across Tuner. New workflows could start from shared foundations and patterns instead of redefining common UI decisions each time.

WHAT I’D BUILD NEXT

Stronger token binding

Connect more component properties directly to semantic tokens.

Engineering documentation

Create a shared reference for how components and patterns are implemented in code.

Theming support

Extend the token architecture so future themes can be introduced without rebuilding components.

27%

fewer support tickets

An early pilot signal from support-ticket volume. Broader product outcomes will continue to be measured as deployment expands.

MEASURED

27%

fewer support tickets

MODELED

2,100+

support hours potentially avoided over six months

≈$140K

estimated support cost avoided over six months

TAKEAWAY

Building the system alongside Tuner helped me treat foundations, components, and patterns as working product infrastructure that could continue evolving with the product.

UP NEXT

SwarajAbility

Designing accessible job discovery and application workflows for people with disabilities.

View case study ↗

Context

Audit

Foundations

Tokens

Components

Patterns

Adoption

Impact