The Scorecard : UX case study part 1

The Scorecard is a personal project to design a hybrid news/sports app based around a set of brand criteria. This blog post is part of an in-development series of blogs that will later form the full case study.

UX is an ever-evolving discipline. It moves and changes with the times. This requires designers to keep working on their process, researching new trends and keeping skills fresh.

After completing a hotel booking UX project, I had a bit of time to start some of my own ideas - The Scorecard is one of those ideas, and this blog is part 1 of a series looking into the process of conceiving, researching and designing an authoritative news mobile app based around a passion of mine, cricket.

This post represents part 1, which outlines the project scoping, research and lo-fidelity design.

Part 2, outlining the design system and strucutre of the project can be found here

The 'client'

Okay, so the 'client' doesn't really exist, but I wanted to work around some parameters, so I setup a simple set of guidelines that outlines the client, the brand and the goals of the product. To do this I came up with 3 simple statements which I used to guide the research and design process.

The three guiding statements are : 1. On Authority & Trust

"We deliver the definitive record of the day by combining rigorous journalistic integrity with uncompromisingly accurate data visualisation."

2. On Design & Heritage

"Our interface honors the structured clarity of traditional broadsheet journalism, utilising a minimalist, grid-based aesthetic that prioritises content over decoration."

3. On the User Experience

"We provide a focused, high-contrast reading environment that eliminates digital noise, allowing users to navigate complex global events with absolute clarity."

Research

I began by analysing the three guiding statements provided by the 'client' and researching how these translate into existing UI patterns. My research focused on a blend of traditional news outlets and specialised sports-focused apps.

The research showed a clear difference between different requirements of the app. News reporting and sports reporting are on the surface similar but need to provide information in different ways.

News Coverage: Traditionally text-heavy, relying on established hierarchy and typography to convey authority.

Sports Reporting: While still text-heavy, it relies on dense, data-driven interfaces to tell the story of a match through live statistics and infographics.

I highlighted a combination of traditional, authoritative news sources as well as providers of trusted sports coverage

Finding 1: The News Experience (Authority & Heritage)

The news side of the app must reflect the heritage of broadsheet reporting. Because news apps have been a staple of the mobile ecosystem since the beginning, users have very specific expectations.

Strategy: Utilise established UX patterns like lead story features, secondary story cards, and significant white space.

Goal: By working with these existing mental models, I can ensure the interface feels "authoritative" without requiring extensive new user training.

News apps have been a staple of the app ecosystems since the beginning of (smartphone) time. They are built on the background of broadsheet heritage. Users know what to expect and there is a strong mental model built up over years of usage.

Finding 2: The Stats Experience (Clarity & Complexity)

Presenting cricket scorecards and results is a significantly different challenge. This area relies on tables, infographics, and acronyms that often require specialised knowledge.

The Problem: Even as a cricket fan, I found that many existing sports apps have layouts that are difficult to decipher.

The Opportunity: To meet the client's goal of "absolute clarity," I need to eliminate digital noise and simplify these dense statistical views, ensuring that the high-contrast environment makes the data digestible at a glance.

Synthesis

By addressing these two areas separately, I can ensure the final product delivers on the primary client goal: combining rigorous journalistic integrity with uncompromisingly accurate data visualisation.

Defining the scope

As with any project, you need to define the scope. Even for self-directed projects (arguably even more so) it's important to do this. I wanted to define what problems I was going to solve, what screens I was going to focus on. I had 'client' goals, but what were 'my' goals on this project?

I wanted to keep it simple and achievable. I wanted a case study project that showcased my UX skills and demonstrated my process. I broke this down into 3 areas.

1. Develop and use a simple design system, showcasing my ability to approach UX design using a process driven approach.

2. Design primary and secondary screens for each core part of the app, being:

   1. The main home page for news, showcasing all different types of news content (news-primary)

   2. A page for a specific news story (news-secondary)

   3. A page that showcases presentation of dense statistical information for a cricket match (stats-primary)

   4. A page for a specific player (stats-secondary)

3. Strong focus on accessibility, including light and dark mode variations of the app.

   
   

I defined the values, goals and objectives of the project on to a series of notes. These were then combined in to matching categories and the overall goals and objectives of the project were established.

Sketching

Now that I've researched the client requirements and outliend the scope of the project, I was able to move on to sketching. I took the main areas of the app that were outlines as priorities and sketched out the layouts of those screens.

As with any project, the sketches are the first point to which theories become concepts. Through this stage I like to come up with a number of options for how to present and organise information. Sketches are quick to do, quick to analyse and quick to throw away - despite their apparent flimsiness, I feel like the sketching phase is incredibly important. I never just jump straight in to figma - for me that just leads to pixel pushing and fine tuning when it's not necessary at this stage.

I've mentioned it before, but I love to make paper prototypes during this stage, a sort of paper component library of the elements that are important.

An example of a paper prototyping component library that I sometimes use during the sketching stage to quickly try out new ideas and layouts without needing to redraw everything each time.

Lo-fi prototyping

Sketching has provided me with the groundwork from which to being lo-fi prototyping. The goal here is two fold. Firstly, it's to get the paper sketches in to the digital world, allowing me to start understanding the technical requirements of the data. Secondly, it's the first stage that I can begin to see how the designs and layouts hold up when viewed on a device through the device simulator.

An example of the different screen elements needed for the news home page

I normally begin by laying out the required elements of a screen as separate auto-layout frames. I already have a good idea of what these are from the sketches - doing these in Figma allows me to understand their technical and layout requirements and an idea of the space required. It's also the first stage in beginning to build an understanding of what will later become the component system - but at this stage they are just auto-layout groups that can be easily changed and adjusted for the lo-fi prototypes.

An overview of some of the screens, with their individual elements laid out alongside.

Once I've developed the required screens I'll then build the prototype screens with the required functionality and interactivity that I'd need from a prototype. As I'm developing a mobile application I want to try this on the device. Simulators in Figma are super useful, but you really need to get them on a device and really try to interact with them exactly as the user would. Scrolling with a trackpad is no substitute for scrolling with your thumbs and fingers on a phone.

The lo-fi protoype on iPhone. Here I can test the usability, readability and layout on an actual device. I can also start to understand the importance and requirements for sticky elements like the pinned score and navigation bar.

Continue to part 2

Now that the research, sketching and lo-fi protoyping is completed, I can move on to the next stage of the project. Here I'll start auditing the required elements, defining the interactions and developing the design system. You can start reading part 2 here