How I built it
- Mapped the user steps (browse classes, check schedule, book) before writing any UI code.
- Kept state and layout predictable even when the brief shifted mid-sprint.
- Live demo on the portfolio so the case study isn't just prose.
Technical depth / education
BodyBlitz gym booking web product
A short DCU web-application build. Static gym site (BodyBlitz) with home, services, classes, schedule, pricing, and contact sections. Animated landing, responsive nav, mobile-first layout.
Architecture
How the booking flow works
How a visitor moves from the landing page through browsing classes and the schedule into the booking flow, ending in a front-end confirmation state on any device.
My front-end structureProcess flow
How I work the steps
- 01 before Browse
Visitor lands and explores services and classes.
User - 02 control Check schedule
User checks class times for the week.
User - 03 handoff Book
User selects a class and reaches the front-end confirmation state.
Booking-flow UI - 04 after Confirmed
Confirmation state shown end to end, mobile-first.
User
Measured results
What I measured
UI flow evidence
front-end booking flow shipped
Responsive layout across the common breakpoints with a hamburger nav, anchored sections, and animated hero.
Findings
- Responsive layout across the common breakpoints with a hamburger nav, anchored sections, and animated hero.
- Owned the front-end structure end to end: HTML, CSS, animations, and the booking-flow UI logic without pretending the static prototype had a production booking backend.