HEYJUNIOR DESIGN SYSTEM · 2026
The app wasn't short on features. It was short on consistency students could rely on.
A design system that turned every screen into one dependable visual language.
Product Designer · Design System · Foundations to 50 variants in 2 weeks · Solo
Project Overview
Giving students an app that looks as reliable as the information inside it
HeyJunior is where KL University students check their timetable, grades, attendance and campus events. When an app holds your SGPA, every mismatched button or random colour raises a quiet doubt: is this right? I designed the HeyJunior Design System so that every screen looks and behaves the same way. That consistency is what makes students trust what they're reading.
Impact: One visual language across every student-facing screen. 459 tokens. Accessible defaults built into every component.
Problem
Every new screen was adding its own rules
HeyJunior grew one feature at a time, and each new screen brought its own colours, spacing and button styles. None of it was wrong on its own, but together the app felt stitched together. For a student checking exam dates or grades, an app that looks inconsistent feels like an app that might also get the facts wrong.
The same action looked different on different screens. Buttons and cards changed style from page to page.
Colours had no meaning. Tile colours were picked screen by screen, not by role.
There was no shared foundation. Every new screen started from zero, which slowed design down.
Every screen wasn't broken. Every screen was just built on its own rules.
Students weren't confused by the content. They were unsettled by the inconsistency.
Red and green become categories, breaking students' learned Mental model
Approach
Methodology
Every choice was tested against one question: does this make the app feel more dependable?
Build tokens before components. The tokens follow a Brand → Alias → Mapped structure
Components only use Mapped tokens. That means the whole palette can change without touching a single component.
Atomic Design Methodology
Atoms hold the foundation styles of the system: colours, fonts, spacing and icons. They're the reference point for building and managing every visual element and component in HeyJunior.
Components
Built once, used everywhere
Components are built atom by atom, then combined into larger patterns
Buttons: 3 types × 4 states, 12 variants.
Icon buttons: 12 variants, each with an accessible name.
Selection: toggle and checkbox.
Forms: label plus field, across default, filled and error.
Navigation bar: 4 destinations.
Every component has its default, hover, focus and disabled states designed, so nothing behaves unexpectedly for students.
Impact
When every screen speaks the same language, students stop second-guessing it
459 variables across 6 collections.
171 primitives distilled into 32 semantic tokens.
8 components and 50 variants.
28 icons.
New screens are now assembled from existing parts instead of designed from scratch. The result I value most isn't the token count. It's that the app now looks as dependable as the grades and timetables it holds.
Learning
What I'd do differently, and what's next
Naming is documentation. Clear token names matter as much as the values behind them. Next time I'd lock naming rules on day one.
Close the loop with code. Syncing tokens with development would keep design and build from drifting apart.
Users never notice a consistent app. They only notice when it isn't.
Built to scale. Designed to be trusted.