The project dashboard. Most of the screen is neutral, so the status colours stand out.
Product Design
Design System
Data-Dense UI
Project in progress
Role
Product Designer & Design Engineer, sole designer
Team
Me, one developer, and the founder
Timeline
January to October 2026
Platform
Responsive web app, dark-first, plus marketing site
Status
Live, pre-revenue, handed over to the founder
Live demo
BuildMetrics is for cost engineers, planners and project managers. They open it to learn four things: is my project late or over budget, which BOQ (bill of quantities) items are causing it, where will we finish, and what do I report this period.
The MVP was a fast prototype that did its job. But its numbers disagreed. On the same project and date, earned value and actual cost sat about 10M apart between the BOQ screen and the dashboard. One screen read “Average health 46, Critical” while the projects scored 94, 94, 54 and 62. The same CPI of 0.91 was amber on one screen and red on another.
Numbers that disagree cannot be trusted.
The MVP on the left, the rebuild on the right.
A visual refresh was the fastest option, and it would have failed. Better type and colour on top of two different budgets only make the wrong number look more convincing.
So the rebuild started with trust in the numbers: which values appear on each screen, and whether the product can stand behind them. Only then did I touch the visuals.
01
The rule is simple: a value shows the same number in the same colour on the dashboard, the BOQ screen and the PDF report.
Behind it sits a stricter principle: never show a number the product can’t validate. When I bound the new interface to the real code, I reviewed every value on screen. That review cut 43 of them, including every AI-generated money figure and every confidence chip.
I rejected keeping figures that looked impressive but could not be checked. Recommendations are labelled “Rule-based”, because rules produce them. Labelling them “AI” would claim more than the product does.
The dashboard and the PDF report. Check any figure in one against the other.
02
The MVP showed the same CPI (cost performance index) of 0.91 as amber on one screen and red on another. A status colour that changes between screens tells the reader nothing.
Now there is one status system. Red is reserved for delayed or critical. Amber means at risk. Everything else stays neutral. Health scores use one set of four bands, with thresholds at 85, 70 and 50, everywhere.
I rejected colouring every metric. When every cell is green, amber or red, the eye has nowhere to land. With most of the screen neutral, the one red row is the first thing you see.
Two status colours and four health bands. The same value gets the same colour on every screen.
03
The product is mostly numeric dashboards and long tables, read in long sessions. I designed dark-first so attention stays on the data and the status colours, and deferred light mode until the dark system was proven.
Teal is the brand colour because it sits apart from red and amber. The brand never competes with a status signal.
Interface text is set in Plus Jakarta Sans. Every number is set in JetBrains Mono with tabular figures, so digits share one width and columns align. You can compare two figures by scanning down a column.
Every digit has the same width, so decimal points and thousands line up down the column.
The system covers 50 screens and 159 states, all rendering. It runs on 75 tokens and 12 components, defined in tokens.css.
Two documents carry the reasoning. PRINCIPLES.md holds the rules, led by the one this whole project rests on: never show a number the product can’t validate. DECISIONS.md holds the choices. I recorded 69 decisions during the binding alone.
I wrote them down because the developer and the founder are not designers, and I was leaving in October. A rule without a reason gets broken the first time it is inconvenient. A rule with a reason can be applied to a screen I never designed.
The styleguide, the tokens and the state-patterns sheet. Every state of every screen is accounted for.
The prototype export was split in two. The developer kept the logic. I rebuilt the interface and bound it to the developer’s code, using AI-assisted tools to carry the design into production.
Then I handed the product to the founder. Three things make that safe:
A practice database, so experiments never touch real data.
Guardrails that sort every change request into safe to build, needs review, or needs a developer. Commands that could delete data or touch the live site are blocked.
A plain-language guide and a ranked to-do list.
50
screens
159
states, all rendering
75
design tokens
12
components
A UX audit of the live build found 12 issues. Almost all are now fixed in code.
The new landing page carried over all 66 existing functions, with zero dead links.
The product is pre-revenue with no customers yet, so these numbers measure quality and readiness, not adoption.
The old landing page and the new one. Every existing function still works.
Two lessons. First, I would audit the data layer before redesigning anything. The number disagreements cost more time than any screen. Second, I would agree account ownership and a staging setup on day one, not at handover.
Still open at handover:
Light mode. The palette is not designed yet.
Extreme SPI values. The fix belongs in the calculation engine. Clamping them in the UI would mean showing a number the product can’t validate.
The BOQ screen and the dashboard still need a final reconciliation, waiting on a founder decision.
Arabic. About 2,000 strings are marked for translation.
The new version is live. Open the dashboard at buildmetricsai.com/demo/dashboard.
