AFL Fantasy

Research & Discovery

Before touching a single screen, I spent time understanding the product from two angles: the user experience and the system underneath.

Design audit I catalogued every component in the product: buttons, cards, navigation patterns, form inputs, data visualisations, and documented every inconsistency. The audit revealed that roughly half of the design patterns in the product were either duplicated, inconsistently applied, or undocumented. That became the benchmark: ~50% design debt to resolve.

User research I ran usability testing sessions with existing AFL Fantasy users, focusing on the three highest-traffic flows: team selection, trade management, and live scoring. Across sessions, three consistent themes emerged:

1. Orientation: users frequently lost track of where they were in multi-step flows

2. Confidence: users hesitated before confirming trades and selections, unsure of the consequences

3. Speed: power users wanted to move faster; the UI was getting in their way

Data review Working with the product manager, I reviewed analytics across the key flows, where users dropped off, which features had low engagement relative to their prominence, and where support tickets were clustering. The scoring and trade flows stood out clearly as areas where user behaviour and design intent had misaligned.

Key Insights:

Three insights shaped everything that followed:

1. The product needed a shared language, not just a visual refresh. The inconsistency wasn't aesthetic, it was structural. A visual refresh would fix how it looked; what we needed was a systematic approach that would fix how it worked, for users and for the team building it.

2. Power users are the product's heartbeat. AFL Fantasy has a core of deeply engaged fans who return every week across a 23-round season. Design decisions that slowed them down, extra taps, confirmation screens, unclear hierarchy, had an outsized impact on retention. Speed and clarity were non-negotiable.

3. Consistency would compound over time. Every hour spent debating component choices in design was an hour not spent on features. By resolving the design language upfront, we were investing in every future sprint, not just this one.

Design Approach

Information Architecture

The first structural decision was to simplify navigation. The existing architecture asked users to make too many choices too early. I consolidated the core flows: My Team, Trades, Scores, Leagues, into a cleaner primary navigation, reducing the cognitive overhead of getting from intent to action.

Progressive disclosure

For complex flows like trades, I introduced progressive disclosure: surface the essential information first, reveal detail on demand. This reduced the perceived complexity of the trade flow significantly, while preserving full functionality for users who wanted it.

Responsive-first, mobile-led

Given that the majority of usage happened on mobile during live matches, I designed mobile-first and scaled up, rather than the reverse. This forced earlier decisions about hierarchy and prioritisation that made the desktop experience stronger too.

Interaction patterns

For live scoring in particular, I designed state-based components that communicated change clearly, player score updates, rank movement, trade lock timing, so users understood what was happening without needing to refresh or navigate away. Real-time context, delivered clearly.

Design System

The design system was the project's structural backbone, and the work I'm most proud of.

Starting from the audit findings, I rebuilt the component library in Figma from scratch using atomic design principles:

• Tokens first: colour, typography, spacing, and elevation, rounded corners, shadows, borderlines, defined as variables, ensuring visual decisions were systematic rather than ad hoc

• Component hierarchy: atoms → molecules → organisms, with clear naming conventions that matched the engineering implementation

• Native variants: each component documented for Web, iOS, and Android, with platform-native behaviour explicitly called out

• States and interactions: every component included all states: default, hover, active, disabled, error, loading

The result was a library the engineering team could build from directly, dramatically reducing the back-and-forth during implementation. Dev handoff shifted from "interpret this design" to "implement this component as built", a fundamentally different relationship.

Outcome: ~50-60% reduction in design debt across the product, with a component library that has become the team's single source of truth for all subsequent feature work.

Key Decisions & Rationale

Rebuilding vs. refining Early in the project, there was a conversation about whether to refine the existing components or rebuild from scratch. I advocated for rebuilding, not out of preference for starting over, but because the existing components had accumulated so many exceptions that refining them would have required as much effort as rebuilding, with less clarity at the end. The audit data supported this position.

Shipping iteratively, not all at once Rather than holding the redesign until every flow was finalised, I worked with the product manager to sequence releases, shipping the most-used flows first, gathering real feedback, and refining the system as we went. This kept the product live and learning while the system matured.

Documenting decisions, not just outputs One of the biggest gaps I found was institutional knowledge, why certain design decisions had been made. I started documenting rationale alongside components in Figma, so that future designers (and engineers) could understand the why, not just the what. This paid dividends almost immediately, reducing the number of "why does this work this way?" questions in review.