UI Design · UE5
Personal · Spec Work
2023
Lotería Card Game — Reward UI
A post-match reward UI concept built in Unreal Engine 5 — exploring how collectible card reveals, anticipation mechanics, and reward pacing work when you build them for real instead of just mocking them in Figma.
Concept
The project started with a question: how do you make a reward moment feel earned? Post-match screens are often an afterthought — a flat list of what you got, a button to continue. But the best ones have weight. They make you feel like something just happened.
Lotería's visual language was the right anchor. The cards are bold, immediately readable, culturally loaded — each one a distinct object. That distinctiveness is what makes a collectible system feel like it has depth, not just volume.
The flow is structured around three states: idle (anticipation before the reveal), reveal (the card appears), and claim/continue (completion and handoff back to the game). Each state has a distinct visual register.


Implementation
Built entirely in UE5 using UMG and Blueprints. No Figma handoff — the design lived in the engine from the start, which forces a different kind of precision. Sizing, timing, and layering all behave differently when you're working in real-time.
- State-driven architecture — transitions between idle, reveal, and claim/continue managed through Blueprint state logic
- Niagara particle systems — ambient effects and reveal polish without sacrificing legibility
- Micro-interactions — card flip, acquire confirmation, continue prompt — each with distinct timing and easing
- Hierarchy maintained throughout — earned items, card count, and new acquisitions all readable at a glance even mid-celebration




Outcome
The main thing this exercise taught: reward systems are fundamentally about pacing. The reveal only works if there's something to reveal against — the idle state earns the moment. Cut the anticipation and the card is just an image.
Building in UE5 rather than prototyping in After Effects meant every timing decision had to be implementable. That constraint makes you more rigorous. If a transition felt off, you couldn't blame the prototype — you had to fix it.