01 / Personal ContextLearner
User Dashboard
Everything the manager needs when completing their own training.
- Take assigned training
- Continue courses
- Track personal progress
- Access certificates
- Complete forms
← Work
Design Engineering Case Study / 01
Design Engineering / Full-Stack Product
Yoda Safety Services.
Designing and engineering an online training platform from the ground up.
I independently designed and developed Yoda Safety Services' production training platform, translating business requirements into the product structure, interface systems and full-stack functionality used by individual learners, companies and administrators.
Individual User Dashboard
Production Interface
70+
Courses
Live training catalogue3
User Contexts
Individual · Company · AdminLive
Production Platform
Checkout · Forms · Certificates02
Product Architecture
Designing the system
One platform. Different responsibilities.
The challenge wasn't simply deciding which pages to build. It was deciding which information, actions and permissions belonged to each user context.
Starting from functional requirements, I identified the different ways people would interact with the platform and structured the application around those responsibilities, while leaving room for new functionality to be introduced over time.
01
Context Separation
Separate the contexts, not the account.
A company manager is also a learner. Instead of combining personal training and company administration into one interface, I kept those experiences intentionally distinct while making both available through the same account.
A clear boundary reduces the chance of users confusing personal training actions with decisions that affect an entire company.
AccountCompany Manager
02 / Company ContextManager
Company Dashboard
A separate workspace for decisions and actions that affect the organization.
- Manage employees
- Track company training
- Send training reminders
- Purchase courses
- Manage forms and manuals
Same identityDifferent responsibilities
03
Designing for Change
The dashboards were never treated as finished screens.
01
Core Training
Establish the foundation.
Training, certificates, company management and distinct dashboards established the initial product structure.
02
Expanded Workflows
Add functionality without losing hierarchy.
Digital forms were introduced later, requiring new user, company and administrative workflows across the existing platform.
03
New Access Models
Extend the permission model.
Subcontractor access builds on the same architecture with a deliberately limited context for external users who only need selected company resources.
03
Responsive Behaviour
Designing for smaller screens
Responsive didn't mean shrinking the dashboard.
The desktop dashboard is designed to expose breadth. Mobile needed to prioritize speed, clarity and the next useful action.
Rather than forcing the desktop layout into a narrow viewport, I created a dedicated mobile composition using the same underlying product data while changing how that information is grouped and surfaced.
01 / Desktop
Broader context
02 / Mobile
Focused actions
Summary
Keep the status. Remove the weight.
Desktop summary items include counts, labels and direct links. Mobile condenses the same information into compact metrics so the learner can understand their current training status immediately.
DesktopCompact mobile metrics
Priority
Preserve what needs attention first.
High-priority actions remain prominent on mobile, but move from a horizontal card grid into a vertical list that is easier to scan and scroll with limited screen width.
Card gridVertical attention list
Content Density
Show enough to act, not everything available.
Training and forms become compact list rows with clear actions and links to the complete views, reducing visual density without hiding access to the larger system.
Dashboard panelsAction-focused lists
Engineering Approach
Same product state. Different composition.
The mobile interface still responds to the same training, company, forms and attention data as desktop. The difference is presentation: mobile-specific components control density, hierarchy and interaction for the smaller viewport.
MobileSummaryMobileAttentionItemMobileTrainingRowMobileFormRowMobileEmptyState
04
Product Workflow + Engineering
Beyond the interface
The interface doesn't stop at the screen.
Purchasing and completing a course crosses multiple parts of the product.
I designed the experience around the full training lifecycle, then implemented the frontend and backend functionality connecting account state, payment, course access, progress, assessment, notifications and certification.
01
Discover
Course Catalogue02
Select
Course + Cart03
Purchase
Account + Stripe04
Learn
Course Content05
Assess
Quiz + Progress06
Complete
Certificate01 / Individual Purchase
Cart + Checkout
01
Identity + Purchase
Preserve the purchase, require the identity.
Learners can browse courses and build their cart before signing in. Because purchased training must belong to an account, authentication becomes part of the checkout flow without forcing the learner to rebuild their purchase.
Cart→Sign in / Create Account→Return to Cart→Stripe
After payment, the purchased course or courses are added to the learner's account and can be started immediately.
02
Company Purchasing
One purchase. Multiple learners.
Company purchasing introduces another layer of responsibility: managers need to choose both what is being purchased and exactly who should receive the training.
Select Course
Choose the required training.Select Employees
Choose who should receive access.Review
Confirm the assignment before payment.Checkout
Complete payment securely through Stripe.Assign
Training is added to the selected learners.Notify
Receipt to manager + course email to learners.Assignment Review
Company Flow
Design decision
Employee selection and review happen before payment so the assignment is explicit before it affects multiple accounts.
03
Learning + Completion
Completion is a state change, not just a score.
Course Experience
Learning
Completion
Certificate
Learn
Course content can include PDF material, supporting documents and video resources. Multi-part courses expose progress throughout the experience.
Assess
Quiz answers are stored as the learner works through the assessment. A score of 85% or higher is required to pass.
Complete
Passing marks the training as complete while keeping the course content available for future review. Learners can then complete the follow-up questionnaire and access their certificate.
Retain
Certificates can be downloaded by the learner and are also stored in S3 so they remain available after the original completion session.
Behind the interface
A connected product system.
01React UI
Interactions + application state
02API Layer
Requests + business logic
03Authorization
Protected access + permissions
04Services + Data
MongoDB · Stripe · S3 · Email
Design Engineering
Frontend feedback and backend state stay connected throughout the workflow, while protected operations are validated server-side rather than relying on the interface alone.
05
Internal Tools + Platform Operations
Behind the learner experience
The product had to work for the people running it, too.
Yoda is not only a training interface. It also includes the operational tools required to manage the platform itself.
I built internal interfaces for managing courses, quizzes, companies, users, forms, manuals, newsletters and training activity without relying on direct database changes for normal platform operations.
Platform Administration
Operational Overview
More data. More controls. Different design priorities.
Content Operations
Create and manage the training system.
Courses and quizzes are created directly inside the application, alongside newsletters, manuals and form resources. The admin experience supports the ongoing content work required to keep the training platform current.
CoursesQuizzesNewslettersManualsForms
People + Companies
Manage the system across organizations.
Administrators can manage users and companies, review platform information, assign training and perform the same company-level management tasks available to managers with broader administrative access.
UsersCompaniesAssignmentsTrainingPermissions
Platform Control
Give administrators control without removing safeguards.
Admins can edit platform data, work with company resources, upload on behalf of organizations and trial-run form workflows, while sensitive actions can be restricted when the surrounding data relationships make a generic delete unsafe.
EditUploadTrial RunAssignSafeguards
Operational interfaces
Internal tools trade polish for operational clarity.
These screens expose more controls, more data and more actions than the learner-facing experience. The priority shifts toward scanability, hierarchy, efficient management and clear system feedback.
Company Management
Overview + Administration
Course Builder
Content Operations
Newsletter
Communication
System Safeguard
Destructive actions need context.
Not every database entity can be treated the same way. A course can become connected to learners, training records and completion history, so destructive actions require additional restrictions rather than a universal delete pattern.
Course
→Assignments
→Training History
→Completion Data
Permission-aware tooling
Administrative access doesn't mean impersonating the user.
Administrators can view and edit company form resources, upload on behalf of a company and perform a trial run of the workflow without completing the form as the company user.
01View + Edit
Manage the company's form resources.
02Upload
Act on behalf of the company where required.
03Trial Run
Test the workflow without producing a real submission.
Communication SystemCreate.
Create.
Edit.
Send.
Newsletter management also lives inside the platform. Admins can write, edit and remove newsletter content and trigger the email send without moving the workflow into a separate publishing system.
Draft→Edit→Publish→Email
06
Iteration + Product Evolution
2024 → Present
Designed to evolve.
Shipping was never the end of the design process.
Yoda has continued to grow as new workflows, product areas and requirements have been introduced. Rather than treating the original interface as permanent, I use implementation and continued testing as feedback for what should be simplified, separated or expanded.
01
Dashboard Hierarchy
From showing everything to showing what matters now.
The original learner dashboard reflected the product that existed at the time: training. Three primary areas surfaced incomplete, completed and all available courses.
As the platform expanded, that structure became less useful. Company training, forms and more nuanced course states introduced new demands on the dashboard.
EarlierCourse-Centric
Initial Product
IncompleteCompletedAll Courses
CurrentPriority-Centric
Expanded Product
Needs AttentionCurrent TrainingForms + Company Context
Design Shift
Completed training and the full catalogue no longer need to dominate the dashboard. The current experience prioritizes incomplete or expiring training and the actions that require the learner's attention now.
02
Workflow Iteration
When one screen started doing two jobs, I separated the jobs.
Digital forms introduced one of the most complex interaction problems in the platform. A reusable form template can produce many individual entries, which means the interface has to distinguish between managing the template, accessing previous entries and completing the form itself.
Original Approach
Too many responsibilities
Form ExperienceTemplate + Completion
Previous Entries
Entry 01
Entry 02
Entry 03
Entry 04
+ more as usage grows01
Completion and management competed for attention.
02
Entry volume made the screen increasingly dense.
03
Application state became unnecessarily difficult to manage.
→
Test
Refine
Separate
Refined Approach
One responsibility at a time
01
Management
Choose what you need to do.↓
02A
View Entries
02B
Access Form
↓
03
Focused Task
Complete the form without historical clutter.Result
Entry history remains available when needed without competing with the primary form-completion experience.
A scalable interface is not always the one that fits more onto a screen. Sometimes it is the one that knows when to separate responsibilities.
03
Engineering Evolution
Extend the foundation instead of replacing it.
The platform's core architecture has remained stable even as the product around it has grown. New requirements have expanded schemas, navigation, permissions and workflows without requiring the application to be repeatedly restructured.
Core Training
Courses + learner accountsCompany Tools
Employees + assignments + oversightDigital Forms
Templates + entries + permissionsCheckout Evolution
PayPal → StripeNew Access Models
Expanded permissions + navigationArchitectural Payoff
The architecture became more capable without becoming a different application.
New checks and requirements have been added as the product has matured, while the underlying data and application structure has continued to support expansion.
Even a larger infrastructure change, migrating checkout from PayPal to Stripe, could be introduced within the existing product while simplifying the resulting purchase experience.
What the project changed
Learning what actually scales.
The biggest evolution was not learning to use reusable components or separate concerns. It was learning which decisions remain manageable as a production product keeps accumulating requirements.
Anticipate edge cases
Inputs and user actions are treated as unpredictable. Validation, trimming and checks happen before data is trusted.
Structure for growth
Frontend, backend and file structures have evolved toward patterns that remain easier to navigate as the number of features grows.
Separate complexity
When a workflow becomes difficult to understand or maintain, the answer is not always another condition. Sometimes a responsibility belongs somewhere else.
Still Evolving
Production, not finished.
01
User Dashboard
Interface refinement02
Training Experience
Visual + interaction refinement03
Component System
Documentation + Storybook