Three connected products across event operations, player experience, and the core data infrastructure behind the tour.
Working with the WTA means moving between event teams, players, operations, and the shared data connecting them. The throughline is the same: understand the real workflow, make it legible, and build an interface that can carry it.
The scope changes by product. Across the relationship, my work spans product framing, interface systems, frontend and full-stack development, and mobile implementation.
I helped turn a straightforward attendance need into a working operational tool that carries registration data into planning, on-site use, and reporting.
I built the mobile product around recurring player tasks and the tournament information needed to navigate day-to-day life on tour.
My work sits within the system used across departments to maintain tour, operations, and player data—including the data behind the Player App.
This page names only work I personally contributed to. Product details are intentionally bounded by confidentiality.
An attendance management platform that tracks internal attendance across WTA events. Registration data informs on-site planning and logistics, while reporting supports teams during and after each event.
An ongoing private app helping WTA players manage day-to-day life on tour: entering and withdrawing from tournaments, viewing entry and acceptance lists, browsing tournament fact sheets, and accessing other essential information.
The backbone CMS for tour, operations, and player data across the WTA. Used by multiple departments, Baseline is an essential internal system and provides the data that powers the Player App.
A useful interface is only one moment in a longer operational sequence. These simplified flows show the job each product is built to carry—without exposing private UI or implementation details.
Turn attendance into something event teams can act on.
Attendance moves from a live count into planning inputs, on-site reference, and post-event reporting.
Put recurring tour tasks in one player-facing place.
Players move between entries, acceptance lists, tournament fact sheets, and the information needed for life on tour.
Make core tour data dependable and reusable.
Shared records support teams across the organization and provide the data foundation behind the Player App.
My role changes with the product, but the throughline is ownership across thinking and making.
Translate operational reality into a product problem that can be shaped and built.
Organize dense workflows, states, and information into legible interface systems.
Carry decisions into working web and mobile products—not just static design artifacts.
Account for the data, departments, and downstream surfaces surrounding each screen.
The most useful proof cannot be a public screen gallery. The case study therefore shows product relationships, workflows, and ownership without recreating confidential interfaces.
An event team working on site, a player moving through a tournament week, and an internal department maintaining tour data need different kinds of clarity.
Baseline and the Player App cannot be treated as isolated surfaces. Upstream structure affects what players see and what internal teams can reliably maintain.
Entries, lists, attendance, logistics, reporting, and player records create edge cases. The interface work is largely about making those states legible and usable.
These products support internal or unreleased work, so public visuals and implementation details are intentionally limited. I can still speak to the problems, constraints, decisions, and my contribution in a conversation.