Government procurement is one of the most data-heavy decisions made at scale
When a government department floats a tender — for a construction project, a technology system, a service contract — they receive hundreds, sometimes thousands, of bids in response. Each bid must be evaluated against a precise scoring criteria defined in the tender document: technical capability, financial health, past experience, pricing, timelines, and more.
Before this portal existed, that evaluation happened in spreadsheets. Officers manually extracted data from bid documents, populated comparison sheets, cross-referenced scoring rubrics, and produced reports — a process that took days or weeks per tender, and was prone to inconsistency and human error.
Tender analysis tools existed before this project — but they were customer-facing, designed to help vendors prepare and submit bids. No purpose-built tool existed for the department side — the government officers who actually evaluate and decide. That's the gap this portal fills.
Hundreds of bids. Dozens of criteria. One spreadsheet.
The existing evaluation process was not just slow — it created serious structural problems for procurement decisions.
The hardest UX problem: two views, one screen
The department had a very specific requirement — and it created the core design challenge of the project.
"We need to see each bid scored against every criterion — and every bid compared on each criterion."
Two fundamentally different views of the same data were required simultaneously:
View 1 — Per bid: For a given bid, how did it score across all criteria? (Vertical read — one bid, all criteria)
View 2 — Per criterion: For a given criterion, how do all shortlisted bids compare? (Horizontal read — one criterion, all bids)
Both views needed to be accessible without losing context. The data was dense — multiple scoring criteria, each with sub-scores, across potentially dozens of shortlisted bids. Fitting this onto a single screen without it becoming a wall of numbers was the central design problem.
This is a genuinely hard information design problem. Too much data on one screen causes cognitive overload. Too little and the user loses the comparative context they need to make a defensible decision.
PRD first. Then design. No wasted screens.
Given the two-week timeline, I couldn't afford to explore broadly and refine later. I started with the PRD to lock down requirements, edge cases, and the exact data model before opening Figma — which meant every screen I designed had a clear purpose from the start.
I authored the PRD for this project
The PRD defined the core user flows, the data relationships (tenders → bids → criteria → scores), the edge cases (what happens when a bid is incomplete? when a criterion has sub-criteria?), and the two primary views the comparison screen needed to support. This document was the alignment tool with the PM and the development team before any design began.
Solving the comparison screen — three approaches considered
The bid comparison view was the hardest screen in the project. I explored three structural approaches before landing on the solution.
A colour-coded matrix gives officers an immediate visual read of where strong and weak bids cluster — before they read a single number. Green/amber/red scoring cells mean a department head can scan 50 bids in seconds and know which ones warrant closer attention. The drill-down panel handles the detail without cluttering the overview.
PRD — requirements, data model, edge cases
Defined the full scope: tender management, bid ingestion, scoring criteria setup, the comparison view, shortlisting workflow, and report export. Edge cases documented — incomplete bids, criteria with sub-criteria, score overrides with audit trail.
Tender management — the starting point
Officers needed to create and manage tenders, define scoring criteria, and set weightings before bids could be evaluated. I designed this as a structured setup flow — criteria builder with weightings that must sum to 100%, preventing invalid configurations at the point of entry.
Bid management — ingestion and status tracking
A dashboard showing all received bids with their processing status — received, under review, scored, shortlisted, rejected. Officers can drill into any bid to see its submitted documents and manually enter or verify extracted scores.
The comparison matrix — the core screen
The matrix view with sticky bid headers, scrollable criteria rows, and colour-coded score cells. Column selection lets officers show only shortlisted bids. Row filtering lets them focus on specific criteria. Clicking any cell opens the detail panel without leaving the matrix context.
Weighted total scores are calculated automatically and displayed as a final row — giving officers an overall ranking without manual computation.
Shortlisting and report export
Officers mark bids as shortlisted directly from the matrix. The shortlist view generates a structured summary — scores, rankings, and evaluation notes — that can be exported as a report for procurement records and audit compliance.
Built on the existing component library
This project used the component library I had already built for other Stratzi.ai projects — tables, badges, status indicators, side panels, form elements. This meant I could focus design effort on the novel UI challenges (the matrix, the criteria builder) rather than rebuilding foundations from scratch.
Matrix view showing all bids (Innovatech Group, Infinity Solutions, CloudSync Technologies) scored across Scoring Criteria Overview, Documents, Eligibility and Scoring — with missing document flags and numeric totals
Per-bid scoring view showing Evaluation Methodology, Technical Marking, and Submission Details across criteria with score, evaluation summary, status and edit action
Per-bid document list showing document name, link, evaluation summary and missing status flags — filterable by reason and searchable
What was delivered — and why it matters
A government department that previously spent days manually comparing bids can now do it in a single session — with a structured, colour-coded view that is both faster and more defensible than a spreadsheet. The evaluation process becomes auditable by design, not by manual documentation.
What I'd do differently
"If I had more time…"
Two weeks is a genuinely compressed timeline for a project of this complexity — especially one where the PRD and design needed to happen sequentially. The biggest casualty was user research. I didn't get to speak to a single government procurement officer before designing. Everything I knew about their workflow came from stakeholder conversations and domain research. A single half-day session observing how a procurement team actually evaluates bids would have been invaluable — particularly for the comparison view, where small details about how officers read and annotate data could significantly change the design.
I'd also have liked to test the matrix view specifically with data at scale — 50+ bids, 12+ criteria. The design works well in controlled Figma frames, but complex data tables always reveal unexpected usability issues when real data is plugged in. A quick prototype test with a data-heavy scenario would have surfaced those issues before development.
Finally, the criteria builder assumes a relatively flat scoring structure — criteria with simple numeric scores. In practice, government tender criteria can be hierarchical — a criterion like "Technical Capability" might have sub-criteria like "Team Qualifications," "Methodology," and "Past Projects," each scored separately and rolled up. Supporting this hierarchy in the UI was acknowledged as a future requirement; I'd have designed the foundation for it from the start if timeline had permitted.