This project was less about designing a travel app and more about mastering the craft of design system engineering. The brief gave us the scope — a travel application — but the real challenge was everything underneath: how do you architect a scalable, consistent design system from scratch, and how do you build it so that anyone on a team can use it without guessing?
Every component was engineered individually. Every decision was documented. The screens at the end were the proof that the system worked — not the deliverable.
The challenge
Most student design projects produce polished screens. Very few produce the system that makes polished screens repeatable. The brief pushed us to work the other way around: build the foundation first, then see what it produces.
Design system work requires a fundamentally different mindset than product design. You're not designing for one user flow — you're designing for every possible context a component might appear in. The discipline of thinking in constraints rather than compositions is something that takes deliberate practice to develop.
How we approached it
The process started at the atomic level and built upward — buttons, inputs, and tags before cards, navigation bars, and modals. Each component was built with documented usage guidelines, usability checks against accessibility and interaction standards, and multiple theme variants. The token architecture came first: spacing, typography, colour, and elevation defined before a single component was assembled.
Key insights:
- Token architecture is the foundation — without it, theming becomes an exercise in manual find-and-replace
- Documenting a component while building it catches edge cases that documentation-after-the-fact always misses
- Multiple themes aren't just visual variants — they test whether the system is actually token-driven or just consistent-looking
- Building for reuse forces you to separate concerns that product design usually fuses together
- The system is only as good as its weakest component — one poorly specced atom breaks downstream organisms
What we built
We engineered each component from atoms to organisms — buttons, inputs, and tags up through cards, navigation bars, and modals. Each component includes documented usage guidelines and props, usability checks against accessibility and interaction standards, and three complete themes: light, dark, and a brand variant. The full token architecture covers spacing, typography, colour, and elevation — consistent across every component and every theme.
All components came together in a final set of high-fidelity travel app screens. The screens weren't the goal; they were the test. The deliverable was the system that produced them.
- Full token architecture: Spacing, typography, colour, and elevation tokens defined before component work began
- Atoms to organisms: Every component level engineered individually with documented props and usage guidelines
- Three complete themes: Light, dark, and a brand variant — all driven by tokens, not manual overrides
- Accessibility-checked: Usability standards applied at the component level, not patched in at the screen level
- High-fidelity proof of concept: Final travel app screens demonstrate the system end-to-end
The project produced a working, documented design system — not a mood board dressed up as one. The final screen set demonstrated that the system held together across diverse screen types and real UI complexity.
It also changed how I think about design work. A component that isn't documented isn't finished. A system that only works for the person who built it isn't a system. These aren't abstract principles — they're things that became obvious only by doing the work this way.