Most trade databases are designed for people who already know what they are looking for.
That is a problem.
A founder, student or small business owner may have a very reasonable question:
“Is Bangladesh importing a lot of this product? From which countries? Is the market growing?”
But the path from that question to an answer can involve commodity codes, large tables, inconsistent labels and multiple filters.
The Bangladesh Trade Explorer began with a different interface assumption:
Search first. Explain the structure later.
The goal is to let someone search for a product or category and quickly see the scale and direction of Bangladesh’s trade around it.
The live project sits inside TaxHishab.com.
The problem with raw trade data
Trade data is powerful because it can reveal:
- product demand;
- sourcing patterns;
- export concentration;
- partner countries;
- category growth;
- long-term changes.
But raw datasets are not naturally friendly.
They are usually organized around codes and classifications.
For a data analyst, that is manageable.
For a casual user, it creates friction immediately.
Imagine someone considering a small import business.
They may know the product name but not the exact HS code.
If the interface starts with:
“Enter HS6 classification”
the product has already lost many users.
A better experience starts with the language the user already has.
The core interaction
The product is designed around a simple flow:
Search product
↓
Match relevant trade categories
↓
Choose import / export
↓
See value + trend
↓
Inspect partner countries
↓
Download / continue research
That is much closer to how people actually investigate an idea.
The user can begin broadly and become more precise only when precision is useful.
What the page should answer quickly
A strong trade explorer should make five questions easy.
1. How large is the trade value?
The first visual should establish scale.
A user needs to know whether they are looking at:
- a tiny niche;
- a meaningful category;
- or a major import/export market.
2. Is it growing?
One year is rarely enough.
A trend can distinguish a stable market from a sudden spike.
3. Who are the partner countries?
Total import value tells only part of the story.
Sourcing concentration matters.
If one country dominates supply, that creates a different market structure from a category with diversified origins.
4. What exactly does the category contain?
Search terms and official classifications do not always align.
The interface should expose the matched code and description so the user can judge whether the data really represents the product they meant.
5. Can I take the data with me?
Exploration often continues in Excel, Sheets, Python or a presentation.
Downloadable data makes the product more useful than a static infographic.
Why charts are only one layer
A common mistake in data products is to treat the chart as the product.
For Trade Explorer, the chart is only the presentation layer.
The harder questions sit underneath:
- How do product names map to trade codes?
- How do we handle classification changes?
- Which units are comparable?
- How do we distinguish country names consistently?
- How do we label missing years?
- What happens when a search matches many products?
That means the architecture needs a clean data model.
Conceptually:
Trade source data
↓
Classification cleanup
↓
Country normalization
↓
Year / flow aggregation
↓
Search index
↓
API / static dataset
↓
Interactive page
The map and charts should not need to understand the messiness of the source.
They should receive normalized data.
Search quality matters more than chart polish
Suppose the chart is beautiful but the search result is wrong.
The whole experience fails.
That is why search needs its own product thinking.
A useful search system can support:
- exact terms;
- partial terms;
- synonyms;
- category descriptions;
- HS codes;
- common user language.
Searching “phone” should not require the user to know the official phrasing used inside a trade classification.
At the same time, the system should never pretend a fuzzy match is exact.
A good result can show:
Matched category: Telephones for cellular networks…
Code: XXXXX
Why shown: matched “phone”
That small explanation protects trust.
Trade value is not market size
This distinction deserves to be visible.
Imports can help indicate demand, but import value is not the same thing as total domestic market size.
A market may also include:
- local production;
- informal trade;
- inventory changes;
- re-exports;
- services;
- taxes and distribution margins.
Likewise, a large import value does not automatically mean a profitable business opportunity.
The explorer is evidence for research, not a business recommendation engine.
That is why methodology and definitions matter.
From data lookup to business research
The interesting opportunity is what happens after the first chart.
Once the system has a normalized product/category, the site could eventually layer additional context:
- import growth;
- top origin countries;
- concentration score;
- average unit value where units are reliable;
- tariff references;
- seasonality;
- related products;
- export potential;
- historical volatility.
This can turn a trade browser into a market-research starting point.
But every extra derived metric needs clear methodology.
A concentration score, for example, should explain whether it uses a simple top-country share or something like HHI.
Derived metrics are valuable only when users can understand what they mean.
A good data product needs “no data” design
Most dashboards are designed around successful queries.
Real public data requires equal attention to failure states.
The explorer needs to handle:
- no result;
- multiple ambiguous results;
- no data for a particular year;
- partner-country data missing;
- zero trade versus unavailable trade;
- a classification with changed coverage.
“0” and “N/A” are not the same thing.
That distinction is easy to lose visually and important analytically.
Mobile changes the priority
A desktop trade page can show:
- search;
- filters;
- trend chart;
- partner-country chart;
- table.
On mobile, all of that cannot compete for attention at once.
The order should become:
- search;
- matched category;
- headline value;
- trend;
- partner countries;
- details / table;
- download.
The product should answer the main question before presenting all possible dimensions.
Why I put this inside TaxHishab
At first glance, trade data may seem unrelated to tax calculators.
The common thread is actually strong.
TaxHishab is becoming a collection of Bangladesh-specific decision tools.
Some help individuals understand financial rules.
Trade Explorer helps people understand public economic data.
Both take a difficult source and create a simpler path to an answer.
That is the product identity I find more interesting than staying inside one narrow content category.
What I would measure
If I want the tool to improve, pageviews are not enough.
Useful product events include:
- search submitted;
- result selected;
- import/export flow changed;
- year changed;
- chart interaction;
- country selected;
- data downloaded;
- no-result search.
The most important event may be no-result search.
That tells you exactly what users want that the search index cannot currently answer.
In other words, analytics becomes part of the product-development loop.
The larger idea
Trade Explorer is not really about drawing import and export charts.
It is about reducing the distance between a question and a usable piece of evidence.
Someone should be able to arrive with:
“I’m thinking about this product.”
and leave with:
“Now I know roughly how much Bangladesh imports, where it comes from, how the trend looks, and what I should investigate next.”
That is a much more useful outcome than handing them a database.
And it is exactly the kind of data product I enjoy building:
complex underneath, simple at the point of use.
Explore the project: Bangladesh Trade Explorer