01
Built for another problem
Generic components did not reflect queues, appointments or service states.
QLess / Pegasus
Pegasus Design System.
A domain-specific design system created to make real-time service operations clearer, more consistent and easier to extend across product surfaces.
- Role
- Product Designer
- Platform
- Responsive web
- Timeline
- 3 months
- Scope
- System foundations & patterns
- Team
- Solo initiative → 3 designers
Challenge
The inherited library was built for a different product.
It had been created for an admin portal without contemplating the product as a whole. Generic components, missing rules and inconsistent states made user-facing screens difficult to design and maintain.
The issue was not a lack of components. It was a lack of a system that understood the product.
02
No internal logic
There were no shared tokens or documented rules for color, spacing, radius, elevation or type scale.
03
No predictable outcome
Screens recombined components differently, states were incomplete and accessibility was inconsistent.
04
A product defined by time
Operators needed to distinguish what was on time, approaching service, ready to act on or already overdue.
Foundations
Building on a proven foundation.
Material Design 3 was used as a foundation for familiar patterns, interaction behavior and state structures. Pegasus expanded that foundation with a more contemporary visual expression and a domain-specific operational language.
Start with familiarity
Use established patterns where users and developers already understand the behavior.
Adapt to the domain
Turn generic roles into a language for queues, appointments, readiness and time urgency.
Modernize the expression
Develop a current visual system through typography, color, shape, spacing and composition.
Urgency is not only colored
Labels, iconography, placement and actions make the time state understandable at a glance.
Architecture
From feedback colors to time-based patterns.
The system translates feedback roles into a shared time reference that travels across components and product patterns without losing its operational meaning.
A shared reference for time made different surfaces easier to interpret.
Time tag
Communicates the visitor’s current urgency.
Queue card
Uses the same state to establish priority at a glance.
Table & filter
Makes urgency scannable across visitors and lets operators isolate a time state.
Visit panel & calendar
Connects the visitor’s state to the next action and appointment context.
In product
Serving flow
Queue → selected visitor → summoned → active service → end service.
Appointment flow
Calendar → filters → visitor panel → edit modal → updated context.
Kiosk extension
Tablet and mobile kiosk experiences reuse the visual language where the interaction model applies.
Outcome
From individual decisions to a shared product language.
The impact was structural: decisions became documented, collectively agreed and reusable across product surfaces.
Shared
Designers and developers gained a common language for discussing states, patterns and behavior.
Reusable
New screens could start from predictable patterns rather than recombining generic components from scratch.
Scalable
The system supported contribution from three designers without making decisions dependent on one person.
Learning
Design work was deciding where the foundation had to become specific to the product.
Familiar interaction models reduced unnecessary invention. The system became distinctive when it encoded time, urgency and next actions; documentation and shared approval made those decisions durable beyond individual files.