Methodology

Introduction to methodology

To ensure that the project is a success, a carefully considered, methodical approach was taken to all tasks and stages. Where applicable, proven, industry-standard methodologies (such as the Waterfall methodology) were used to increase the viability of the project further. Before development work could begin, detailed primary and secondary research was required to ensure that the project was needed and suitable for the people who needed it.
First, it was important to conduct primary research into the market segment, competitors operating in this segment and the specific requirements of the target users. Once this research had been completed and requirements were clearly defined, secondary research in the form of a thematic literature review could be completed.

Primary research

The primary research completed for this project primarily focused around analysing and evaluating similar products to identify a variety of facts (such as price), their successes and their failures. This process included an analysis of the company’s website, brochures and other promotional materials, as well as reading reviews and user feedback of the product itself to construct a true picture rather than just relying on biased promotional material. The findings of this competitor analysis are shown on the following page in Table 2.

Based on this analysis of multiple competitors, some commonality was identified, as shown in Table 3:

Once this competitor analysis had been completed, an initial set of user requirements were constructed based upon the commonality and successes of competitors’ products (which clearly show the features that are needed by users) and what was needed to address the shortfalls of these other solutions. This list was then developed further through secondary research, as per Section 2, and then it was finally shared with a subset of the target user base for feedback and refinement, as shown in Table 5, Section 3.10, to provide the most accurate and appropriate list of user requirements possible.

Secondary Research

Secondary research for this project was primarily completed via a comprehensive literature review whereby existing research was analysed, compared and learned from. The findings from this research have been detailed in Section 2.

Findings

When combining the results of the primary and secondary research, a number of key points stood out where the primary research was supported by the findings from the secondary research. One such example was the impact that the cost of a Sports Management system has on its usefulness and success with a grassroots sports team. As suggested by Burgess et al. (2021), it is typically the ‘upper-level’ and more well-resourced clubs that have higher adoption levels of websites, social media and more sophisticated internet usage – this is supported by the primary research, which found that many sports management systems cost well over £500 per year, plus other fees.

Similarly, where Mills (2023) and Burgess et al. (2021) suggest that a lack of technical skills amongst grassroots sports staff may contribute to low levels of technological adoption, the primary research found common feedback of competitors’ systems included poorly designed and confusing UI/UX, which will only contribute to this problem.

Both of these points underscored the importance of ensuring that My SportApp is both affordable and simple to use – points which were constantly used to inform design and functional decisions.

Software development methodology

Secondary research into software development methodologies helped to identify the Waterfall methodology as the most appropriate for this project. When compared to Rapid Application Development, the Prototyping Methodology and the Iterative and Incremental Methodology, while the Waterfall methodology has a number of drawbacks for many modern projects, it was chosen as the most suitable method for this specific project for a number of reasons.

Firstly, the project required comprehensive documentation at all stages – the Waterfall methodology emphasises this, and the structured, linear approach complements this. Moreover, this methodology lends itself well to less-experienced project teams, unlike other methodologies – something that was imperative for this project.

Considering the short timeframe of only nine months, establishing well-defined requirements and objectives from the beginning was imperative in ensuring the project did not run over. As such, the Waterfall methodology stands out as the best fit, providing a structured workflow with clear objectives and comprehensive documentation, all of which fulfil the needs of the My SportApp project exactly.

Another advantage of the Waterfall methodology was that a portion of the planning had already been completed as part of the project definition and Gantt chart. As shown in Figure 4, when viewed as a Gantt chart, the list of project tasks forms a waterfall shape, clearly showing the process that must be followed for each outcome, and the overall completion of the project. It should be noted that the deadlines for each task on the Gantt chart and project plan were designed to provide some flexibility of movement should dates become impractical as the project progressed (for example, due to tasks/assignments in other modules).

Design Methodology

Once the aims, objectives and user requirements had been defined through primary and secondary research, the design process could begin.
The design methodology selected for My SportApp was User Centred Design (UCD). UCD consists of an iterative process that involves users (placing them at the centre) of the process, right from the beginning. According to (Dusch & Currier, 2023), the four stages of UCD are:

1. Understand: The needs of the user.
2. Specify: A specific problem.
3. Design: A solution to the problem.
4. Evaluate: The designed solution to access successes and implement feedback.

These four stages align closely with the overarching stages of the project, which made it a suitable design methodology for My SportApp. Traditionally, as this is an iterative process, the four stages would be repeated indefinitely until the users/client are 100% happy with the proposed solution. However, due to timescale restrictions on this project, this was not possible – instead, initial discussions around design were held, with users then being able to provide feedback on the initial design prototypes.

structural design

First, it was important to identify a structure for the system in the form of a sitemap, as shown in Section 3.12. The root levels of this sitemap were derived directly from the key user requirements which are covered in Section 3.10:

• Store and manage information on the club, its members, teams and staff.
• Communicate with members via email.
• Communicate via members via SMS.
• Communicate via members via push notification.
• Collect recurring membership fees via online payment methods.
• Collect one-off payments via online payment methods.

By designing the sitemap around the user requirements, it became clear to users how their requirements had been addressed. Similarly, it made it simple for them to use the system (addressing another requirement) when the menu explicitly makes reference to the tasks that they want to complete.

wireframing

Wireframing was a key phase of the design process and involved creating an initial visual representation of a page(s)’s structure, concentrating on the layout, available functionality and intended interactions (Frantz, 2013). This practice proved useful in helping to optimise the efficiency of the design process as it allowed for a significant amount of time to be saved compared to developing these initial designs in HTML/CSS – instead, the wireframes could be designed on paper or utilise specialised design applications. This time-saving strategy then facilitated the opportunity for meetings with a subset of users for feedback on the designs before development began.

Industry standards state that wireframes should omit aesthetic details such as colour and images (Nulab, 2021). This deliberate exclusion helped to ensure that any feedback received on the designs was solely focused on their functionality and ease of understanding, compared to simply subjective opinions on the stylistic aspects.

Testing and evaluation methodology

The effective evaluation and testing of any software or web development project is critical to the overall success of the project – poor testing consistently leads to failure (Stout, 2001). There are a variety of testing techniques that are commonly used, often in combination with each other to effectively test a website/app. There has been a trend towards remote or automated testing (Larsen et al., 2021), which can help to increase the volume of responses (Francis, 2019), but equally can reduce the quality of results. As such, all testing for My SportApp was completed in person.

Unit Testing

Unit Testing was a fundamental part of the testing and evaluation process and was the only one which took part in the development stage. Where all other tests were completed once the development stage had been completed, Unit Testing involved systematically testing each component and page as the development of said component/page progressed to verify their functionality and correct working order (Moradov, 2023).

This approach was crucial to identifying and rectifying any errors or oversights early in the development cycle rather than at the end. This greatly reduced the likelihood of releasing a buggy webapp. Furthermore, it meant that time was not spent troubleshooting other components/pages that rely on previously developed, unvalidated code. By thoroughly testing each component and page, there is greater confidence in the platform’s stability.

Task Completion Time

Task Completion Time (TCT) testing is specific to website/application testing (OKRify, 2023) and is used as a measure of efficiency (Wills & Hurley, 2012) – the lower the time, the better the user experience (Ghazaryan, 2015).

TCTs were a useful indication of how easy My SportApp is to use – how intuitively it is designed.

It was important that the tasks that were assigned to users were representative of tasks that a real user would complete using the system; otherwise, the results would be irrelevant. As such, a comprehensive list of tests was constructed, as shown in Appendix 3: Testing Task List.
The results of the TCT observations are discussed in Section 5.3.

Error Rate Observations

Error Rate Observations (EROs) also aim to measure the efficiency of the design of the website. Rather than finding errors within the website, as the name may suggest, it instead records how many errors a user makes when attempting to complete a given task (Salkind, 2010) – the lower the number of errors, the more intuitive and well-designed the website is (Hrzenjak, 2022).

For My SportApp, the ERO testing recorded how many false clicks a user made in their attempt to complete a given task. Alongside Task Completion Time observations, this data helped to identify deficiencies in the structure and/or design of My SportApp.

These tests were conducted simultaneously with Task Completion Time observations to reduce the time taken to complete all required testing with each user, increasing the total number of users who could be sampled in a given timeframe.

The results of the EROs are discussed in Section 5.3.

System Usability Scale

System Usability Scale (SUS) testing is a tried and tested method that has been in use for over 30 years in various industries and is often referred to as an ‘industry standard’ testing methodology (Klug, 2017). It serves to gain an understanding of the human perception towards the system (Lewis, 2018).

In order to complete SUS Observations, it was important to identify suitable participants. For all testing related to My SportApp, participants were selected both from the target userbase and from others to ensure that people with no existing context/experience with similar systems still react positively.

The calculation of the final SUS score required some data manipulation (Betteridge, 2023). Once calculated, plotting these scores on a chart created a clear visual representation of how well-received My SportApp was, both by target users and otherwise.

The results of the SUS tests are discussed in Section 5.3.

Accessibility Testing

Accessibility testing is another key type of testing that was employed. In many countries, accessibility is mandated by legislation, which in turn requires usability testing (Minister for the Cabinet Office, 2018). It is possible to manually check for accessibility compliance, but many web developers utilise automated testing tools such as ‘WAVE’ and ‘SiteImprove’ (Alsaeedi, 2020) to speed up the process. While these tools are effective, Vigo et al. (2013) argues that any over-reliance on automated testing often still leads to time needing to be spent conducting further tests that require expert evaluation.

In the case of My SportApp, any issues that were detected by the automated tools (such as those mentioned above) that could be addressed within the scope and timeframe afforded by the project were actioned accordingly. Due to the limited project resources and timeframe, testing that requires expert evaluation, as suggested by Vigo et al. (2013), unfortunately, could not be completed.

The results of the accessibility tests are discussed in Section 5.3.

Software and Hardware Requirements

My SportApp is a web-based application, so a web server and various web technologies is required. As shown in Figure 5, My SportApp is hosted on a single web server (svr911.hstgr.io) and utilises PHP, HTML, JavaScript, CSS and MySQL on this webserver, which integrates with various APIs, as shown in Figure 5.

HTML and CSS are used to define the structure, layout and styling of the pages that are displayed to the user. JavaScript, as a client-side scripting language (Mendez, 2014), is used to enhance the HTML and CSS and provide interactive functionality. Finally, PHP, as a server-side scripting language (Hansen & Lengstorf, 2014), is used to allow the user to interact with the database through the HTML web pages, either viewing existing data or inserting new data into the database.

Data Requirements

The internal data requirements for My SportApp are driven by a MySQL database. This database holds all of the data for My SportApp and is broken down into multiple tables. Some tables are defined as ‘global’ tables (those which are accessed by all users), as shown in Figure 4.

Others are defined as ‘organisation’ tables (those which are accessed only by users of that organisation), as shown in Figure 4 – these tables are all prefixed with the organisation’s ID (for example, “MyTestOrg1678393287_member’). This segmentation of data is done both for speed (Karlsson, 2021) and security (Satori, 2023).

While global tables were set up once manually during the development process, the organisation tables are automatically provisioned during the signup process for a new organisation – if this were not done, new organisations would not be able to sign up to the system automatically, instead needing to wait for the developer to manually create their tables – this would be a time-consuming task and a barrier to entry for these organisations.

To facilitate more advanced functions of My SportApp, external data services are used for Monitoring, Payments, Email and SMS – these are Hetrix, Stripe, ZeptoMail and The SMS Works, respectively.
Hetrix is a monitoring platform used to provide data on the reliability/uptime of My SportApp and interfaces with the webapp through ping and HTTP status monitoring.

Stripe is a two-way API in which My SportApp creates new payments via the Stripe API, with Stripe then returning information about these payments via a webhook. Stripe handles all payments and operates via a two-way connection with the Stripe API. The web server makes POST requests to the Stripe API to create new products, prices and payment links. Stripe’s servers then inform the My SportApp webserver when payments are made by sending POST requests to a defined webhook on the server. This webhook processes the incoming data and reacts accordingly (such as writing it to the database).

ZeptoMail and The SMS Works are one-way APIs with message information being passed to both platforms via their own APIs. No information is returned from these platforms to My SportApp at this time.

Figure 6 shows an overview of the architecture of My SportApp.

Requirements specification and analysis

User requirements for My SportApp were informed based upon primary and secondary research, as detailed in section 3, as well as existing knowledge of the problem being addressed.

A key method of gathering user requirements was the User Requirements Gathering questionnaire that was circulated amongst volunteers, members and parents/carers of members of local sports teams. The form utilised branching to allow for more specific questioning based on previous answers (such as the participant characteristics). Some key findings from this questionnaire can be seen in the following figures. Refer to Appendix 2: User Requirements Gathering Questionnaire for a copy of the questionnaire.

Figure 7 shows a balance between staff and parents/carers, with a minority of members. This should provide an even spread of responses.

Figure 8 shows an overwhelming majority of submissions are from members of football clubs, with rugby, tennis and golf having minor submissions.

Figure 9 supports the statement that sports clubs do not effectively utilise technology to improve their operations, with only two staff participants having used a sports management app/website before.

Figure 10, responses from members and parents/carers of members, makes it clear which features are most important and supports initial presumptions.

Similarly, Figure 11 shows staff responses to the same question. While there are additional staff-only features, it is interesting to see how communication preferences and payment preferences align between all stakeholders.

Figure 12 helps gain insight into the types of devices that My SportApp would be used on. Looking at the data behind this question, there is clear preference for desktop/laptop and tablets amongst staff, and smartphones amongst members and parents/carers of members. This makes sense as staff will likely be performing more detailed operations that benefit from a larger screen, compared to members or parents/carers of members who will only be concerned with a single entity.

Other key takeaways include:
• Common issues with other systems are the price and parent engagement with apps.
• The average response for cost is sub £1 per member.

Based on all of these sources, the following list of requirements was constructed:

Use Case Diagram

Figure 13 shows a high-level use case diagram of the path a user may take when using My SportApp. A significantly more detailed use case diagram can be found in Appendix 2: Detailed Use Case Diagram.

Sitemap

My SportApp operates a simplistic sitemap, with a repeating substructure to ensure that the system is as intuitive to use as possible. The sitemap that is visible to the user can be seen in Figure 14, though this sitemap excludes any pages that a user is redirected to as part of a process flow, such as pages that are not directly accessible.

Figure 15 shows the complete directory and file structure of My SportApp, highlighting the complexity of the system in the background, most of which is effectively hidden from the user in the interest of simplicity.

User Interface Designs

As discussed in Section 3.6.2, as part of the design process, wireframes were produced early on to help visualise and gain feedback on the system before development began. The following figures and accompanying discussion cover the main UI designs for My SportApp. All pages use a consistent UI to help the user get used to the system. For complete wireframes of all pages, refer to Appendix 2: Wireframes.

Figure 17 shows the login/sign-up page wireframe design. Both the login and signup pages follow a consistent, clean and simple UI. The only difference between these two pages is that sign-up has a next button to load more questions in the white box, whereas login has a submit button. This page adopts a simple design with only a minimal amount of information, adhering to the requirement for a simple system. This design can be easily adapted to a mobile-friendly layout, too, by only displaying the white box on smaller displays.

Figure 18 shows the Home/Welcome dashboard (the first screen a user sees after logging in). As with all pages, this page adopts a simple design, placing the key information front and centre for the user to see and interact with. The clearly organised menu bar is also introduced to the user for the first time, giving them access to all of the ‘modules’ within My SportApp.

Continuing this consistent UI design, Figure 19 shows the ‘entity’ search page (with ‘entity’ being either member/team/staff). The UI for all search pages is identical, with only the results changing. This helps the user to get used to My SportApp much quicker, and reduces the complexity of the system greatly. Not only is this UI present in dedicated search pages, it can also be loaded as a module within other pages (such as displaying members of the team on a team’s page). Again, this familiarity and consistency is designed to make the system as simple to use as possible.