CASE STUDY · RYLMNL
Designing rylmnl: One Mobile App to Replace Two Web Systems
rylmnl is a Philippine race organizer running marathons and fun runs nationwide, from Baguio to Albay to Siargao. Today, registering for a race, tracking it live, and finding your race photos afterward live on two separate websites. This case study documents redesigning that experience into one native app — from UX audit through engineering handoff.
Role
UI/UX Designer
Scope
iOS · Android
Screens
100+
01 — THE BRIEF
What the product team handed me
rylmnl came to this project already knowing two things: they run two disconnected products for the same race weekend, and mobile users — the majority of their runners — were struggling to complete registration. Both were stated upfront in the brief. My job started after that, turning the brief into a synthesized problem I could actually design against.
royalmnl.com
Race Registration & Tracking
→ Race discovery & registration
→ Live checkpoint tracking
→ Official results lookup
→ Internal ops dashboard
getsureshot.com
Sureshot — Photo Discovery
→ Selfie-based AI photo search
→ Photographer Portal
→ Organizer Login
02 — SYNTHESIS
Turning the product team's findings into design inputs
The product team had already gathered runner feedback and support-ticket patterns before I joined. My first task wasn't more research — it was organizing what they already had into something I could actually design against, and spotting the gaps their data left open.
Given by the product team
What I started with
Runners are majority-mobile, opening links from Facebook/Messenger
Support tickets mention payment failures and "page looks broken"
Registration and photo discovery live on two separate domains
Gaps I flagged
What wasn't in the brief
No breakdown of exactly where in the funnel runners drop off
No data on whether runners realize Sureshot is a separate product
No severity scoring — just anecdotal ticket volume
My synthesis
Reframing the problem
Root cause is likely in-app browsers breaking payment gateways, not "mobile" as a device category
The existing warning modal is proof the team already suspected this, without fixing it structurally
Fragmentation across domains compounds the drop-off, it doesn't just sit beside it
Recommended next step
Closing the gaps
Instrument funnel analytics before/alongside the redesign
Run a short follow-up survey targeted at the drop-off step specifically
Use both to validate the design direction below post-launch
03 — UI/UX EXPLORATION
From three features to one flow
With the problem synthesized, this is where the actual design work started: exploring how registration, live tracking, and photo discovery could read as one runner journey with three checkpoints, instead of three products maintained separately.
Start · Registration
Register without leaving the app you clicked from
Detect in-app browsers (Messenger, Instagram) on load and offer a one-tap handoff to the phone's native browser — before checkout, not after it fails.
Replaces: a warning modal that shifts the fix onto the runner
Split · Live tracking
Carry the runner's identity forward automatically
Bib number and race entry from registration pre-fill live tracking, so there's no second search-by-name step on race day.
Replaces: a disconnected results/tracking lookup
Finish · Photo discovery
Surface Sureshot as the next step, not a separate errand
Once a runner crosses the finish line in-app, prompt the selfie photo search directly — same account, same session, no second domain to remember.
Replaces: runners forgetting Sureshot exists at all
04 — BEFORE START · ONBOARDING
Telling runners what this actually is, before they sign up for anything
Most runners' mental model for a running app is a fitness tracker — steps, pace, GPS routes. rylmnl does none of that. So onboarding's first job isn't a feature tour, it's resetting that expectation: this app exists for race day itself, not the training in between.
Each of the three following screens maps one-to-one to a checkpoint in the runner's actual journey — register, get tracked live, find your photos — so the value is legible before the runner ever creates an account.
05 — START · REGISTRATION
One flow, from browsing to bib confirmation
Home surfaces the runner's in-progress race first, then upcoming events to register for. Registration itself is a five-step flow — category, personal, contact, kit claiming, payment — with a visible countdown and live pricing per distance, closing with an actual bib number the runner keeps.
Because this lives in one native app instead of a browser form, there's no in-app-browser payment breakage to design around in the first place — the mobile-friction problem from the research is solved structurally, not patched with a warning.
06 — SPLIT · LIVE TRACKING
Every runner on the course, not just the leaderboard
Live Result lists every ongoing, upcoming, and just-finished race a runner has a connection to. Inside a race, checkpoints render as real dots on an actual course map, and tapping any runner in the list — searchable by name or bib — pins their live position and progress bar.
This turns "tracking" from a static results table into something closer to watching the race happen, which is what people actually want when someone they know is running.
07 — FINISH · PHOTO DISCOVERY
Bib, browse, or selfie — three ways in, one AI doing the matching
Not every runner wants to take a selfie to find themselves, and the audit confirmed selfie search alone wasn't reliable enough to be the only path. Bib number search and full-gallery browsing now sit right alongside Selfie Search as equal entry points, so the AI-matching feature reads as one option among several rather than the only door in.
Selfie Search itself narrates the AI's confidence back to the runner — a live camera guide, a confirmation step, then results ranked by match percentage — so the "magic" doesn't feel like a black box returning random photos.
08 — STATUS
Handed off. Now in development.
Prototype walkthroughs are complete and the files have been handed off to engineering, along with the different scenarios and edge-case states each flow needs to account for — including error, success, and warning handling. The app is now being built against that handoff.
Delivered
Race Registration & Tracking
Validated prototype walkthroughs, registration → tracking → photo finder
Full file handoff for all three flows
Edge-case scenarios documented per screen: failed redirects, no camera permission, low photo-match confidence, empty states
Error, success, and warning states specified beyond the happy path
My role now
While development is underway
Available for design QA as screens come together, checking builds against spec
Ready to run usability validation once a build is testable
Aligning with the product team on what to track after launch
09 — REFLECTION
What I learned
A brief handed to me isn't the whole problem — it's a starting point. The product team knew mobile registration was losing runners, but the audit is what turned that into two specific, designable findings: a checkout modal patching a symptom, and a photo finder with no fallback when its own AI came up short. Synthesis meant reading between what was stated and what the product itself was already admitting.
The Sureshot finding also reshaped how I think about AI features generally: selfie search is the flashy part, but it's only good UX once there's a graceful way out when it doesn't work. Bib number search and browsing aren't the exciting screens in this case study, but they're the ones that make the AI feature trustworthy instead of a gamble.
Working solo also changed how I approached handoff. With no dedicated QA or research team behind me, documenting error, success, and warning states for every flow wasn't optional polish — it was the only way engineering would catch the edge cases I wouldn't be in the room to explain. That discipline is the biggest thing I'm carrying into the next project.
LET’S TALK
You've seen how I think
Now let's build something
Whether you're hiring, collaborating, or just want to talk design — I'm open to the conversation. I work best with people who care about the thinking behind the pixels, not just the pixels themselves.
Get in Touch
I’m Jason Piano, a UI/UX Designer with 4+ years of experience. I design interfaces that don’t just look good, they reduce friction, guide decisions, and support business goals.
Follow me at
Jason Piano. All rights reserved. 2026
Let's Work Together!
itsjasonpiano@gmail.com