Tanisha Jain

Resume

CASH DASH · 2025

Role : Lead Product Designer · Team : 2 PM, 1 Engineer, 1 QA · Timeline : 10 weeks · Platform : Mobile (Web)

Cash Dash

There was no existing game to learn from. No UX pattern to borrow. Just a mechanic nobody had designed before — and 10 weeks to ship it.

The product was built around a mechanic no one had shipped before: variable pricing where your choice determines your upside, and the value available decreases in real time with every action taken. Users needed to understand what they were buying, what it was worth right now, and that the value was actively falling — all simultaneously, all without instruction.

I led end-to-end design — from first principles to shipped product — including pushing back on the brief, negotiating technical constraints, and making calls with incomplete information under timeline pressure.

The Problem

Players choosing a stake were making a financial decision under time pressure with a mechanic they'd never encountered. They needed to simultaneously understand what their stake unlocked, what the current prize was, and that it was actively falling with every action in the session. If any of those connections broke, the product broke.

No category precedent meant every pattern had to be reasoned from the brief itself — not borrowed from convention.

The Brief

01

Show the decreasing

prize system

Show the decreasing

prize system

Make it instantly clear that earlier ball calls equal bigger prizes — without explaining it.

02

Work within the existing brand colour palette

No creative freedom on brand. Every design decision had to live inside their existing visual language.

03

Make pricing feel like a choice,

not a barrier

Make pricing feel like a choice,

not a barrier

Players should want to spend more. The UI had to make higher ticket prices feel rewarding — not risky.

Everything else was blank canvas. No wireframes. No precedent. No existing product to reference.

Design Exploration

Three concepts. One clear direction. Zero compromise on clarity.

Three concepts. One test: does a first-time user understand the prize mechanic in seconds, without being told?

used gem imagery per prize tier with background colour shifts on each state change. Visually clear — but when a ball was called, players were processing a new image, new colour, and new number simultaneously at exactly the moment they needed to make a purchase decision. The animation competed with the information it was meant to communicate.

Rejected

Concept A

showed a single live prize value updating in real time. Clean — but a number with no context is just a number. Players could see the prize but had no frame of reference for how fast it was falling or where it was heading. Without visible trajectory, the core mechanic was invisible.

Rejected

Concept B

A persistent prize ladder on the right side of the screen, always visible, showing all prize levels simultaneously. When a ball was called, the top prize card slid off the right edge — revealing the next level beneath it — while the entire game background shifted colour to reflect the new tier. Warm gold at the highest prizes, cooling progressively to grey at the lowest. The mechanic wasn't just visible. It was felt.

Selected

Concept C

Concept A

Rejected

Concept B

Rejected

Concept C

Selected

The Fights Worth Having

Ticket format.

Stakeholders pushed to use Mecca's standard bingo ticket. I pushed back. The standard format consumed significantly more vertical space — reducing the number of tickets visible on screen at once, which for players holding up to 60 tickets was a functional problem, not an aesthetic one. A compact ticket also let tier colour carry the identity rather than competing with it. We shipped the new format.

Ticket format.

Background colour shift & ladder position.

Engineering didn't want to build the background tier system — updating a number was simpler than shifting the game environment. I argued that a number changing communicates information; a background shift communicates consequence. Players shouldn't need to check the ladder to know the prize had dropped — the environment should tell them. We kept it.

Engineering had placed the floating action buttons on the left. I needed them moved to the right, directly below the prize ladder. One move, three problems solved: buttons no longer overlapped the ticket grid, the ladder had a natural anchor point, and prize cards could now animate off the right edge as each ball was called — following natural reading direction, making the prize feel like it was moving away from you. Moving the buttons was non-trivial. We did it anyway.

A known compromise we shipped.

There was no elegant mobile solution for showing the full prize ladder within the floating button constraint. The stacking mechanic was functional — the full table one tap away — but the default state showed less than the desktop version, where the full ladder sits permanently visible. I'd revisit this with engineering earlier next time.

Toast notifications after ball 47

Win probability increases significantly in the second half of a round — after ball 47, wins start happening more frequently, sometimes to multiple players in the same call.

A full-screen win state works in a single-player game. In a multiplayer round where wins are clustering in the final stretch, it would repeatedly break the game for everyone who hadn't won yet — at exactly the moment tension is highest.

Toast format gives each winner their moment without stopping the round. The game stays live. Other players stay engaged. And when multiple players win simultaneously, each sees their own toast without the experiences colliding.

Ticket format.

Stakeholders pushed to use the standard product template. I pushed back. The standard format consumed significantly more vertical space — reducing the number of tickets visible on screen at once, which for players holding up to 60 tickets was a functional problem, not an aesthetic one. A compact ticket also let tier colour carry the identity rather than competing with it. We shipped the new format.

Background colour shift & ladder position.

A known compromise we shipped.

Toast notifications after the midpoint of the session.

Win probability increases significantly in the second half of a round — after ball 47, wins start happening more frequently, sometimes to multiple players in the same call.

Validation

Moderated usability test · 20 participants · Playtech, 2025

We ran a structured usability test with 20 participants — covering regular players, occasional players, and people with no prior knowledge of the product.

One question drove the entire test: could players understand the relationship between ticket price and prize potential without being told?

94%

understood the full prize progression after a single playthrough.

92%

correctly identified the ticket/prize correlation without prompting

100%

completed a full game round — zero drop-off during the session.

These results validated that the design was communicating the mechanic correctly before build. The inclusion of real users unfamiliar with the product, not just internal employees gave us confidence the comprehension held beyond a sheltered population.

Results

35% of all purchases at launch were at the two highest price tiers — the two highest price points — from day one. We treat this as directional validation: no benchmark to compare against, but the direction confirmed the design was working.

Visible trajectory over live state.

Showing where the prize was heading — not just where it was — was the decision that made the mechanic comprehensible. This is a principle that applies well beyond gaming: any interface involving a changing value benefits from showing the direction of change, not just the current state.

Environment as status indicator.

The background tier system communicated game state passively, at screen scale, without requiring attention. The colour did narrative work no label could.

Prize before price.

Showing the max prize ceiling before the stake cost in the purchase flow reframed the decision from risk to ambition. Players chose their level of upside first, then confirmed the cost.

Reflections

What I'd do differently process-wise.

The two biggest revision cycles — floating button repositioning and the background tier system — both emerged as engineering constraints at handoff rather than during ideation. One collaborative session in week one would have caught both. Design–engineering alignment isn't a handoff problem. It's a process problem.

What we learned from players post-launch

One consistent piece of feedback that came through after launch: players wanted the ticket quantity slider removed. The slider — intended to make quantity selection feel fluid — added a step that felt unnecessary to players who knew exactly how many tickets they wanted. We logged this as a confirmed priority for the next release. It's a good reminder that interaction patterns that feel intuitive in design don't always survive contact with real usage at scale.

What I'd build next.

The tutorial screen worked for first-time players — but it got skipped by anyone who assumed they already understood the game. You can see why: it's a static overlay that asks for attention before the game has given players any reason to be invested.

Next iteration: contextual pop-ups woven into the first round itself, appearing at the exact moment each mechanic first becomes relevant. The prize ladder appears — a tooltip explains it. The first ball is called and the prize drops — a prompt highlights what just happened. Four or five moments of contextual explanation, zero gap between learning and playing.

What I'd do differently process-wise.

What we learned from players post-launch

What I'd build next.

V1 onboarding —

functional, skippable, and a clear signal for what V2 should fix.

This project changed how I think about designing any interface where a value changes in real time.