Runtiva

01

There was a product idea, but not yet a product experience

When I joined, Runtiva was at an early stage. There was no established product experience, design system or mature UX architecture to build on.

My responsibility

1. Product requirements
2. UX architecture
3. User flows
4. Wireframes
5. Interaction design
6. UI
7. Design system
8. Prototyping
9. Developer handoff
10. Iteration

02

We weren't designing in a vacuum

Fantasy sports already has strong players in the US. I studied them to understand how users discover contests, read formats and rules, build teams and track results. The aim wasn't to copy their interfaces.

Competitor matrix

"Not found" means no evidence in store listings or press coverage, not confirmed absence. Researched October 2026.

Where the gaps are

03

Multiple formats. One product.

Each format brings its own rules, team structures, scoring, durations and entry requirements. Users still shouldn't feel like they're entering a different product every time they switch formats.

Different contest experiences should feel like different modes of the same product, not completely different products.

04

Before designing screens, I needed to understand the system

Users could have several contests, several teams, different formats, upcoming games and a history. The structure had to scale as more formats and features arrived.

Inside a game: Single game detail → Contests / My Contests / My Teams → Contest detail (Prizes, Leaderboard, Scoring rules) → Create team → Success.

05

From discovering a contest to entering it

At each stage the user has a different decision to make: what the contest is, which format it uses, what's required, how to build a team, and what happens after they submit.

1. DiscoverBrowse upcoming games by sport on HomeFormat badge and entry fee + prize shown together on every card
2. UnderstandOpen a game, compare its contests"How to play" per format; filters by fee, type and prize
3. SelectContest detail: prizes, leaderboard, rulesDual CTA: Reserve entries (outlined) vs Join | $49 (filled)
4. BuildPick players into position slotsSalary cap tracker pinned to the bottom
5. ReviewCheck the final lineup and costLock countdown always visible; edit until submit
6. Enter"You're in the game!" confirmationLocked team, entry ID and more contests for the same team

06

How the contest flow evolved

The contest flow went through four major versions in six weeks. Each round I walked the prototype end to end, checked it against the pain points in the journey map and the audit, and fixed what got in people's way.

The contest card, four ways

Version by version

07

Three journeys, one emotional arc

I mapped how users move through each contest type, 19 stages in total, to find where trust, anxiety and excitement peak. Choose a journey, then a stage.

08

The challenge wasn't adding information. It was making it understandable.

Player selection is the densest screen in the app: positions, stats, salary, ownership, injuries and rules, all under a deadline. I decided what users need at each moment, and pushed everything else back.

—

A key decision: what stays the same, what adapts

For every format I decided which patterns stay shared across the product and which behaviours adapt to that format.

09

Designing for scale, not just the first release

Because Runtiva started from scratch, I could build reusable foundations instead of designing every screen on its own. The system had to absorb new formats without breaking consistency.

10

A product doesn't only live on the happy path

I designed for what users see off the ideal path: empty, loading, error, validation, no results, unavailable contests, incomplete teams, deadlines, unavailable players and network states. Here are some of the empty states I illustrated.

• Empty
• Loading
• Error
• Validation
• Success
• No results
• Contest full / unavailable
• Incomplete team
• Lock deadline
• Player unavailable
• Insufficient balance
• Network

—

Good UX has to survive implementation

The design kept evolving as I worked with engineering. Where an interaction had technical implications, I worked with the engineers to validate feasibility, clarify behaviour, define states, resolve edge cases and simplify where needed.

11

What I contributed

Because this was a 0→1 product, the outcome was more than a redesigned interface.

What I learned

1. Architecture comes before polish. A beautiful screen can't make up for a confusing product structure.
2. Consistency doesn't mean identical. A scalable product needs shared patterns that still allow context-specific behaviour.
3. Design continues after handoff. Some of the most important decisions happen while working out with engineering what's feasible to build.