Buying cooking gas in Lagos today is inconvenient and opaque. Households either travel to a filling station and wait in line, or rely on informal delivery arranged over a phone call — with no visibility into price, ETA, or who's showing up at their door. There's no standard for pricing (it varies station to station and negotiation to negotiation), no tracking, and no accountability if something goes wrong mid-delivery.

On the supply side, independent riders who could do these deliveries have no way to find demand efficiently, and gas retailers have no digital tools to manage pricing, riders, or customers at scale.

The opportunity: apply the on-demand logistics model — the thing Uber and Bolt made mainstream in Lagos — to a category that still runs on phone calls and guesswork.

To ensure a seamless user experience, the interactions between the four touchpoints were mapped

Three groups had to be designed for, each with very different needs and contexts of use:

The Customer — orders gas from home, usually when they notice the cylinder running low or empty. Wants speed, price transparency, and to trust that a stranger showing up at their gate is legitimate.

The Rider — a delivery partner working for income, often juggling multiple jobs or platforms. Needs to make accept/reject decisions in seconds, always knows exactly what they'll earn before committing, and needs the app to work reliably while in motion.

The Ops/Support Team — runs the business day to day: tracking orders, managing rider quality and payouts, handling pricing across different local government areas (LGAs), and responding to customer support tickets.

Designing for all three in one system meant every decision on one surface had a consequence on another — a pricing change in the Admin Portal needed to surface instantly and clearly in the User App; a rider's real-time location needed to power both the customer's tracking screen and the ops team's dashboard.

Before diving into individual screens, it's worth showing how the four products connect. This isn't four separate apps — it's one system viewed from four different seats at the table.

• A customer places an order in the User App.
• The order is broadcast to nearby Riders, who accept, pick up the empty cylinder, get it filled, and deliver it back.
• Every order, rider, and customer interaction rolls up into the Admin Portal, where ops manages pricing by LGA, monitors active riders, and handles support.
• The Website is the front door — where new customers and prospective riders first learn about Gasly before ever opening the app.

Designing them together (rather than as four disconnected briefs) meant I could build one shared design language, and made trade-offs visible early — e.g., a "rider en route" state needed to exist identically in the customer's tracking view, the rider's own screen, and the admin's live order view.

A few principles guided decisions across all four products:

1. Borrow familiar patterns, don't reinvent them. Lagos users already understand ride-hailing UX. The live map, the "X riders nearby," the price-before-you-commit pattern — all deliberately echo Uber/Bolt so the mental model transfers instantly.
2. Price and time, always visible, always upfront. No surprises at checkout. The Home screen leads with live price/kg and ETA before the user even taps anything.
3. Every actor gets a decision, fast. Riders see distance and earning on the order card before they decide to accept — no digging for information under time pressure.
4. Ops needs levers, not just dashboards. The Admin Portal isn't read-only reporting — pricing by LGA, rider management, and payouts are editable directly from the dashboard.

One shared system powers all four surfaces:

• Type: Clash Grotesk for display/headline moments (prices, big numbers), Geist for UI and body text — a pairing that feels premium at the "hero number" moments (₦1,300/kg, ₦12,500 earned today) without feeling heavy in dense UI like tables and lists.
• Color: A warm, energetic orange (#FF7A1A) as the single brand accent against black/white and neutral greys — plus a standard semantic set (green for success/online/earnings, red for alerts/offline/errors) reused identically across the consumer apps and the admin dashboard.
• Components: a shared button, input, badge, card, and icon-button library meant the Rider App's "Accept Order" button and the User App's "Request Gas Delivery" button are built from the same primitives — consistent, but re-skinned per context (green for a rider's affirmative action, orange for the brand's primary CTA).
• The live map is a recurring hero element across both mobile apps — dark-mode, with soft orange glow markers for riders and current location — reinforcing that this is a real-time logistics product, not a static ordering form.

The customer's entire relationship with Gasly happens in three moments: checking the price, placing the order, and tracking the delivery. Everything else in the app supports those three moments.

Riders aren't casually browsing — they're working, often on a bike, making fast decisions between jobs. Every screen in this app was designed around speed and clarity under time pressure.

The website is the front door for two audiences at once — prospective customers deciding whether to download the app, and prospective riders deciding whether to sign up to earn. The hero leads with the core promise (gas delivered to your door, fast), backed by an FAQ section addressing the two biggest trust questions any new user has about a service like this: is the pricing fair, and is the rider legitimate.

The hero section features a Lottie animation simulating riders making gas deliveries. This Lottie animation was created in After Effects and exported to a .JSON format using the plugin "Body Movin". Then I converted it to Lottie so the file size can be greatly reduced while still keeping it's vector properties

The project also required me to design a mascot for Gasly that could be used across it's branding to express emotions. Making the brand appear more cheerful

Designing four connected products at once forced a discipline that a single app doesn't: every pattern had to work across contexts, not just look good in isolation. The clearest example is the live map — reused as the emotional anchor of both mobile apps — and the card/badge system, which flexes from a simple status pill on a customer's order to a dense KPI card on the ops dashboard without ever feeling like a different product.