Lead Product Designer
After creating a series proto-personas and use cases, I developed a set of requirements that informed our roadmap for the next two months. The proto-personas ensured we could accommodate all users from every entry point and with different levels of access.
For the MVP we designed and built three pages with an accounts table, followers, page views and successful crossposts.
The old system required athletes to email our internal agents basic profile information such as names, teams, leagues etc… For version 2 we designed and built a set of forms so athletes could create profiles themselves. After conducting usability tests on usertesting.com we quickly identified that most users want to update names and avatars inline instead of going through the athlete’s profile.
Agents who already have a working relationship with their athletes still need to request permission to post on their behalf. This step protects everyone in the relationship including Sqor. The flow below demonstrates a request to represent an athlete as well as options to terminate a relationship from both sides. When a new representation is requested an email is sent out to the athlete requesting a response and taking them directly to the interface where they can grant access. Once access is granted agents are alerted and encouraged to create a first post. This notification brings agents to the tool and gets them posting right out of the gate.
Simultaneous to optimizing the first three versions, I initiated a card sorting exercise with our in-house athlete relations team to determine the future architecture of the site. From this exercise we moved the agent/athlete messaging feature and the monthly payment tables to the main navigation in order to make them more easily accessible.
Immediately after the release of both Fangagement and Sqor Manager, our athletes and agents provided an abundance of positive feedback.
What we heard from our users: