Quse Design System
Consulting client · Quse · iOS & Web
Built a design system from scratch to make development faster and more consistent.
Quse's early screens weren't tied to any component library or shared system. I built one from scratch to unify the experience and support future versions.
Quse design system components and properties
The Problem
The product lacked a unified system, leading to inconsistencies, duplicated work, and slower development.
Without shared standards, it was difficult to scale efficiently.
My Role
LEAD PRODUCT DESIGNER
I built the system on my own, from primitives and semantic tokens to components, patterns, and documentation, while redesigning the app alongside it.
WHAT SHIPPED
Primitive and semantic color tokens with light and dark modes
Core components and patterns for mobile and web
Queue-specific colors and icons for Upcoming, Saved, and Everyday
Documentation to guide usage
Quse design system components
Decisions & Trade-offs
NAMING TOKENS BY USAGE
I named semantic tokens by where they’re used, such as background/queue/upcoming/primary, so engineers could pick the right color without guessing and a theme change would only touch one layer.
BUILDING DARK MODE IN FROM THE START
Dark mode wasn’t in the app yet, but I gave every token light and dark values so the team could add it later without reworking the system.
Constraints
The system needed to support a small team and evolving product without introducing unnecessary complexity.
A snapshot of system primitives, semantics, and defined variables
What Changed
Engineers built faster and came to me with fewer questions about how to use components. The product gained a consistent visual and interaction language, ready for dark mode when the team adds it.
Hindsight
Future improvements could include expanded documentation and deeper integration with engineering workflows.
Organizational structure of Quse design system