Hedgehog · Prediction market

People wanted to predict. The product asked them to trade.

I redesigned participation so a newcomer could pick a side in a shared pool, without learning an orderbook first.

A five-minute bet, not a trading desk.

Hedgehog is a prediction market. People take a side on whether a price goes up or down.

The category already had demand. Polymarket, Augur, and a wave of DeFi products had proved that. What had not scaled was who could join.

The shipped loop: choose a side, wait for the round, see the result, stay for the next one.

Interest died in the mechanics, not in the idea.

Existing platforms asked for orderbook literacy, liquidity, and trading mechanics before a single prediction.

That system was built for financial professionals. For everyone else, the first half minute was enough to leave.

Category interfaces built around trading mechanics
The pattern across the category: a lot of market structure before the actual decision.

Two audiences, and designing for only one would lose the other.

The curious newcomer had heard of prediction markets and bounced if orientation took more than about 30 seconds.

The experienced DeFi user wanted short cycles, not a position to manage for days, and left when the product felt shallow.

The opportunity was a participation model that stayed legible for the first group and fast enough for the second.

Deposit into a pool. Pick UP or DOWN.

We replaced the orderbook with a shared pool. The decision is binary. There is no counterparty to find and no liquidity lesson before the first action.

Desktop and mobile were designed together. Every state was built for both.

UP or DOWN decision on Hedgehog
The primary idea, on the screen where it matters.

Four moments that make the loop understandable.

A round with a beginning and an end.

Three minutes to choose an amount and a direction. The room locks. Two minutes resolve the outcome. The whole cycle is about five minutes: short enough to repeat, contained enough to lower the stakes of waiting.

Round timer and modal states
Preparation, lock, and resolution as distinct states.

One action louder than everything else.

UP or DOWN is the strongest element on screen. Amount and confirmation stay secondary, so the interface answers one question at the moment that matters.

UP and DOWN as the dominant actions
The decision is visually louder than the setup around it.

Other people's bets, in the open.

Pool distribution is public, including a table of what each participant chose. Newcomers get social proof. Experienced users get a contrarian signal. Either way, the decision stays inside the product.

Public participation data
Participation is part of the interface, not a hidden backend field.

The result sends you into the next round.

Win or loss appears as a modal. Acknowledge it and you are still on the same screen, ready for the next round. The emotional peak feeds the next action instead of ending the session.

Win and loss states
Resolution is a beat in the loop, not a dead end.

The orderbook was the barrier before any prototype existed.

I benchmarked six products: Polymarket, Augur, Drift Protocol, Binance Predictions, Azuro, and Limitless. The point was to see where people stalled, not to collect screens.

More data at the moment of decision raised hesitation. Weak feedback left people unsure what their own prediction had done. Short cycles built a habit. Long cycles tied to outside events did not.

So the decision to avoid an orderbook was a starting constraint, not a pivot after a failed prototype.

Three calls that changed the product, not just the pixels.

Change the model, then design the screen.

Polishing an orderbook would have made a trader's tool prettier. It would not have let a newcomer in. We took the pool as the product, and the interface followed.

Show the crowd, carefully.

Hiding what others were doing ignored how people actually decide. Publishing the pool gave newcomers a cue and gave experienced users something to disagree with, without turning the screen into a leaderboard.

Add conversation where people still froze.

Live chat was not in the original launch. In the closed beta, some people still hesitated on a side after they understood the mechanics. Chat opened for anyone with an active prediction in that round, so the choice stopped happening in a vacuum.

How the mechanics are explained in product
The flow had to explain itself. The landing page had already done some of that teaching.

A closed beta, with people who already wanted in.

There was no lab A/B. For five days, five groups of 20 people from the product's own waitlist used it in production. One hundred people, with real intent.

More than half already understood the purpose before they entered, because of the landing page. With a self-explanatory flow, every participant understood the mechanics by the second round. Individual wins and losses varied, and that was never the success criteria.

100%Understood the mechanics by round two
10s → 2–4sTime to first action
120+Components in the design system, cutting handoff time by about 35%

Founders who followed the beta described the same thing users did: intuitive, clear, and matched to the promise. The 37.5% waitlist conversion belongs to the pre-launch page, not to this beta.

Hedgehog on mobile
The same loop on a phone, which was in scope from the start.

When people are confused, fix the model before the interface.

We never polished our way out of an orderbook. We replaced the model, then designed the loop around it.

The open question is the three-minute preparation window, when someone chooses amount and direction alone, before the room locks. That is where a newcomer is most likely to stall. The next useful move is guidance at room creation, before the lock, which is what the beta chat was already pointing at.