01 / Fragmentation
Scattered components
The same pattern was rebuilt in multiple places, allowing small differences to accumulate across the product.
01 · Overview
01 / CONTEXT
LearnPress is a WordPress LMS ecosystem for learners, instructors, administrators and education businesses.
THE DESIGN CHALLENGE
As features and themes expanded, similar components were rebuilt separately. Naming, tokens, and documentation no longer pointed to one reliable source.
I mapped 93 screens to the product journey, standardized foundations and components, and checked those decisions against real UI. The figures below describe the design audit, not learner behavior.
93UI screens reviewed across the product journey
235variables organized as Global → Alias
67text styles for desktop and mobile
7stages in the product journey
02 · Product context
One platform, many touchpoints and expressions.
LearnPress supports the work of teaching and learning. Eduma brings that platform into different educational and brand contexts. A component change can surface in a course list, a learning flow, and several demos; scope therefore needs to be defined around journeys and shared rules.
PLATFORMWordPress
LearnPress LMSCourses · lessons · assessment · management
LearnPress LMSCourses · lessons · assessment · management
JOURNEYSThree sets of tasksLearners: discover and learn
Instructors: content and assessment
Admins: track and operate
Instructors: content and assessment
Admins: track and operate
EXPRESSIONEdumaDifferent educational demos, shared semantic roles and component structure
This map interprets the product relationship shown in the design files. Source LearnPress screens and Eduma demos appear below.
03 · The design challenge
As the UI grew feature by feature, inconsistency became an operating cost.
02 / Semantics
Values without meaning
Color, spacing, and radius were set manually instead of expressing their roles in the interface.
03 / Scale
Multiple roles and journeys
The system needed to support discovery, learning, assessment, collaboration, and administration.
04 / Constraints
The WordPress ecosystem
The solution had to flex across WordPress themes and add-ons while giving developers clear implementation rules.
The goal was a dependable source of truth for product design decisions.
04 · Reframing the problem
Move the unit of design from screens to shared decisions.
DESIGN QUESTION
How can the UI support more journeys and brand contexts without repeating the same decisions on every screen?
Prioritize by reach
- Find recurring patternsMap 93 screens across seven stages to locate shared structures and behavior.
- Define what stays stableColor roles, component anatomy, states, and information order belong at the source.
- Allow meaningful variationBrand modes and content can change; the meaning of actions retains shared rules.
This is my design framing from the audit, not a claim from user testing.
05 · Product architecture
Organizing 93 screens around the learner journey.
I organized 93 screens into seven stages of the learning journey. This made the relationships between touchpoints visible and allowed each screen to be traced back to its instance, component, and token.
- Discover01
- Evaluate & enroll02
- Learn03
- Assess04
- Collaborate05
- Track & manage06
- Extend & administer07
The journey in real product UI
Four real touchpoints show how the journey spans course discovery, learning, collaboration, and progress tracking.
Learn with continuity
Consistent lesson navigation, question states, and progress cues help learners understand where they are and what comes next.
Create with confidence
Reusable patterns across courses, curricula, lessons, and assessments reduce the need to relearn each module.
Manage at scale
Metrics, statuses, tables, and feedback follow shared rules so information can be interpreted and acted on consistently.
06 · Rebuilding the system
Fixing the foundation instead of patching components.
Global tokens raw values
Alias tokens semantic roles
Components behavior + states
Patterns reusable flows
Product screens real contexts
Global → Alias → Component
Color, typography, spacing, radius, surfaces, borders, actions, feedback, and icons were organized in layers. Components reference semantic tokens so changes can be controlled at the source.
Names that describe purpose
Temporary names, typos, hidden characters, and duplicate variants were removed. Properties now describe style, size, state, content, layout, and direction.
Controlled migration
Legacy values were identified separately so migration could continue without changing existing screens unexpectedly.
How does a change travel from token to UI?
This example follows Eduma’s Global / Alias Color Tokens and semantic usage guide. The blue Global card illustrates a raw color value; it does not indicate a selected state.
- 01 · Globalblue/main-2026Primitive value #2563EB for Eduma Main 2026.
- 02 · Aliascolor/bg/brandThe brand color role; components reference the alias rather than a hex value.
- 03 · ComponentButton (canonical)Variants and states are maintained in one component source.
- 04 · PatternCourse discovery CTAA primary action pattern used at the discovery touchpoint.
- 05 · Product UIEduma Main 2026Check the brand mode on the real demo homepage.
The Global → Alias mapping is documented in Figma; the demo UI is where the mode is checked in context.See Eduma Main UI ↗
07 · Components in product context
Reuse matters only when components work in real product flows.
Across course discovery and assessment, I examined component anatomy, state feedback, and how instances appear in product screens. Course Card and Quiz Choice provide two examples traceable to the source files. See Course Card in the discovery screen ↗
User needLearners need to compare courses by ratings, lessons, enrollment, price, and the next action.
Component anatomyImage → rating and title → lesson/student details → price → CTA. Each group has a clear reading order.
System decisionKeep Course Card as an instance with nested content groups and a Button, allowing one structure to serve course listings.
EvidenceThe image on the left is the real LearnPress component; the image below documents Quiz Choice states for assessment.
EXPLANATORY DIAGRAM · NOT A PRODUCT SCREENResponsive verification map
Check information order and layout behavior as Course Card moves from a multicolumn listing to one column.
Information priorityImageTitle + ratingMetadataPriceCTA
08 · Responsive behavior
Define component behavior before expanding across viewports.
Using the Course Card anatomy above, I identified which information must retain its order and which behaviors to verify at each breakpoint. The adjacent diagram is a design checklist, not product UI.
01Preserve reading order: image → title/rating → metadata → price → CTA.
02Test long titles, multiline metadata, and CTA width on narrow viewports.
03Define Hug, Fill, Fixed, and touch targets in the component specification before handoff.
These are responsive QA criteria; this case study does not claim a shipped mobile screen.
Checking the Eduma source component
Figma shows vertical and horizontal Course Card variants. The Responsive / Usage specification defines columns and behavior at each breakpoint.
Desktop ≥ 1200px4 columns · container max-width 1290px
Tablet 768–1199px2 columns · cards Fill the grid
Mobile < 768px1 column · touch targets at least 44px
09 · Extending to Eduma
One core system, multiple brand expressions.
Eduma began as a UI Kit I built while developing several demos. As the scope grew, I restructured it into a Design System: separating Foundation from Component Source, consolidating Button, organizing Input as Base–Composite, and bringing icons into one canonical library.
120 Button variants10 color modes314 icon variants254 icon meanings
Shared coreLearnPress Core
10 Eduma color modesGlobal color → semantic mode → component
10 / 10Eduma Main 2026#2563EB
Online Learning#098CE9
Global University#418435
Yoga Coaching#A36C45
Preschool#8329FE
Single Course#5D30F7
Marketplace#356DF1
Learning Platform#FF7700
Ecommerce#003AAA
Ivy League#FA394A
Mode names and colors are drawn from Global / Alias Color Tokens in the Eduma Design System.
One foundation, multiple education contexts
The demos share component architecture while adapting message, imagery, typography, and semantic color to their intended audiences.
01 / 05
10 · Design decisions & trade-offs
Keep one source of truth without freezing every interface.
These trade-offs describe the consequences of the architecture recorded in the design files. They do not imply that every alternative was tested.
Meaning before hex values
Problem: the same action role appears across different Eduma brand colors.
Decision: Global holds raw values; Alias names roles; components reference semantic tokens by mode.
Trade-off: each mode needs governance and QA, while Button can remain a shared component.
Evidence · Alias Color Tokens · 10 modesSeparate types from state combinations
Problem: combining input type, size, and state in one matrix makes the source hard to maintain.
Decision: organize Base → Composite → Selection. Base has 30 variants (3 radii × 2 sizes × 5 states); Input / Field keeps ten type variants at product level.
Trade-off: library users must understand the nested relationship; this avoids a 300-variant matrix.
Evidence · Input Architecture / 01 BasePreserve traceability during migration
Problem: existing screens and icons cannot be replaced in a single design operation.
Decision: distinguish legacy values, relink icon instances, and inspect detached instances after migration.
Trade-off: migration requires additional checks but makes later updates more controlled.
See audit measures ↗11 · Measured outcomes
Changes verifiable in the design files.
spacing properties in Eduma Component Source bound to tokens.
legacy icon instances relinked to the canonical library.
duplicate icon masters removed.
Input / Field type variants instead of a 300-variant matrix.
instances detached from their main components after migration.
standard documentation canvas width, down from as much as 5,200px.
These measures describe design assets and migration within the audited LearnPress / Eduma files. They do not measure delivery speed, conversion, or postlaunch learning outcomes.
12 · Product implications
A shared set of rules for design and development.
01 · Consistency
Shared rules, contextual application
One Button is maintained at the source, while ten Eduma color modes govern its expression across demos.
02 · Workflow
Less repeated work in the design file
Input / Field is kept to 10 type variants instead of expanding into a 300-variant matrix. Actual design time savings have not been measured.
03 · Maintenance
Changes at the source
Spacing properties in Eduma Component Source are token-bound; more than 1,000 legacy icon instances were relinked to the canonical library.
04 · Handoff
Less guesswork for implementation
Specifications cover anatomy, states, tokens, and breakpoints. This provides a consistent handoff reference, not a measured delivery-speed gain.
13 · Collaboration & handoff
Make implementation rules explicit.
01 · ROLEcolor/bg/brandAlias maps to Global color by mode.
02 · COMPONENTButton / Course CardAnatomy, properties, variants, and states at source.
03 · BEHAVIORGrid & breakpoint≥1200: 4 columns · 768–1199: 2 · <768: 1.
04 · CHECKInstances in UIVerify information order and long content.
A verifiable handoff example
The Eduma Course Card specification sets a Fill container with a maximum width of 1290px, Fill cards in the grid, fixed media aspect ratio, and touch targets of at least 44px. The semantic color guide lets developers map implementation back to component roles.
These specifications exist in the design file; development speed and code quality after handoff have not been measured here.
Responsive / UsageSemantic color usage
14 · Role & contribution
From the core system to product demos and launch assets.
My contribution spanned three connected areas: creating the shared design source, designing new demos and themes using LearnPress, and producing the visual touchpoints needed for release.
Audit & Design System
Mapped screens and repeated patterns; defined Global / Alias tokens, typography, components, variants and states. Specified responsive behavior, migrated instances, and documented usage for development.
Demos & themes
Designed additional demos and themes built on LearnPress, applying shared components to real interfaces while adapting expression to each educational and brand context.
Release visuals
Designed landing pages, thumbnails, covers, and illustrations for product releases, keeping the product UI, message, and visual language connected.
Role details were supplied by the designer. The case study shows demo UI; launch assets are not included as visual evidence here.