Things I build. Systems that fit human capability.

Human Problem

A small local brand needed a web presence that felt like the product: quiet, specific, and calm. Most template-driven small-business sites optimize for density and novelty. They're full of motion, autoplay media, low-contrast type over imagery, and carousels that interrupt reading. For a visitor who wants to understand what the brand sells and how to reach them, that's friction.

The second constraint was accessibility. Many small-business sites fail WCAG basics (contrast ratios, focus states, alt text, keyboard navigation) because accessibility is treated as a compliance checkbox rather than a design input. Designing for accessibility first tends to produce a better site for everyone, not just users relying on assistive tech.

Design Principles

Technical Scope

• Static site build with semantic HTML, responsive layout, and optimized asset delivery
• WCAG 2.2 AA: color contrast, focus indicators, keyboard support, reduced-motion support
• Lighthouse accessibility and performance scores above 95 on mobile
• Structured content model that non-technical owners can update without touching code

Human Problem

A personal training practice is four jobs at once: booking clients, designing their programs, running the session in real time, and handing them something useful to take home. Most trainers glue these together with calendar apps, a notes doc, a whiteboard, and a text message after the session. Every seam between those tools is where information gets dropped and the client feels it.

I built the suite as one connected system so the data moves cleanly: a client books, their VO₂ and assessment data shape the program, the program displays on a TV during the session with live timers and round counts, and the finished workout is delivered to them afterward with notes. No retyping. No whiteboard photos. No "I'll send it to you later."

Module 1: Scheduling App

A scheduling layer built on top of Cal.com with a credit wallet and availability rules calibrated to a real training week. Clients see only the slots that match their session type and trainer. Back-office logic handles cancellation windows, rescheduling credits, no-shows, and automatic reminders.

Design priorities: a booking link must display real-time availability and affordability in one glance. The system must never let a booking happen that the backend can't fulfill. When the user's state changes (credit balance, cancellation count), the interface updates without a page reload.

Module 2: VO₂ Data → Workout Integration

Internal tooling that imports VO₂ max test results and translates them into training zones that actually drive the program. Raw test data (max, ventilatory thresholds, recovery curves) gets mapped to the training model: zone definitions, interval lengths, rest ratios, and session RPE targets.

When I write a workout for a specific client, the tool auto-fills their zone numbers, paces, and load prescriptions based on their most recent test. If they retest and their thresholds move, their future workouts update automatically. The program is always calibrated to current physiology, not whatever numbers I remember.

This is where physiological testing stops being a report and starts being a live input into training. The gap between "your VO₂ is X" and "today's intervals should be Y at Z pace" is exactly where most testing services fail clients. The integration closes it.

Module 3: TV Display App (In-Session)

An app that mounts on the gym TV and displays the current workout during the session. Built for glanceability under physical load, not for browsing.

Module 4: Post-Session Delivery

At the end of the session, the workout the client just did, along with the actual loads lifted, any RPE notes I logged mid-session, and the prescription for the next session, gets delivered to their client dashboard. They can replay the exact block list, see their progression across sessions, and read my coaching notes without asking.

This matters because memory is the worst part of training. Nobody remembers what they did three Tuesdays ago. A week later the client can't reconstruct what weight they used on the final set. The delivery layer makes the session a permanent, searchable record. Progressive overload stops being a guess.

Technical Scope

• Scheduling layer on Cal.com with custom credit wallet, availability logic, and webhook reconciliation
• VO₂ import and zone-mapping tool that propagates test data into active workout templates
• Big-screen TV display app with live interval timers, round counters, and remote control from the trainer's phone
• Client-facing workout history with session-by-session progression, coaching notes, and load tracking
• Shared data model across booking, programming, session, and delivery so every view reads from the same source
• Supabase + Next.js stack with row-level security for client data

Human Problem

Most fitness environments fail two distinct user populations at the same time. Clients hit cognitive overload from excessive stimuli, unclear norms, poor equipment layout, and the kind of social pressure that keeps people from showing up consistently. Independent trainers hit a different wall: operational friction from shared-space conflicts, unpredictable scheduling, opaque pricing, and zero feedback on their own behavior within the space.

The conventional solution treats the gym as a container. I treated it as a system with interacting human operators, overlapping task demands, shared resources, and failure modes that propagate across users.

Human Constraints Identified

System Design: Physical Environment

The physical facility applies human factors principles typically used in control rooms, cockpits, and clinical environments.

System Design: Digital Operational Layer

I designed and built a full operational platform that manages the human side of facility operations. It spans scheduling, resource management, behavioral enforcement, and decision support, all integrated to reduce human error and operator burden.

Technical Scope

• Full-stack platform: Next.js, TypeScript, Supabase (PostgreSQL + Auth), Cal.com integration, Tailwind CSS
• 9 database tables with row-level security, automated triggers, and atomic RPC functions
• 10 API endpoints covering application scoring, booking management, violation tracking, and community features
• 229 SEO landing pages with internal linking architecture
• Automated cron systems for credit allocation, strike decay, and wallet management
• Real-time dashboard with data visualizations, behavioral analytics, and decision support tools

This is a live system managing real trainers, real bookings, and real behavioral feedback loops. The facility operates daily and the digital layer runs alongside it, collecting data that will refine every design decision over time.

Human Problem

Most physiological testing services are measurement-focused, not decision-focused. They produce numbers (VO₂ max values, resting metabolic rates, body composition percentages) and hand them to people who don't have the framework to interpret them. The result is data without direction.

The failure isn't in the testing. The equipment works. The protocols are standardized. The failure is in the human interface: the moment where complex quantitative output has to become something a real person can understand, trust, and act on.

Three things typically go wrong. First, results are presented in technical language that creates anxiety instead of clarity. Second, too many metrics are delivered simultaneously, overwhelming working memory. Third, there's no connection between what was measured and what to actually do differently tomorrow. The system I designed addresses all three.

Human Constraints Identified

System Design: Test Protocol Architecture

Tests are sequenced to manage cognitive and physiological load, not for operational convenience. The order in which information is collected affects both data quality and the subject's capacity to receive results.

System Design: Results Interpretation Framework

Results are never presented as raw scores. Every metric is translated through a three-layer interpretation model designed to close the gap between measurement and meaning.

Information is delivered in a specific order: metabolic data first (connects to daily habits), then body composition (connects to the metabolic data just discussed), then cardiovascular capacity (contextualizes fitness within the metabolic picture). Each layer builds on the previous one, creating a coherent narrative rather than a collection of disconnected scores.

System Design: Comparative Framing and Retest Architecture

Single-point measurements have limited decision value. The system is designed around longitudinal comparison: initial testing establishes a baseline, and retesting at defined intervals reveals trajectory. The value isn't in any single number. It's in the delta.

Results reports use visual comparison layouts: current values alongside previous values with directional indicators. This eliminates the cognitive work of remembering old numbers and computing change. The system does the comparison; the subject sees the trajectory.

Retest intervals are calibrated to the metric: body composition shifts are meaningful at 8–12 week intervals, cardiovascular improvements at 6–8 weeks, metabolic adaptations at 4–6 weeks. Testing too early produces noise that the subject interprets as failure. Testing too late loses the motivational window where visible progress reinforces behavior change.

Technical Scope

• Standardized testing protocols for VO₂ max (metabolic cart), RMR (indirect calorimetry), and body composition (multi-method)
• Three-layer results interpretation framework applied consistently across all metrics
• Structured results delivery protocol with sequenced information architecture
• Longitudinal tracking with visual comparison reports and directional indicators
• Retest cadence calibrated to physiological adaptation timelines per metric
• Client-facing educational materials designed to bridge the health data literacy gap

This system directly parallels usability challenges in medical devices and consumer health technology. The same gap between raw measurement and human comprehension exists in patient-facing health data, clinical decision support, and wearable device interfaces.

Context

The NOHrD Sprintbok is a mechanically elegant, self-powered curved treadmill designed for natural running mechanics. The hardware is exceptional. The software is not. The stock onboard interface undermined the physical experience through poor usability, creating a gap between what the machine could do and what users actually experienced.

Human Problem

Users found the treadmill's native interface frustrating and disengaging, which reduced usage and distorted performance feedback. The interface forced runners to do cognitive work that should have been invisible: converting units, parsing cluttered layouts, waiting for laggy display updates, and mentally filtering irrelevant data points during physical exertion.

The result was a human-machine system where the display actively degraded performance. Runners spent attention on the screen instead of on their movement. They couldn't pace accurately because the feedback loop was broken. Some stopped using the display entirely, losing all the performance data the machine was collecting. Others stopped using the treadmill altogether.

Human Constraints Identified

System Design: Information Hierarchy

The interface prioritizes metrics based on task analysis of what runners actually look at during a run, not what the treadmill can measure.

This hierarchy reflects the Proximity Compatibility Principle: the most critical information for the running task is spatially proximate and visually dominant. Less urgent metrics don't compete for the same attentional resources.

System Design: Feedback Loop Responsiveness

The stock interface updated speed readings approximately every 2–3 seconds, creating a perceptible disconnect between physical effort and visual feedback. The custom app reduced this to sub-second updates by optimizing the Bluetooth data pipeline and smoothing sensor readings to eliminate jitter without introducing perceptible lag.

Responsive feedback matters because runners use the speed display as a closed-loop control system. They adjust their effort based on what they see. When the display lags, the control loop breaks: runners overshoot or undershoot their target pace because the feedback doesn't reflect their current state. On a self-powered curved treadmill where speed changes with every stride adjustment, tight coupling between effort and display is essential. A 2-second delay turns pacing into guesswork.

System Design: Visual Design Under Motion

Every visual decision was driven by the constraint that the user is physically moving, cognitively loaded, and viewing the display through a bouncing visual field.

Technical Scope

• Custom application built for the NOHrD Sprintbok's embedded Android display
• Bluetooth Low Energy data pipeline optimized for sub-second speed updates with jitter smoothing
• Unit conversion layer (km/h → mph) with pace calculation
• Redesigned visual hierarchy based on runner task analysis and glance-time constraints
• High-contrast, motion-stable typography and layout system with fixed-width numerals
• Zero-animation rendering architecture for maximum legibility under motion

This project solidified my interest in Human Factors and HCI at the intersection of physical systems, embedded displays, and performance feedback. It demonstrated that small interface changes, when grounded in human capability analysis, can fundamentally alter both user experience and system effectiveness.

Human Problem

Most behavior change programs fail not because clients lack motivation, but because the starting point is wrong. When you prescribe changes that exceed someone's current capacity, they don't gradually build up. They stop. The system selected for the wrong behavior first.

The other failure mode is systems that rely on willpower rather than structure. Willpower is a finite resource that degrades under stress, fatigue, and competing demands. Any system that depends on it will eventually fail. This is well-established in behavioral psychology but ignored by most consumer health products, which treat motivation as an input rather than an output.

The third failure mode is invisible: systems that can't distinguish between actual behavior and reported behavior. People consistently overestimate healthy behaviors and underestimate unhealthy ones. An intake process that asks "how often do you exercise?" gets an aspirational answer, not a behavioral baseline. Every downstream recommendation built on that answer is miscalibrated from the start.

Human Constraints Identified

System Design: The Intake Process

The process starts with a structured intake questionnaire designed to establish a behavioral baseline. Not goals. Not aspirations. Current reality: what the person is actually doing, what they're not doing, what they're already good at, and where the obvious gaps are.

The questions are calibrated to surface the lowest-hanging fruit: the one behavior change that requires the least disruption to the existing routine and has the most downstream leverage. That's where we start. Not because it's easy, but because a successful first habit builds the cognitive model that makes the next one possible.

Critically, the questionnaire is designed to detect the gap between stated and actual behavior. It asks about frequency, timing, context, and barriers. Not just "do you do this?" but "when did you last do this, what happened before and after, and what got in the way the time before that?" This produces a behavioral map that's more accurate than self-assessment alone.

This intake approach is systematic. It produces a clear picture of where someone actually is, which makes the starting point a design decision rather than a guess.

System Design: The Progression Model

Once the starting point is established, the progression follows a consistent structure:

System Design: Feedback Loop Architecture

Behavior change without feedback is guessing. The feedback loops in this system are designed to be short, specific, and actionable.

System Design: Failure Mode Prevention

The most common failure in behavior change programs is abandonment in weeks 2–4. The system is designed to prevent this through three mechanisms:

Technical Scope

• Structured intake questionnaire with behavioral baseline scoring and aspirational-vs-actual detection
• Progressive habit assignment framework with capacity-matched challenge selection
• Check-in and tracking protocol with real-time practitioner notification pipeline
• Longitudinal consistency tracking with pattern visualization (day-of-week, context, compliance trends)
• Adaptive difficulty model: challenge level adjusts based on compliance data, not calendar progression
• Graceful degradation system: streak breaks don't trigger resets or shame signals

This framework operationalizes principles from behavioral psychology, habit formation research, and self-determination theory into a repeatable system that adapts to individual variance. The same architecture applies whether the target behavior is nutrition, movement, sleep, or any other domain where sustained change requires more than information and intention.