Tech/Skills

• React Native
• Product design

Summary

I wanted a flexible way to make notes on football matches, offering capability for analytical detail or quick, fun observations, easily accessible (i.e. on my phone).

Naturally, I also wanted to have a way of viewing various statistics of the matches - number of games viewed, average rating of teams, a text search to find particular things in the notes that have been made. Since the app got to a point where I could download a development build to my phone in February 2025, I've used it consistently.

This was also my first real React Native project, which was a fun learning experience.

Learnings

React Native and mobile development

With some React experience (mostly on previous personal projects featured on this site), React Native wasn't too foreign, although there was still a learning curve both for the language and for mobile development in general.

The biggest learning area was probably around navigation, with screens being a different way of thinking about navigation than I am familiar with, having mostly thought about a web-based world in the past.

Mobile product design for speed

The nature of the app - being a note-taking service that can be used live during football matches - means that it needed to be easy and quick to use. A lot of this was a case of learning by trial and error, but it was interesting to explore things like whether certain actions 'needed' a confirmation/submit action or not.

Deeper dive

This project was mainly driven by a desire for the functionality of the app for my own use, rather than being driven by either a) desire for learning b) desire for meeting a customer need. As such, it felt like one of the more 'natural' projects that I've done when using a coding language that was new to me.

I think there were two factors that made the designing feel more natural. One is that the app is pretty simple. Although there's a decent amount of functionality, that's mostly a case of different levels of complexity (like different levels of granularity of notes) rather than lots of bells and whistles. The other is that the user journeys were very familiar with me, because I had years of (off-and-on) experience of trying to take notes during football matches.

In hindsight, it helped that there was one central journey with slight variations (note-taking) that was fairly clear and another main journey that was less clear but also less important (checking stats). The clear use case gave a solid spine, while the secondary use case gave the app a fuller reason to exist. There's probably some lessons to take around app/product development in that, but I'm not sure whether that's extrapolating too much from a single example.