Footy

PRODUCT DESIGN

The Overview

Footy is a football-focused Farcaster mini-app built by KMac. Designed as a hub for football communities on Farcaster, the app combined live match discussions, team notifications, Fantasy Premier League tools, and interactive matchday experiences into a single product.

Its flagship feature, Score Square, was a prediction game where users bought squares representing possible final scores of football matches. At full time, the user holding the correct scoreline won the entire prize pool.

As Footy expanded, Score Square became the product's most important and heavily used experience — but the interface struggled with information density, inconsistent interaction patterns, and a lack of visual cohesion. My role was to redesign the experience, establish a scalable visual system, and improve clarity across the entire purchase flow.

The Problem

Footy was originally designed with functionality as the primary concern. By the time I began redesigning it, the product already worked, but the interface lacked consistency, visual cohesion, and clear interaction patterns.

I decided to focus first on Score Square, Footy's core and most heavily used feature. It represented the highest-impact opportunity to improve both usability and the overall product identity.

The Score Square experience revolved around a simple interaction model: users selected a football match, bought one or more squares representing possible final scores, and progressed through the entire purchase flow on a single screen. Rather than moving users between multiple pages, the interface relied heavily on state changes to communicate progress throughout the transaction process.

This created an interesting design challenge. The interface needed to:

• present a large amount of contextual information,
• communicate state changes clearly, and
• support fast decision-making without overwhelming the user.

As I audited the existing experience, three key problems emerged.

Information Density

Score Square compressed a significant amount of information into a small interface: match context, payout information, square selection, purchase states, and transaction feedback all competed for attention simultaneously.

Most of this information was necessary, but presenting everything at once created unnecessary cognitive load and made the flow feel harder to navigate than it needed to be.

Visual Cohesion

The visual language lacked consistency across screens and interaction states. Colours, spacing, and hierarchy shifted unpredictably throughout the experience, making related screens feel disconnected from one another.

The redesign needed a clearer and more scalable visual system that could unify the product across states and future features.

State Communication

The product depended heavily on state changes during the purchase flow. Users needed to understand immediately:

• where they were in the process,
• what action had just occurred, and
• what would happen next.

However, important transitions and feedback states were often visually disconnected from the square-selection interface itself, making the experience feel fragmented at critical moments.

The Design System

The redesign focused on making the Score Square experience easier to navigate by improving information hierarchy, system consistency, and state communication across the purchase flow.

Creating a Cohesive Visual System

With the interaction challenges clearly defined, I turned my attention to creating a more cohesive visual system for the mini-app.

The existing interface lacked consistency across colours, typography, and hierarchy, which made related screens feel disconnected from one another. Since Score Square relied heavily on repeated interaction patterns and rapid state changes, consistency became especially important — users needed the interface to feel predictable as they moved through the purchase flow.

I started with colour.

The redesigned system was built around three core colour tokens: Footy's existing magenta brand colour, a black surface colour, and an off-white for contrast and structure. Each token was then expanded into a wider range of shades to support different interaction and interface states across the product.

This allowed the interface to handle:

• active and inactive states,
• emphasis and de-emphasis,
• feedback states, and
• layered hierarchy,

while still maintaining visual consistency across screens.

Next, I refined the typography system.

Because Score Square relied heavily on dense informational text, readability and scanning speed became more important than expressive typography. Rather than pairing multiple typefaces together, I chose a single typeface — Josefin Sans — with a wide range of weights that could create hierarchy while keeping the interface visually consistent.

This made it easier to:

• scan match information quickly,
• distinguish primary and secondary content, and
• maintain clarity across different interface states.

Clarifying Information Hierarchy

The first step in the redesign process was auditing the information displayed across the Score Square flow and ranking it by importance.

For every screen, I focused on two questions:

• What action is the user trying to complete?
• What information is essential to completing that action confidently?

This led to a simple hierarchy system:

• Primary information remained visible at all times because it directly supported the user's immediate task.
• Secondary information was still useful, but not critical in the moment. This content was either moved into modals or relocated elsewhere within the mini-app to reduce visual clutter.
• Unnecessary information was removed entirely when it did not meaningfully support the user's decision-making process.

This process significantly reduced visual noise throughout the purchase flow while preserving the contextual information users needed to understand match states, payouts, and transaction progress.

Clearer State Communication

The purchase flow relied heavily on state changes to communicate progress during transactions, making clear feedback especially important throughout the experience.

In the original interface, transaction states were split between the square-selection frame and a separate area above it. This fragmented the interaction flow and made important feedback feel disconnected from the action the user had just taken.

I redesigned the flow so that all transaction and progress states were communicated directly within the square-selection frame itself.

This created a more cohesive interaction pattern and better aligned with the user's mental model: users naturally looked toward the square-selection area to understand what was happening during the purchase process.

By consolidating feedback into a single interaction surface, the experience became easier to follow and visually more predictable during critical transaction states.

The Outcome

The redesign tightened the visual language and interaction model of Score Square — turning an early prototype into a more coherent product.

Using the new visual system and interaction patterns, I designed the complete purchase flow — from arriving on the Score Square homepage to successfully buying squares for a match.

Although the flow spans multiple states, it was designed around a single core interaction surface. Beyond the entry point, every state is a variation of the same screen — sections updating dynamically as users move through selection, submission, and confirmation.

This approach helped:

• preserve continuity throughout the flow,
• reduce unnecessary navigation, and
• make state changes easier to follow during transactions.

Beyond the visual redesign itself, the project also established:

• a reusable foundation for future Footy features,
• clearer interaction patterns across states, and
• a more consistent interface language for the product moving forward.

The Reflection

Working on Footy reinforced the importance of treating interfaces as connected systems rather than isolated screens.

The most interesting challenge wasn't visual polish, but designing interaction patterns that could handle information density, rapid state changes, and transaction feedback without overwhelming users.

The project also pushed me to think more deeply about scalability — not just in terms of visual consistency, but in how interface decisions affect future product development, implementation clarity, and user understanding over time.

Heyfood Checkout Redesign

PRODUCT DESIGN

The Overview

Heyfood is a food delivery platform that I used extensively after moving to Ibadan. Over time, I found myself migrating to competing products whose ordering experience felt clearer and easier to use. Eventually I settled on Chowdeck because it was better designed, more visually appealing, and frankly the mental models just made more sense (especially when it came to ordering food).

Despite that, Heyfood remained appealing because of its extensive restaurant coverage, which made me curious about how the experience might improve with a more thoughtful product design approach.

Rather than redesigning the entire app, I focused on one of its most important user journeys: checkout.

The Problem

Checkout is one of the most critical parts of a food delivery experience. It is the point at which users review information, make final decisions, and commit to a purchase.

Heyfood's checkout flow attempted to present too much information at once. Ordering details, pricing information, payment options, delivery preferences, and secondary actions all competed for attention simultaneously, making it difficult for users to focus on the decision immediately in front of them.

This is what the checkout page looked like when I started redesigning it.

The result was a checkout experience that felt cluttered and overwhelming, increasing the likelihood that users would ignore important options or rush directly to payment without fully reviewing their order.

The Design System

Checkout is fundamentally a multivariable decision-making environment. In environments like this, it's important to manage cognitive load while still ensuring users make all the decisions necessary to complete their purchase confidently.

To present all the available options without overwhelming users, I first grouped the information on the screen into three categories.

A fourth category, Delivery Details, would include information such as rider information, contact details, estimated delivery times, and live order tracking. Because this information only becomes relevant after an order has been placed, I excluded it from the scope of this redesign exercise.

Some items in the existing flow did not fit neatly into any category. Features such as Leave Instructions For The Store and Send This Order As A Gift were treated as supporting actions and handled separately within the redesigned flow.

Once the information architecture became clear, splitting the checkout flow into two sequential steps became the obvious solution.

The first screen focused on reviewing and refining the order itself, while the second focused on contact details, payment information, and order completion.

I chose this structure for two reasons.

Final Review Before Commitment

I wanted users to have a final opportunity to review and adjust their order before entering payment.

Separating order review from payment creates a clearer progression through the checkout process and reduces the number of decisions users need to make simultaneously.

Supporting Alternative Purchase Paths

Actions such as sending an order as a gift introduce different contact and payment requirements.

Placing these decisions before the payment step creates a cleaner branching structure and prevents unnecessary complexity later in the flow. Users can settle on the contents of their order first before being routed into the appropriate payment experience.

The Outcome

The redesign transformed checkout from a single overloaded screen into a two-step flow organised around distinct user decisions.

The first screen focuses on reviewing and refining the order itself, while the second focuses on payment and completion. By separating these responsibilities, the flow reduces cognitive load while still surfacing all the information users need to place an order confidently.

Visually, I stayed close to Heyfood's existing brand language while refining hierarchy, spacing, and typography to create a more polished and cohesive experience.

I replaced the existing typography with a pairing of Constantia and Source Sans Pro. Constantia provided a more refined reading experience for longer blocks of text, while Source Sans Pro introduced clear hierarchy for headings, labels, and key interface elements.

The result was a checkout experience that felt more structured, easier to navigate, and visually more cohesive without departing significantly from the product's existing identity.

The Reflection

This project introduced me to the idea of sequential choice architecture as a useful framework for designing information-heavy interfaces.

Rather than presenting every option simultaneously, the redesign focused on surfacing decisions at the moment they became relevant. The result was a flow that felt more structured, easier to navigate, and better aligned with the way users naturally make purchasing decisions.

This project also really made me appreciate how much typography can make or break a project, in conjunction with basic things like spacing of course. Changing the typeface elevated the design so much, and I wasn't expecting that at all.

Bribe

VISUAL DESIGN

The Overview

Bribe is a Farcaster mini-app for sending and receiving voice notes. The catch is that voice notes come with bribes attached (hence the name). Listening to a voice note enables you to claim the bribe attached to it. And if you want to get someone's attention, you can send them a voice note with a bribe attached.

The Problem

Given the technical constraints of a Farcaster mini-app and the narrow scope of this experiment, the ask here wasn't to redesign the UX top-down or to create a design system for an expanding product.

What I needed to do was quite straightforward: overhaul the visual language and give Bribe some personality. Make it look better, and make it stand out in the imaginations of the people who will encounter the mini-app.

The Design System

A lot of writing went into the design of this one. First, I tried to define the product, figure out its place in the Farcaster ecosystem, and throw out possible new directions for the product to take eventually.

Then I started thinking about a narrative to tie it all together. I'd learned, by this point, that it's important to ground your redesign in a good narrative. A story, if you will, about what the product is, what kind of feelings it evokes (or should evoke), and what connections those feelings may have to real-world things from which you can take further inspiration.

In the case of Bribe, I ended up going with a narrative grounded in the Matrix movies.

Once I'd settled on this direction, I took a lot of screenshots of scenes from the Matrix movies and tried to extract a colour palette that closely matched the feel of the Matrix.

For typography, I kept the Blenny font for the Bribe wordmark, but given the Matrix leanings of the redesign, I chose IBM Plex Mono for body text. IBM Plex Mono is at once very readable while also looking very technical and engineered. It's the kind of typeface that evokes a "machine" feel — even if you can still read the words, it looks at once like what a developer uses in their journal, and what Agent Smith might use in communicating with his copies.

The Outcome

With Matrix connotations, a new colour palette, and a complementary body type in hand, I redesigned all the existing screens.

The Reflection

Making digital rain animation all by hand in Figma is hard. That part of the project required more thought than any other, and I still don't think I nailed it — in the end, I had to resort to asking an LLM to give me digital rain code.

Besides digital rain, I learnt how important narrative is to designing (all credit to Antimo for pointing this out to me). It's one thing to take something and redesign it and give it a better visual look; it's another thing when you do take the time to find a narrative to build it around. Finding a narrative gives a clearer direction and ties everything together — from the visual language of the app to marketing copy and the brand's tone of voice.