2018
BetBull — Turning Social Betting Ideas Into Shipped Experiences
How live prototypes, A/B tests, and close engineering collaboration helped turn fast-moving product ideas into testable, shippable mobile experiences.
BetBull was a social betting product built around live football, shared betting slips, and real-time interaction between users. My role went beyond designing interfaces: I turned early ideas into interactive experiences that the team could use, test, compare, and take into production. Live prototypes became the bridge between product thinking, user experience, and engineering.
At a glance
Role
Product Designer — Interaction and Prototyping
Scope
Product Discovery · UX/UI · Interaction Design · Live Prototyping · A/B Testing · Motion Design · Developer Handoff
Platform
Mobile product
Contribution
Testable product ideas · Clearer engineering decisions · Shipped interaction patterns
Context
BetBull combined betting with a social layer. Users could follow football activity, create live betting slips, and share their choices with others. This meant the experience had to support two behaviours at once: the speed and clarity expected from a betting product, and the engagement and discovery patterns of a social platform.
The challenge
The product moved quickly and many ideas involved behaviour that could not be understood from a static screen alone. A flow might look clear in a design file but become confusing once odds changed, selections were added or removed, feedback appeared, or a user moved between social content and a betting journey.
The challenge was therefore not only to produce polished UI. It was to make product ideas tangible early enough to evaluate them, expose missing states, compare alternatives, and give engineering a reliable picture of how the experience should behave before implementation began.
My role and ownership
I worked across product thinking, UX/UI, interaction design, prototyping, motion, and handoff. I translated broad concepts into complete flows, explored how interactions should respond across different states, and built live prototypes that allowed the team to experience an idea rather than interpret a sequence of static frames. I stayed close to developers as those ideas moved into the product, helping resolve the gap between intended behaviour and technical implementation.
Evidence through experimentation
Because many decisions concerned timing, behaviour, and comprehension, prototypes were part of the design process rather than a presentation layer added at the end. They helped us identify where a concept felt slow, where feedback was too subtle, where the next action was unclear, and which states needed to be designed before development.
When more than one direction was credible, A/B tests gave the team a way to compare alternatives through user behaviour instead of relying only on internal preference. I used the results as decision input, then refined the interaction and visual hierarchy around the direction that communicated the task more effectively. Where a reliable quantitative result was not available, I treated the test as directional evidence rather than claiming an artificial performance uplift.
Key design decisions
1. Prototype behaviour before polishing screens
I used live prototypes to answer interaction questions while they were still inexpensive to change. How should a selection enter or leave a betting slip? What feedback is needed after an action? What happens when information changes during the flow? Exploring those moments in motion exposed gaps that a happy-path screen sequence could easily hide.
2. Use A/B tests to turn opinions into choices
Some problems had several visually convincing solutions. Instead of selecting a direction because it looked more refined in isolation, I prepared alternatives around one clear hypothesis and kept unrelated variables stable. This allowed the team to compare comprehension, engagement, or completion signals with greater confidence and made the reasoning behind the final direction easier to explain.
3. Design for live and changing states
A betting interface is rarely static. Match status, odds, selections, validation, and confirmation can change while a person is acting. I designed flows as systems of states rather than collections of screens, making sure that loading, success, error, disabled, and changed-data conditions remained understandable. In a product involving money and time-sensitive decisions, clear feedback was part of the core experience rather than visual polish.
4. Use motion to explain cause and effect
Motion helped connect an action to its result: where an item moved, what had changed, and what the user should notice next. I used animation to reinforce hierarchy and continuity, not simply to decorate the interface. The same interaction prototypes also helped product and engineering discuss pacing, transition rules, and technical feasibility using a shared reference.
From prototype to production
The prototype was not a separate concept that ended when the design review finished. It became a working specification for implementation. Developers could see the intended sequence, timing, feedback, and state changes in context, while I could review builds against behaviour rather than comparing only visual details.
What the handoff included
Interactive prototypes · State and edge-case definitions · Transition and timing rules · Interaction annotations · Reusable UI patterns · Design reviews during implementation
This reduced the amount of interpretation required during handoff and made technical trade-offs easier to discuss. When a behaviour could not be implemented exactly as designed, the prototype made the underlying intent visible, allowing us to find an alternative that preserved the purpose of the interaction instead of copying its surface appearance.
Outcome and impact
The work helped ideas move from discussion to something the team could experience, evaluate, and implement. Live prototypes created faster feedback loops, A/B tests provided evidence for choices between credible directions, and behaviour-led handoff reduced ambiguity between design and development. The strongest impact was not a single screen or animation; it was a more concrete way of making product decisions and carrying them into a shipped experience.
Faster idea validation · Evidence-led iteration · Clearer developer handoff · Shipped product behaviours
What I learned
This project reinforced that interaction design is a form of product thinking. A high-fidelity prototype can reveal product questions, technical dependencies, and edge cases long before a final build exists. It also taught me to separate evidence from certainty: an A/B test is valuable when the hypothesis and decision criteria are clear, but it should not be used to manufacture confidence where the data is incomplete.
Reflection
If I were extending the work today, I would connect each major experiment to a clearer measurement plan before designing the variants, then follow the selected direction through production analytics and qualitative feedback. I would also document the relationship between prototype decisions and shipped behaviour more explicitly, creating a stronger record of what changed, why it changed, and what the team learned.
Following BetBull’s merger with WynnBet, I continued developing the product experience within WynnBet. This gave me the opportunity to carry forward the interaction patterns, prototyping approach, and product knowledge established at BetBull while adapting the work to a broader platform and organisational context.