If You Cannot See It, You Cannot Run It: Data Visualisation in Business Software

A managing director I worked with in Kampala once handed me a 47-page PDF and said, "Tell me where we are losing money." Every page was a wall of small numbers. He had been staring at it for two hours. He could not answer his own question.

I closed the PDF, opened a simple line chart of monthly gross margin by branch, and pointed. One branch in Mukono had been bleeding margin for nine months in a row. The line dropped. It was unmistakable. He looked at it for ten seconds and reached for the phone.

That moment is the whole argument for data visualisation in business software. Numbers in tables hide. Numbers in charts speak. The software that wins in your business is the one that turns your data into pictures your eye can read in seconds — not reports your finance officer reads on Sunday evenings.

This article is for two audiences. The first is the CEO, managing director, or department head deciding which software to buy. The second is the developer or IT lead being asked to build or evaluate it. Both groups need the same vocabulary, because both groups will live with the consequences. Charts are not decoration. They are the user interface of business decision-making.

Why the Eye Beats the Spreadsheet

The human brain processes images roughly 60,000 times faster than text. That is not a marketing claim — it is basic cognitive science. Your eye sees a downward slope before your conscious mind has finished reading the column heading. Show a manager a table of 24 monthly revenue figures and they will hunt. Show them a line chart and they will know.

This matters because every business decision sits on top of the same question: what changed? Sales fell — when, where, by how much? Stock turned slowly — which products, which branches? Cash flow tightened — what tipped it? In a table of numbers, you must compute the change in your head. In a chart, the change is the shape of the line. The work is already done.

I have watched this play out in boardrooms across the continent. The CEO who gets a weekly dashboard makes faster decisions than the CEO who gets a weekly report, because the first one sees the problem and the second one reads about it. Speed of seeing translates directly into speed of acting. Over a year, that compounds into the difference between a business that adjusts and one that drifts.

The Five Charts Every Business System Owes You

Most business software ships with dozens of report types. Ignore most of them. The work of running a company sits on a small handful of visualisations, used relentlessly. If your software does these five well, the rest is decoration.

The trend line. A simple line chart over time. Revenue by month, stock value by week, cash position by day. This is the most-used and most-abused chart in business. It must be ruthlessly clean. One axis labelled. One unit. One line, or at most three. No 3D effects.

The comparison bar. Horizontal or vertical bars ranked by size. Sales by branch. Margin by product line. Days outstanding by customer. This chart exposes outliers — the branch dragging the average down, the client who has stopped paying.

The composition stack. A stacked bar or treemap showing what is inside the total. Revenue by category. Inventory by ageing band. Pie charts work for two or three slices, but stop using them beyond that — humans cannot judge angles accurately.

The distribution histogram. A bar chart that groups values into ranges. Order sizes, payment delays, ticket resolution times. Averages lie. A distribution tells you whether your "average" is a real average or the result of a few extreme values pulling the rest.

The progress gauge or KPI tile. A single big number, with last period's number underneath, and an arrow showing direction. This is what goes on the homepage of any dashboard worth opening. It must be readable from across the room.

If your prospective software cannot produce these five at a quality you would put on the boardroom screen, walk away. Everything else — fancy heatmaps, sankey diagrams, geospatial overlays — is icing on a cake that has not been baked.

What Good Visualisation Looks Like

A good chart has one job and does it. The title states the question being answered, not the data being shown. "Revenue by branch, March 2026" is fine. "Branch performance — are we losing the south?" is better. Axes are labelled with units. Numbers are formatted for humans — UGX 1.2M, not 1,234,567. Colours mean something, or they are not used.

A sloppy chart hides its job under decoration. 3D pies that distort the slices. Dual axes that let you put any two unrelated lines on top of each other. Truncated y-axes that make a 2% movement look like a cliff. Legends in a corner, far from the data they label.

I am picky about this because the difference is not aesthetic. It is operational. A misleading chart causes a wrong decision. I once saw a CFO insist that a category was growing because the bar in the dashboard was getting taller. The chart was set to "auto-scale" each month — the bar grew because the y-axis quietly shrank. Underlying revenue was flat. He was about to hire two more salespeople for a category that did not need them.

For developers and IT teams, the practical rules are short. Default to bar and line. Avoid pies above three slices. Never put two unrelated metrics on dual axes. Lock the y-axis to a sensible zero unless there is a strong reason not to. Pre-format numbers and currencies for the locale — UGX, FCFA, KES are not optional. Use colour-blind safe palettes; about 8% of men cannot distinguish red and green, and your CFO might be one of them. And remember that mobile phones are the primary screen for many African managers — every chart must read at 360 pixels wide, not just on a desktop monitor.

The Buyer's Demo Checklist

If you are evaluating ERP, accounting, CRM or operations software for your business, the demo is your only real chance to test what the dashboards actually do. Salespeople will show you the prettiest screens. Make them show you these instead.

• Open the live dashboard with your own data, not theirs. Ask for a 30-minute import of a sample of your real numbers and watch the dashboards render.
• Drill from the chart to the row. Click a bar that looks suspicious. Can you reach the underlying transactions in one or two clicks? Real dashboards are doors, not posters.
• Change the date range. Can you compare this month to the same month last year, side by side, in two clicks?
• Resize on a phone. Open the dashboard on the salesperson's phone. If the charts squash or hide critical numbers, your branch managers will not use the system on the road.
• Export to PDF and to Excel. Both must work. Boards still want PDFs. Finance teams still rebuild things in Excel.
• Add a new KPI without a developer. Ask the salesperson to add "average order value" to the homepage in front of you.
• Show me a chart that is wrong. Ask how they handle missing data, partial months, or branches with no transactions. The answer reveals whether the software has thought about the messy reality of your business.

A demo without these checks is theatre. I have rescued more than one client from a bad purchase by simply running this list in front of the vendor. Twice the vendor refused. That answered the question.

A Story From the Field

In 2018, I was helping a multi-branch retailer in central Uganda choose between two inventory systems. One was a well-known international product. The other was a much smaller regional offering. On paper, the international product won everything — bigger feature list, more modules, slicker marketing.

We ran the demo checklist. The international product had beautiful dashboards on the demo dataset. When we loaded a sample of the client's actual data — 4,500 SKUs, three years of history, six branches — three things happened. The trend chart took 40 seconds to render. The branch comparison bar showed branches in alphabetical order, with no way to sort by size. And drilling from a chart to the underlying transactions required exporting a CSV and opening it in Excel.

The smaller regional product did all three correctly in under three seconds. Its feature list was shorter. Its marketing was thinner. But every chart was a door, and every door opened.

We bought the smaller product. Two years later the client still uses it daily. The international product would have been abandoned within six months. Not because it lacked features, but because its visualisations made the daily work harder, not easier.

Building It Right (For the Technical Reader)

If you are on the build side of this conversation — designing software for your own organisation or for clients — the visualisation layer deserves real engineering attention, not a last-minute "and then we'll add some charts."

Pick your chart library deliberately. For dashboards inside web applications, mature options include Apache ECharts, Highcharts, Plotly, and Chart.js. For embedded analytics, Metabase, Apache Superset, and Grafana are open-source and battle-tested. For server-rendered PDFs and emails, you will need a separate path — most JavaScript libraries do not render outside the browser without effort.

Design the data pipeline before the chart. The most beautiful chart will lie if the underlying query is wrong. Define your metrics in writing — what counts as "revenue", what date a transaction belongs to, how a returned item affects yesterday's report. Centralise these definitions in a metrics layer or a set of database views, so the same number cannot mean two different things on two different dashboards. I have walked into more than one organisation where the CEO and the CFO disagreed on monthly revenue, and the answer was that their two dashboards were running different SQL.

Cache aggressively, but expire predictably. Live-querying a million-row table every time a manager opens a dashboard is a recipe for slow, expensive software. Pre-aggregate by day, week, month. Tell users when the data was last refreshed; an old number with a clear timestamp is honest. An old number presented as live is a lie.

Test the empty state, the partial state, and the broken state. What does your dashboard look like on day one of a new branch with no data? On a public holiday with three transactions? When the upstream system was down for two hours? The answers should be designed, not accidental.

The Bottom Line for Decision-Makers

Charts are not a feature. They are the surface on which your software is judged, every day, by the people who paid for it. CEOs and managers do not log in to admire data models or marvel at API integrations. They log in to see the picture. If the picture is clear, fast, and trustworthy, the software earns its place. If the picture is slow, ugly, or misleading, the software gets ignored — no matter what the back-end can do.

When you next sit in a software demo, watch your own eyes. If they keep drifting back to the same chart, that chart is doing its job. If they glaze over, the software has already failed and the salesperson has not noticed yet.

The managing director with the 47-page PDF? We replaced his accounting reports with a six-tile dashboard he could read on his phone. He stopped reading reports. He started running his business.

If you would like a clear-eyed review of the dashboards in your current business software, or help building software that actually shows your team what is happening, explore our consulting services or get in touch for a conversation. You can also read more about our work across more than ten African countries.