This project addressed the inequalities in development access to elite Rugby Union, where talented players from non-traditional backgrounds lack exposure.

The purpose was to create an socially-driven performance sharing and tracking platform following. This solution empowers players to log training and showcase commitment, assisting players in development and ensuring fair visibility to scouts and coaches without relying on expensive or inaccessible tracking software.

The design, informed by the Technology Acceptance Model (TAM) and Octalysis Analysis, followed the Double Diamond Design Framework. The projects scope was limited so iteration had to be carefully considered per stage, as outlined in the project summary.

Project Summary

    • Secondary Research: Investigated socio-economic and socio-cultural limitations to player development, market research on current performance tracking/sharing applications; and similar UCD studies.

    • Exploratory Online Survey: Gathered initial qualitative and quantitative data for user insights and requirements, using questions adapted from the Technology Acceptance Model (TAM).

    • Exploratory Octalysis Analysis: Assessed the motivational potential of proposed platform features.

    • Data Insights (R): Survey results were analyzed and visualized in RStudio, primarily focusing on the disparity between state-educated and independently-educated players, and also including coach/development stage responses.

    • Thematic Conceptualization: Thematic Analysis of qualitative data was conducted and conceptualized into an initial TAM. Furthermore, quantitative results gathered fromdata analysis showing a consensus or strong disparity in user groups’ responses could form themes.

    • Empathy Maps: Used to build a picture of the user prior to final survey results and data analysis. Allowing for earlier iteration with the define stage.

  • Iterated primarily with Discover Stage:

    • Personas: Developed four Qualitative Personas (e.g., Angus Macdonald - Overlooked Player) based on small sample research to build empathy and define context of use.

    • Storyboards: Created using Figma and StoryTribe to visually represent user scenarios and interaction with the proposed solution, linking them directly to the personas.

    • Job Stories: Employed to contextualize user problems by focusing on situation, motivation, and expected outcome ("When... I want to... So I can...").

    Iterated primarily with Develop Stage:

    • "How Might We" (HMW) Questions: Used to transform broad problem statements into actionable, creative solution tasks, serving as a bridge to the ideation stage.

    • MoSCoW Model: Utilized to prioritize features (Must-have, Should-have, etc.) based on the HMW solutions and research outcomes, aligning with the project's scope.

    • User Flows: Developed visual representations of complex processes (e.g., onboarding, recording exercise) to identify key screens and optimize user interaction.

    • Task Flows: Used to define specific, goal-oriented tasks for user evaluation, ensuring that the limited project scope allowed for focused testing of the solution's main features.

    • Crazy Eights: Brainstormed page layouts and navigation to ensure efficient communication of features.

    • Paper Prototyping: Sketched initial layouts and used an informal MoSCoW model for page-specific feature prioritization.

    • Low-Fidelity Wireframing: Visualized layout and navigation early to identify design issues and inform the high-fidelity design.

    • High-Fidelity Prototyping (Figma): Built the final proof-of-concept.

    • User/Task Flows: Continuously iterated flows to optimize the user journey, define necessary screens, and ensure consistency and standards across complex tasks.

    • Jakob's 10 Usability Heuristics: Used as core design guidelines to inform all UX decisions (e.g., Consistency, User Control, Match Between System and Real World).

    • Gestalt Principles (Chunking/Proximity): Employed to organize data (e.g., training, game and workout stats) and visual elements for improved comprehension and efficiency of use.

    • Usability Testing: Practical evaluation using the high-fidelity prototype and detailed Task Sheets (based on task flows) to observe user interactions and test functionality.

    • System Usability Scale (SUS): A quantitative survey used to provide a clear score measuring the solution's perceived ease-of-use; ideal for use with non-expert users.

    • Pre-Post Tests: Quantitative surveys administered before and after using the prototype to measure the solution's impact on player attitude towards using and perceived usefulness, based on the Technology Acceptance Model (TAM).

    • Octalysis Analysis: Users were first given a basic explanation of the evaluation model. They then ranked features specific to their core drive before rating the overall effect of the core drive on their motivation to engage with the application and training routines.

    • Semi-Structured Interviews: Qualitative data collection conducted after testing, utilizing open-ended questions modeled on the TAM. The interviews were then transcribed and Thematic Analysis conducted.

    • Data Analysis: Due to time constraints and the smaller sample size, Excel was used to visualize and analyze the results of this survey.

    • Final Conceptualization: The evaluation results were converged with the findings with the exploratory TAM and exploratory Octalysis Analysis, for use in discussing the design success, findings, and informing future design decisions.

  • The comprehensive evaluation confirmed the platform's ability to address both primary project purposes: assisting player development and improving talent visibility.

    • Player Development & Support: Qualitative feedback strongly supported the design's potential to improve player consistency and accountability in their training and workout routines. Quantitative data (SUS and Pre-Post TAM) confirmed high perceived ease-of-use and a positive shift in player attitude towards using the self-reported tracking solution to manage their development.

    • Addressing the Core Problem (Visibility): The platform was recognized by players as providing a fairer, accessible opportunity to showcase commitment and potential to coaches and scouts. The findings demonstrate that a low-cost, socially-driven design can effectively help level the playing field for talented athletes regardless of their educational background or location.

    • Scope of Solution: The project was defined as a proof-of-concept design, meaning the developed solution was a high-fidelity prototype (not a fully functional application) and only core features necessary for evaluation were implemented.

    • Limited Evaluation Sample: Due to time and resource constraints, the study utilized a small sample size for evaluation, which limits the validity of the quantitative and qualitative findings. However, findings matched with that of the exploratory study showing the results to be relevant.

    • Non-Expert Evaluation: The usability testing did not include formal heuristic evaluations by expert UX designers, relying instead on non-expert user feedback, which may overlook some technical usability issues.

    • Focus Exclusions: Due to time and scope, key considerations such as full accessibility implementation and detailed privacy options were not prioritized in the design, though they would be necessary for a live product.

Discover

Problem Validation and Insight Gathering using primary and secondary research.

Discover

The discover stage utilized several methods (covered in the project summary). Insights were gathered using secondary research, a quantitative and qualitative online survey and data analysis in RStudio. With initial findings placed into simple empathy maps to allow for earlier iteration with the define stage.

Discover Results

Exploratory Octalysis Analysis

Conceptualized TAM Themes

The Exploratory Octalysis Analysis focused on assessing the motivational potential of proposed platform features. The results:

  • Identified Key Motivators: Determined which of the 8 Octalysis Core Drives were most relevant to the target rugby players' engagement (e.g., Accomplishment, Social Influence, Epic Meaning).

  • Core Drive Alignment: Directly guided the design process by mapping specific proposed platform features (e.g., streaks, leaderboards, club community feeds) to these identified core drives.

  • Informing Design Decisions: Established a clear rationale for the inclusion and prioritization of features in the MoSCoW model, ensuring the platform was designed to maximize user motivation and sustained engagement with training and performance tracking.

The thematic analysis of the Exploratory survey identified key themes surrounding the following:

  1. Necessity for Visibility: A strong belief, particularly among state-educated players, that a digital platform could be effective in gaining visibility and mitigating systemic disadvantages in talent identification.

  2. Focus on Performance Tracking Utility: Players reported that the greatest Perceived Usefulness lay in the platform's ability to facilitate consistent self-reporting of training habits and build personal accountability for their performance routines.

  3. Social and Community Engagement: Confirmation of player willingness to engage with the social elements of the platform (e.g., sharing achievements, connecting with club communities), validating the social-centric design approach. However, independently educated players were less willing to use the application in a performance sharing and social context.

Discover Key Takeaways

Visibility and Networking

The social component allows players to showcase achievements. Allowing players to connect with the wider rugby community, including potential coaches and scouts.

Accountability is Key

Players raised holding themselves accountable as a key factor in engagement with the application, representing ownership.

Accessible Tracking

Players outwith high-level development circles may not have access to expensive tracking software or approved wearables.

Market Gap

A clear gap exists for the proposed solution. Existing tools are structurally or financially inaccessible to every player or team

General Acceptance

Players generally accepted the proposed solution. However, State Educated Players were more willing to adopt the application.

Focus on Flexible Tracking

Players were inconsistent in naming Key Performance Indicators, as such the user must have control over their metrics tracked.

Systemic Limitations

Research indicates location and education background can have an significant impact on players access to development.

Define

Synthesizing insights from discover stage into actionable design decisions.

Define Process

  • To build empathy and visualize the diverse needs of the target audience. Focusing on representing players from varying backgrounds, while also representing stakeholder (coach) concerns. This helps to begin to understand the context of use.

    The personas developed are described as qualitative personas, based on small sample size research and are beneficial in gathering necessary data in parallel with other work

  • To establish the Context of Use and define the underlying Motivation behind a player's actions. These aligned with the developed personas and gave context to their needs, motivations and pain-points.

  • Job Stories were an effective tool for contextualizing user problems by focusing on the situational motivation for using the product. They follow the structure: "When… (Situation) … I want to … (Motivation) … So I can … (Expected Outcome)." This method provided valuable insight into the functional and emotional context of the players' needs.

    This also began to develop an understanding of the specific functions the application may need to address.

  • How might we questions were employed to focus the problem on actionable solutions. Beginning to inform specific tasks and design decisions that satisfy the end users goals, needs and motivations. Bridging the gap between the broader problem statement and solutions.

  • The MoSCoW model was used as a feature prioritization technique to categorize the solutions derived from the "How Might We" (HMW) questions into four categories: Must-have, Should-have, Could-have, and Won't-have.

    It was chosen primarily because it offers a straightforward method to define feature priority without requiring a complex prioritization dataset or further user input. This was essential given the limited scope of the project and the need for a clear, rapid definition of the features necessary for the proof-of-concept design.

  • User flows were chosen because they served as a vital visual representation of the steps required to complete complex tasks (such as onboarding and recording exercise data). By outlining these processes, the flows allowed for the optimization of user interaction, helped to efficiently identify key screens necessary for the high-fidelity prototype, and ensured robust navigational consistency that was continually iterated upon during the design process.

  • Task flows were chosen specifically to facilitate the project's evaluation within its limited scope. They were used to create context-specific, goal-oriented scenarios for the user testing. By defining the exact step-by-step path required to complete a single, critical goal (e.g., adding a session), the task flows efficiently ensured that evaluators focused exclusively on testing the key features and the necessary navigational requirements of the proof-of-concept design.

Personas

Storyboards

  • Angus Macleod Storyboard

Job Stories

How Might We Questions

MoSCoW Model

  • The MoSCoW model was utilized for feature prioritization based directly on feedback from the exploratory survey to ensure the design addressed the most critical user needs within the project's constraints. Must-Have features (Onboarding, Home Page/Feed, Profile Page, Progress Page, Club Page) were defined as core pages and functions essential for the proof-of-concept to function, serving as the non-negotiable functional requirements necessary to build the application skeleton and facilitate evaluation. Should-Have features (flexible logging, goal tracking, feedback) were prioritized because they aligned with the strong preference toward performance tracking by all player groups, emphasizing the Empowerment, Accomplishment, and Epic Meaning core drivers identified in the exploratory Octalysis study. Could-Have features (e.g., social leaderboards, flexible showcase) focused on social elements, which, while important, were given a lower priority due to mixed opinions (as they might not be seen as novel compared to general social applications) and because representative spaces for these elements would be present in the design anyway. Won't-Have items were relegated to maintain focus on the core evaluation scope.

Octalysis Feature Alignment

Aligned features with representative core drive in Octalysis for further evaluation.

  • Black - prototyped features

  • Amber - evidenced but not fully implemented

  • Red - Not efficiently evidenced within scope of project

User/ Task Flows

User Flows and Task Flows were instrumental in creating a logical design blueprint. They were chosen to visually map the steps for complex processes (like onboarding or logging a workout), ensuring navigational consistency and optimizing user efficiency. Task Flows were specifically used to define the goal-oriented scenarios required for the focused evaluation of the proof-of-concept.

Develop

Onboarding Flow

  • Log In Page

  • Sign Up Page

  • Welcome Page

    Following “Sign up with Facebook”

  • Personal Detail Input

    Following input of details; height, age and weight collected as important factors to development discovered through research. Along with main position.

  • Position Selector

    Players may play multiple positions. Reflecting real life Rugby structure, users can quickly and simply select the all positions they are able to play.

  • Club Search Page

  • Club Selected

    Following searching for club

  • Loading Club Details

  • Team Selection Page

    Clubs may have multiple teams, player selects the main team that they play for.

  • Privacy Preferences

    Due to sensetive details such as Age, Weight, Height and Club being collected. Users are shown privacy measures would be in place.

  • Choose Workout Plans

    Reccomendations based on league and position, with option to customize these or create your own from scratch. Pop-over with reccomended exercises available.

  • Chosen Workout Plan

  • Exercise Selector

    Pre-selected reccomended exercises displayed, for addition into regular workout routines. Option to search, sort or filter exercises.

  • Exercises Searched

    Users simply tap to add or remove exercises. Target muscles, skill or area of fitness are clearly displayed and able to be filtered.

  • Engagement Goal Setting

    Due to scope and exploratory research goal setting was focused on engagement. Users receive reccomended engagement goals, or can set their own with feedback on what level their target engagement would reflect.

  • Onboarding Complete

The homepage was designed to satisfy Octalysis’s core drives of motivation from when the user first opens the application. With motivation for exercise being primarily intrinsically driven, it was decided to focus on the core drives that are associated with core needs within Self-Determination Theory (Accomplishment, Empowerment and Social Influence). Exploratory and Secondary research indicated Rugby players hold a strong sense of community, highlighting the importance of emphasising “purpose” or “epic meaning” through features such as recent league results.

Homepage

Add Training Session Flow

  • Add a Training Session

  • Use Club Plan

  • Log Exercises

  • Input Exercise Details

  • Logged Exercises

  • PB Evidence Checker

  • Included Witness Referral

  • Confirmation of Posts

Add a Workout Flow

  • Add a Workout Session

  • Add Exercises

  • Exercises Logged

  • Workout Complete Message

  • PB Message

  • Workout Post Confirmation

Check Back Soon!

This page is a Work In Progress