D&DZOMBIE DRAGON ADVENTURE

I owned the UX process, player flows, information architecture, documentation strategy and design-system decisions for this experience. I led a team of three designers, defined the structure for the FTUX, Adventure Book, stores and upgrade systems, and was responsible for producing implementation-ready deliverables. My role included defining what needed to be designed, how it needed to be documented, and how the work should be handed off — not just executing individual screens.

UEFN is not a blank canvas. You get a fixed Fortnite HUD, limited widget behavior, constrained font options, and a player base that arrived to play Fortnite — not to learn a new game. Any complex system you design has to work inside those limits, or it does not ship as designed. Add a recognizable D&D IP with visual expectations, a four-month window, and multiple implementation dependencies across teams. That was the starting condition for everything we built.

As UX Lead, I led both the process and the people involved in UX/UI work.

• —Leading the UX/UI process for the project
• —Coordinating a team of three designers including myself
• —Defining flows, priorities and documentation needs
• —Creating UI assets such as iconography and store banners
• —Designing the Adventure Book screen system
• —Supporting copy for UI and player-facing systems
• —Creating documentation for features and implementation
• —Reviewing accessibility and heuristic issues
• —Preparing wireframes, HiFi screens, WBP references and optimized assets for implementation
• —Working with design, engineering, art and production to align the experience

• —UEFN did not provide the same flexibility as a fully custom responsive UI system.
• —The interface needed to work across different screen sizes and support split-screen considerations.
• —Font options were limited to platform-supported typography.
• —Several systems depended on a mix of Verse and widgets.
• —Some store functionality could not use widgets in the expected way at the time.
• —Textures and assets needed to be optimized carefully to protect performance.
• —The project had a recognizable IP, which meant UI decisions needed to respect visual direction and approval needs.
• —The production window was short and the scope was high.

The main loop was roguelike: kill, die, improve and try again. Players started in a shared lobby with personalized progression. From there they could buy upgrades in stores, interact socially and prepare for the next run. Before entering the adventure, players selected one of three classes. During the run they explored routes, fought enemies, completed rooms, opened chests, interacted with D20 events and progressed toward the final boss.

[ zoom ]

Player experience loop: from lobby to Dracolich. Roguelike structure across sessions.

These are the design choices that shaped the most important UX outcomes of the project.

The UX/UI work focused on giving structure to a complex experience: shifting from scattered systems toward a clear, documented, player-readable architecture.

• —Wireframes and HiFi screens for all player-facing UI systems
• —Adventure Book screen system with IA, flow and UI documentation
• —FTUX flow definition and staged onboarding structure
• —Store flow documentation and upgrade logic reference
• —Iconography and store banner UI assets
• —WBP references and implementation handoff documentation
• —Naming conventions, export guidelines and asset optimization rules
• —Accessibility and heuristic review documentation
• —Reusable design templates for future UEFN projects

The Adventure Book gave players a single place to check everything that mattered — stats, missions, inventory, progress. The FTUX got new players through the roguelike loop without stopping the Fortnite pace. Store documentation removed ambiguity during implementation. Some features were cut or simplified based on playtest findings. That was the right call — complexity that does not serve the player is a bug, not a feature. The experience shipped live.

The handoff was built into the process from the start, not treated as a final step. Each screen, flow and asset was produced with WBP references, naming conventions, export guidelines and asset optimization rules. Because UEFN has specific technical constraints around responsiveness, fonts and widget behavior, the design system was built to account for those limits rather than assuming they could be handled later. Documentation in Confluence preserved design intent across areas and created reusable references for future projects.

This work was informed by player clarity goals, UEFN platform constraints, IP visual requirements and internal playtest findings. Playtests and feedback sessions helped identify where players struggled to understand the loop, where systems created unnecessary friction and where some features added complexity without enough value. The UX review process included heuristic evaluation, accessibility checks and readability analysis. Not every finding could be addressed within the production window, but they shaped iteration priorities and informed future decisions.

The project included playtests and internal feedback sessions. Those sessions helped identify navigation issues, critical experience bugs and moments where some features created more friction than value. Some features were removed or reduced because they added complexity without enough player value. The UX review also detected issues around system complexity, economy balance, accessibility and clarity for the target audience. Not every issue could be fully addressed within the production window, but those findings became important learnings for future projects.

UEFN constraints are design inputs, not implementation problems. If you treat them as something to solve at the end, you end up with screens that look right in Figma and cannot ship. I started incorporating sizing rules, font limitations, and widget behavior into the system early. That made the handoff cleaner and saved cycles late in production. The other thing I took away: complexity costs more than you think at the feature level. Some systems looked interesting during design and created confusion for actual players in playtests. Knowing when to cut is as much part of the job as knowing what to build.

The UX work that mattered most on this project was not visible in the final screens. It was the information architecture that made the Adventure Book navigable, the FTUX structure that sequenced onboarding by action instead of explanation, and the documentation that kept implementation moving without constant back-and-forth. Player flows that account for how people actually enter an experience. Assets that hold up across different UI states. Documentation that engineering can work from. That is what I care about building.