Agyle App Design.

A modern solution for professional soccer players seeking to connect with agents to help them line up their next career move. Designed every step of the way with the players' needs top of mind.


Playing soccer (or, more appropriately, football) was always a serious part of my life up until I began school at Stanford in 2017. In December 2019, I decided to take a deep-dive into the daily lives of players who've prolonged their careers longer that I have, be it into the professional scene or at a college level. I sought to design for them a solution (in the form of a mobile app) to a novel painpoint, whatever that may be.

Design goals

Hone in on a need

Uncover an underlying painpoint for my users


Understand the domain space

Analyze the current user journey and its touchpoints around which to design


Ideate a solution

Consolidate insights, conceptualize a solution


Iterate towards a refined product

Prototype and iterate based on insights + design goals


Ideally, my app design would eradicate, or at least alleviate, a universal pain-point that professional or pre-professional players experience regularly.


Design Research

Interviewing users, honing in on a need, conducting domain research, constructing user personas, deciding on a "How Might We" statement.


Starting with the players

Because of my adjacency to collegiate-level players on campus and within my personal network, I decided to, at least at the outset, focus on that user group (as opposed to full-time pros).

Initial insights

I reached out to several players, including the captain of Stanford's Mens varsity soccer team and a goalkeeper with plans to play professionally in Germany.

Within my interviews, I sought to get into the headspace of a high-level player, empathizing with the day-to-day drudgeries, frustrations, and highlights that come with their trade.

A high-level summary of interviews

Potential problem areas


My users made sure to mention the occasionally overlooked importance of injury prevention. With such a short regular season, players could miss most of it just because of a preventable injury.

Team coordination

One captain mentioned how he needs to coordinate practice times, pre-game meet-ups, and even team dinners. This often seemed tedious, as there were no patterns or set schedules for the team to follow.


Once players reach the D1 level, film becomes a large part of the experience. I wondered if there was potential for a product to help expedite the process of getting valuable film clips to players, rather than relying on team-meetings when all players are present.

Agents/"getting that tryout"

For players who aspire to play professionally, there's seemingly no universal way to get your foot in the door other than, that is, through the guidance and advocacy of an agent.

After analyzing my notes, I decided to further investigate the world of soccer agents. It seemed like a ripe problem area for innovation, far moreso compared to my other problem areas.


Understanding the industry

With my potential problem space in mind, I reached back out to contacts who would have personal knowledge of and (hopefully) experience with agents. I also made sure to pore over articles and documents online.

The nuts and bolts of the industry
Right now it’s pretty hard - if you don’t know about that website TransferMarkt, it’s pretty hard to find agents because there’s not much to type in to find one, so that takes a lot of initial time if you don’t have a connection.

Eli, goalkeeper (D.C. United)

Key takeaways

Low degrees of separation

In the soccer world, players are actually just an introduction away from many many different teams and leagues across the globe.

How do I expect to [get that tryout in England]? Well, for one, my coach is English. Think about who he knows. The soccer world is smaller than you think.

Logan, Stanford captain

(Agent access) low discoverability, high barriers of entry

See Eli's quote above!

References and mutual connections are huge

Many agents won't even talk to a player until they've received good word from a mutual connection.

Not one size fits all

Just like players have specific career goals, agents too have specific clientelle that they specialize in serving. Players need to provide a variety of information (CV, highlight reel, desired market, teams, etc.) to match with a fitting agent.

Importance of reputation and trust

In an industry where fraud and exploitation are not without concern, players need to do their homework before they make anything official with an agent.

At this point, I had many insights to utilize and an accurate grasp on the potential problems that players might face navigating the agent/agency industry.

Just as importantly, I realized that players at all stages of their professional careers, and not just the pre-professional players that I'd been interviewing in person, need agents tailored to their ever-changing goals.


Key personas to design for


Young Gun Gary

Gary's an ambitious player playing for a competitive D1 college. After a solid first year, he has realized that college isn't for him. Gary seeks to leverage his network to land a gig in Europe.

User Journey

Not happy with college ball in general, but also not sure how to land a tryout in Europe.



Reaches out to alumni contacts who can't help, decides to contact former teammates instead.



Gets frustrated with all the emails, phone calls, and waiting.



Finally hears from an agent in Sweden.



After a poor tryout, has to wait for many more months for another lead and continue college.



Veteran Victor

Victor is a seasoned player playing on a top team in Spain. However, he's been the second string goalie for the last 3 years. He's eager, in his final years as a pro, to freshen things up and move to a more exotic league in South America where his playing time will be guaranteed.

User Journey

Not getting the minutes he wants, starts to feel depressed.



Sets his sights on playing in a South American league.



Struggles to find any agents that he has confidence in with specialization that region.



Forced to rely on his trusted, but limited connections from his current agent.



Gets placed instead in a lower-league team still in Spain.



Based on these user personas (and indirectly my domain research), it was clear that their main issue was *finding* agents, with the intention that the agents would get them in contact with relevant teams.

For this reason, I decided to focus my design solution on this specific touchpoint.

How Might We statement

To launch my brainstorming and ideation process, I consolidated my past design work into one cohesive statement.

How might [I] design an effective way for soccer players to find an agent to help them meet their career goals?


Solution Ideation

Scattered brainstorming, researching UI patterns, crafting a generic user flow, information architecture, and app screen sketches.


Getting my ideas on paper

The initial brainstorm

So what did I come up with?

My mind map surrounding my How Might We statement

Key ideas

input bullets here of my key takeaways

Encouraging *goals*

Inspired by my Veteran Victor persona, I wanted to allow users to tailore their experience to their specific career goals. I explored methods to emphasize a user's goals as a result.

The dichotomy of two user groups

I sketched through various ways to cater to both agents and players within the same application, as well as what each party desired in a business relationship.

"Applying" to an agent/agency

The idea of applying came the operations of agenices. This took empathy with the agent – i.e., it would be unreasonable to allow any interested player to be able to directly message a high-profile agent.

Optimizing for "matches"

More than just applying a content-centered approach towards creating reationships, I knew I needed to bring to the forefront the characteristics of each player and agent most relevant to eachother's interests.

A focus on connections

Exploring what it means to allow players to "leverage their network" – viewing their network, searching through players as well as agents.


Inspiration from elsewhere

How would these ideas play out on a mobile application? I needed to do more investigating.

On catering to 2 different user groups

I first needed to figure out how (or if) I was going to attend to the interests of both the players and the agents.

There were two key complications to my user bases.

Competing interests

While players seek reputable agents to help lock in their next big transfer, agents seek money and sometimes even notoriety from their next client.


Not simply 1-1 pairs

The relationship between players and agents is more complicated than a dating relationship – players can have more than one agent, while agents can have more than one client.



I found inspiration in Uber's two app approach, in part because they differentiate between to contrasting parties – the drivers and the riders.

Uber dedicates 2 apps for its 2 user groups

Uber's solution was a very sound approach for another reason: focusing on the player-specific app would allow me to stay focused exclusively on the needs of the *players*, my goal from the outset.

This was a decision that I maintained throughout the rest of my design process.

Moving forward, "users" means exclusively "players".

Designing the "Agent application" flow

Knowing the importance of trust and reputability when choosing an agent to apply to, I sought a process that provides the user with the time and information they need to make a decision that they are confident in.


Airbnb, a company that makes "designing for trust" an integral facet of their design approach, implements a like-minded user flow for reserving from a host that would be extremely relevant to this endeavor.

Airbnb's "make your reservation" flow

Creating an environment for matches

I asked myself – what is the best way to extract the necessary information (i.e., team played for, CV, highlight reel) from users without scaring them off during onboarding?


Among dating apps that I walked through, Hinge required the most information from users, yet did so in one of the most eloquent, painless manners among its competitors.

How Hinge prompts the users to enter a lot of information

Leveraging connections

I needed a way for users to not only leverage their network, but to know how to do so in the first place.


Linkedin was a reliable source of inspiration, wherein users can view and analyze their network to see where introductions can be made and new relationships might be formed.

How Linkedin helps the user visualize their professional network

Around this time, I devised a name for my app: Agent + Agile + *cool spelling* = Agyle!

(Still pronounced the same as "agile")


What can the user do?

Initial thoughts

I had to get my thoughts out on paper first.

Attempting to answer, "how will the user use Agyle?"

At this point, here's how I envisioned a user using Agyle in a (very simplified) sequential order.


User fills out most of the information prompted during set-up.



User refines their profile to their liking, completing any fields still required to access the app's core features.



User builds up their network through connections.


Browse/Explore + Apply

User searches for a compatible agent and applies upon finding one.



Upon the application being accepted, the agent reaches out to the user.


The refined generic flow

Some key decisions that I made.

References as part of the application

A pure extension of my domain research, I incorporated an optional "choose a reference" portion of the application flow, where a user chooses from their mutual connections with the agent whom they are applying to.

Browsing through agents AND players

In an industry where what players you know is almost as important as what agents you have, I wanted to reflect that in the app itself. For this reason, when browsing, users can quickly alternate between agents and players.

The refined generic user flow for Agyle

The home screen

At this stage, I still hadn't decided: what content will the home screen have?


I decided to make my "Explore" content the first thing users see upon opening the app. This an effort to make Agyle content-centered: to place the *primary* user flow that users most care about to the forefront – finding the agents themselves.

Here, I've defined my primary user flow – finding an agent and applying. This, after all, is the bread and butter of the app, and I wanted to reflect that in the design moving forward.


Organizing Agyle

The architecture strategy

Using the iOS Human Interface Guidelines, I evaluated several app architecture strategies.

Flat (tab) navigation

When using Agyle, the user will be alternating between flows 2-5 (enumerated above), but in practice they will usually not be done sequentially in the manner that my simplified ordering suggests. Thus, users will need to be able to switch contexts easily. For these reasons, flat navigation woud be the primary organization strategy for Agyle.

Hierarchical navigation

However, within my Explore category, I envisioned my explore + apply primary user flow with several sequential steps (search, choose, consider, add reference, review profile, apply). In order to optimize for this flow, to guide users through it, that required an architecture strategy to reflect its sequential nature. Similar to Airbnb's reservation flow, hierarchical navigation would be required here, at least upon initiating the application process.

My first rendition of Agyle's IA

The refined IA

Some key decisions that I made.

Separating agents from players in Messages

As I learned in my domain research, other players and agents serve different purposes in landing a new contract, with the former essentially being a means to get an introduction/referral to the latter. Therefore, rather making my messaging category a mixed list of agents and players, I categorized/separated the two.

Saved Profiles

Empathizing with my Young Gun Gary persona, I envisioned a situation in which Gary decides he wants to finish college ball while still keeping tabs on a move to Europe post-graduation. Gary would find value in the ability to "save" agent (or player) profiles that he runs across while browsing – a list that he can always return to.

The refined information architecture for Agyle

At this stage, I was ready to breath life into my ideas. My research that I had done earlier on UI patterns would help inform what my screens would look like and how they would interact with eachother.


Creating my initial screens

Onboarding + Profile

Sketching the set-up process and completing one's profile

Some key developments (utilizing Hinge onboarding flow as inspiration).

Skippable at every step

To avoid dissuading users during a lengthy onboarding flow, users are able to skip through the rest of the onboarding if they so choose.

"Essential items"

If users fail to fill out essential items for their profile, they are alerted that they need to finish their profile to use Agyle.

Network + Messages

Sketching the messages and network screens

Some key developments (utilizing Linkedin as a source of inspiration).

New, Current, Saved tabs

This organization prioritizes growing a user's network (New is the first tab open), while providing 1-click access to a user's current network and saved profiles. Separating these in this way allows the user to easily form a mental model of their pending, current, and future connections.

Message labels

Messages can be labeled ("Reference for Jack Smith", "Application Approved") for users to quickly understand the context surrounding their conversation. Because I'd already used tabs to differentiate between players and agents in this Messages category (see "The refined IA" section), I didn't want to further categorize the messages, so labeling was a handy solution.


Sketching the explore + application flow

Some key developments (utlizing Airbnb reservation flow as a source of inspiration).

Search view

When the user searches for a specific profile or region, they can choose to continue previous searches as well.

Browse view

The immediate profiles that a user can scroll through are the agent's "based on their goals". I.e., if a player wants to play in Germany, agent's who specialize in German leagues occupy that real estate.

I was ready to render my screens digitally. But first, I needed to build a design system/visual language with which to do so.


High Fidelity Designs

Devising a design system, designing high-resolution mockups and final prototype in Adobe Xd,


Refining the UI

Choosing the accent color

When choosing an accent for color, I wanted to choose a color that conveyed a sense of reliability and trustworthiness. As I had learned in my design research, some players are weary when entering the agency industry for fear of fraud and exploitation. For these reasons, a chose blue, a color known to evoke emotions of trust.

Optimizing ubiquitous UI

I allocated extra time to decide how to organize my visual hierarchy for the large and small card components used primarily in my primary explore user flow. Calling upon my domain research and design goals, I came up with a ranked list of information items to use in my card designs.

Agent or Player

This status determines everything about a player's mental model of that profile, and therefore should always be at the forefront of the UI, visually.


Market (where an Agent specializes)

Because Agyle is centered around users' goals (i.e., where they want to play), an agent's alignment, or lack thereof, with those goals is effectively make-or-break for a player.



Because trust is such a big factor of importance for players, conveying an agent's reputability needed to come to the forefront once a user deemed them as a potential fit.


Pay cut

While one could argue that pay is make-or-break for a user choosing an agent, I wanted to optimize for trust, and thus pay cut became my fourth information item in terms of priority.


Agyle's design system

Without further ado...

The Agyle mobile design system, typography, and color pallette

Putting it Together

Onboarding + Profile Set-up

Users are guided through a set-up phase complete with value proposition and skippable steps... should the user skip through on-boarding, they must complete their profile within the app to use its features.

Onboarding flow – building a user's profile, completing remaining forms within Profile category

Explore + Apply flow

The primary user flow, users can search through agents, and upon choosing an agent, they can apply with a reference!

Explore flow – building a user's profile, completing remaining forms within Profile category

The Final Design

Here's what the final Agyle design looks like in the hands of a user!

The final product, from onboarding through most user flows

Thanks for visiting.


Songkick Redesign