One real example: the CozonLagosHub discovery flow
Here is a concrete example from CozonLagosHub, the Lagos marketplace I am building. On the public homepage, a visitor is asked to continue to Lagos. The page then offers a listing search field, an area selector and category buttons such as Phones & Gadgets, Cars and Services. These are visible product decisions: the location is explicit, and a buyer has more than one route to a relevant listing.
The small implementation choice I want to highlight is the order of the journey. A buyer should first know which market they are browsing, then narrow by item and area, then inspect a listing. Showing Lagos before the search prevents an ambiguous result set. Category buttons give someone with a specific need a shortcut without requiring a perfect search term. This is the kind of local context that changes the interface, not just the marketing copy.
What I can verify from the public page today is the presence of those controls. I have not published a timed weak-network test, a mobile usability study or a completed purchase-flow result, so I will not claim the flow is proven fast or frictionless. My next useful check is to load the homepage on a low-end phone with a throttled connection, search for an item in one Lagos area, and record the time until usable results appear, any layout shifts, and what the user sees if the request fails. I will publish the measurements and a screen capture when I have them.
That is the practical standard behind this article: show the actual screen, explain why a decision was made, then test whether it helps a real user. An attractive page is only the starting point.
.png)
A product can work perfectly in a developer's browser and still be badly designed for the people it is supposed to serve.
That is one of the lessons I keep coming back to while building products around users and businesses in Nigeria.
I can choose modern tools, build a clean interface and deploy the app successfully. None of that automatically means the product fits the environment where somebody will actually use it.
Local constraints are not excuses for poor software.
They are product requirements.
Mobile is not a smaller desktop
For many users, the phone is the main computer.
That means mobile design cannot be the final stage where I shrink a desktop page and hope nothing overlaps.
I need to think about the phone from the beginning.
Can the main action be reached with a thumb?
Does a form require too much typing?
Will a modal fit when the mobile keyboard opens?
Are important controls too close together?
Does the page still make sense on a narrow screen?
If a marketplace or payment flow is frustrating on mobile, the fact that it looks beautiful on my laptop does not rescue it.
Data cost changes how I think about performance
A heavy page is not only slow.
It can be expensive for the user.
Large hero videos, uncompressed images and unnecessary JavaScript have a real cost when someone is using mobile data.
This changes how I think about “nice” design.
If a 4 MB image can become 300 KB with almost no visible loss, that optimization is not a technical detail. It is part of respecting the user's connection.
I try to ask:
- Does this asset need to load now?
- Can I compress it?
- Can I lazy-load it?
- Do I need the library that added hundreds of kilobytes?
- What happens on a slower connection?
Performance is accessibility too.
A weak network should not destroy the user's confidence
Networks are not always stable.
An action can take longer than I expect.
A request can fail after the user already tapped the button.
The connection can disappear during a form submission.
A product needs to communicate what is happening.
I want clear loading states.
I want buttons to avoid duplicate submissions.
I want retry behavior to be safe.
I want the interface to distinguish between:
We are processing this
and:
This failed and you can try again.
If the page just freezes, the user has to guess whether the product is broken.
That is especially damaging when the action involves money or business information.
Payments are not one generic problem
Nigeria has a strong digital-payment ecosystem, but “accept payments” is not a complete product requirement.
Different users care about different things.
A small business may want a simple payment link.
Another user may care about bank transfer.
Some transactions may involve provider callbacks or asynchronous confirmation.
A builder needs to understand the exact flow the product is offering instead of treating payments as one button.
This is something building CozonPay pushed me to think about more seriously.
The technical integration is only one layer.
The user also needs clarity about status, amount, recipient and what happens when a transaction does not complete immediately.
Trust is local too
People bring previous experiences into a new product.
If users have seen fake websites, failed payment pages or businesses that disappear after collecting money, they become careful.
That means trust signals matter.
I want a product to make basic things obvious:
- who operates it;
- how to contact support;
- what the service does;
- what data it collects;
- whether the domain and HTTPS are correct;
- what happens after an important action.
Trust is not created by adding a padlock icon to the design.
The product has to behave consistently.
WhatsApp can be part of the product journey
When I think about products such as CozonLagosHub, I do not need to force every interaction into a custom messaging system immediately.
If buyers and sellers already use WhatsApp comfortably, letting them move into a familiar communication channel can reduce friction.
That does not mean every product should depend on WhatsApp forever.
It means I should respect existing user behavior before rebuilding it.
Sometimes integration with what people already do is smarter than teaching them a completely new workflow.
Forms need to respect real input
Names, phone numbers, addresses and business details do not always fit the assumptions in generic examples.
I avoid validation rules that exist only because a tutorial used them.
A form should reject genuinely invalid data, not legitimate users who do not match an imagined format.
Phone-number handling needs a clear country-code strategy.
Names should not assume exactly two words.
Addresses may not fit a rigid structure.
The more global a product becomes, the more dangerous narrow assumptions become.
Support cannot be an afterthought
A small product may not have a support department.
That makes support design more important, not less.
If I am the developer and the person investigating problems, I need the system to give me useful information.
A user should not have to describe a transaction as:
That one I did yesterday evening.
There should be references, dates, statuses and enough history to identify what happened.
Supportability starts in the database.
Offline thinking is useful even for online products
Most web products still require a connection.
But I can design around temporary loss of connection.
For a long form, can I preserve input so a network failure does not erase everything?
Can I show that the device is offline before the user submits?
Can I prevent a destructive action from being repeated when the browser retries?
I do not have to turn every web app into a fully offline application.
I should still think about what the user loses when connectivity becomes unreliable.
Simplicity matters more than developer excitement
A local product can easily become overloaded because the market has many possible needs.
Payments.
Marketplace.
Airtime.
Data.
Profiles.
Advertising.
Messaging.
Rewards.
Each idea can sound useful.
The danger is building a platform that does everything badly.
I have become more interested in one clear job done reliably.
A focused product is easier to explain.
It is easier to support.
It is easier to make fast.
It is easier for the user to decide whether they need it.
I test on the conditions I claim to serve
If I say I am building for mobile users, I should test on a phone.
If I say the product is lightweight, I should inspect its network usage.
If I say it works on weak connections, I should throttle the network and see what happens.
If I say it is easy for a small business, I should watch a person who did not build it try the core workflow.
Assumptions become product debt when I never test them.
Local problems can produce stronger products
Building for Nigerian users is not about creating a lower standard.
It is about creating a more specific standard.
The product should still be secure.
It should still be fast.
It should still be understandable.
But the decisions should reflect the environment where the value is created.
That is one reason I like building locally relevant products.
The constraints force me to ask better questions.
Not:
What feature is popular in another app?
But:
What would make this action easier and more trustworthy for the person actually holding the phone?
That is the kind of question that turns technology into a product.