Some Things

PopFlyXP (August ‘19 - Present)

Not to be confused with PopFly (Microsoft)

The team behind PopFlyXP has three goals:  
  • revolutionize the way sports players build and monetize their brand
  • enable players to create their own personal applications through a common platform
  • bring fans closer to their favorite player

The final product with be a CMS and app combo, whose libraries will be replicated so each player has their individual application. The team behind the player (see project personas below) will generate and publish content from the CMS to the application, where it will go live. 

Role: UX Designer (I’m working closely with my colleague Chisa, who’s the project’s UI Designer)

Timeline: 4 months

Tools: Sketch, Abstract, and InVision studio

Research & Discovery

We dived into an experience canvas exercise (an Atlassian exercise) to get the product’s big picture. In order to avoid long discussions, we opted for 5 minute braindumps which stakeholders then voted on for prioritization. 

Experience Canvas (cropped):

We moved on to proto-personas for the product’s key users, which include: 

  • John, the baseball player
  • Casper, the ghost--the person who’s regularly with the player and captures key moments
  • Jessica, the content manager, who refines the content the ghost creates
  • Julio the engaged fan--somewhere between a hardcore fan and an occasional one


We validated the proto-personas during the discovery phase (the week after the client onsite) through a series of interviews, which led us to identify an additional persona: Karen, an engaged fan. Like Julio, she loves baseball, but she favors personal content over scores, stats, and training. Julio doesn’t care for personal content. 

Fan variables:



Once we concluded the research phase, we identified the following risks:

Scalability: the client requested that each player signed onto PopFlyXP have their own CMS and app and the client is aiming to sign on 42 players by the end of 2020.
Recommendation: we were able to negotiage a different CMS solution. Instead of a CMS per player, there will be one CMS that will act as a hub and permissions will restrict (or allow) access to particular parts of the platform. This will help eliminate the need for multiple logins and increase security.

Usage: 88% of interviewees stated they were not likely to download multiple apps to follow their favorite players--instead, what they asked for was information consolidation.
Recommendation: Having one app for all players was non-negotiable so we proposed creating a proof of concept after the release of the MVP. The PoC would be one application with multiple layers, which would emulate the sense of having one app per player.


While Chisa and I collected information during the client visit, the Fullstack, Android, and iOS teams defined the product’s architecture: 


CMS user flow:
User flow for login:

Login and sign up explorations (wireframes):


The CMS MVP will allow users to do the following: 

  • Login through Okta
  • Select the player they will be generating content for
  • Store media (photos and video)
  • Create posts that will be able to be published in the app
  • View upcoming posts in a calendar schedule
  • Approve content for app publication
  • View all content that has been published on the app


Prior to working with us, PopFlyXP had no centralized way of managing images and video. When collaborating with each other, content managers and ghosts shared content through Telegram or SMS.

With the solution we’re building, all content will be centralized and the content libraries will be pulled up when content managers are creating new posts. 

Media wireframes: 

Create a Post wireframes:

More content coming soon