Leveraged crypto betting, built for people who had never done either.
Leveraged crypto betting, built for people who had never done either.
Trust is an interface problem before it’s a marketing one.
Trust is an interface problem before it’s a marketing one.
Real-time data
Real-time data
Risk legibility
Risk legibility
Operations tooling
Operations tooling
Mobile
Mobile
WLT/LVR-04
WLT/LVR-04
Role
Role
Lead Product Designer
Lead Product Designer
Deployed
Deployed
Sept 2024 to present
Sept 2024 to present
Engagement
Engagement
Fractional, sole designer
Fractional, sole designer
Surfaces
Surfaces
Consumer betting product, internal operations console
Consumer betting product, internal operations console
Constraint
Constraint
Irreversible leveraged positions, nothing written down
Irreversible leveraged positions, nothing written down
Tools
Figma, Claude Code, Cursor
Measured
FullStory, Google Analytics, own dashboard
2x
2x
2x
2x
2x
Wallet-to-bet conversion in three months
Wallet-to-bet conversion in three months
60%
60%
60%
60%
60%
Faster onboarding
Faster onboarding
01
01
The problem, and it is a translation problem
A traditional sportsbook says: you bet ten dollars on Team A, and now you wait.
LEVR has to say: your position is currently healthy, and if the market moves this far against you, it liquidates.
Those are not the same sentence and they do not fit in the same interface. One is an outcome you wait for. The other is a state you hold, that changes while you are looking at it.
I was not the first designer here. I was the one who arrived after.
What was waiting was a Figma file with no components and no auto layout. Every screen drawn by hand. Nothing reusable, nothing that updated when something else changed, and no one left to explain why any of it was the way it was.
I did not work that out from looking at it. I worked it out on the first change request.
Something small needed updating, and updating it meant opening every screen and doing it by hand. On a product that ships against live sporting events, where the calendar is set by the season and not by us, that arithmetic gets ugly fast.
That is when it stopped being a tidy-up job.
On most products a file like that is a tidiness problem you get to fix eventually. On this one it was a speed ceiling, and a speed ceiling on a product whose hardest job is explaining a position that moves while you watch it.
So the first real work was not a screen. It was rebuilding the file into a system. Components, variants, auto layout, tokens. The unglamorous kind of work that does not appear in any release note and without which nothing after it happens on time.
The first deliverable was not a screen. It was the ability to make screens quickly.
Leverage, liquidation, capped downside, none of that was mine. What was mine was whether anybody could understand what they were holding. That turns out to be most of the product, because a mechanic nobody can read is a mechanic nobody uses twice.
02
02
Borrowing a language that already exists
The reference was not other sportsbooks. It was trading terminals.
Patterns, colour semantics, interaction model. Green and red meaning direction rather than decoration, density treated as a feature, status shown continuously rather than on request. People who take leveraged positions already read that language, and inventing a new one for the same concepts would have meant teaching before anybody could bet.
That is a translation decision between two industries rather than a styling choice, and it is the reason the product could assume comprehension it had not built from scratch.
One thing had to be built rather than borrowed. Icons, team colours and tournament indicators are a custom sports identity in a generic visual language, not official league and team assets, which is a licensing constraint solved with design instead of with lawyers.
03
03
Making the position readable
A leveraged position is seven things a person has to hold at once: entry odds, stake, multiplier, current value, health, liquidation line, exit.
The multiplier had to feel powerful without hiding what it costs. Those pull in opposite directions, and every version that made leverage feel purely like a bigger payout was a version that would eventually surprise somebody.
So risk sits next to reward at the moment of decision, not behind a disclosure, and the position keeps reporting its own health afterwards.
The same logic runs underneath onboarding. Real money, irreversible transactions, leverage, and users who do not yet understand what any of those words mean together has exactly one honest answer, and it is not a warning modal.
Cap what somebody can do while they understand least, and lift the cap as they demonstrate they understand more.
That costs conversion, and everybody knew it cost conversion. Somebody who wanted to take a big leveraged position on day one could not. That is the trade, made deliberately, on a product where the alternative is a first-time user losing more than they deposited on a mistake the product let them make.
Bet history shows every placed bet, its outcome and its full detail. In a product where the money is real and the ledger is public, transparency is not a feature. It is the price of being trusted at all.
04
04
Density on desktop, action on mobile
Desktop could hold market, chart, order book and bet slip at once, because research and decision happen in the same place.
Mobile is not that layout compressed. It is a different question: market, then bet, then confirm, with the supporting information reachable rather than present.
The work was deciding what survives, which is progressive disclosure as a product decision rather than responsive CSS.
All of it built from the component library rather than drawn, which is the only reason weekly iteration during a live season was possible at all.
05
05
The console
The consumer product was half of it. The other half was the thing the operators use.
An internal team had to run the betting system: put games into it, configure what could be bet on, watch for trouble, and step in when something went wrong. What existed had grown one feature at a time, which is how most internal tools get built and why most of them are hard to use.
A game is a container, not a thing you bet on.
That sounds obvious written down. It was not obvious in the product, where registering a game read as a completed action. It is not. A game holds markets, markets carry odds, odds are what a bet is placed against. Game, then market, then odds, then bets.
Once that hierarchy was explicit, a category of confusion disappeared. A registered game with no markets initialised is not ready, and the old model had no way to say so.
Upcoming games and our games are two different questions.
The schedule started as a list of what was coming up, with a button on each row. That works until there are forty games in a day, and there are forty games in a day.
So they became separate surfaces answering separate questions. What is happening in the world, filterable by league, sport, date, team and status. And what have we actually taken on, with everything an operator needs to see about it. Same underlying data, two jobs, and collapsing them was making both worse.
Cards summarise. Tables operate. Charts show trend.
The pull on an internal dashboard is always toward large cards and decorative visualisation, because that is what dashboards look like in screenshots. With thousands of users and forty games a day, an operator needs density and scanning, not a hero number in a box.
What this actually is, is closer to a trading terminal than a CRM. Density, then hierarchy, then status, then action, then confirmation. In that order, and the last one is not optional.
Dangerous things need friction, and that is a feature.
Pausing a game stops betting across every market inside it. Settling one moves money. Overriding a system-declared winner moves money against what the system determined.
These are not everyday actions. The system handles them on its own almost always, which is exactly why the manual versions are dangerous: they are rare, so nobody has a habit around them, and they sit on screen next to controls that are safe.
So every one of them states its consequence before it runs. Not a generic confirm, a sentence naming what is about to happen and to what. Slowing an operator down by two seconds is cheap. The alternative is not.
The general form of the rule: automate what the system already knows, recommend a default where judgment is usually the same, and require a decision only where the consequence is real.
06
What it cost
I built a system for the interface and never built one for the rules.
That is the whole of it, and it took me a while to see it that way. Components got structure. Variants, tokens, auto layout, the works. The logic governing real money got a conversation.
Three things broke because of it.
Onboarding a new person. Nothing to hand them. Every rule lived in somebody’s head, which meant ramp was slow and the knowledge stayed concentrated. Mine was one of the heads. That felt like leverage at the time and was actually a liability.
Clarity. Decisions came back. Not because anyone was careless, but because there was no place to point at, so the fastest way to resolve a question was to have the conversation again. Sometimes it landed differently the second time.
A constraint I specified did not survive into the build. It was never written down anywhere, so there was nothing to check the build against and nothing to catch the drift. I found it later, by looking.
That one is the reason this section exists. On a product where positions are leveraged and irreversible, a constraint that quietly changes between design and build is not a documentation problem. It is the whole problem, and the version of me who turns up at Quest with a decisions log that fills itself from the transcripts is a direct consequence of it.
What I’d do differently: write it down. One page. Not a spec system, not a knowledge base, one page holding the rules that govern real money. The limits, the thresholds, what lifts them. It would have taken an hour and it would have caught the thing that got past me.
The reason I did not is that the environment moved fast and documentation felt like friction. What I would push back on now is the framing. “We move too fast to write things down” is a description of a choice, not a constraint, and on a product where somebody can lose more than they deposited it is the wrong one.
What it returned, since the cost is only half the ledger. Wallet-to-bet conversion doubled within three months of relaunch and onboarding time came down by sixty percent. Measured in FullStory and Google Analytics, and in the operations dashboard I built.
We went from clunky to clean. Mobile users now feel like they’re playing, not deciphering.
Beta feedback, live season
I built the system for the pictures and not for the rules.
ケビン・チャップマン
No. 26 / Lot 01 / SS26