Case Study
Scope
Designing a new feature that allows users to modify an already placed bet by changing selections, adding new ones, removing existing ones, and optionally increasing their stake—while keeping the experience clear and stable in real-time betting conditions.
Problem
Once users placed a bet, they had no way to adjust it as the game evolved. This limited flexibility and often resulted in frustration or missed opportunities when odds changed or users reconsidered their strategy.
Goals
The main focus was on giving users control and confidence throughout the editing experience.
Give users full control to update their bet after placement.
Keep the editing flow transparent, safe, and easy to follow.
Ensure all updates reflect live odds and market availability.
Reduce errors and uncertainty during the editing process.
Process
User Stories
First I mapped out all edit scenarios. Here are some indicative scenarios:
1. Changing selections within the same market → As a user placing a combination bet, I want to swap one selected team for another without losing my other picks, so that I can adjust my selections based on new information without starting over.
2. Adding new markets → As a bettor placing a single bet, I want to add a new market (e.g., tennis) to my current bet, so that I can increase potential winnings by expanding across different sports.
3. Removing unwanted picks → As a bettor reviewing my combination bet, I want to remove legs I'm less confident about, so that I can reduce risk and improve my overall win probability.
4. Increasing stake → As a bettor satisfied with my bet selections, I want to increase my stake amount, so that I can boost potential returns.
User Flow Diagram
Then proceeded with early-stage flow mapping the core editing scenarios, used as a foundation for identifying edge cases and system constraints before moving into the designs.
Design Proposals
After the initial research phase, early-stage flow mapping helped establish the core editing scenarios, serving as a foundation for identifying edge cases and system constraints before moving into designs.
Early Explorations
Initial explorations focused on two aspects of the feature: the entry point and the actual editing experience. Two directions were considered:
a dedicated screen that would give users a distraction-free environment to make changes, and
an in-page solution that kept users within their current context.
Design Redirection
Due to implementation constraints and resource availability, the decision was made to use a clone of the existing betslip component. Since the betslip already handled the core logic, odds updates, selection combining, and unavailable state management, it provided a practical and consistent foundation to build the edit experience on top of.
Solution
The final solution was built around a clone of the existing betslip component, allowing users to swap selections, add new ones, remove existing ones, or adjust their stake, all within a familiar interface. Reusing the betslip's core logic for odds updates, selection combining, and unavailable state handling ensured a consistent and reliable editing experience, while real-time feedback and clear confirmation steps kept users confident throughout the process.
Learnings
This project was a reminder that design direction can shift significantly once development constraints enter the picture and that's not always a bad thing.
At first, I was skeptical about moving away from the dedicated screen solution toward a betslip clone. But working through the designs made me realize the two weren't as different as I initially thought.
What stuck with me most was recognizing when a solution stops serving the user. As more limitations were added, like requiring users to empty their betslip before editing, it became clear the feature would not add real value to the experience. I was glad it didn't ship in that state, and it reinforced that advocating for the user matters even when technical or business pressures push in a different direction.
This feature was fully designed as part of a product exploration, but it was not implemented due to shifting business priorities. It is included here to demonstrate the design process, decision-making, and problem-solving behind real-time betting features.