CASE STUDY 01 / 04

Solo designInteraction designGovTech

Designing government mini-competitions around the two-quote rule.

Open Quotation (OQ) is a request-for-quotation and negotiation flow for government agencies and state-owned enterprises on Mbizmarket. I initiated the project and owned the end-to-end design, with an initial brief from the PM.

Role: Solo designer · Initiated the project
Worked with: PM (initial brief)
Status: Design & prototype
Platform: Web · buyer & vendor

Open Quotation: annotated product screen

Annotated screen from the OQ design file. Profile details are blurred; project and vendor names are sample data from the file.

The 30-second version

The problem

A mini-competition produces several quotes per request, and a round only proceeds with at least two vendors. Buyers need to compare those quotes inside the procurement flow.

My contribution

I initiated the project and designed it end to end: buyer and vendor flows, high-fidelity screens, and a clickable HTML prototype of both flows.

Status

Design and prototype. Production metrics are not included in this case study.

Who it’s for

Three roles, one transaction.

Mbizmarket is a B2B e-procurement marketplace used by Indonesian government agencies and state-owned enterprises. In OQ, a buyer invites several vendors to quote on the same request, compares the offers, negotiates, and moves to approval and a purchase order.

Buyers

Agencies and SOEs. They create the request and choose who to negotiate with.

Vendors

Suppliers, including small businesses (UMK). They send and revise quotes.

Approvers

The buyer’s approver, who signs off before the order goes ahead.

The problem

Business need, user need, design response.

The design had to serve a procurement rule, the buyer’s decision and the existing product at the same time.

Business need

Mini-competitions on the platform

Buyers invite several vendors, compare quotes, negotiate and move to an order on Mbizmarket. A round needs two or more vendors and is cancelled when only one quotes.

User need

Decide who to negotiate with

Buyers weigh price, budget gap, local content (TKDN), delivery time and documents across many vendors. Vendors need a clear invitation and quote flow.

Design response

Rule on screen, comparable quotes

The minimum shown where buyers manage the request, uniform quote cards ranked by price, and one shell for buyers and vendors that matches the live product.

Role, team & status

My contribution.

OQ was my own initiative. The PM gave the initial brief; the design work, from flows to prototype, was mine.

Design

Buyer and vendor UI

Requests, invitations, quote comparison, negotiation, quote details and buyer approval, designed in Figma.

Prototype

Both flows, clickable

HTML pages built with an AI assistant on values measured from the live Mbizmarket UI. I reviewed every page against the design and the live product.

Collaboration

PM

Initial brief for the project.

Key decisions

Three decisions in the design.

Show the minimum where the buyer acts.

The call: The request page explains up front that at least two quotes must come in before OQ can proceed, and the design includes a cancelled state for requests that don’t get there.
Why: The rule decides whether a round can continue, so it sits on the screens where buyers manage the request.
For comparison: Keeping the rule only in help content.
Trade-off: More text on the request pages.

HTML prototype screen (“How Open Quotation works”), in Indonesian.

Uniform cards in a ranked list.

The call: Every quote is a card with the same structure: total in the same spot, savings against the budget, then business classification, local content and documents. Cheapest first by default, and buyers tick who they want to negotiate with.
Why: At this step the buyer is choosing who to negotiate with, across price, budget gap, local content and documents for many vendors.
For comparison: A side-by-side table, the common pattern for quotes. It scrolls in two directions once there are many vendors and attributes.
Trade-off: Row-by-row comparison is less precise than a table; the sort, the budget gap on every card and full details one click away make up for some of it.

Annotated screen from the OQ design file. Sample data.

One shell, two roles.

The call: Buyers and vendors share the same layout with different accents: blue for buyers, orange for vendors.
Why: One design system serves both sides, and the accent shows which side you’re on.
For comparison: Separate vendor pages with their own look.
Trade-off: Orange is limited to the breadcrumb, the role toggle and the active sidebar item; buttons stay blue on both sides.

Illustration made for this page from two design-file screens. Profile details are blurred.

Testing & results

Checks, outcome and what to measure.

What has been checked so far, what is known, and the indicators worth tracking.

Checked

Prototype against the live UI

Scripts compared the prototype’s components, spacing and type with values measured on the live test environment. On 31 Oct 2026 every page shared the same header markup and none used 15px text. A consistency check, not a usability test.

Observed outcome

Design and prototype complete

The buyer and vendor flows exist as a design file and a clickable HTML prototype.

Measure next

Task success and shortlist time

Whether buyers complete a shortlist, how long it takes, and how often they misread a requirement.

Looking back

A rule on screen is a design goal, not an outcome.

The next useful evidence is watching buyers compare real quotes, and tracking how many rounds end with fewer than two.

Screens

From request to quote, two roles in one shell.

Screens from the OQ design file, shown in browser frames. Profile details are blurred; project and vendor names are sample data from the file.

NEXT · CASE STUDY 02 / 04