Enterprise • B2B • Real estate
Construction Tender Management System
End-to-end tender platform for a large-scale real estate authority in Saudi Arabia — three roles, one coherent product
TL;DR
Designed an end-to-end construction tender platform for a large-scale real estate authority in Saudi Arabia. Led three major design pivots against stakeholder direction — each backed by user research. Post-launch: onboarding time cut from 8 days to 4, bid errors down 28%, submissions up 34%.
The Problem
Email chains, Excel templates, disconnected documents — delays, repeated errors, zero visibility across the bid lifecycle. Three different user roles (clients, bidders, evaluators) with opposing mental models.
The Solution
Single platform with scope creation, pre-qualification, evaluation criteria, Q&A, and NDA/EOI flows. In-app editing over upload-only; scoped Arabic where it mattered; unified role-based navigation.
The Impact
50% reduction in onboarding time (8 days → 4). 34% increase in bid submissions. 28% reduction in bid errors. 5,200 average bids per tender.
Onboarding time
The Problem
The client managed large-scale construction tenders across multiple contractors, evaluators, and procurement teams. The existing process relied on email chains, Excel templates, and disconnected document handling — creating delays, repeated errors, and zero visibility across the bid lifecycle.
The core challenge wasn't just digitizing the workflow. It was serving three fundamentally different user roles — clients building tenders, bidders submitting proposals, and evaluators scoring responses — without fragmenting the interface or duplicating effort.
Constraints
- System complexity: Scope creation, pre-qualification, evaluation criteria, Q&A, bilingual documentation, and NDA/EOI legal flows — all within one coherent product.
- User diversity: Clients (project managers), bidders (contractors and estimators), and evaluators had opposing mental models and competing priorities.
- Language: The requirement was full Arabic/English bilingual support.
- Excel dependency: All users were habituated to spreadsheet workflows; bidding data mapped to multi-level BOQ structures from Excel.
- Regulatory context: Local procurement rules required formal NDA execution and EOI stage-gating before bidders could access tender documents.
Three Decisions That Shaped the Product
Decision 1: In-App Editing Over Excel Upload-Only
Stakeholder position: Download a template, fill it in Excel, re-upload. Simple, low dev cost, familiar.
The problem I saw: Last-minute changes — common in construction bidding — would force a full re-upload cycle. There was also no way to surface a running total without opening the file externally.
My call: Pushed to build in-app editing on top of Excel upload. This added development scope but unlocked two things stakeholders hadn't anticipated: live total calculation visible in the Bid Overview panel, and the ability for evaluators to compare bids without exporting.
The stakeholder mandate was Excel-upload-only for bid submissions. I pushed back after research showed that formatting mismatches during upload were a primary source of bid errors. I proposed in-app editing on top of Excel upload, which unlocked live bid totals and real-time evaluator comparison. Post-launch, we discovered multi-department paste behavior we hadn't anticipated, which validated the in-app approach further.
Post-launch finding: Users started pasting data from multiple department Excel files directly into the grid. This introduced overwrite risk we hadn't designed for. We responded with a targeted copy-paste feature that preserved source structure on paste — solving the real behavior rather than blocking it.
Decision 2: Scoped Arabic — Not Platform-Wide
Stakeholder position: Full Arabic/English bilingual throughout the entire platform.
The problem I saw: Building bilingual UI everywhere is expensive and increases maintenance risk. More importantly, I hadn't validated where Arabic was actually needed.
My call: Ran targeted interviews and mapped where Arabic-speaking users dropped off or needed support. The finding was clear: the need was concentrated at the agreement and legal documentation stage — specifically the EOI and NDA flows. Contractors filling in scope data were typically bilingual procurement professionals. The legal documents were the barrier.
Decision: Implemented bilingual display only in Registration, EOI, and NDA screens. All other surfaces remained English-primary.
The initial direction was full Arabic language support across the entire platform. I scoped Arabic to only the Registration, EOI, and NDA legal flows based on user research showing that technical bid content was exclusively authored in English. This reduced development scope significantly and avoided RTL layout issues in complex data grids.
Outcome: Reduced implementation scope significantly without impacting the user group who genuinely needed language support.
Decision 3: Role-Based Architecture Without Interface Fragmentation
The challenge: Three roles, three different jobs-to-be-done, but one URL structure and one codebase. The temptation was to build three separate portals.
My call: Unified navigation with role-based view switching. A client, bidder, and evaluator all move through the same tab structure (Scope, Pre-qualification, Evaluation, Q&A) but see contextually filtered data per role.
The Product Owner and I jointly decided to consolidate the originally planned separate portals (client-side and evaluator-side) into a single role-based architecture. This added conditional UI logic but eliminated duplicate maintenance and preserved cross-role visibility.
Why this mattered: It kept the system maintainable and allowed administrators to switch bidder view to review exactly what a contractor would see — which became critical for QA and support.
What I Didn't Build (and Why)
- Full Excel replacement: The scope grid deliberately mirrors spreadsheet conventions. I chose not to abstract away the row/column mental model because the users were estimators who think in BOQ format. Changing that pattern would have extended the learning curve without adding value.
- Arabic everywhere: Already covered. Evidence drove the scope down, not budget.
- Automated bid scoring: Evaluators wanted an auto-ranking system. I pushed back because the evaluation criteria differed per tender and required human judgment on weighting. I designed the Bid Radar as a structured comparison tool instead — giving evaluators the view without removing their authority.
Process
- Discovery: Stakeholder workshops, contractor interviews, workflow mapping across the existing email and Excel process.
- Definition: Journey mapping across three roles. Identified the five-stage tender lifecycle: Setup, Pre-qualification, Bidding, Evaluation, Award.
- Design: Information architecture first — single navigation structure serving all roles. Then interaction design per stage, starting with the highest-complexity surface (scope grid) to validate technical feasibility early.
- Iteration: Three rounds of design review against stakeholder direction. Each pivot documented with the reasoning and the alternative considered.
- Validation: Usability testing with 12 participants across client and bidder roles. Two rounds.
Screen Reference
Key screens from the platform, mapped to the case study narrative.
Outcomes
| BEFORE | AFTER |
|---|---|
| 8 days Onboarding time | 4 days Onboarding |
| Lower bid submission rate | +34% Bid submissions |
| Higher bid error rate | −28% Bid errors |
| Fragmented visibility | 5,200 Average bids per tender |
Onboarding time dropped from 8 days to 4. Bid submission rate increased 34%. Error rate fell 28%. The post-launch copy-paste behavior — where users pasted from multiple department spreadsheets — validated that in-app editing was the right call. It revealed real workflow patterns that the upload-only model would have made invisible.
What I'd Do Differently
The dashboard (client setup view) was deprioritized during the engagement. It shipped functional but visually thin. For a platform where project managers return daily, the dashboard needed stronger status signaling — completion percentage per tender stage, deadline proximity indicators, and a cleaner action hierarchy. That's the screen I'd revisit first.
