Designing across Konga’s shopping experience and business tools
Konga is a Nigerian marketplace where many merchants sell into one basket. I joined as a product designer and spent 4 years there, improving the parts shoppers already used every day and building tools that did not exist yet for the people running the business, working alongside other designers and a wider team of product managers, engineers, merchandisers and operations staff.
Three pieces of that work are developed on this page: the shopping journey from listing to checkout, with KongaNow same-day delivery running through it; the Konga Search Service, the internal platform behind search on Konga; and Inventory, a stock management system built from nothing for small businesses on web, mobile and POS.
For each, I’ll show what needed attention, how I worked through it with the team, and the choices we made along the way, including what improved and what remained difficult.
Product designerJune 2021 – September 2025Web, mobile web, iOS, Android, POS
Full-time, then part-time retainer (2 days/week) from May 2022.
24%
Revenue increase attributed to KongaNow
$75K+
Annual third-party costs avoided with KSS
0 → 1
Inventory, built from nothing
The work at a glance
pick one to jump to it
An honest chapter
The Super App
My first real project as a product designer was also the most ambitious thing Konga attempted while I was there: a Super App unifying Konga Online, KongaPay, Konga Health, Konga Logistics, and KongaFood into a single experience.
Working alongside three other designers, I helped design the unified app. We were proud of it, but it didn’t succeed.
KongaFood has since closed, and the Super App is no longer in use. The honest diagnosis is that the strategy asked users to adopt a bundle before the individual products had each earned independent, habitual trust. The market wasn’t ready, and the organisation couldn’t resource five verticals evenly enough to make the bundle stronger than its parts.
One app for the whole ecosystem: shopping, payments, food, travel, logistics, and health
Shoppers
Finding a product, trusting the seller, and knowing what delivery will cost
One Konga basket can hold items from three merchants, each with its own delivery fee and its own delivery speed. When I joined, shoppers only found that out at the last step. Across the product page, the listings and checkout, I worked on making the answer visible wherever someone is still deciding, and on making KongaNow same-day delivery something you notice while browsing rather than discover at the end.
Deciding who to buy from
Before anything about delivery, a shopper has to decide whether to trust the seller at all. Two changes on the merchant’s store came out of my audit of the web app, and neither is about delivery. Merchants with large catalogues were effectively unbrowsable, so I argued for a search box inside the store. And ratings were static, so a merchant’s reviews were aggregated into something a shopper can read before buying. Separately, I designed the product review prompt: customers returning after a delivery are asked to rate the product and share their experience.
The merchant store on mobile web.
The same store on desktop: rating, review count, product quality and delivery rate at the top, search within the store on the left.
The product review prompt, shown to a customer after delivery.
Search within a storeI audited how shoppers browse a merchant’s catalogue, sorted the user feedback, and routed the fixes the audit found to engineering. In later feedback, shoppers rated store search as useful.
Merchant ratings, and product reviewsMerchant ratings tell you about the seller: quality, delivery rate, how long they have sold on Konga. Product reviews tell you about the item. The audit had identified trust as the problem shoppers kept losing on, so prompting customers to review a product after delivery was meant to build the evidence other shoppers would need.
The merchant-page findings in the audit, as routed.
The product page
Once a shopper has settled on a seller, the product page has to answer the next question: what will this cost to get to me, and when. Before the redesign, delivery sat in a row of small icons below the price. The redesign moves it into a panel beside the product: the same-day city, the 3PM cut-off, what happens if you order after it, and the returns policy in the same place.
Before the redesign
After the redesign
Closer in
Delivery above the fold. Same-day city, the cut-off time, and the returns policy together.
Two badges answer two questions at once: can I get it today, and is this an authorised seller.
Why this change
My audit of the web app had flagged the product page for exactly this: it needed to give the delivery timeline in calendar days so we could manage expectations before purchase rather than after.
What shoppers said
In a survey of 395 shoppers after the changes were live, the delivery panel was the clearest-rated of everything we asked about.
KongaNow, where people browse
That delivery information also needed to be visible before someone opened a product page. KongaNow introduced same-day delivery to Konga. I designed how shoppers would discover the service while browsing, recognise eligible products and understand the delivery conditions at checkout. The KongaNow badge and the city sit on the product card itself, on the homepage carousels and in category listings, and mobile web gets a same-day section on the home screen. Most Konga sessions happen on a phone, so the badge had to read at card size on a small screen first.
Desktop web. The badge on every eligible card in the Electronics and Phones carousels.
Mobile home. A same-day section of its own.
Category listing on mobile.
Checkout, with the fee for each store
Checkout is where everything above comes together, and where the answer has to hold. Delivery is calculated per merchant, not per order. Checkout now shows each merchant’s fee against that merchant’s items, flags which items are not eligible for same-day, and keeps the KongaNow cut-off visible while paying. The total stops being a surprise because every part of it is on the page.
Desktop checkout. Delivery method as a choice with its cost attached; the order panel names which items qualify.
Mobile. One delivery line per merchant.
Fee against the merchant, not the orderA basket from three sellers shows three delivery lines, each named. The subtotal and the delivery fee add up in front of the shopper.
Eligibility per item, not per basketSame-day is only possible for some items in some cities. The order panel says which, so nobody expects a same-day basket that cannot exist.
What shoppers said
Most people found the breakdown of delivery cost across merchants clear. The cost itself stayed the most mentioned subject in the open responses.
“I will shop for several goods only to be charged delivery fee for each one of them.”
Official brand stores
Trust in the seller runs through all of this, and for brands it takes a specific form: is this store authorised. Authorised brand stores answer the counterfeit question that formal ecommerce in Nigeria keeps losing on. I proposed two directions for presenting them: a revamped filter with a brand carousel that could prioritise newly onboarded brands, and the same plus sellable banner space above it. The built page carries the brand grid and the Official Store badge that then appears on every card.
The official stores page as built, and the badge it feeds.
Impact
24%revenue attributed to KongaNow
The data team reported this after launch, attributed to KongaNow income. It is not a 24% increase in all Konga revenue.
Trade-off
Showing the fee per merchant makes the total look higher than a single delivery line would. We chose to explain the charge rather than smooth it over. The clearer breakdown helped people understand where the cost came from; concerns about the charges themselves remained, and that was a pricing question the design could not settle.
Internal platforms
A search platform Konga’s own team could run
The shopping work above starts once a shopper has found a product. Search is where finding one most often broke down, and it needed a different kind of fix: an internal platform rather than a page. Search was a complaint from both sides of the marketplace. Shoppers searched for a product and got accessories or unrelated items first, and staff testing the site reported the same thing. Konga chose to build its own search service rather than keep paying for one. I designed the internal tooling for that service, the merchandising rules, the index configuration and the analytics the marketing team operates day to day, working with search engineering and with the merchandisers themselves. That service now powers search results on Konga.
Requirements written in three voices
Shopper, administrator and merchandiser, each as a user story. The merchandiser’s is the one that shaped the tool: “I want to be able to set rules for products as they apply on the platform e.g model, brand, pricing, store name etc.” The shopper’s path and the administrator’s path were drawn separately. The shopper’s ends in a branch, satisfied or not, and the unsatisfied branch loops back to a rewritten query. The tooling exists to shrink that loop.
From the search service board. The branch on the right, is the user satisfied with the results, is the one the merchandising rules are measured against.
Relevancy. The sort order and its effect on results, side by side.
Five steps to a working index
Before building, I ran a competitive analysis which I presented to business stakeholders that compared a field of hosted search services against seven criteria: features, target use cases, ease of use, scalability, open source, machine learning and pricing model. Building in house won.
I designed the KSS so that anyone on Konga’s team could use it, not only engineers. An internal user goes from importing data to a live search in five steps: import, choose what to display, set searchable attributes, configure relevancy, implement. The keys and documentation sit on the same screen so nobody has to ask engineering for them.
Rules: ranking as a decision, not a ticket
A rule is a condition and an action. Query contains, category page is, a date range; then boost, pin to a position, hide, bury a category, filter or redirect. A merchandiser can run a campaign without an engineer in the loop, and see the result in the browse pane beside it.
Index configuration. Searchable attributes in priority order, with ranking, typo tolerance, synonyms and facets in the same list.
Released, and received well
Gabriel Ilochi, the engineering manager who led the build, announced the release of Konga Search: over $75,000 a year had been going to a third-party tool while customers still struggled to find what they needed, and moving to Konga’s own infrastructure removed that cost and gave the team the merchandising control it had been missing. He credited the group who built it, and I was part of that group. Within weeks of release, shoppers were describing the experience as seamless, and the head of growth noted the site was smoother to navigate overall.
We were spending over $75,000 a year on a third-party search tool, but our customers still struggled to find what they needed.
…
Within just a few weeks of release, shoppers are already sharing testimonies of a "seamless experience".
From the release announcement.
Impact
$75K+annual third-party costs avoided
Third-party search costs Konga no longer pays. This is avoided cost, not net saving after the internal build, and it was the work of a team.
Trade-off
Building search in house meant accepting a period where relevance was still maturing. I designed the merchandising and relevance controls first, so the business could close that gap itself rather than waiting on engineering for every change.
Small businesses
Inventory: a free way for small businesses to keep track of stock and sales
The other side of my work at Konga was tools for the people running businesses on KongaPay, and Inventory is the one built from nothing. Most small and less structured businesses in Nigeria keep stock in their heads, in a notebook or in a spreadsheet, if anywhere. Inventory was built from nothing as a free tool for those businesses to manage what they hold and what they sell, on web, mobile and the POS terminal, as part of KongaPay’s wider offer to help businesses grow. Working from the product manager’s PRD, I was responsible for the V1 design, from user research and prototyping through QA testing with engineers.
Two states of the same dashboard
A new business lands on nothing, so the empty state says what to do next: add items by hand or upload a file. Once stock is in, the same dashboard shows total value, the sales trend, distribution by category, top sellers and the alerts that matter, low stock, updates, a report ready for review.
Empty
With stock
Getting stock in
Two ways in. Manual entry for a handful of items, with categories, variations, batch numbers and branch; a CSV upload for a whole catalogue, with a sample template to follow. The upload is previewed before anything is committed. When a file has problems, the preview reports how many errors it found and offers Re-upload or Upload Anyway.
Manual entry. Item type, name, category, batch and barcode, quantity, unit and branch, over three steps.
Bulk upload. Choose a file, or download the sample template first.
The preview, clean. The file is shown back before anything is committed.
The preview, with errors.
The preview reports the errorsFour errors found, with a note on what is invalid, before the file becomes stock.
Two ways forwardRe-upload a corrected file, or continue with Upload Anyway. The choice stays with the business.
Selling from the same stock on the POS
The POS side of Inventory lets a business scan or search an item, build a sale, take payment by card, transfer or cash, and print a receipt, with the stock count and low-stock alerts updating from the same record the dashboard shows. The mobile app serves Android and iOS from one design.
Inventory on the POS. Sales today, stock counts and alerts.
Scan or search, set quantities.
Invoice and payment method.
Receipt, printed from the terminal.
Inventory Admin, the tool behind the tool
Inventory Admin is Konga’s internal operational console for the Inventory product: the team uses it to see how the platform is being used across businesses and branches, to look into an individual business’s stock, sales and activity when they need support, to generate reports, and to manage roles, alerts, configuration and POS device usage. It is a separate product from the business dashboard above, for Konga staff rather than for the businesses themselves. The figures in these screens are design data, not measured results.
Overview. Usage across the platform, alerts and the audit log.
A business, as the support team sees it: profile, inventory, branches, sales history, activity.
Reports and exports, filtered by type, business, branch and date.
Settings and controls: roles, audit trail, configuration and POS device usage.
Impact
0 → 1built from nothing
A stock and sales tool that did not exist before, offered free to small businesses on web, mobile and POS, with an admin console behind it.
Trade-off
Shipping Inventory across web, mobile and POS at once stretched a small team. One platform first would have shipped faster but left merchants managing stock in two places. Coverage mattered more than speed here.
Wider work
Also at Konga
Here are some exciting products I worked on: merchant and business tools, the affiliate programme, the payments website and the POS terminal.
Seller HQ
The back office for merchants selling on Konga: store summary, orders, products, warehouse, transactions and subscription plans. Ibkay designed the web dashboard; I designed its responsive mobile view, the redesigned onboarding shown here, and the marketing website, after an audit that found two near-identical landing pages and a registration page whose navigation was mostly inactive. Worked through with Samuel, Chidera and Chuks, mainly engineers. Reached staging, where I reviewed it. It did not launch.
KongaPay merchant web
The web experience for businesses on KongaPay: dashboard, wallet, bills, transaction history, payment requests, invoices, disputes, POS, sub-accounts, bulk transfer, approvals and settings. I designed the merchant web experience. Mosope, the KongaPay designer, handled the design system, the mobile experience, account creation and onboarding.
Overview: the affiliate link, clicks, sales and commission.
Reports: orders, commission and payment status.
Banners and links: a generated banner, image link and embed code to copy.
Affiliate portal
Konga’s affiliates share links and banners and earn commission on the orders that follow. I audited the old portal, developed the information architecture and wireframes, and designed the main dashboard for web and responsive mobile: overview, campaigns, banners and links, commission and payment reports. Ibkay designed the admin dashboard and the marketing website.
After the redesign
The overview page. Click to open the full page.
The business page. Click to open the full page.
The personal page. Click to open the full page.
Before the redesign
The earlier site: one page for everyone. Click to open the full page.
KongaPay website redesign
The business wanted visitors to understand the full range of KongaPay’s offerings. I redesigned the website to make those offerings easier to discover and explain, with an overview of KongaPay and dedicated pages for its business and personal services, across desktop and mobile.
Settings on first use.
Home: balances and the collection methods.
Transactions for the day.
Bank success rate by card scheme, so an agent knows which route to use.
The collections flow from the requirements board: card, transfer, QR or cash, each ending in a receipt.
POS terminal
The app on the terminal that KongaPay business users carry. I worked from the requirements to the flows: requesting a terminal, activation, wallet, collections by card, transfer, QR or cash, receipts, and the end-of-day report, then the screens. Research with the people using the terminal sat alongside the flows. The POS is currently in use nationwide in Nigeria.
Explorations
Gift cards
Konga had no gift card, and on most stores I audited the one they had was hidden in the footer, so shoppers could reasonably assume there was none. I explored what a Konga gift card would take: the purchase page, choosing an amount, a design and a delivery method, and the email that carries the card and its code to the recipient.
Loyalty scheme
The business wanted a rewards scheme and had a PRD. I explored five directions against it, points, tiers, category-based, referral and limited-time, and mapped where rewards would surface, how they would be tracked and how they would be redeemed. One question came back to the business: if a user orders from 5 categories, is the point awarded per category or per successful purchase? I asked for order and return data before going further, to weight points and to stop them accruing on returned orders.
Konga Logistics mobile client
Booking a Konga Logistics delivery involved manual back-and-forth even though a web page existed for it. I explored a mobile client: the information architecture, and an MVP of sending a package, requesting a truck or van, a shipping calculator, booking confirmation and live tracking, on top of the existing logistics systems.
Working method
How I worked
When I joined, a product manager would hand over a PRD and expect high-fidelity screens soon after, and reviews turned into discussions about visuals while functionality slipped. I pushed for reviews to start earlier and from different material: wireframes, audits of what already existed, research, and proposals with numbers in them. It moved into the process gradually, and it is the part of the job I am most pleased with. Most of the work on this page began that way.
Research before screensSession analytics on the live site with Google Analytics or Microsoft Clarity. Audits of the web and mobile app. Surveys of shoppers and merchants before and after changes shipped. Interviews with business teams across Konga, and with shoppers and merchants. Internal beta rounds with staff from commercial, e-commerce, operations, customer service, marketing and technology.
Proposals with options and expected outcomesFor improvements to the user experience I wanted on the platform, I would carry out research, create wireframe mockups and present proposals with options to stakeholders. The decision stayed with the business and the reasoning stayed on the record.
Implementation review and follow-throughI kept a shared bug and UX enhancement queue where design recommendations, feature requests and customer complaints were triaged together, routed to the team that had to act, and followed up. A complaint about prices changing at the point of payment could outrank a design item.
Working with other designersAcross shared products, I worked with other designers to divide the work, review each other’s designs and keep the experience consistent. Ibkay and I collaborated on Seller HQ and Affiliate, while I worked with Mosope on KongaPay’s merchant platform.
Looking back
Konga broadened the way I think about product design. Working across the group meant learning how different parts of the business operated, from logistics and warehouse teams to marketing, technology and customer support. Their priorities, locations and ways of working varied, and understanding those differences became part of designing something useful.
I had room to put forward ideas and help shape how we approached problems. I also found the red tape frustrating at times. Experimentation and delivery could move slowly as work passed through different teams and competing priorities.
Overall, Konga was a valuable place to learn. I left with a wider understanding of how products are built, how to work with different stakeholders, and how much the organisation around a product shapes what can happen.
Next case study
Making African music easier to explore
User research and information architecture for Josplay’s African Music Library.
Designing across Konga’s shopping experience and business tools
Konga is a Nigerian marketplace where many merchants sell into one basket. I joined as a product designer and spent 4 years there, improving the parts shoppers already used every day and building tools that did not exist yet for the people running the business, working alongside other designers and a wider team of product managers, engineers, merchandisers and operations staff.
Three pieces of that work are developed on this page: the shopping journey from listing to checkout, with KongaNow same-day delivery running through it; the Konga Search Service, the internal platform behind search on Konga; and Inventory, a stock management system built from nothing for small businesses on web, mobile and POS.
For each, I’ll show what needed attention, how I worked through it with the team, and the choices we made along the way, including what improved and what remained difficult.
Product designerJune 2021 – September 2025Web, mobile web, iOS, Android, POS
Full-time, then part-time retainer (2 days/week) from May 2022.
24%
Revenue increase attributed to KongaNow
$75K+
Annual third-party costs avoided with KSS
0 → 1
Inventory, built from nothing
The work at a glance
pick one to jump to it
An honest chapter
The Super App
My first real project as a product designer was also the most ambitious thing Konga attempted while I was there: a Super App unifying Konga Online, KongaPay, Konga Health, Konga Logistics, and KongaFood into a single experience.
Working alongside three other designers, I helped design the unified app. We were proud of it, but it didn’t succeed.
KongaFood has since closed, and the Super App is no longer in use. The honest diagnosis is that the strategy asked users to adopt a bundle before the individual products had each earned independent, habitual trust. The market wasn’t ready, and the organisation couldn’t resource five verticals evenly enough to make the bundle stronger than its parts.
One app for the whole ecosystem: shopping, payments, food, travel, logistics, and health
Shoppers
Finding a product, trusting the seller, and knowing what delivery will cost
One Konga basket can hold items from three merchants, each with its own delivery fee and its own delivery speed. When I joined, shoppers only found that out at the last step. Across the product page, the listings and checkout, I worked on making the answer visible wherever someone is still deciding, and on making KongaNow same-day delivery something you notice while browsing rather than discover at the end.
Deciding who to buy from
Before anything about delivery, a shopper has to decide whether to trust the seller at all. Two changes on the merchant’s store came out of my audit of the web app, and neither is about delivery. Merchants with large catalogues were effectively unbrowsable, so I argued for a search box inside the store. And ratings were static, so a merchant’s reviews were aggregated into something a shopper can read before buying. Separately, I designed the product review prompt: customers returning after a delivery are asked to rate the product and share their experience.
The merchant store on mobile web.
The same store on desktop: rating, review count, product quality and delivery rate at the top, search within the store on the left.
The product review prompt, shown to a customer after delivery.
Search within a storeI audited how shoppers browse a merchant’s catalogue, sorted the user feedback, and routed the fixes the audit found to engineering. In later feedback, shoppers rated store search as useful.
Merchant ratings, and product reviewsMerchant ratings tell you about the seller: quality, delivery rate, how long they have sold on Konga. Product reviews tell you about the item. The audit had identified trust as the problem shoppers kept losing on, so prompting customers to review a product after delivery was meant to build the evidence other shoppers would need.
The merchant-page findings in the audit, as routed.
The product page
Once a shopper has settled on a seller, the product page has to answer the next question: what will this cost to get to me, and when. Before the redesign, delivery sat in a row of small icons below the price. The redesign moves it into a panel beside the product: the same-day city, the 3PM cut-off, what happens if you order after it, and the returns policy in the same place.
Before the redesign
After the redesign
Closer in
Delivery above the fold. Same-day city, the cut-off time, and the returns policy together.
Two badges answer two questions at once: can I get it today, and is this an authorised seller.
Why this change
My audit of the web app had flagged the product page for exactly this: it needed to give the delivery timeline in calendar days so we could manage expectations before purchase rather than after.
What shoppers said
In a survey of 395 shoppers after the changes were live, the delivery panel was the clearest-rated of everything we asked about.
KongaNow, where people browse
That delivery information also needed to be visible before someone opened a product page. KongaNow introduced same-day delivery to Konga. I designed how shoppers would discover the service while browsing, recognise eligible products and understand the delivery conditions at checkout. The KongaNow badge and the city sit on the product card itself, on the homepage carousels and in category listings, and mobile web gets a same-day section on the home screen. Most Konga sessions happen on a phone, so the badge had to read at card size on a small screen first.
Mobile home. A same-day section of its own.
Desktop web. The badge on every eligible card in the Electronics and Phones carousels.
Category listing on mobile.
Checkout, with the fee for each store
Checkout is where everything above comes together, and where the answer has to hold. Delivery is calculated per merchant, not per order. Checkout now shows each merchant’s fee against that merchant’s items, flags which items are not eligible for same-day, and keeps the KongaNow cut-off visible while paying. The total stops being a surprise because every part of it is on the page.
Mobile. One delivery line per merchant.
Desktop checkout. Delivery method as a choice with its cost attached; the order panel names which items qualify.
Fee against the merchant, not the orderA basket from three sellers shows three delivery lines, each named. The subtotal and the delivery fee add up in front of the shopper.
Eligibility per item, not per basketSame-day is only possible for some items in some cities. The order panel says which, so nobody expects a same-day basket that cannot exist.
What shoppers said
Most people found the breakdown of delivery cost across merchants clear. The cost itself stayed the most mentioned subject in the open responses.
“I will shop for several goods only to be charged delivery fee for each one of them.”
Official brand stores
Trust in the seller runs through all of this, and for brands it takes a specific form: is this store authorised. Authorised brand stores answer the counterfeit question that formal ecommerce in Nigeria keeps losing on. I proposed two directions for presenting them: a revamped filter with a brand carousel that could prioritise newly onboarded brands, and the same plus sellable banner space above it. The built page carries the brand grid and the Official Store badge that then appears on every card.
The official stores page as built, and the badge it feeds.
Impact
24%revenue attributed to KongaNow
The data team reported this after launch, attributed to KongaNow income. It is not a 24% increase in all Konga revenue.
Trade-off
Showing the fee per merchant makes the total look higher than a single delivery line would. We chose to explain the charge rather than smooth it over. The clearer breakdown helped people understand where the cost came from; concerns about the charges themselves remained, and that was a pricing question the design could not settle.
Internal platforms
A search platform Konga’s own team could run
The shopping work above starts once a shopper has found a product. Search is where finding one most often broke down, and it needed a different kind of fix: an internal platform rather than a page. Search was a complaint from both sides of the marketplace. Shoppers searched for a product and got accessories or unrelated items first, and staff testing the site reported the same thing. Konga chose to build its own search service rather than keep paying for one. I designed the internal tooling for that service, the merchandising rules, the index configuration and the analytics the marketing team operates day to day, working with search engineering and with the merchandisers themselves. That service now powers search results on Konga.
Requirements written in three voices
Shopper, administrator and merchandiser, each as a user story. The merchandiser’s is the one that shaped the tool: “I want to be able to set rules for products as they apply on the platform e.g model, brand, pricing, store name etc.” The shopper’s path and the administrator’s path were drawn separately. The shopper’s ends in a branch, satisfied or not, and the unsatisfied branch loops back to a rewritten query. The tooling exists to shrink that loop.
Tap to enlarge
From the search service board. The branch on the right, is the user satisfied with the results, is the one the merchandising rules are measured against.
Relevancy. The sort order and its effect on results, side by side.
Five steps to a working index
Before building, I ran a competitive analysis which I presented to business stakeholders that compared a field of hosted search services against seven criteria: features, target use cases, ease of use, scalability, open source, machine learning and pricing model. Building in house won.
I designed the KSS so that anyone on Konga’s team could use it, not only engineers. An internal user goes from importing data to a live search in five steps: import, choose what to display, set searchable attributes, configure relevancy, implement. The keys and documentation sit on the same screen so nobody has to ask engineering for them.
Rules: ranking as a decision, not a ticket
A rule is a condition and an action. Query contains, category page is, a date range; then boost, pin to a position, hide, bury a category, filter or redirect. A merchandiser can run a campaign without an engineer in the loop, and see the result in the browse pane beside it.
Index configuration. Searchable attributes in priority order, with ranking, typo tolerance, synonyms and facets in the same list.
Released, and received well
Gabriel Ilochi, the engineering manager who led the build, announced the release of Konga Search: over $75,000 a year had been going to a third-party tool while customers still struggled to find what they needed, and moving to Konga’s own infrastructure removed that cost and gave the team the merchandising control it had been missing. He credited the group who built it, and I was part of that group. Within weeks of release, shoppers were describing the experience as seamless, and the head of growth noted the site was smoother to navigate overall.
We were spending over $75,000 a year on a third-party search tool, but our customers still struggled to find what they needed.
…
Within just a few weeks of release, shoppers are already sharing testimonies of a "seamless experience".
From the release announcement.
Impact
$75K+annual third-party costs avoided
Third-party search costs Konga no longer pays. This is avoided cost, not net saving after the internal build, and it was the work of a team.
Trade-off
Building search in house meant accepting a period where relevance was still maturing. I designed the merchandising and relevance controls first, so the business could close that gap itself rather than waiting on engineering for every change.
Small businesses
Inventory: a free way for small businesses to keep track of stock and sales
The other side of my work at Konga was tools for the people running businesses on KongaPay, and Inventory is the one built from nothing. Most small and less structured businesses in Nigeria keep stock in their heads, in a notebook or in a spreadsheet, if anywhere. Inventory was built from nothing as a free tool for those businesses to manage what they hold and what they sell, on web, mobile and the POS terminal, as part of KongaPay’s wider offer to help businesses grow. Working from the product manager’s PRD, I was responsible for the V1 design, from user research and prototyping through QA testing with engineers.
Two states of the same dashboard
A new business lands on nothing, so the empty state says what to do next: add items by hand or upload a file. Once stock is in, the same dashboard shows total value, the sales trend, distribution by category, top sellers and the alerts that matter, low stock, updates, a report ready for review.
Empty
With stock
Getting stock in
Two ways in. Manual entry for a handful of items, with categories, variations, batch numbers and branch; a CSV upload for a whole catalogue, with a sample template to follow. The upload is previewed before anything is committed. When a file has problems, the preview reports how many errors it found and offers Re-upload or Upload Anyway.
Manual entry. Item type, name, category, batch and barcode, quantity, unit and branch, over three steps.
1 of 4
The preview reports the errorsFour errors found, with a note on what is invalid, before the file becomes stock.
Two ways forwardRe-upload a corrected file, or continue with Upload Anyway. The choice stays with the business.
Selling from the same stock on the POS
The POS side of Inventory lets a business scan or search an item, build a sale, take payment by card, transfer or cash, and print a receipt, with the stock count and low-stock alerts updating from the same record the dashboard shows. The mobile app serves Android and iOS from one design.
Inventory on the POS. Sales today, stock counts and alerts.
1 of 4
Inventory Admin, the tool behind the tool
Inventory Admin is Konga’s internal operational console for the Inventory product: the team uses it to see how the platform is being used across businesses and branches, to look into an individual business’s stock, sales and activity when they need support, to generate reports, and to manage roles, alerts, configuration and POS device usage. It is a separate product from the business dashboard above, for Konga staff rather than for the businesses themselves. The figures in these screens are design data, not measured results.
Overview. Usage across the platform, alerts and the audit log.
A business, as the support team sees it: profile, inventory, branches, sales history, activity.
Reports and exports, filtered by type, business, branch and date.
Settings and controls: roles, audit trail, configuration and POS device usage.
Impact
0 → 1built from nothing
A stock and sales tool that did not exist before, offered free to small businesses on web, mobile and POS, with an admin console behind it.
Trade-off
Shipping Inventory across web, mobile and POS at once stretched a small team. One platform first would have shipped faster but left merchants managing stock in two places. Coverage mattered more than speed here.
Wider work
Also at Konga
Here are some exciting products I worked on: merchant and business tools, the affiliate programme, the payments website and the POS terminal.
Seller HQ
The back office for merchants selling on Konga: store summary, orders, products, warehouse, transactions and subscription plans. Ibkay designed the web dashboard; I designed its responsive mobile view, the redesigned onboarding shown here, and the marketing website, after an audit that found two near-identical landing pages and a registration page whose navigation was mostly inactive. Worked through with Samuel, Chidera and Chuks, mainly engineers. Reached staging, where I reviewed it. It did not launch.
KongaPay merchant web
The web experience for businesses on KongaPay: dashboard, wallet, bills, transaction history, payment requests, invoices, disputes, POS, sub-accounts, bulk transfer, approvals and settings. I designed the merchant web experience. Mosope, the KongaPay designer, handled the design system, the mobile experience, account creation and onboarding.
Overview: the affiliate link, clicks, sales and commission.
Reports: orders, commission and payment status.
Banners and links: a generated banner, image link and embed code to copy.
Affiliate portal
Konga’s affiliates share links and banners and earn commission on the orders that follow. I audited the old portal, developed the information architecture and wireframes, and designed the main dashboard for web and responsive mobile: overview, campaigns, banners and links, commission and payment reports. Ibkay designed the admin dashboard and the marketing website.
After the redesign
The overview page. Click to open the full page.
The business page. Click to open the full page.
The personal page. Click to open the full page.
Before the redesign
The earlier site: one page for everyone. Click to open the full page.
KongaPay website redesign
The business wanted visitors to understand the full range of KongaPay’s offerings. I redesigned the website to make those offerings easier to discover and explain, with an overview of KongaPay and dedicated pages for its business and personal services, across desktop and mobile.
Settings on first use.
1 of 4
Tap to enlarge
The collections flow from the requirements board: card, transfer, QR or cash, each ending in a receipt.
POS terminal
The app on the terminal that KongaPay business users carry. I worked from the requirements to the flows: requesting a terminal, activation, wallet, collections by card, transfer, QR or cash, receipts, and the end-of-day report, then the screens. Research with the people using the terminal sat alongside the flows. The POS is currently in use nationwide in Nigeria.
Explorations
Gift cards
Konga had no gift card, and on most stores I audited the one they had was hidden in the footer, so shoppers could reasonably assume there was none. I explored what a Konga gift card would take: the purchase page, choosing an amount, a design and a delivery method, and the email that carries the card and its code to the recipient.
Tap to enlarge
Loyalty scheme
The business wanted a rewards scheme and had a PRD. I explored five directions against it, points, tiers, category-based, referral and limited-time, and mapped where rewards would surface, how they would be tracked and how they would be redeemed. One question came back to the business: if a user orders from 5 categories, is the point awarded per category or per successful purchase? I asked for order and return data before going further, to weight points and to stop them accruing on returned orders.
Konga Logistics mobile client
Booking a Konga Logistics delivery involved manual back-and-forth even though a web page existed for it. I explored a mobile client: the information architecture, and an MVP of sending a package, requesting a truck or van, a shipping calculator, booking confirmation and live tracking, on top of the existing logistics systems.
Working method
How I worked
When I joined, a product manager would hand over a PRD and expect high-fidelity screens soon after, and reviews turned into discussions about visuals while functionality slipped. I pushed for reviews to start earlier and from different material: wireframes, audits of what already existed, research, and proposals with numbers in them. It moved into the process gradually, and it is the part of the job I am most pleased with. Most of the work on this page began that way.
Research before screensSession analytics on the live site with Google Analytics or Microsoft Clarity. Audits of the web and mobile app. Surveys of shoppers and merchants before and after changes shipped. Interviews with business teams across Konga, and with shoppers and merchants. Internal beta rounds with staff from commercial, e-commerce, operations, customer service, marketing and technology.
Proposals with options and expected outcomesFor improvements to the user experience I wanted on the platform, I would carry out research, create wireframe mockups and present proposals with options to stakeholders. The decision stayed with the business and the reasoning stayed on the record.
Implementation review and follow-throughI kept a shared bug and UX enhancement queue where design recommendations, feature requests and customer complaints were triaged together, routed to the team that had to act, and followed up. A complaint about prices changing at the point of payment could outrank a design item.
Working with other designersAcross shared products, I worked with other designers to divide the work, review each other’s designs and keep the experience consistent. Ibkay and I collaborated on Seller HQ and Affiliate, while I worked with Mosope on KongaPay’s merchant platform.
Looking back
Konga broadened the way I think about product design. Working across the group meant learning how different parts of the business operated, from logistics and warehouse teams to marketing, technology and customer support. Their priorities, locations and ways of working varied, and understanding those differences became part of designing something useful.
I had room to put forward ideas and help shape how we approached problems. I also found the red tape frustrating at times. Experimentation and delivery could move slowly as work passed through different teams and competing priorities.
Overall, Konga was a valuable place to learn. I left with a wider understanding of how products are built, how to work with different stakeholders, and how much the organisation around a product shapes what can happen.
Next case study
Making African music easier to explore
User research and information architecture for Josplay’s African Music Library.
Designing across Konga’s shopping experience and business tools
Konga is a Nigerian marketplace where many merchants sell into one basket. I joined as a product designer and spent 4 years there, improving the parts shoppers already used every day and building tools that did not exist yet for the people running the business, working alongside other designers and a wider team of product managers, engineers, merchandisers and operations staff.
Three pieces of that work are developed on this page: the shopping journey from listing to checkout, with KongaNow same-day delivery running through it; the Konga Search Service, the internal platform behind search on Konga; and Inventory, a stock management system built from nothing for small businesses on web, mobile and POS.
For each, I’ll show what needed attention, how I worked through it with the team, and the choices we made along the way, including what improved and what remained difficult.
Product designerJune 2021 – September 2025Web, mobile web, iOS, Android, POS
Full-time, then part-time retainer (2 days/week) from May 2022.
24%
Revenue increase attributed to KongaNow
$75K+
Annual third-party costs avoided with KSS
0 → 1
Inventory, built from nothing
The work at a glance
pick one to jump to it
An honest chapter
The Super App
My first real project as a product designer was also the most ambitious thing Konga attempted while I was there: a Super App unifying Konga Online, KongaPay, Konga Health, Konga Logistics, and KongaFood into a single experience.
Working alongside three other designers, I helped design the unified app. We were proud of it, but it didn’t succeed.
KongaFood has since closed, and the Super App is no longer in use. The honest diagnosis is that the strategy asked users to adopt a bundle before the individual products had each earned independent, habitual trust. The market wasn’t ready, and the organisation couldn’t resource five verticals evenly enough to make the bundle stronger than its parts.
One app for the whole ecosystem: shopping, payments, food, travel, logistics, and health
Shoppers
Finding a product, trusting the seller, and knowing what delivery will cost
One Konga basket can hold items from three merchants, each with its own delivery fee and its own delivery speed. When I joined, shoppers only found that out at the last step. Across the product page, the listings and checkout, I worked on making the answer visible wherever someone is still deciding, and on making KongaNow same-day delivery something you notice while browsing rather than discover at the end.
Deciding who to buy from
Before anything about delivery, a shopper has to decide whether to trust the seller at all. Two changes on the merchant’s store came out of my audit of the web app, and neither is about delivery. Merchants with large catalogues were effectively unbrowsable, so I argued for a search box inside the store. And ratings were static, so a merchant’s reviews were aggregated into something a shopper can read before buying. Separately, I designed the product review prompt: customers returning after a delivery are asked to rate the product and share their experience.
The merchant store on mobile web.
The same store on desktop: rating, review count, product quality and delivery rate at the top, search within the store on the left.
The product review prompt, shown to a customer after delivery.
Search within a storeI audited how shoppers browse a merchant’s catalogue, sorted the user feedback, and routed the fixes the audit found to engineering. In later feedback, shoppers rated store search as useful.
Merchant ratings, and product reviewsMerchant ratings tell you about the seller: quality, delivery rate, how long they have sold on Konga. Product reviews tell you about the item. The audit had identified trust as the problem shoppers kept losing on, so prompting customers to review a product after delivery was meant to build the evidence other shoppers would need.
The merchant-page findings in the audit, as routed.
The product page
Once a shopper has settled on a seller, the product page has to answer the next question: what will this cost to get to me, and when. Before the redesign, delivery sat in a row of small icons below the price. The redesign moves it into a panel beside the product: the same-day city, the 3PM cut-off, what happens if you order after it, and the returns policy in the same place.
Before the redesign
After the redesign
Closer in
Delivery above the fold. Same-day city, the cut-off time, and the returns policy together.
Two badges answer two questions at once: can I get it today, and is this an authorised seller.
Why this change
My audit of the web app had flagged the product page for exactly this: it needed to give the delivery timeline in calendar days so we could manage expectations before purchase rather than after.
What shoppers said
In a survey of 395 shoppers after the changes were live, the delivery panel was the clearest-rated of everything we asked about.
KongaNow, where people browse
That delivery information also needed to be visible before someone opened a product page. KongaNow introduced same-day delivery to Konga. I designed how shoppers would discover the service while browsing, recognise eligible products and understand the delivery conditions at checkout. The KongaNow badge and the city sit on the product card itself, on the homepage carousels and in category listings, and mobile web gets a same-day section on the home screen. Most Konga sessions happen on a phone, so the badge had to read at card size on a small screen first.
Desktop web. The badge on every eligible card in the Electronics and Phones carousels.
Mobile home. A same-day section of its own.
Category listing on mobile.
Checkout, with the fee for each store
Checkout is where everything above comes together, and where the answer has to hold. Delivery is calculated per merchant, not per order. Checkout now shows each merchant’s fee against that merchant’s items, flags which items are not eligible for same-day, and keeps the KongaNow cut-off visible while paying. The total stops being a surprise because every part of it is on the page.
Desktop checkout. Delivery method as a choice with its cost attached; the order panel names which items qualify.
Mobile. One delivery line per merchant.
Fee against the merchant, not the orderA basket from three sellers shows three delivery lines, each named. The subtotal and the delivery fee add up in front of the shopper.
Eligibility per item, not per basketSame-day is only possible for some items in some cities. The order panel says which, so nobody expects a same-day basket that cannot exist.
What shoppers said
Most people found the breakdown of delivery cost across merchants clear. The cost itself stayed the most mentioned subject in the open responses.
“I will shop for several goods only to be charged delivery fee for each one of them.”
Official brand stores
Trust in the seller runs through all of this, and for brands it takes a specific form: is this store authorised. Authorised brand stores answer the counterfeit question that formal ecommerce in Nigeria keeps losing on. I proposed two directions for presenting them: a revamped filter with a brand carousel that could prioritise newly onboarded brands, and the same plus sellable banner space above it. The built page carries the brand grid and the Official Store badge that then appears on every card.
The official stores page as built, and the badge it feeds.
Impact
24%revenue attributed to KongaNow
The data team reported this after launch, attributed to KongaNow income. It is not a 24% increase in all Konga revenue.
Trade-off
Showing the fee per merchant makes the total look higher than a single delivery line would. We chose to explain the charge rather than smooth it over. The clearer breakdown helped people understand where the cost came from; concerns about the charges themselves remained, and that was a pricing question the design could not settle.
Internal platforms
A search platform Konga’s own team could run
The shopping work above starts once a shopper has found a product. Search is where finding one most often broke down, and it needed a different kind of fix: an internal platform rather than a page. Search was a complaint from both sides of the marketplace. Shoppers searched for a product and got accessories or unrelated items first, and staff testing the site reported the same thing. Konga chose to build its own search service rather than keep paying for one. I designed the internal tooling for that service, the merchandising rules, the index configuration and the analytics the marketing team operates day to day, working with search engineering and with the merchandisers themselves. That service now powers search results on Konga.
Requirements written in three voices
Shopper, administrator and merchandiser, each as a user story. The merchandiser’s is the one that shaped the tool: “I want to be able to set rules for products as they apply on the platform e.g model, brand, pricing, store name etc.” The shopper’s path and the administrator’s path were drawn separately. The shopper’s ends in a branch, satisfied or not, and the unsatisfied branch loops back to a rewritten query. The tooling exists to shrink that loop.
From the search service board. The branch on the right, is the user satisfied with the results, is the one the merchandising rules are measured against.
Relevancy. The sort order and its effect on results, side by side.
Five steps to a working index
Before building, I ran a competitive analysis which I presented to business stakeholders that compared a field of hosted search services against seven criteria: features, target use cases, ease of use, scalability, open source, machine learning and pricing model. Building in house won.
I designed the KSS so that anyone on Konga’s team could use it, not only engineers. An internal user goes from importing data to a live search in five steps: import, choose what to display, set searchable attributes, configure relevancy, implement. The keys and documentation sit on the same screen so nobody has to ask engineering for them.
Rules: ranking as a decision, not a ticket
A rule is a condition and an action. Query contains, category page is, a date range; then boost, pin to a position, hide, bury a category, filter or redirect. A merchandiser can run a campaign without an engineer in the loop, and see the result in the browse pane beside it.
Index configuration. Searchable attributes in priority order, with ranking, typo tolerance, synonyms and facets in the same list.
Released, and received well
Gabriel Ilochi, the engineering manager who led the build, announced the release of Konga Search: over $75,000 a year had been going to a third-party tool while customers still struggled to find what they needed, and moving to Konga’s own infrastructure removed that cost and gave the team the merchandising control it had been missing. He credited the group who built it, and I was part of that group. Within weeks of release, shoppers were describing the experience as seamless, and the head of growth noted the site was smoother to navigate overall.
We were spending over $75,000 a year on a third-party search tool, but our customers still struggled to find what they needed.
…
Within just a few weeks of release, shoppers are already sharing testimonies of a "seamless experience".
From the release announcement.
Impact
$75K+annual third-party costs avoided
Third-party search costs Konga no longer pays. This is avoided cost, not net saving after the internal build, and it was the work of a team.
Trade-off
Building search in house meant accepting a period where relevance was still maturing. I designed the merchandising and relevance controls first, so the business could close that gap itself rather than waiting on engineering for every change.
Small businesses
Inventory: a free way for small businesses to keep track of stock and sales
The other side of my work at Konga was tools for the people running businesses on KongaPay, and Inventory is the one built from nothing. Most small and less structured businesses in Nigeria keep stock in their heads, in a notebook or in a spreadsheet, if anywhere. Inventory was built from nothing as a free tool for those businesses to manage what they hold and what they sell, on web, mobile and the POS terminal, as part of KongaPay’s wider offer to help businesses grow. Working from the product manager’s PRD, I was responsible for the V1 design, from user research and prototyping through QA testing with engineers.
Two states of the same dashboard
A new business lands on nothing, so the empty state says what to do next: add items by hand or upload a file. Once stock is in, the same dashboard shows total value, the sales trend, distribution by category, top sellers and the alerts that matter, low stock, updates, a report ready for review.
Empty
With stock
Getting stock in
Two ways in. Manual entry for a handful of items, with categories, variations, batch numbers and branch; a CSV upload for a whole catalogue, with a sample template to follow. The upload is previewed before anything is committed. When a file has problems, the preview reports how many errors it found and offers Re-upload or Upload Anyway.
Manual entry. Item type, name, category, batch and barcode, quantity, unit and branch, over three steps.
Bulk upload. Choose a file, or download the sample template first.
The preview, clean. The file is shown back before anything is committed.
The preview, with errors.
The preview reports the errorsFour errors found, with a note on what is invalid, before the file becomes stock.
Two ways forwardRe-upload a corrected file, or continue with Upload Anyway. The choice stays with the business.
Selling from the same stock on the POS
The POS side of Inventory lets a business scan or search an item, build a sale, take payment by card, transfer or cash, and print a receipt, with the stock count and low-stock alerts updating from the same record the dashboard shows. The mobile app serves Android and iOS from one design.
Inventory on the POS. Sales today, stock counts and alerts.
Scan or search, set quantities.
Invoice and payment method.
Receipt, printed from the terminal.
Inventory Admin, the tool behind the tool
Inventory Admin is Konga’s internal operational console for the Inventory product: the team uses it to see how the platform is being used across businesses and branches, to look into an individual business’s stock, sales and activity when they need support, to generate reports, and to manage roles, alerts, configuration and POS device usage. It is a separate product from the business dashboard above, for Konga staff rather than for the businesses themselves. The figures in these screens are design data, not measured results.
Overview. Usage across the platform, alerts and the audit log.
A business, as the support team sees it: profile, inventory, branches, sales history, activity.
Reports and exports, filtered by type, business, branch and date.
Settings and controls: roles, audit trail, configuration and POS device usage.
Impact
0 → 1built from nothing
A stock and sales tool that did not exist before, offered free to small businesses on web, mobile and POS, with an admin console behind it.
Trade-off
Shipping Inventory across web, mobile and POS at once stretched a small team. One platform first would have shipped faster but left merchants managing stock in two places. Coverage mattered more than speed here.
Wider work
Also at Konga
Here are some exciting products I worked on: merchant and business tools, the affiliate programme, the payments website and the POS terminal.
Seller HQ
The back office for merchants selling on Konga: store summary, orders, products, warehouse, transactions and subscription plans. Ibkay designed the web dashboard; I designed its responsive mobile view, the redesigned onboarding shown here, and the marketing website, after an audit that found two near-identical landing pages and a registration page whose navigation was mostly inactive. Worked through with Samuel, Chidera and Chuks, mainly engineers. Reached staging, where I reviewed it. It did not launch.
KongaPay merchant web
The web experience for businesses on KongaPay: dashboard, wallet, bills, transaction history, payment requests, invoices, disputes, POS, sub-accounts, bulk transfer, approvals and settings. I designed the merchant web experience. Mosope, the KongaPay designer, handled the design system, the mobile experience, account creation and onboarding.
Overview: the affiliate link, clicks, sales and commission.
Reports: orders, commission and payment status.
Banners and links: a generated banner, image link and embed code to copy.
Affiliate portal
Konga’s affiliates share links and banners and earn commission on the orders that follow. I audited the old portal, developed the information architecture and wireframes, and designed the main dashboard for web and responsive mobile: overview, campaigns, banners and links, commission and payment reports. Ibkay designed the admin dashboard and the marketing website.
After the redesign
The overview page. Click to open the full page.
The business page. Click to open the full page.
The personal page. Click to open the full page.
Before the redesign
The earlier site: one page for everyone. Click to open the full page.
KongaPay website redesign
The business wanted visitors to understand the full range of KongaPay’s offerings. I redesigned the website to make those offerings easier to discover and explain, with an overview of KongaPay and dedicated pages for its business and personal services, across desktop and mobile.
Settings on first use.
Home: balances and the collection methods.
Transactions for the day.
Bank success rate by card scheme, so an agent knows which route to use.
The collections flow from the requirements board: card, transfer, QR or cash, each ending in a receipt.
POS terminal
The app on the terminal that KongaPay business users carry. I worked from the requirements to the flows: requesting a terminal, activation, wallet, collections by card, transfer, QR or cash, receipts, and the end-of-day report, then the screens. Research with the people using the terminal sat alongside the flows. The POS is currently in use nationwide in Nigeria.
Explorations
Gift cards
Konga had no gift card, and on most stores I audited the one they had was hidden in the footer, so shoppers could reasonably assume there was none. I explored what a Konga gift card would take: the purchase page, choosing an amount, a design and a delivery method, and the email that carries the card and its code to the recipient.
Loyalty scheme
The business wanted a rewards scheme and had a PRD. I explored five directions against it, points, tiers, category-based, referral and limited-time, and mapped where rewards would surface, how they would be tracked and how they would be redeemed. One question came back to the business: if a user orders from 5 categories, is the point awarded per category or per successful purchase? I asked for order and return data before going further, to weight points and to stop them accruing on returned orders.
Konga Logistics mobile client
Booking a Konga Logistics delivery involved manual back-and-forth even though a web page existed for it. I explored a mobile client: the information architecture, and an MVP of sending a package, requesting a truck or van, a shipping calculator, booking confirmation and live tracking, on top of the existing logistics systems.
Working method
How I worked
When I joined, a product manager would hand over a PRD and expect high-fidelity screens soon after, and reviews turned into discussions about visuals while functionality slipped. I pushed for reviews to start earlier and from different material: wireframes, audits of what already existed, research, and proposals with numbers in them. It moved into the process gradually, and it is the part of the job I am most pleased with. Most of the work on this page began that way.
Research before screensSession analytics on the live site with Google Analytics or Microsoft Clarity. Audits of the web and mobile app. Surveys of shoppers and merchants before and after changes shipped. Interviews with business teams across Konga, and with shoppers and merchants. Internal beta rounds with staff from commercial, e-commerce, operations, customer service, marketing and technology.
Proposals with options and expected outcomesFor improvements to the user experience I wanted on the platform, I would carry out research, create wireframe mockups and present proposals with options to stakeholders. The decision stayed with the business and the reasoning stayed on the record.
Implementation review and follow-throughI kept a shared bug and UX enhancement queue where design recommendations, feature requests and customer complaints were triaged together, routed to the team that had to act, and followed up. A complaint about prices changing at the point of payment could outrank a design item.
Working with other designersAcross shared products, I worked with other designers to divide the work, review each other’s designs and keep the experience consistent. Ibkay and I collaborated on Seller HQ and Affiliate, while I worked with Mosope on KongaPay’s merchant platform.
Looking back
Konga broadened the way I think about product design. Working across the group meant learning how different parts of the business operated, from logistics and warehouse teams to marketing, technology and customer support. Their priorities, locations and ways of working varied, and understanding those differences became part of designing something useful.
I had room to put forward ideas and help shape how we approached problems. I also found the red tape frustrating at times. Experimentation and delivery could move slowly as work passed through different teams and competing priorities.
Overall, Konga was a valuable place to learn. I left with a wider understanding of how products are built, how to work with different stakeholders, and how much the organisation around a product shapes what can happen.
Next case study
Making African music easier to explore
User research and information architecture for Josplay’s African Music Library.
