Srikant Mehra

Case study 02 / 06iDesign.MarketProcurement2023–2025Shipped

Vendor & PO

Interior design firms buy materials for a project here, from the client’s quote to the vendor’s payment, and I designed it on my own. Over five phases between 2023 and 2025 I built the purchase flow and the spending rules that connect orders to the budget.

  1. 01Quotation
  2. 02Material request
  3. 03Purchase order
  4. 04Delivery
  5. 05Invoice
  6. 06Payment
Create PO step 2, redesigned in 2026: each vendor rate with the BOQ rate under it and the difference in rupees, and a Before you send panel with the remaining budget, the rules that apply and the approver.
Role
Lead and sole designer, research to handoff
Worked with
Founders, product, engineering, firms
Platform
Web, inside iDesign.Market
Scale
5 phases · ~690 screens, dialogs and drawers · 6 spending rules

Interior firms set their margin in the quotation and lose it one purchase at a time. Nothing checks an order against the budget before the money is committed.

Four small drifts

Each one is easy to miss. In this example, together they take ₹22 of a ₹30 margin.

  1. A vendor quotes above the BOQ rate.
  2. More is ordered than the BOQ allows.
  3. Parts add up to more than the item.
  4. The invoice comes in above the PO.

Product context

Interior firms run their projects on iDesign.Market. Vendor & PO is where they buy the materials, against the quotation the client approved.

Terms used on this page

  1. BOQThe approved quotation, line by line: the budget.
  2. BOMWhat one BOQ item is bought as, part by part.
  3. MRThe site’s request for material, with a due date.
  4. POThe order to a vendor, checked before it goes out.
  5. GRNWhat actually arrived, logged against the PO.
  6. Non-tenderBought outside the quotation, with no budget line.
PO

PO-014Deepanshu Steel Corp. · Sharma Residence

Pending · Avinash

Raised from MR-003 · due Fri

Gypsum board 12 mmBOMFalse ceiling

40 × ₹64BOQ ₹58

₹240 over

GI channel, 3 mBOMFalse ceiling

60 × ₹145BOQ ₹150

₹300 under

Cove light profileNon-tender

18 × ₹210No BOQ line

No budget

GRN-07Challan 0412 · received by Ravi

26 of 40 boards

User research

I watched session recordings and spoke to purchase teams and owners. This sample follows one item through six hand-offs, from quotation to payment.

1Quotation

BOQ_Sharma_final_v3.xlsx

ItemQtyRate
False ceiling1,200 sft₹85
Gypsum board 12mm40₹58
Wardrobe3₹48,000

1The BOQ stays a spreadsheet. Nothing checks a purchase against it.

2Material request

Ravi · SiteNeed 40 gypsum boards for the bedroom ceiling. By Friday please

A quantity in a message, without the BOQ line it belongs to.

3Rates

Gupta TradersGypsum 12mm, ₹62 a board. Channels and screws extra.

Ok, send 40

2₹62 against a BOQ rate of ₹58, and nobody compares.

3Bought as boards, channels and screws, so the ceiling’s real cost is hard to add up.

4Approval

OwnerOutgoing call · 1:42Fine, go ahead.

4Every firm approves differently, and the rules live in people’s heads.

5“Pending” with whom? Nobody can tell.

5Delivery

DELIVERY CHALLANNo. 0412

Gypsum board 12mm26 nos

Ordered40

Received by__________

6Material arrives in parts, and nobody tallies it against the order.

6Payment

TAX INVOICEINV-2291

Gypsum board 12mm× 40

Rate₹68

Total₹2,720

Billed at ₹68, above the ₹62 agreed. It surfaces when the project closes.

Pain points

What went wrong the old way, and the hand-off where it shows up.

No.What went wrongWhere
01

The BOQ stays a spreadsheet.

Quotation
02

Vendor rates drift from BOQ rates.

Rates
03

Items are bought as parts.

Rates
04

Every firm approves differently.

Approval
05

“Pending” doesn’t say with whom.

Approval
06

Deliveries come in parts, invoices run high.

Delivery · Payment

Competitor analysis

I compared how other tools check spending, using public pages, help docs and app listings from 2026. Vendor & PO checks each BOQ line.

How each option ties buying to a budget
OptionChecks spending againstSite request to POChecked before the PO goes outBuilt for
Spreadsheet and chatWhat most firms useWhatever’s at handAnyone
ProcoreGeneral contractorsProject budgetcounts once approvedLarge contractors
Studio DesignerInterior designersClient proposalFurnishings
Houzz ProDesigners and buildersSpending reportsSmall studios
PowerplayIndian contractorsMaterial and stocklogged on siteSite teams, mobile
OnsiteConstruction firmsBudgets, material userequest, PO, GRNlimits on requestsSite teams, mobile
Vendor & POInside iDesign.MarketThe BOQ lineMR on BOQ linesspending rulesDesign-and-build firms

Described in its documentationPartlyNot described on its public pages

What I took from it

Where other products put the budget check, the item record and site work.

Finding 1

Other tools count a PO once it’s approved

Procore counts an approved PO as spent. In my 2026 proposal, I moved the check earlier, into the draft.

Finding 2

One record follows the item

Studio Designer keeps one item record from proposal to invoice. Here the BOQ line does that job.

Finding 3

Site teams work on phones

Powerplay and Onsite are built for them. Requests and delivery logs start on site here too.

Design goals

Drawn from the six problems and the other tools: what the module had to do for a firm.

Goal 1

Check orders before they go out

Compare every order with the BOQ while it can still change.

Goal 2

Let each firm set its own rules

Who approves, and what happens when an order goes over budget.

Goal 3

Link every amount to the step before

Each quantity and amount traces back to the request, order or delivery it came from.

What to check

I followed one item from quotation to payment, mapping each check and where the firm’s spending rules apply.

One item, left to right The check at each hand-off Where the rules come from Quotationthe client’s BOQ Material requestthe site asks for it Purchase ordervendor · rate · terms Delivery · GRNwhat actually arrived Invoicewhat the vendor billed Paymentwhat was paid out BOM partsgypsum, channel, screws BOQ balanceasked vs. left to order Spending rulespass · approve · stop Received ≤ issuedchallan, photos, receiver Billed ≤ deliveredbooked deliveries lock Eligible amountPO − already requested Outside-quotationno BOQ line behind it PO settingsset once by the firm The purchase order is the step where the firm’s own settings apply.

Design principles

Four rules I set before drawing any screens, and checked each screen against.

Rule 1

Budget data stays with the item

BOQ quantity, rate and what’s ordered, wherever the item appears.

Rule 2

Firms set the rules in settings

Who approves, and what happens over budget, set per firm in sentences.

Rule 3

Warn before a PO goes out

Rate and budget problems flagged while the PO can still change.

Rule 4

Quantities add up step to step

Requested, ordered, delivered and invoiced each trace to the one before.

User flow

Five people move a purchase from quotation to payment. The firm’s rules check the PO after creation, and payments can’t exceed the order and its deliveries.

Tied to its BOQ line Let it through Ask for approval Stop it No · a reason on the PO Yes Vendor delivers Invoice, or an advance request Approves quotationEvery line becomes a BOQ line Raises a request Creates the PO Rules pass? Approves? Issues the PO Logs each deliveryReceived can’t exceed issued Within eligible?No: an alert before paying Pays the vendor
  • Start and end
  • A decision
  • Stopped or rejected: back to purchase
  • nFixes pain point n from the research

Information architecture

Seven lists show the same purchase orders by project or company, with deliveries, GRNs, invoices and logs attached to each PO.

Side panel Inside One level down Deliveries, payments and logs attach to one PO Vendor & PO · per project or company-wide Purchase ordersMaterial requestsVendorsPayment requestsDeliveriesReportsPO settings Status filtersCreate in three stepsIssue as a link or PDFQuotation itemsOutside-quotation itemsBOM partsType and tagsDocumentsPOs issuedAdvanceAgainst deliveryChallan and photosA GRN per deliveryOrder historyAgainst the BOQPO IDAuto-approval limitsSpending rulesSet once by the firm A purchase order · PO-014 ItemsDeliveries and GRNsInvoices and paymentsActivity log

Key flows

A PO can start from an item list, a material request or a blank order. Each route follows the same steps and spending rules.

Spending rules

Each firm sets, once in settings, what happens when a PO crosses a limit. Every rule has the same three outcomes, each described in one sentence.

Budgetthe PO is over the item’s budget

Outside-quotation itemsno BOQ line to check against

Order quantityissuing more than the MR asked for

Parts of an itemthe BOM ordered piece by piece

PO approvalevery PO, whatever its amount

Auto-approvala spending limit per person

From delivery to payment

Material rarely arrives in one delivery. Each one is logged against its PO, and every payment request is checked against what’s eligible.

  1. Each delivery is logged against the PO, with its delivery challan (the vendor’s delivery note) and proof.
  2. A delivery can be billed once it has arrived, or an advance can be requested before anything arrives.
  3. Eligible amount = PO amount − amount already requested, adjusted for advances.
  4. A request above the eligible amount raises an alert before any payment is made.
  5. Once an invoice is booked against a delivery, that delivery can’t be edited.

Wireframes

I used greyscale frames to test three ways to group items for a PO, then revisited the approach for invoice booking two years later.

Greyscale wireframe: items selected from work orders, one tab per work order, parts nested under an item.
Greyscale wireframe: work-order items grouped by section.
Greyscale wireframe: work-order items grouped by category.
Wireframe: create payment request with request type, vendor, PO number and a summary box.
Wireframe: payment request against an advance, with the PO summary as tiles.
Wireframe: payment request against a delivery, choosing the invoice and the GRN.

Create PO, step 1

  1. Three named steps, always in view. The main button names the next one: “Step 2: Vendor details”.
  2. One tab per BOQ, plus one for non-tender items, instead of one long page listing every quotation.
  3. MR quantity and issued quantity on every line, next to the budget.
  4. A status per line (issued, in progress or not issued), so an item isn’t ordered twice.
  5. Adding an item changes only its button. The row stays where it is, so the list doesn’t shift while you choose.

Payment request

  1. Advance or delivery comes first, because that choice sets the eligible amount.
  2. The PO’s figures come before any input: amount, already requested, booked, advance and balance.
  3. Only the eligible amount is green. It’s the figure to check.
  4. Invoice quantity per line, checked against what was delivered.
  5. The total stays pinned to the footer while amounts are entered.

Design system

Most screens show money and whether it’s within a limit, so I added components for both.

Four components on every screen

  1. Amounts₹ 4,00,000Indian digit grouping, tabular figures, right-aligned.
  2. Variances−₹ 8,00,000Signed and coloured. A minus means over budget.
  3. PO statusPending · AvinashNames the person a PO is waiting on.
  4. Line statusPartly deliveredWhere each line stands, from not issued to delivered.

PO-014Deepanshu Steel Corp. · Sharma Residence

Pending · Avinash
ItemAmountvs BOQLine
Gypsum board 12.5 mm40 sqft × ₹64₹2,560−₹240Partly delivered
GI channel, 3 m60 nos × ₹145₹8,700+₹300Delivered
Cove light profile18 m × ₹210₹3,780No BOQ lineNon-tender
Total, with 18% GST₹ 60,676

The kit

The palette and type are shared with the rest of iDesign.Market. Status colours always come as a pair, tint and text.

Action#0084EF
Heading#333333
Text#41424A
Muted#717789
Line#D9D9D9
Surface#F2F5F8
Selected#EBF6FF
App bar#292929

PO status

DraftApproval pending with youPending · AvinashIssued · by VipinCancelled

Line status

Not issuedIn progressIssuedPartly deliveredDeliveredNon-tender
Type
Inter, 11 to 18. Tables moved from 12 to 14 in 2025, for long item names.
Shape
Radius 8 for controls, 4 for cells, pills for status.
Drawers
Settings and deliveries open as 800px drawers, not modals.
Sources
144 styles from four sources, and Phosphor icons in six weights.

Version history

Five phases shipped between 2023 and 2025. The first put POs in the product, but only flagged overspending after an order was placed.

  1. Ver 2.0 Create PO, items grouped by section.

    2023

    Ver 2.0

    The first build: all items, BOMs, material requests, Create PO from work orders, approvals and delivery proof.

    32 screens · 18 dialogs

  2. Ver 2.1 purchase orders across projects, with status chips.

    2023–24

    Ver 2.1

    Nine areas reworked together, each with a written change list. Status chips, counts, and BOQ rates while choosing items.

    37 screens · 52 dialogs

  3. Ver 2.2 vendor list.

    Jul 2024

    Ver 2.2

    Requests from firms in daily use: custom PO numbers, taxes, vendor documents and sharing. Requests for quotation were designed, then put on hold.

    33 screens · KT 4 and 19 Jul 2024

  4. Ver 2.3 PO details with a rate warning.

    Aug–Dec 2024

    Ver 2.3

    The rules phase: PO settings, auto-approval and guardrails, plus rate warnings, the parts-versus-item lock, reports and payment requests.

    133 screens · KT 20 Aug and 10 Sep · released 15 and 19 Oct

  5. 2025 purchase orders, in one layout with a rail for every view.

    2025

    Redesign

    One layout for every list, Create PO in three steps, settings in a drawer, delivery logs and invoice booking.

    146 screens · KT 21 Jan 2025

What each phase added

Four phases, from version 2.0 to 2.3, shown through the screens that changed most.

Ver 2.0 Create PO: items grouped by section with quantity, unit, BOQ rate, amount, MR, issued, budget and an Add button per row.
Create BOM: one item split into parts with quantities, units and prices.

Ver 2.0 · 2023

The whole chain in the product, in one long flow.

  1. Items with BOMs, material requests, an approval step and delivery proof.
  2. Create PO on one page, with the BOQ rate, MR, issued quantity and budget on every line.
  3. The budget showed only as an overspend, after the PO was created.
Ver 2.1 purchase orders across projects with status filter chips, delivery status, payment status and PO status columns.
Cancel purchase order, asking for a reason.

Ver 2.1 · 2023–24

Nine areas reworked together, each with a written change list.

  1. Status chips, counts and a delivery-status column on company-level POs.
  2. Choose the BOQ in Create PO, with its rate and amount on each line.
  3. “Issue PO” with a link, a download or sharing; cancelling needs a reason.
Ver 2.2 vendor list with legal name, vendor type, contact, documents, POs issued and vendor tags.
Configure purchase order ID: a prefix and next number, or system-generated numbers.

Ver 2.2 · July 2024

Handed over on 4 and 19 July 2024, from firms using it daily.

  1. The firm’s own PO numbering.
  2. Taxes, discounts, and vendors with types, tags and documents.
  3. Requests for quotation were designed, then parked.
Ver 2.3 PO details with an attention banner: vendor rate of 2 items exceeds the BOQ rate, with those rates in red.
Book invoice, pending approval, with a warning in the summary that the invoice amount is higher than the PO amount.

Ver 2.3 · Aug–Dec 2024

The rules phase: handed over in August and September, released in October 2024.

  1. PO settings, auto-approval limits and spending rules.
  2. The vendor rate checked against the BOQ rate, and parts that lock the main item.
  3. Payment requests, and invoices that warn when they exceed the PO.

Final design

The 2025 redesign brought the lists into one layout, made PO creation three steps, and clarified settings, deliveries and payment requests.

Before: Ver 2.0 purchase orders, with every status written as a sentence in one column.
Ver 2.02025

Design proposal

The current flow hides spending rules until after a PO is created. This unshipped 2026 proposal brings them into the order form.

Create PO step 2, redesigned in 2026: six lines with the vendor rate, the BOQ rate and average under it, and the difference against the BOQ in rupees.

Vendor and rates

  1. The BOQ rate sits under every vendor rate, and each line shows the difference in rupees. This replaces the difference column that only filled in after the order went out.
  2. The average price sits next to the rate field. In 2.3 it was in a separate dialog.
  3. Non-tender lines are marked on every screen, because they have no budget to be checked against.
  4. One currency format: tabular figures, Indian grouping, right-aligned. The file’s sample data mixed $ and ₹; I corrected that here.

Before you send

  1. The rules show in step 2: each spending rule from settings, in the same wording, with a pointer to where it’s set.
  2. Remaining budget replaces total budget, since earlier POs have already used part of the total.
  3. The approval route, before sending: who will approve, why, and whether your own auto-approval limit applies.
  4. Fixes are suggested in place: use the BOQ rate, or move a non-tender item to its own PO. Each one names the rule it clears.

What changed

Over two years, the order form grew to link BOQ lines, approval rules, deliveries, invoices and payments to each PO.

What worked

Settings written as sentencesAn owner could read a setting and know what it would do.
BOQ data in every tableQuantity, rate, requested and issued stay with the item.

Next time

Configurable fields, earlier“Manage fields” shipped in 2.3. It should have come first.
Next case study03 / 06 EazyDiner Elite Applying for a credit card inside a restaurant app