BottleKing
Designing a better way to shop together
I designed BottleKing's Group Ordering experience to support shared purchases without making the underlying complexity visible to the customer, from inviting participants to payment, order tracking and viewing the completed order.
My Role
I designed the Group Ordering experience across web and mobile, working through the host and participant journeys, payment states, order history and supporting components. The work meant translating a multi-user ordering model into an interface that stays simple even when an order has several participants and transactions.
The Problem
A normal e-commerce order has one buyer and one payment. A group order is different: several people contribute to the same order, each with their own relationship to it. That raises new questions. Who is the host? What did each participant pay for? Who covered the full amount? How should the order appear in order history?
The product had to represent one shared order without pretending everyone experienced it the same way. A host cares about the full order, a participant cares about their contribution, and both need to see the shared delivery and current status.
How Might We
How might we make a multi-person purchase feel as clear as a normal order while still giving each participant the information relevant to them?
One shared order, end to end
I mapped the group order as a single journey that both roles move through, so every screen could be designed against the same model.
Scroll sideways to see the full diagram →
Starting a group order
Rather than building a separate system, I extended the existing shopping and order patterns, so a group order feels like BottleKing, only shared.
One order, two perspectives
The host needs the full picture. A participant should not have to understand the whole order to understand their own part in it. I modelled both as variants of one order system rather than two separate experiences.
Host
Participant
Sees
Every participant, item and payment status
Their own items and paid portion
Totals
The whole-order total
Their own contribution
Shared
Delivery details and order status
Delivery details and order status
Making the money make sense
The same order behaves differently depending on how it is paid for, so the interface always has to say whether an amount is the whole order or an individual's share. Totals map to confirmed Paystack transactions and clearly separate whole-order amounts from participant amounts.
Split Payment
- Each participant pays their own portion
- Participant-level payment status is visible
- Whole-order total stays distinct from each share
Pay-for-All
- The host covers the full amount
- It is clearly communicated that the host paid
- Participants see the shared order without a payment ask
Designing beyond the happy path
Group orders introduce states a normal order never has: refunded participants, long participant lists, discrepancies and mixed payment states, alongside loading and error states. I treated these as part of the core experience, and on mobile the dense participant breakdown reflows into compact structures without losing clarity.
Decision
Model host and participant views as variants of one order system.
Why
This keeps the experience consistent while allowing each role to see the information that matters to them.
What I learned
The harder a product becomes, the more important the underlying model is. Once I separated the needs of the host, the participant and the shared order, the interface became much easier to structure. It sharpened my approach to role-based experiences and financial clarity.
Try it yourself