Role
Founding Designer (0-1)
Skills
Design Systems / Visual Design
Project Type
Self Initiated
Tools
Figma, Claude, Antigravity IDE
Overview
While generic agent ready design systems (like Meta’s Astryx, shadcn) handle standard layouts just fine, they fall apart when hit with domain-specific complexity.
That’s why I am building Flite UI. Which is an AI native, agent ready and open-source design system contribution specifically for the travel space.
The Origin
I wanted to learn the art of building design systems from end to end. I started with an audit of IRCTC's UI inconsistencies. During that audit, I noticed a huge pattern: almost every travel platform out there uses identical patterns for their search bars, results pages etc.
Research
Yes, I was Ekalavya! 🏹
Before touching Figma, I spent time in watching, reading, and learning from people who've actually built systems people use.
Not just my gut feeling.. 😌
To understand where travel UI actually breaks down, I audited a range of travel platforms and 3 of them are shown here as examples: IRCTC Air, IRCTC Bus, and Confirmtkt.
two things stood out from audit!
IRCTC's own products don't even agree with each other
Confirmtkt a smaller, private company runs a noticeably tighter, more consistent system
…and that's when
I realised: the problem isn't that travel apps are badly designed, Confirmtkt proves good discipline is achievable. It's that this kind of discipline exists in isolated way, not open for smaller teams (or AI agents) to actually learn from or build on.
Why are u creating this? why now?
Multi-modal choas
No dominant open-source design system specifically solves the unique UX challenges of multi-modal travel density. However, existing open source systems (like Orbit by Kiwi.com) focus purely on modern air travel, ignoring complex regional rail/bus infrasturcture.
Unreliable AI Code Handoff
Traditional design systems are built only for human eyes, not for agents. And these libraries lack machine-readable logic under the hood, feeding them to AI agents results in slop.
Wait, who is this for? 👀
Design Principles
Solution
3 Token Architecture
To solve the friction of multi-modal data density, Flite UI runs on a 3-tier token system built directly into Figma variables.
Global tokens are raw, context-agnostic primitives
Alias tokens give those primitives meaning. I split this into two independent dimensions: theme (light/dark mode) and responsive breakpoints
Component tokens map alias tokens to specific UI decisions
For naming, I followed Nathan Curtis's token naming convention...
Current Stage
I built the Flite UI's foundations from the ground up. Color system, typography, variables and components are live in Figma. More in [documentation site].
Colors
A warning red looks different at midnight than noon. On a smartwatch vs a car dashboard. Most color systems ignore this complexity & they throw HSL or HSV at the problem and move on.
Flite UI uses OKLCH color space, which actually understands how humans perceive color across different lighting and contexts. Every color adheres to the WCAG contrast standards.
OKLCH color space in Leonardo
Typography
Travel is fast. You're scanning for a flight gate, a train platform, directions to your next destination and you need information now. Flite UI's typography system is built with this reality in mind.
DM Sans commands attention for headlines and hierarchy, Inter breathes in body text with readability, General Sans whispers through metadata, and Space Mono keeps our code clean.
Shown: Desktop Typography
Layout
Layout lives everywhere - on your wrist, in your pocket, on a dashboard, or at the airport. Flite UI defines breakpoints from a 1-2 col smartwatch view to a full 12-col desktop grid.
Gutters follow the same logic Compact, Cozy, Comfy, and Default densities, so a data-heavy comparison table and a spacious hero section can both feel intentional, not identical.
Shown: Large breakpoint (1024–1439px).
Figma Variables
Every color, spacing, and typography value in Flite UI exists as a real Figma Variable — not just a static style applied by hand.
Beyond these, Flite UI also defines elevation, border radius, and early motion tokens (still evolving) — all documented in full on the [documentation site].
Components
The full set is available on the documentation site, here's the Button component as an example.
Insight
While researching how to make component behaviour actually agent ready, I came across a distinction Meta's Astryx.
I haven't built the code layer yet, that's next. The principle below is what, I'm carrying into Flite UI's own component behavior.
💡
Guidance over Enforcement
Instead of rejecting invalid prop combinations, components accept the props they get and render best possible UI. Best practices are documented, not enforced.
What's next?
Right now, Flite UI has its foundations, documentation, and 10 core components live in Figma.
The roadmap:
Ship components to code
Export tokens as structured JSON, not just Figma Variables
Add component-level usage docs an AI agent can actually parse
Explore an
llms.txtfile once docs are public
TL;DR?
Solo Founder & Designer — building Flite UI, an open-source, agent-ready design system for travel.
Audited real travel platforms, backed by design systems research
Built a 3-tier token architecture (Global → Alias → Component) to solve travel's multi-modal complexity.
Currently: foundations, documentation, and components live in Figma.
Next: shipping to code, then making it agent-ready.