Click anywhere to exit
Case Study | POCUS Focused
How I led design and frontend development on a custom learning management system built from scratch to replace an off-the-shelf LMS for a business that creates educational courses for physicians.
Overview
POCUS Focused teaches point-of-care ultrasound to physicians through online courses that count toward continuing medical education (CME) credit for their ongoing licensure. The previous off-the-shelf LMS helped them build a paying audience, but as the business grew, the platform got in the way and limited how they could deliver content. My business partner and I designed and built a replacement they fully own, giving them the flexibility they wanted.
The Challenge
The biggest challenge we faced was supporting multiple user types on both the business and end-user sides: four business user roles, three end-user group types with access to different features, and two end-user types whose experience changed based on group type. This created complexity and unforeseen requirements that emerged in the last few months of development.
My Role
I led the project's design, owning user flows, information architecture, the design system, and every screen. I then built most of the frontend in React and TypeScript while my partner built the backend. Designing and building the same product meant design intent never got lost in handoff, but it also required me to juggle two distinct sets of responsibilities.
Impact
Foundations
Most greenfield projects start with a blank screen, but this one started with a 26-course library built around another platform's structure. My first task was to determine how much of that structure was valuable and what needed to change. In our first month, I audited the existing platform and mapped out all features and workflows, including course building and management, user management, course completion, subscriptions & course purchasing, analytics, and more. I then sat down with the business team to understand where the old platform was failing them and where it was serving them.
Rigid authoring
POCUS Focused's content relied on a combination of images, video clips, written content, and structured assessments, but the legacy platform heavily dictated how course information could be presented.
Borrowed identity
Branding, marketing pages, and core student workflows had to bend to inflexible page templates and a clunky editor.
One-size-fits-all groups
Worst of all, the old platform couldn't support the variety of users and user groups POCUS Focused served, forcing all user types to share the same UI.
Discovery helped me create a prioritized roadmap focused on content creation and delivery for launch, and deferred features like gamification, CRM integration, and the marketing page builder, which aren't vital to the learning experience, to post-launch implementation.
Our Focus
Three principles guided the design process.
A course author should be able to intuitively compose rich, interactive lessons without needing an editor how-to guide, so they can focus on course content instead of wrangling the platform's UI.
POCUS Focused's learners are clinicians who study in short windows between shifts and may need quick access to course material while on the job. The learner experience prioritizes focus, flexible learning material, and making it easy to pick up where you left off.
Every user type shares the same underlying components and patterns, so the product feels like one platform for both the business user authoring a course and the end user managing a residency program or completing a lesson.
The Core Challenge
The biggest design challenge was the sheer number of people the platform had to serve, and how differently each one needed it to work. Users split into two categories, business users and end users, each with its own subtypes. Even within a single end-user role, the experience changes depending on the group a user belongs to.
Course Viewer
Reviews course content without being able to edit it.
Course Author
Creates and edits course content as well as supplemental learning content like flashcards, but can't see or manage end users.
Admin
Manages users and groups, invites people to the platform, and emails platform users.
Owner Super Admin
Everything an Admin can do, plus inviting business users and configuring the platform itself.
End Users
Learners
Complete course content, review their learning stats, practice with flashcards and assessments, explore featured content, and download certificates for completed courses.
Group Managers
Set their group's curriculum, manage group seats, and track learners' progress/performance.
Group Types
Residency Programs
Program-managed curricula tailored to each residency level, built around the weeks residents spend on their ultrasound rotation.
Physician Groups
Self-managed groups where the seat manager sets a default curriculum, and individual physicians can adjust their own curriculum if they want to deviate from the group.
I started by mapping user flows for each role on the business and end-user side, and documenting what each user needed to accomplish. Once I then laid those flows side by side, it showed where roles overlapped across group types and where they truly diverged. That let me design a shared core that every user experiences the same way, then layer role- and group-specific experiences on top only where the needs actually differed.
The hardest part wasn't designing any one experience. It was managing the complexity of orchestrating so many different experiences on the same platform, without making it confusing for the users.
No two of the 11 variants share the same access profile. Hover a dot to see the rule behind it.
Flagship Feature
A closer look at one of the flagship features I designed, from problem space to shipped solution.
Residency programs train physicians at multiple stages at once, and a senior resident doesn't need the same ultrasound curriculum as a first-year resident. Program directors need a way to deliver the right content to each level.
Residents only work through their curriculum during their ultrasound rotation. For most of the year, they don't use the platform, and when they do log in, they won't have courses to complete, but they could benefit from flashcards and featured content.
How do we show the right amount of content at the right time while keeping every content modality, from courses to flashcards to featured content, easy to discover?
For most of the year, residents don't have coursework to complete. The dashboard had to be valuable to them, even without courses.
Layout Explorations
I explored multiple layouts for displaying courses alongside flashcards, featured content, and notifications. [ what didn't work ]
Information Hierarchy
I played around with hiding certain information in favor of other content to find the right balance between focus and discoverability. [ what you hid & learned ]
Focused, but nothing hidden
The final design put in-progress courses front and center while still making it easy to toggle between curriculum weeks or scroll below the fold to see flashcards and featured content for additional practice and learning.
Weekly tabs
Group courses into tabs by rotation week so residents see only one week's worth of courses, not the whole curriculum at once.
Curriculum sidebar
A sidebar gives residents a quick, high-level view of their full curriculum and where they are within it.
Notifications widget
Notifications live in their own on-screen widget, so residents can see them on the fly and get alerted when new content becomes available.
Two Sides of the Platform
Authoring content and consuming it are fundamentally different jobs. I treated them as two distinct design problems, each with its own priorities, but halves of the same whole that should feel like an interconnected platform.
Authors needed more control. Learners needed less noise.
Design problem: Give a non-technical physician real control over rich content creation and management without exposing complexity.
Design problem: Help a busy clinician make steady progress in short sessions.
My Process
With new AI tools, I could easily transition the design from Figma into frontend code by connecting Claude Code to the Figma MCP server, allowing me to blur the line between design and development, making it easier (and more effective) to wear both hats.
Design System Preservation
The very first thing I did was extract design tokens from Figma into style sheets and mirror the 20+ components that I designed in Figma as React components in code.
Figma → Code Pipeline
Nothing was lost in translation because I could oversee the creation of every screen to exactly match how I designed it without having to do the manual translation myself.
Design + Build in Parallel
With design and development overlapping, I could update the design file first, then easily update the build to reflect the change, saving time trying to tweak the styles and UI elements in the code.
Below is the UI for the course outline screen that an author sees when managing a course. On the left is the screen designed first in Figma, and on the right is the end product we built for the platform. There are several minor differences, but using the Figma MCP server, we were able to build the UI to be nearly identical to the design files with very little effort.
My Impact
A summary of measurable outcomes across product, process, and business dimensions.
Product
6
User roles designed for
Product
20+
Design system components
Product
26
Courses migrated from LearnWorlds
Process
9 mos
From discovery to launch
Process
50%
Faster course creation
Business
✓
Managed scope creep to stay on track for our intended launch date
Business
1,000+
Active users in the first 3 months
Business
✓
Replaced off-the-shelf LMS with a platform the client fully owns
My Takeaways
Designing for six roles and multiple group types reinforced the importance of letting the platform absorb complexity—through shared components, clear role boundaries, and smart defaults—so users can enjoy simplicity. And I had to learn to design this experience while also being the one who had to build around the complexity the experience demanded.
Building the frontend myself held me accountable to the design decisions I made. I made decisions knowing exactly what they'd cost to build, which gave me restraint and empowerment because I knew when the price was worth paying for the sake of the user experience.
We optimized our scope to deliver everything the client needed to guarantee a positive end-user experience while minimizing the business's burden during the transition. We did this by deferring features like a page builder for the pocusfocused.com marketing site: we could easily build the first version ourselves, so the page builder itself didn't add value for the end user. We did the same for several other features: we shipped the functionality for the end user and acted as the go-between, making code changes as needed, until the business was ready for its own controls. That kept the launch focused on what learners and authors needed most, and deprioritized everything else.
This was by far the biggest project I've undertaken so far, especially given the resources my partner and I had. Who would have thought it would be so much work for two guys to build an enterprise-level learning platform from scratch? (Yes, that's a joke.) But it was an incredibly rewarding experience.
I'd love to talk about this project, my design process, or how I can contribute to your team.
Home
