Designing a corporate LMS where every role has its own world
A token-based HR learning platform built for 3 distinct user roles — from IA and design system to a launch-ready prototype. Delivered in 1 month as team lead and internal mentor.
Overview
What we were building
Companies lose people before they even start. Not because the job is wrong — because the onboarding is broken.
Team.UP is a corporate LMS built around five core capabilities — onboarding, training and testing, a searchable knowledge base, competency management, and a rewards system — all scoped to three distinct roles: Employee, Learning Manager, and Admin.
The core design challenge wasn't just building screens. It was building three separate product experiences that share one visual language — without making any role feel like an afterthought.
We started with a problem most LMS tools ignore: when everyone sees the same interface, nobody feels like it was built for them. Team.UP is role-first by design — every dashboard, every navigation pattern, every content type is scoped to the person using it.
How it works
Platform functionality
How does it work in Team.UP?
The problem
Every role saw the same interface — and felt like an afterthought
Most corporate LMS platforms treat learning as a checklist, not an experience. That shows up in four recurring failures.
Key problems
Fragmented onboarding
Most LMS tools treat onboarding as content delivery. Team.UP had to solve it as a structured, role-aware journey — not a folder of documents.
No role separation
Existing tools force all users into one interface. Employees, managers, and admins don't share context — yet most platforms make them share screens.
Training without visibility
Learning happened, but nobody could track it. Managers had no real-time view of team progress, completion, or skill gaps.
Gamification as an afterthought
Points and badges existed in competing tools as decorative extras — not as a designed system connected to real learning milestones.
My contribution
What I shaped across three roles
As team lead, I designed the Employee experience myself end to end, and directed the structure and logic for Learning Manager and Admin — then built the shared system that held all three together.
Contribution by role
Employee
Navigates personalized learning paths, completes daily micro-modules, and tracks their own skill growth through an intuitive dashboard.
Learning Manager
Curates content libraries, assigns training batches, and analyzes team performance trends to identify critical knowledge gaps.
Admin
Manages system integrations, user permissions, and high-level security protocols while ensuring the entire ecosystem scales seamlessly.
Employee Experience
Designed end to end, from information architecture to final UI — the dashboard, course flows, all lesson types, Point Shop, and profile are my individual contribution within the team.
Learning Manager Experience
Defined the structure, logic, and prototype direction for the LM flow — screen hierarchy, navigation, key interactions — then reviewed and refined the team's execution against that reference.
Admin Experience
Same model as Learning Manager: set the interaction logic and prototype reference for the Admin flow, then guided revisions until the execution matched the system.
Design System
Set up the shared Figma environment — naming conventions, file structure, and review process — that let the team build the component library and shared styles together, keeping four designers of different skill levels aligned to one visual language.
Interfaces
Three roles, walked through
Not just the dashboards — the everyday screens that make each role feel like its own product, not a permission level.
Employee
Learns, redeems points, and finds resources — built for someone who wants to get through their day, not manage a platform.
Learning Manager
Runs the operational core — assigns courses, reviews submissions, manages participants, and configures the rewards employees redeem.
Admin
Owns the platform itself — organizational structure, role permissions, and the subscription that keeps it all running.
The design system
One token system, every role, every theme.
Inter, Indigo #4648D4, glassmorphism cards, and light/dark themes driven by the same color tokens — not duplicated components. Change the token, not the screen.
Process
Four weeks, five phases
No developers, no product manager — every decision happened inside the four-person team, moving between research and screens in tight loops rather than one clean handoff.
Process phases
Discovery
Competitive analysis (SmartExpert, Paradiso, HillelLMS) via Perplexity, market research, and defining the three roles the whole product would be built around.
Foundation
Information architecture, user flows, and the first reference screens — where I set the visual direction (Inter, Indigo, glassmorphism) the rest of the system would build on.
Parallel Build
Design tokens and components built together as a team, while role-based screens were designed in parallel across Employee, Learning Manager, and Admin — flows blocked out fast in Google Stitch before moving to full-fidelity Figma screens.
Validation
Review cycles against the design system, with prototypes tested end-to-end in Lovable to catch broken flows before polish.
Handoff
Final consistency pass across all three roles, then delivery as a launch-ready prototype.
Outcomes
