My Role

End-to-end

UX Researcher and

UX/UI Designer

Timeline

7 weeks

Tools

Figma

FigJam

Adobe Illustrator

Adobe Photoshop

TEST PROJECT PROTOTYPE

PROJECT OVERVIEW

Kick Fun is a mobile-first web app designed to organize and manage a 7-a-side amateur football community.

The project focuses on making participation more reliable by structuring access to matches, integrating booking and payment, and supporting long-term engagement.

TEST PROJECT PROTOTYPE

EMPHATIZE

DEFINE

IDEATE

PROTOTYPE

TEST

My Role

End-to-end

UX Researcher and

UX/UI Designer

Timeline

7 weeks

Tools

Figma

FigJam

Adobe Illustrator

Adobe Photoshop

PROJECT OVERVIEW

Kick Fun is a mobile-first web app designed to organize and manage a 7-a-side amateur football community.

The project focuses on making participation more reliable by structuring access to matches, integrating booking and payment, and supporting long-term engagement.

TEST PROJECT PROTOTYPE

My Role

End-to-end

UX Researcher and

UX/UI Designer

Timeline

7 weeks

Tools

Figma

FigJam

Adobe Illustrator

Adobe Photoshop

PROJECT OVERVIEW

Kick Fun is a mobile-first web app designed to organize and manage a 7-a-side amateur football community.

The project focuses on making participation more reliable by structuring access to matches, integrating booking and payment, and supporting long-term engagement.

1. PROJECT INTRODUCTION

Context

A community of ~100 players meets weekly to play 7-a-side football.

What started as an informal activity has evolved into a recurring, structured experience with coordination needs around access, participation, and group management.

An internal website supports match organization, but most coordination still depends on a single organizer.

1. PROJECT INTRODUCTION

Context

A community of ~100 players meets weekly to play 7-a-side football.

What started as an informal activity has evolved into a recurring, structured experience with coordination needs around access, participation, and group management.

An internal website supports match organization, but most coordination still depends on a single organizer.

As the group grows, the system no longer scales with the complexity of participation.

Problem

The current system does not support fair and reliable participation over time.

Access to matches depends on speed rather than availability
Booking, payment, and communication are fragmented
Rules and expectations rely on manual enforcement

As a result, participation becomes unpredictable, inconsistent, and organizer-dependent.

Goal

Design a system that enables fair, predictable, and continuous participation.

Focus on:

Flexible and reliable match access
A unified booking + payment flow
Explicit and system-supported rules
Sustained engagement beyond single matches

Design Strategy

Shift from a fragmented, organizer-driven process to a system that structures participation end-to-end.

Three decisions define the project from the start:

Access should not depend on speed
Booking, payment, and rules should be part of one continuous flow
Participation should be supported beyond the single match

These decisions guide the entire solution, from structure to interface design.

Solution

A mobile-first web app that connects onboarding, match organization, and longterm engagement into a single system.

Core areas:

Player setup → role and skill definition
Match flow → booking, payment, confirmation
Growth layer → mentorship, goals, progress tracking

Problem

The current system does not support fair and reliable participation over time.

Access to matches depends on speed rather than availability
Booking, payment, and communication are fragmented
Rules and expectations rely on manual enforcement

As a result, participation becomes unpredictable, inconsistent, and organizer-dependent.

Goal

Design a system that enables fair, predictable, and continuous participation.

Focus on:

Flexible and reliable match access
A unified booking + payment flow
Explicit and system-supported rules
Sustained engagement beyond single matches

Design Strategy

Shift from a fragmented, organizer-driven process to a system that structures participation end-to-end.

Three decisions define the project from the start:

Access should not depend on speed
Booking, payment, and rules should be part of one continuous flow
Participation should be supported beyond the single match

These decisions guide the entire solution, from structure to interface design.

Solution

A mobile-first web app that connects onboarding, match organization, and longterm engagement into a single system.

Core areas:

Player setup → role and skill definition
Match flow → booking, payment, confirmation
Growth layer → mentorship, goals, progress tracking

Results

The redesigned experience improves clarity and reduces friction across the main flows. Booking, payment, and confirmation are combined into a single sequence, reducing reliance on external coordination. Payment becomes predictable, and rules are made explicit before participation.

Some complexity remains in advanced features, but was refined during iteration without changing the overall structure.

2. RESEARCH

2.1 Research Introduction

2. RESEARCH

2.1 Research Introduction

Context

Joining a match is not only a booking action.

It involves access, coordination, group dynamics, and continuity over time.

The initial analysis showed that the breakdown does not depend on a single feature but on how the system supports participation as a whole.

Research Problem

Some players join regularly, while others struggle to access matches or stay involved.

The problem is not only access, but the lack of a system that supports participation consistently over time.

Despite having an existing system, participation remains inconsistent.

Objectives

The research focused on understanding:

How players access matches
Where friction occurs across booking, payment, and communication
How group dynamics influence participation
Which needs are not currently supported

Methods

Two complementary approaches were used:

Competitor analysis to identify patterns and gaps
4 user interviews + organizer interview to understand real behaviors and constraints

2.2 Competitor Analysis

Existing platforms address parts of the experience, but not the full journey.

Booking platforms provide efficient access, but do not support long-term participation
Group tools enable coordination, but lack mechanisms for fair and consistent access
Payment is often external and fragmented
More advanced systems are too complex for informal groups

View Competitor Analysis

2.2 Competitor Analysis

Existing platforms address parts of the experience, but not the full journey.

Booking platforms provide efficient access, but do not support long-term participation
Group tools enable coordination, but lack mechanisms for fair and consistent access
Payment is often external and fragmented
More advanced systems are too complex for informal groups

View Competitor Analysis

Insight: no solution supports participation as a continuous and structured experience.

2.3 User Interviews

Interviews helped ground the analysis in real behaviors and experiences.

Recurring evidence:

“Fast response is required” → access depends on speed

“Cash payments make collection inefficient” → payment friction

“Last-minute dropouts disrupt team balance” → instability

“Rules help keep play safe, but are not always followed” → weak enforcement

“Overall participation is declining” → lack of continuity

View Affinity Map

2.3 User Interviews

Interviews helped ground the analysis in real behaviors and experiences.

Recurring evidence:

“Fast response is required” → access depends on speed

“Cash payments make collection inefficient” → payment friction

“Last-minute dropouts disrupt team balance” → instability

“Rules help keep play safe, but are not always followed” → weak enforcement

“Overall participation is declining” → lack of continuity

View Affinity Map

2.4 Research Synthesis

The synthesis revealed a consistent pattern: the experience breaks down over time due to lack of system support.

Core insights:

Match access depends on timing and availability rather than system support, making participation uneven across users
Participation is difficult to maintain over time due to cancellations, weather, and inconsistent attendance
Payment is a recurring operational friction, especially when handled manually
Rules exist, but they are not reinforced consistently enough to support fair and safe play
Team balance depends on skill distribution and player reliability, but the current system does not support either clearly enough
The experience does not support continuity beyond the match, despite users expressing interest in improvement, connection, and progression

Some complexity remains in advanced features, but was refined during iteration without changing the overall structure.

Prioritization

The focus was placed on the issues that most directly affect participation:

Access
Continuity
Payment
Rules
Engagement

Other aspects, such as team balance and social dynamics, remained important but were treated as secondary at this stage. Team balance was partially addressed through role and skill

inputs, while broader social dynamics were considered less directly controllable through system design alone.

2.4 Research Synthesis

The synthesis revealed a consistent pattern: the experience breaks down over time due to lack of system support.

Core insights:

Match access depends on timing and availability rather than system support, making participation uneven across users
Participation is difficult to maintain over time due to cancellations, weather, and inconsistent attendance
Payment is a recurring operational friction, especially when handled manually
Rules exist, but they are not reinforced consistently enough to support fair and safe play
Team balance depends on skill distribution and player reliability, but the current system does not support either clearly enough
The experience does not support continuity beyond the match, despite users expressing interest in improvement, connection, and progression

Some complexity remains in advanced features, but was refined during iteration without changing the overall structure.

Prioritization

The focus was placed on the issues that most directly affect participation:

Access
Continuity
Payment
Rules
Engagement

Other aspects, such as team balance and social dynamics, remained important but were treated as secondary at this stage. Team balance was partially addressed through role and skill

inputs, while broader social dynamics were considered less directly controllable through system design alone.

3. DEFINE

3.1 Framing the Problem

Research highlighted multiple issues, but the core problem is not fragmented.

Participation breaks down because the system does not support it consistently over time. Access, payment, rules, team balance, and continuity are not independent issues, but connected parts of the same experience.

This reframes the project from improving isolated features to making a more fundamental decision: participation should be structured by the system rather than managed through speed, manual coordination, or user effort alone.

3. DEFINE

3.1 Framing the Problem

Research highlighted multiple issues, but the core problem is not fragmented.

3.2 Point of View

A player needs flexible access to matches because time-based booking excludes those who cannot respond immediately
A player needs to participate consistently because external factors (weather, schedule) disrupt continuity
A player needs a regulated environment because excessive competitiveness reduces enjoyment and safety
A player needs an integrated payment system because fragmented methods create confusion and delays
A player needs ways to improve and stay engaged because the experience currently ends at the match

3.3 How Might We

The Point of View statements are translated into design challenges that guide solution exploration.

Instead of addressing isolated issues, each question focuses on improving a key part of the participation flow.

How might we enable match access without relying on speed?
How might we support consistent participation despite changing availability?
How might we reinforce rules and fair play through the system?
How might we integrate payment into the booking flow?
How might we extend the experience beyond the match?

3.2 Point of View

A player needs flexible access to matches because time-based booking excludes those who cannot respond immediately
A player needs to participate consistently because external factors (weather, schedule) disrupt continuity
A player needs a regulated environment because excessive competitiveness reduces enjoyment and safety
A player needs an integrated payment system because fragmented methods create confusion and delays
A player needs ways to improve and stay engaged because the experience currently ends at the match

3.3 How Might We

The Point of View statements are translated into design challenges that guide solution exploration.

Instead of addressing isolated issues, each question focuses on improving a key part of the participation flow.

How might we enable match access without relying on speed?
How might we support consistent participation despite changing availability?
How might we reinforce rules and fair play through the system?
How might we integrate payment into the booking flow?
How might we extend the experience beyond the match?

3.4 Summary

The Define phase turns research into a clear design position: participation should be reliable, explicit, and structured across the whole experience. This creates a focused direction for the next phase, ensuring that ideation is not about adding features, but about deciding which mechanisms can make participation fairer, clearer, and more sustainable over time.

3.4 Summary

4. USER PERSONA

4.1 Why Personas

Personas are used to translate research insights into concrete user perspectives and guide design decisions.

Rather than representing all users, they focus on two critical moments of the experience: entering the system and staying engaged over time.

This distinction reflects a key finding from the research: participation issues emerge both at entry and over time, but for different reasons.

4. USER PERSONA

4.1 Why Personas

Personas are used to translate research insights into concrete user perspectives and guide design decisions.

Rather than representing all users, they focus on two critical moments of the experience: entering the system and staying engaged over time.

This distinction reflects a key finding from the research: participation issues emerge both at entry and over time, but for different reasons.

4.2 Mark — Returning Player

Mark represents users who are already part of the group but struggle to maintain consistent participation. His needs highlight issues related to:

Reliability of access
Team balance and fairness
Reduced dependency on manual coordination

These insights directly informed decisions around booking structure, system-supported rules, and continuity mechanisms.

4.3 Arthur — New Player

Arthur represents users approaching the group for the first time. His needs highlight issues related to:

Clarity of the system
Ease of entry
Perceived safety and inclusivity

These insights informed decisions around onboarding, rule visibility, and reducing friction in early interactions.

4.2 Mark — Returning Player

Mark represents users who are already part of the group but struggle to maintain consistent participation. His needs highlight issues related to:

Reliability of access
Team balance and fairness
Reduced dependency on manual coordination

These insights directly informed decisions around booking structure, system-supported rules, and continuity mechanisms.

View User Persona Mark

4.3 Arthur — New Player

Arthur represents users approaching the group for the first time. His needs highlight issues related to:

Clarity of the system
Ease of entry
Perceived safety and inclusivity

These insights informed decisions around onboarding, rule visibility, and reducing friction in early interactions.

View User Persona Arthur

View User Persona Mark

View User Persona Arthur

4.4 Summary

Although Mark and Arthur represent different moments of the experience, their needs converge on the same system requirements:

Accessible and predictable booking
Clear and enforced rules
Reduced reliance on external coordination
Support for long-term engagement

Designing for both ensures that the system works across the full participation lifecycle, from first access to sustained involvement.

4.4 Summary

Although Mark and Arthur represent different moments of the experience, their needs converge on the same system requirements:

Accessible and predictable booking
Clear and enforced rules
Reduced reliance on external coordination
Support for long-term engagement

Designing for both ensures that the system works across the full participation lifecycle, from first access to sustained involvement.

5. IDEATION

5.1 Ideation Approach

Once the main design directions were defined through the Point of View statements and the How Might We questions, the goal was not simply to produce a large number of ideas, but to explore solutions that directly respond to user needs.

The process unfolded in two stages: a divergent phase, where a wide range of solutions was generated across the experience and a convergent phase, where ideas were evaluated and reduced based on their impact, coherence, and feasibility.

This shift from exploration to selection allowed moving from a broad set of possibilities to a more focused and structured design direction.

5. IDEATION

5.1 Ideation Approach

This shift from exploration to selection allowed moving from a broad set of possibilities to a more focused and structured design direction.

5.2 Idea Exploration - Brainstorming

The How Might We questions were used as a structured starting point to explore possible solutions. Ideas were generated across all key areas of the experience, including booking, participation, rules, payment, and long-term engagement.

View Brainstorming Idea Generation

5.2 Idea Exploration - Brainstorming

View Brainstorming Idea Generation

The exploration revealed a set of recurring directions, but also an early pattern in decision-making.

Reducing dependency on speed

automatic booking, yearly calendar, prioritization systems

Shifting coordination from people to system logic

limits, role/skill categorization, structured allocation

Integrating fragmented steps into one participation flow

booking + payment + confirmation

Making rules part of the experience

rule acceptance, penalties, behavioral feedback

Extending value beyond the single match

mentorship, goals, content, engagement features

At this stage, the key shift was from generating isolated ideas to identifying which mechanisms could realistically support participation over time.

5.3 Worst Possible Idea

To further test the solution space, the Worst Possible Idea technique was used to deliberately generate ineffective or extreme solutions.

View Worst Possible Idea

5.3 Worst Possible Idea

To further test the solution space, the Worst Possible Idea technique was used to deliberately generate ineffective or extreme solutions.

View Worst Possible Idea

Across all areas, the exercise highlighted consistent constraints:

Manual coordination does not scale

solutions relying on organizer intervention were not viable

Lack of structure increases friction

open or uncontrolled systems lead to instability

Separated flows create confusion

booking, payment, and rules must be integrated

Implicit behavior is unreliable

rules need to be explicit and system-supported

These principles were used as filters in the next phase, helping eliminate solutions that depend on user discipline or external coordination.

5.4 Idea Selection

NOW HOW WOW Matrix

Ideas were evaluated using the Now–How–Wow matrix to balance impact, feasibility, and complexity.

Rather than balancing categories, the matrix was read to identify patterns:

Now ideas

define the foundation of the system simple, high-impact, immediately implementable

How ideas

extend the system with moderate complexity useful but not critical

Wow ideas

high potential value often dependent on user behavior or more complex systems

Key decision

Many “Wow” ideas were intentionally not prioritized as core features, because they introduced higher complexity, depended on sustained user initiative, or added value without improving the stability of participation.

Ideas related to social engagement, rewards, and richer community interaction remained relevant but were treated as secondary compared to the more urgent need to make access, payment, and rules more reliable.

View Now How Wow Matrix

NOW HOW WOW Matrix

Ideas were evaluated using the Now–How–Wow matrix to balance impact, feasibility, and complexity.

Rather than balancing categories, the matrix was read to identify patterns:

Now ideas

define the foundation of the system simple, high-impact, immediately implementable

How ideas

extend the system with moderate complexity useful but not critical

Wow ideas

high potential value often dependent on user behavior or more complex systems

Key decision

View Now How Wow Matrix

The focus remained on stabilizing participation before extending the experience.

5.5 Final Selection

Six Thinking Hats

After prioritization through the Now–How–Wow matrix, the selected ideas were further evaluated using the Six Thinking Hats method.

The method was used to assess each idea from multiple perspectives:

User value
Feasibility and constraints
Risks and potential downsides
Impact on the overall system

This step was not used to generate new ideas, but to make decisions explicit, clarifying which ideas should define the system and which ones should remain secondary.

View Six Hats Method

5.5 Final Selection

Six Thinking Hats

After prioritization through the Now–How–Wow matrix, the selected ideas were further evaluated using the Six Thinking Hats method.

The method was used to assess each idea from multiple perspectives:

User value
Feasibility and constraints
Risks and potential downsides
Impact on the overall system

This step was not used to generate new ideas, but to make decisions explicit, clarifying which ideas should define the system and which ones should remain secondary.

View Six Hats Method

What emerged

Across the evaluation, consistent patterns became visible:

Ideas connected to booking and participation reliability created the strongest system impact
Solutions that reduced manual handling were more robust and scalable
Ideas depending on moderation, subjective enforcement, or sustained initiative were more fragile
Simpler mechanisms produced more reliable outcomes than layered or highly social features

This made the selection criteria more explicit: ideas were not advanced because they were interesting but because they improved participation in a reliable and repeatable way.

Outcome of the evaluation

The Six Thinking Hats analysis led to a clear distinction between three types of outcomes:

Core ideas

Ideas that directly shape how the system works and define the main user flows

Supporting ideas

Ideas that extend the experience but are not essential to the system’s core functionality

Design principles

Ideas that do not translate into specific features, but guide the structure, clarity and usability of the interface.

This classification is the result of a consistent evaluation applied across all selected ideas. It reflects a clear trade-off: priority was given to ideas that improve reliability, reduce friction, and scale without depending too heavily on organizer intervention or unpredictable user behavior.

What emerged

Across the evaluation, consistent patterns became visible:

Ideas connected to booking and participation reliability created the strongest system impact
Solutions that reduced manual handling were more robust and scalable
Ideas depending on moderation, subjective enforcement, or sustained initiative were more fragile
Simpler mechanisms produced more reliable outcomes than layered or highly social features

This made the selection criteria more explicit: ideas were not advanced because they were interesting but because they improved participation in a reliable and repeatable way.

Outcome of the evaluation

The Six Thinking Hats analysis led to a clear distinction between three types of outcomes:

Core ideas

Ideas that directly shape how the system works and define the main user flows

Supporting ideas

Ideas that extend the experience but are not essential to the system’s core functionality

Design principles

Ideas that do not translate into specific features, but guide the structure, clarity and usability of the interface.

5.6 Ideation Outcome

The ideation phase results in a structured set of decisions that define both the system and its level of implementation.

5.6 Ideation Outcome

The ideation phase results in a structured set of decisions that define both the system and its level of implementation.

1. Core ideas (define the system and main flows)

These ideas are fully developed in the prototype and shape the key moments of the experience, such as onboarding, booking, payment, and continuity.

Create an account
Player role and skill category
Accept rules before accessing the platform
Automatic booking when availability is enabled
Advance booking through a yearly calendar
Book a match instantly
Allow online pre-payment
Mandatory payment during booking
Accept rules summary during booking
Display current weather to players
Booking confirmation screen
Instant booking notification
Cancellation option
Low balance notification
Three player skill levels instead of two
Individual technical goals
Access the mentorship program
Mentor selection system
Track progress within the program

2. Supporting ideas (extend the experience)

These ideas are present at a conceptual or visual level but are not fully developed in the prototype. They indicate possible directions for future iterations.

Interactive field location map
Post-match stats and score reports
Hall of fame for results and trophies
Rechargeable wallet for payments
Tactical tutorials
Pre-match team chat
Post-match behavior feedback
Photo and video archive by match and period
Group status based on participation, fair play, and team balance
Matches between players with similar age and fitness

3. Design principles (guide the experience)

These ideas do not correspond to specific features, but define how the system is structured and experienced.

Clear, concise rules
Clear and minimal page structure
Mobile-first design
Content organized by sections
Readable typography and color system
Vertical navigation adapted to content
Simple and clean content layout
Easy interactions (buttons, links, forms)

1. Core ideas (define the system and main flows)

These ideas are fully developed in the prototype and shape the key moments of the experience, such as onboarding, booking, payment, and continuity.

Create an account
Player role and skill category
Accept rules before accessing the platform
Automatic booking when availability is enabled
Advance booking through a yearly calendar
Book a match instantly
Allow online pre-payment
Mandatory payment during booking
Accept rules summary during booking
Display current weather to players
Booking confirmation screen
Instant booking notification
Cancellation option
Low balance notification
Three player skill levels instead of two
Individual technical goals
Access the mentorship program
Mentor selection system
Track progress within the program

2. Supporting ideas (extend the experience)

These ideas are present at a conceptual or visual level but are not fully developed in the prototype. They indicate possible directions for future iterations.

Interactive field location map
Post-match stats and score reports
Hall of fame for results and trophies
Rechargeable wallet for payments
Tactical tutorials
Pre-match team chat
Post-match behavior feedback
Photo and video archive by match and period
Group status based on participation, fair play, and team balance
Matches between players with similar age and fitness

3. Design principles (guide the experience)

These ideas do not correspond to specific features, but define how the system is structured and experienced.

Clear, concise rules
Clear and minimal page structure
Mobile-first design
Content organized by sections
Readable typography and color system
Vertical navigation adapted to content
Simple and clean content layout
Easy interactions (buttons, links, forms)

Final direction

The ideation phase does not result in a list of features, but in three system-level decisions:

Access must be reliable and not based on speed

participation should depend on visibility, structure, and system support rather than reaction time

Booking, payment, and rules must be integrated into a single flow

the most critical part of the experience should be predictable, explicit, and self-contained

The experience must support continuity beyond individual matches

the system should not stop at coordination, but create reasons for users to return and stay engaged over time

These decisions define the foundation of the product and guide the transition to the next phase, where they are translated into system structure and flows.

Final direction

The ideation phase does not result in a list of features, but in three system-level decisions:

Access must be reliable and not based on speed

participation should depend on visibility, structure, and system support rather than reaction time

Booking, payment, and rules must be integrated into a single flow

the most critical part of the experience should be predictable, explicit, and self-contained

The experience must support continuity beyond individual matches

the system should not stop at coordination, but create reasons for users to return and stay engaged over time

These decisions define the foundation of the product and guide the transition to the next phase, where they are translated into system structure and flows.

6. INFORMATION ARCHITECTURE

6.1 Sitemap

At this stage, the system is already defined. The goal is no longer to decide what to build, but to organize it into a clear and usable structure.

The sitemap translates the outcomes of the ideation phase into a navigable product structure.

It is built around the main areas of the experience shown in the system map: Home, Play, Match, Improve, Community, Profile, and Inbox, with their related sub-sections.

The structure is intentionally centered on a limited number of main entry points. This avoids fragmentation and supports a clear progression across the experience: entering the system, joining matches, and staying engaged over time.

6. INFORMATION ARCHITECTURE

6.1 Sitemap

At this stage, the system is already defined. The goal is no longer to decide what to build, but to organize it into a clear and usable structure.

The sitemap translates the outcomes of the ideation phase into a navigable product structure.

It is built around the main areas of the experience shown in the system map: Home, Play, Match, Improve, Community, Profile, and Inbox, with their related sub-sections.

HOME

The central hub of the experience. It connects users to the main sections and supports orientation across the product.

PLAY

The section dedicated to match access and participation. It includes the booking flow, payment, and confirmation, making the most critical interaction of the system visible and direct.

MATCH

A dedicated area for the active match experience, including feedback, lineups, stats, and chat. This separates the act of booking from the experience of participating in a specific game

IMPROVE

The area focused on long-term engagement and player development. It includes mentors, goals, and program overview, extending the experience beyond single matches

COMMUNITY

A distinct section dedicated to collective and social content, such as the league dashboard, match history, awards, and media center. Its role is not to support core task completion, but to reinforce belonging, shared memory, and group continuity

PROFILE

A separate personal area focused on the individual user. It includes account information, level and position, previous results, wallet, reviews, settings, tactics, and skills overview. Unlike Community, which is group-oriented, Profile is centered on personal data, progress, and self- management

INBOX

A supporting area for communication, kept structurally separate from the core match and profile sections.

HOME

The central hub of the experience. It connects users to the main sections and supports orientation across the product.

PLAY

The section dedicated to match access and participation. It includes the booking flow, payment, and confirmation, making the most critical interaction of the system visible and direct.

MATCH

A dedicated area for the active match experience, including feedback, lineups, stats, and chat. This separates the act of booking from the experience of participating in a specific game

IMPROVE

The area focused on long-term engagement and player development. It includes mentors, goals, and program overview, extending the experience beyond single matches

COMMUNITY

PROFILE

INBOX

A supporting area for communication, kept structurally separate from the core match and profile sections.

Key structural decision

The architecture is not organized by technical functions, but by user intent.

Users do not think in terms of features; they think in terms of actions such as joining a match, following an active game, improving over time, or accessing group content. For this reason, the system was structured around distinct areas with clear purposes rather than around a flat list of tools.

This also meant avoiding a more fragmented architecture. Instead of multiplying sections and sub-sections, the structure keeps the experience compact and readable, making the path from access to participation and continuity easier to understand.

View Sitemap

Key structural decision

The architecture is not organized by technical functions, but by user intent.

View Sitemap

6.2 User Flows

Once the structure is defined, the next step is to clarify how the most important parts of the system work in practice.

Rather than mapping every possible interaction, three flows were selected because they represent the core of the experience: entering the system, joining a match, and staying engaged over time. These flows are shown in the authentication, booking, and improve diagrams.

6.2 User Flows

Once the structure is defined, the next step is to clarify how the most important parts of the system work in practice.

Authentication flow

The onboarding flow is designed to reduce uncertainty and make the system understandable from the beginning. Users move from personal information to player setup and final setup, including role, skill definition, and rule acceptance. This supports clarity at entry and helps the system collect only the information needed to shape participation.

Booking flow

This is the most critical flow in the product. The main structural decision is to bring booking, payment, and confirmation into one sequence. This directly responds to one of the strongest research findings: participation becomes unreliable when access depends on speed, payment is handled separately, and expectations are clarified too late. The flow was intentionally designed to avoid fragmentation. Instead of forcing users to switch between tools, people, or separate steps, the system keeps the full participation process in one place. By doing so, the experience becomes more predictable, reduces external coordination, and makes expectations explicit before participation.

Improve flow

This flow supports continuity over time. Through mentor selection, goal setting, and program overview, it introduces a dedicated path for growth and sustained engagement. The flow makes improvement a recurring part of the experience rather than an optional extra.

Authentication flow

Booking flow

Improve flow

6.3 Structural Rationale

The architecture is guided by one main principle: prioritizing clarity and continuity over feature quantity. The sitemap defines the overall structure, while the flows clarify how the most important interactions are meant to work. Together, they translate the earlier design decisions into a system that is understandable, navigable, and aligned with the main problems identified during research. This is the point where the project shifts from selected ideas to product structure.

6.3 Structural Rationale

7. SOLUTION DESIGNED

7.1 Wireframes

After defining the structure and flows, wireframes were used to validate the clarity of the system before introducing visual design. The focus was not on visual exploration, but on verifying that:

The main flows are understandable
Interactions follow a clear and predictable logic
Users can complete key actions without ambiguity

Key decisions

7. SOLUTION DESIGNED

7.1 Wireframes

After defining the structure and flows, wireframes were used to validate the clarity of the system before introducing visual design. The focus was not on visual exploration, but on verifying that:

The main flows are understandable
Interactions follow a clear and predictable logic
Users can complete key actions without ambiguity

Key decisions

Onboarding (Player Setup)

Information is distributed across multiple steps to reduce cognitive load.

Users progressively define their role, skill level, and profile, allowing the system to structure participation from the beginning.

This reflects an earlier decision:

Role and skill are not optional inputs

They are necessary to support team organization and fair play.

Booking (Play)

The calendar is the central element of the booking experience. This is not only a layout choice, but a direct translation of a core design decision: access should not depend on speed, but on visibility and planning. Making availability central helps shift participation away from reactive booking and toward a more structured system. Users can see available dates, understand constraints, and act within a clearer participation model rather than competing for access through timing alone.

Payment integration

Payment is part of the same flow, not a separate step.

This decision:

Removes fragmentation
Avoids context switching
Reinforces commitment before participation

The booking process becomes a continuous sequence rather than a set of disconnected actions.

Onboarding (Player Setup)

Information is distributed across multiple steps to reduce cognitive load.

Users progressively define their role, skill level, and profile, allowing the system to structure participation from the beginning.

This reflects an earlier decision:

Role and skill are not optional inputs

They are necessary to support team organization and fair play.

Booking (Play)

Payment integration

Payment is part of the same flow, not a separate step.

This decision:

Removes fragmentation
Avoids context switching
Reinforces commitment before participation

The booking process becomes a continuous sequence rather than a set of disconnected actions.

Onboarding (Player Setup)

Information is distributed across multiple steps to reduce cognitive load.

Users progressively define their role, skill level, and profile, allowing the system to structure participation from the beginning.

This reflects an earlier decision:

Role and skill are not optional inputs

They are necessary to support team organization and fair play.

Booking (Play)

Payment integration

Payment is part of the same flow, not a separate step.

This decision:

Removes fragmentation
Avoids context switching
Reinforces commitment before participation

The booking process becomes a continuous sequence rather than a set of disconnected actions.

7.2 Visual Direction

The visual design supports clarity, action, and consistency rather than aesthetic exploration.

7.2 Visual Direction

The visual design supports clarity, action, and consistency rather than aesthetic exploration.

Logo & Naming

The name Kick Fun reflects two key aspects of the experience:

The activity itself (football)
The social and accessible nature of participation

The logo reinforces this by:

Integrating a goal structure
Using a ball element within the wordmark

The objective is immediate recognition and readability, especially in mobile contexts.

Logo & Naming

The name Kick Fun reflects two key aspects of the experience:

The activity itself (football)
The social and accessible nature of participation

The logo reinforces this by:

Integrating a goal structure
Using a ball element within the wordmark

The objective is immediate recognition and readability, especially in mobile contexts.

Color system

The palette is designed to support hierarchy and interaction:

Dark tones create a stable background and reduce visual noise
High-contrast accents highlight primary actions
Neutral tones separate content from interaction

This makes interactive elements immediately recognizable, particularly in fast mobile usage.

Color system

The palette is designed to support hierarchy and interaction:

Dark tones create a stable background and reduce visual noise
High-contrast accents highlight primary actions
Neutral tones separate content from interaction

This makes interactive elements immediately recognizable, particularly in fast mobile usage.

Components

The interface is based on a consistent set of reusable components.

Each component makes system logic explicit:

Inputs and dropdowns reduce ambiguity in data entry
Toggles and checkboxes define system states clearly
Buttons reflect action availability (active/inactive states)
Cards structure content across different sections
Calendar supports direct interaction with availability
Sliders simplify subjective inputs such as skill level

Consistency across states (default, active, inactive) ensures that users always understand what is possible and what has been selected.

Components

The interface is based on a consistent set of reusable components.

Each component makes system logic explicit:

Inputs and dropdowns reduce ambiguity in data entry
Toggles and checkboxes define system states clearly
Buttons reflect action availability (active/inactive states)
Cards structure content across different sections
Calendar supports direct interaction with availability
Sliders simplify subjective inputs such as skill level

Consistency across states (default, active, inactive) ensures that users always understand what is possible and what has been selected.

7.3 High-Fidelity Prototype

The final prototype translates structure and interaction logic into a cohesive experience.

7.3 High-Fidelity Prototype

The final prototype translates structure and interaction logic into a cohesive experience.

Booking

The sequence is continuous:

Match selection
Payment
Confirmation

This reflects a core decision made during ideation: reduce fragmentation and external coordination.

Confirmation

The confirmation step includes a summary of the rules.

This makes expectations explicit before participation and reinforces system-supported behavior.

Booking

The sequence is continuous:

Match selection
Payment
Confirmation

This reflects a core decision made during ideation: reduce fragmentation and external coordination.

Confirmation

The confirmation step includes a summary of the rules.

This makes expectations explicit before participation and reinforces system-supported behavior.

Improve

This section introduces continuity:

Mentorship
Goals
Progress tracking

It transforms participation from a single event into an ongoing experience.

Match

The match screen centralizes:

Location
Teams
Communication
Feedback

This avoids reliance on external tools and keeps the experience contained within the system.

Improve

This section introduces continuity:

Mentorship
Goals
Progress tracking

It transforms participation from a single event into an ongoing experience.

Match

The match screen centralizes:

Location
Teams
Communication
Feedback

This avoids reliance on external tools and keeps the experience contained within the system.

7.4 Design Rationale

The design is guided by a single principle: clarity over complexity. Every decision, from structure to interface, is aligned with the main problems identified during research:

Unreliable access
Fragmented interactions
Unclear expectations
Lack of continuity

This also required trade-offs. The design intentionally prioritizes reliability, clarity, and flow integration over feature richness.

More layered social, analytical, or interactive elements were kept secondary whenever they risked adding complexity without improving the core experience.

The result is a system where actions are clear, flows are predictable, and participation is supported more consistently over time.

7.4 Design Rationale

The design is guided by a single principle: clarity over complexity. Every decision, from structure to interface, is aligned with the main problems identified during research:

Unreliable access
Fragmented interactions
Unclear expectations
Lack of continuity

This also required trade-offs. The design intentionally prioritizes reliability, clarity, and flow integration over feature richness.

More layered social, analytical, or interactive elements were kept secondary whenever they risked adding complexity without improving the core experience.

The result is a system where actions are clear, flows are predictable, and participation is supported more consistently over time.

8. TESTING

8.1 Test Setup

A moderated remote usability test was conducted with 5 participants from the football group the product was designed for. All participants regularly play in the group; 4 had already taken part in the user interview phase, while one was the group founder and represented an expert-user perspective.

The sessions took place on Google Meet. Participants shared their screen, used the high-fidelity prototype in full-screen mode, and followed a think-aloud approach while completing three task-based flows:

Onboarding and account creation
Booking and paying for multiple matches
Joining the improvement program by selecting a mentor and focus areas.

The analysis focused on task completion, hesitation points, misunderstandings, assistance needed, navigation choices, and post-test feedback.

8.2 What Worked

The test also helped identify which parts of the prototype were already working effectively.

The manual calendar supported the booking flow well. Participants were able to review available dates and select the matches they wanted to join without relevant friction.

Once participants reached the payment screen, the payment step was clear. The confirmation message also provided a clear sense of completion after payment.

The Improve flow worked well from an interaction perspective. Mentor selection, focus-area selection, and mentor change were completed smoothly by most participants.

8.1 Test Setup

Onboarding and account creation
Booking and paying for multiple matches
Joining the improvement program by selecting a mentor and focus areas.

The analysis focused on task completion, hesitation points, misunderstandings, assistance needed, navigation choices, and post-test feedback.

8.2 What Worked

The test also helped identify which parts of the prototype were already working effectively.

The manual calendar supported the booking flow well. Participants were able to review available dates and select the matches they wanted to join without relevant friction.

Once participants reached the payment screen, the payment step was clear. The confirmation message also provided a clear sense of completion after payment.

The Improve flow worked well from an interaction perspective. Mentor selection, focus-area selection, and mentor change were completed smoothly by most participants.

8.3 Key Findings

The test surfaced five issues affecting clarity, hierarchy, and confidence at key decision points.

ONBOARDING RULES WERE UNCLEAR

Two participants interpreted the rules as selectable items, while none of the participants discovered the scroll independently. The rules section needed a clearer structure for reading, opening, and accepting the content.

BOOKING NEEDED ONE CLEAR PRIMARY ACTION

After selecting match dates, the presence of both “Book” and “Next” created uncertainty about the next step and required clarification during the task. The booking flow needed a stronger primary CTA.

BOOKED MATCHES WERE NOT CLEARLY FRAMED

Around half of the participants were unsure about the purpose of “Booking Summary”. The “Cancel” action was also unclear, because it did not communicate that it cancelled participation in an already booked and paid match.

PAYMENT MISSED KEY MATCH INFORMATION

Some participants expected to see the match location before paying. The wallet also needed stronger visibility in the payment flow, while multiple paid matches required clearer match-level actions.

CRITICAL ACTIONS NEEDED CLEARER FEEDBACK

Some moments created uncertainty: new users attempted to log in before signing up, and “End program” in Improve could be misread. Confirmation messages were added to clarify sensitive actions before users continued.

8.3 Key Findings

The test surfaced five issues affecting clarity, hierarchy, and confidence at key decision points.

ONBOARDING RULES WERE UNCLEAR

BOOKING NEEDED ONE CLEAR PRIMARY ACTION

BOOKED MATCHES WERE NOT CLEARLY FRAMED

PAYMENT MISSED KEY MATCH INFORMATION

Some participants expected to see the match location before paying. The wallet also needed stronger visibility in the payment flow, while multiple paid matches required clearer match-level actions.

CRITICAL ACTIONS NEEDED CLEARER FEEDBACK

8.4 Design Iterations

Onboarding Rules

Making rules easier to read and accept

Onboarding Rules

Making rules easier to read and accept

Booking Screen

Simplifying booking actions and match management

Booking Screen

Simplifying booking actions and match management

Payment Page

Adding match context before payment

Payment Page

Adding match context before payment

Confirmation Messages

Clarifying critical actions before confirmation

Confirmation Messages

Clarifying critical actions before confirmation

9. CONCLUSION

9.1 Result

Kick Fun moved the group’s match-joining process from an informal, organizer-driven routine to a clearer mobile-first service flow.

The final prototype brought together the core experience: account creation, role and skill setup, rule acceptance, match booking, payment, paid-match management, and a first layer of long-term improvement through mentorship.

Usability testing helped refine the areas where the experience needed stronger clarity: rule interaction, booking hierarchy, paid booking management and the information users need before committing to payment.

9. CONCLUSION

9.1 Result

Kick Fun moved the group’s match-joining process from an informal, organizer-driven routine to a clearer mobile-first service flow.

9.2 Future Impact

Future iterations could extend the product beyond the core booking flow, developing concepts from the ideation phase into more complete community and engagement features.

The first opportunity is the post-match layer: score reports, player stats, and a photo/video archive could turn each match into a shared record and make progress easier to track over time.

The second opportunity is stronger group coordination: pre-match team chat, behavioural feedback, and group status could support communication, accountability, and fair play within the community.

The third opportunity is long-term engagement: hall of fame, tactical content, and selected reward mechanics could encourage return use while keeping the product grounded in its main goal: making participation more reliable before expanding the experience.

9.2 Future Impact

Future iterations could extend the product beyond the core booking flow, developing concepts from the ideation phase into more complete community and engagement features.

The first opportunity is the post-match layer: score reports, player stats, and a photo/video archive could turn each match into a shared record and make progress easier to track over time.

The second opportunity is stronger group coordination: pre-match team chat, behavioural feedback, and group status could support communication, accountability, and fair play within the community.

TEST PROJECT PROTOTYPE