Case study: MyParkrun app
As a UX designer and an avid runner, I took on a personal challenge to enhance the digital experience of Parkrun events.
Parkrun is an organised series of free weekly sporting events taking place on a Saturday morning in more than 2,000 locations around the world. The grassroots organisation brings together runners and walkers of all abilities and relies on volunteers for most of its operations. Parkrun does a brilliant job of hosting fun, safe, and inclusive running events and strengthening local communities, but its digital presence lacks structure and unity.
As a UX designer and an avid runner, I saw an opportunity for an app that enhances the event experience as well as allowing anyone enjoy Parkrun anywhere anytime. I called the app MyParkrun.
For a project of this scale, I began the work by defining personal objectives and decided to focus my efforts on the following three areas that I found most interesting and challenging:
- Functionality — what tasks should the app support?
- Structure — how should these tasks be grouped?
- UI — what are the most effective ways of presenting complex interactive data on a small screen?
I started the design process with a wishlist. As a Parkrun regular, I created a longlist based on a personal experience, then asked fellow runners to complete this survey to understand which tasks are the most important. Here the results in order of priority:
- Find a Parkrun near you or another location
- View your latest results and result history
- Get your barcode scanned to register a run
- Register as a runner and receive a unique number and barcode that allows you to view your results after the run
- View and subscribe to updates from selected Parkruns. This includes news, volunteering opportunities and other highlights that currently appear on each event’s social media pages.
- View latest results and performance history of other runners
- Subscribe to updates from other runners
- Meet and connect with runners
- View and analyse your performance over time
- Compare your performance to selected runners
- Virtually compete with runners at different Parkrun events. This should include different categories, like fastest time, most runs, biggest progress, highest age grading score etc.
- View information about each Parkrun, including the course, parking and other facilities nearby
- Read other running-related news and stories
- Share other running-related news and stories
- Receive personalised training tips
- Purchase Parkrun merchandise
You may have already spotted a few clear themes emerging from this little research exercise. They formed the core of the information architecture (IA), with different sub-tasks brunching off each category. Let’s have a look.
I like to think of IA as a project backbone that gives it stability and integrity. If you get it right, the rest of the pieces will often seamlessly fall into place, but major mistakes at this stage will cripple the entire project and no fancy UI will cover up its flaws.
Most of the tasks listed above fall into one of the three categories:
- Events: this encompasses information and updates about Parkruns with an opportunity to find and follow them.
- Personal account: this is the information about the app’s user, their result history, performance and other updates.
- Community: this holds the information about other runners, their result history and updates.
It was equally important to decide what functionality to leave out. This decision was mainly based on the functionality definition exercise, and I decided to leave out:
- Shop: buying Parkrun merchandise got rated as the lowest priority task by most users. I suspect it has a very different weighting for the project stakeholders and, in fact, might be paying for the existence of this very app, but I’m taking a user-centric approach here and leaving it out.
- PT: while many parkrunners have used one or more training plans, it’s a saturated market with apps like Strava, Nike Plus, Couch to 5k and many others specialising in personalised training plans. I decided to leave it out of the MVP as well.
I was in-two minds about the social aspect of the app. It’s also an extremely saturated market with complicated onboarding process that relies on a critical mass for its success — no one want to be the first user of social media platform and talk to an empty room. That said, Parkrun already has a large dedicated following, so a space for them to connect, share, collaborate and compete seemed essential for a true Parkrun experience.
Wireframes and wireflows
Once the overall structure and key functionality of each screen have been defined, I created a set of wireframes to mirror the IA. Following my usual wireframing process, I started with rough pen and paper sketches, then moved to high-fidelity wireframes. These in turn serve as building block for the wireflows mapped against the key user stories.
The app’s interface will have five main areas that can be accessed through the bottom navigation:
- Account: all information related to the user, including their result history, performance analysis and social posts.
- Parkruns: all information about the events, including a search, and result history and social posts from the event you follow.
- Barcode: a stand-alone page that allows you to quickly and easily get your barcode scanned at the end of a run.
- Community: all information about other users, including a search, and results and social posts from the users you follow.
- Settings: account details, notification preferences, notes on medical conditions, emergency contacts etc.
As you can see, result history and social posts appear in multiple areas of the interface depending on whom they belong to — the user, a Parkrun event or another runner. Scroll down to the UI section to see the layout for each of the screens.
Parkrun has a strong visual identity successfully used both online and offline. Their colour palette, full of natural hues evoking autumn foliage, says “park” but, in my opinion, forgets to add “running”. Sport is traditionally represented with vibrant colours loaded with energy. The muted earthy tones of the current brand palette fall short at inspiring one to tie up their laces and run.
Updating the brand palette, I kept the same three core colours — orange, green and inky blue — but chose the more vibrant variation of each. I removed some muddy browns and yellows and replaced them with a range of lighter and darker tones derived from the core palette. I also added a neutral range of greys with a slight tint of purple to have all the tools needed for creating a clean and accessible UI design.
Parkrun website uses Open Sans — a humanist sans-serif typeface from Google. Its rounded glyphs feel friendly and approachable, it rates high on accessibility and is available for free, so I saw no reason to replace it as the main font. It does, however, lack personality, making it harder to communicate content hierarchy in an information dense interface, so I paired it up with Zila Slab serif font for contrasting headings.
User Interface design
For nerds like me, one of the greatest appeals of the Parkrun events is the vast amount of data they gather and share. The run itself is only one part of the experience, as, over a post-workout protein shake, I check my phone regularly in anticipation of an email with the summary of this day’s event. If I was diligent enough to remember to bring my barcode (which won’t be an issue if you have Parkrun app!), I get my results and performance history, which I can compare to other participants across all Parkrun events filtered by gender, age and age grading! I can spend hours sifting through this goldmine of data, so making sure it’s presented in a clear, functional and accessible way was the key focus of the Parkrun app UI.
The biggest challenge for the structure of the app that came up while building the information architecture was the fact that some of the same content thematically belongs to different parts of the interface. There were two ways to structure the main navigation:
- Have separate sections for all results and all social posts and allow on-screen filtering for showing content that belongs to the app’s user vs an event or another runner they follow.
- Have separate sections for all information related to the app’s user, Parkrun events and other runners with result history and social posts appearing in each section.
As you may remember from the wireframes, I went with the latter solution, based on my gut feeling backed up by researching similar apps. My preferred approach would have been to develop both solutions and test them with real users, but resource constrains called for decisive actions. Since this is likely to be the most confusing feature of the interface, I decided to focus on it in the UI phase to illustrate how results and social posts will appear in the three different areas of the interface: