Case study · Product design · B2B SaaS · ERP for Indian SMEs
Quorum, one login, one stock record.Hug × Hug
Quorum is an ERP for Indian small businesses. It runs procurement, inventory, orders, bookings and approvals in one product. I designed it end to end, from competitor research to the full app and its marketing website, for mobile, tablet and desktop.
Design complete, in development
Role · Solo product designer
4–6 months
Mobile · Tablet · Desktop
The dashboard, desktop and phone
Modules
1010
modules mapped in the information architecture
Screens
150+150+
app screens and states designed
Breakpoints
33
for every screen: mobile, tablet, desktop
Website
66
marketing website pages
Problem
Indian SMEs run goods and services on separate tools. A salon that sells shampoo, or a detailer that buys wax, needs two or three apps that don't talk to each other.
Approach
One product with a shared shell. Fast floating screens for data entry, a dashboard that flags work and clears routine approvals in one tap, AI docked beside the work, and onboarding that asks only six questions.
Outcome
Eight modules designed across three breakpoints, plus the marketing website, handed off to development. The founders called it “extremely high quality output”.
Team
Worked directly with the client's founders
Scope
Research, IA, flows, UI, website
01 · Context
A client brief with room to rethink
The client gave me a product requirements document and a functional spec. The PRD said it plainly: change the flows and modules wherever that makes the product easier to use.
The gap
Most SME tools pick a side: goods (stock, POs, GST) or services (staff, rooms, time slots). Many Indian businesses are both.
Who it serves: three users, three front doors
Login → Dashboard
Single-entity owner
One business, one branch. Lands straight on their dashboard.
Login → Entity picker → Consolidated view
Multi-entity owner
Branches or subsidiaries. Needs a combined view and a quick way into each entity.
Login → Platform console
Super admin
Runs the platform: onboards clients, sets plans, handles billing and support.
Role-based on top of all three. Every client assigns roles to their users, so each screen also has to work when parts of it are hidden or read-only.
02 · Research & principles
Eight competitors, one recurring gap
I reviewed the tools these businesses already use, in two groups: goods tools and booking tools. For each, I noted why people buy it and where it stops being useful.
CompetitorWhy people buy itWhere it stops
Goods
Zoho
The suite
Why people buy it: Cheap, trusted, native e-invoicing and e-way bills
Where it stops: Stock, accounts and staff live in separate apps. You can't see staff and stock on one screen.
Goods
Odoo
The Lego set
Why people buy it: Customisable, handles manufacturing and multi-company
Where it stops: Pay per app and often a consultant to set it up. Master-detail navigation means a page load for every record.
Goods
Kladana
The workhorse
Why people buy it: Strong bill of materials and batch tracking
Where it stops: Treats labour as a cost, not a bookable service. Dated interface.
Goods
Precoro · Coupa
The specialists
Why people buy it: Best-in-class approvals and 3-way matching
Where it stops: Procurement only, priced for enterprise. You still need another tool to sell.
Services
Calendly
The meeting
Why people buy it: Zero learning curve, perfect calendar sync
Where it stops: No back office. It can't deduct stock or raise a GST invoice.
Services
Trafft
The salon app
Why people buy it: Visual staff and slot picking, deposits
Where it stops: “Extras” isn't inventory. There are no batches or POs for products used in a service.
Services
Reservio
The reminder
Why people buy it: Visit history and strong no-show reminders
Where it stops: Schedules people only. It can't require staff, a room and a machine together.
Feature depth: nobody covers procurement, inventory, sales and bookings together
Ratings from my teardown, on a four-step scale from basic data entry to best-in-class.
Capability
Precoro
Coupa
Zoho
Odoo
Kladana
Procurement
Inventory
Sales channels
None
None
Service booking
No
No
Separate app
Separate app
No
Indian compliance
Where Quorum can win
Goods and services in one product, native marketplace sync, and asking the data questions instead of learning menus.
Where it's exposed
No track record against Zoho, rivals that start at $0–$10 a month, and frequent GST rule changes.
What the research told me: five rules I designed every screen against
Each comes from a competitor gap or a line in the brief. The decisions in chapter 05 refer back to them.
P1
One screen for staff and stock
From: Zoho's split apps and Trafft's missing inventory. A salon owner shouldn't open two tools to see who's free and what's in stock.
P2
Never leave the list to enter data
From: Odoo's click, load, back pattern. Purchase and sales teams key in dozens of documents a day.
P3
Quick yes on the dashboard, full review in Approvals
From: Approvals carry money. Routine items should take one tap, but anything that needs a closer look belongs on a screen built for checking.
P4
Help sits beside the work
From: The PRD. AI chat opens at the side, not floating, so people can keep using the tool while they ask.
P5
Ask only what's needed now
From: Odoo's consultant-led setup. Get owners to a working dashboard first and configure modules when they're opened.
03 · Information architecture
One shell, eight sections in the sidebar
Research mapped ten modules. I grouped them by the job the owner is doing, so the final sidebar has eight sections: watch the business, buy and stock, sell and serve, then insight and control.
The sidebar · eight sections and their pages
Before the shell
Onboarding
6 required questions, then optional module setup.
App shell
Sidebar
Global search
Entity switcher
Notifications
AI drawer
Profile
Separate console
Super admin
Tenants, plans and feature flags, logs, impersonation.
Watch
Dashboard
reads + quick approve
KPI row with trends
Pending approvals: one-tap approve
Critical alerts
Sales vs spend
Activity feed
Buy & stock
Procurement
PR → PO → GRN
Overview
Requisitions
Purchase orders
Goods received + QC
Invoices
Vendors
Inventory
goods + services
Overview
Catalogue
Stock: reserved vs available
Bin locations
Adjustments
Stock ledger
Sell & serve
Orders
every channel
Overview
Quotes & pro-forma
Orders & invoices
Returns
Customers
Discounts
Bookings
time as inventory
Overview
Calendar: day, week, month
New booking
Services
Resources & availability
Insight & control
Reporting
trends + exports
Trends
Pre-built reports
Custom report
Download data in 5 steps
Approvals
where money moves
Overview
To review, with SLA
My requests
Workflow builder
Settings
admin only
Organization
Users & roles
Integrations
Templates
Notifications
Opens as a floating panel over its listBuy & stockSell & serveInsight & control
How the sections connect: inventory sits in the middle of everything
The hybrid model works because every module writes to one stock record. This is the data path behind P1.
Teal arrows change stock. Goods come in through procurement and go out through orders; an accepted return puts them back. Bookings share the catalogue. The dashboard only reads stock. Its one action is a quick approve, and anything complex goes to Approvals.
04 · Key flows
Procure to pay, lane by lane
The longest chain in the product crosses five roles and the system. Read it top to bottom: each column is a role, so you can see exactly where work changes hands.
Six hand-offs, one record. The dashed box is automatic. Rejections go back to the requester with a reason, and stock moves only after QC, not when goods arrive.
The screens behind each numbered step
Six steps, six panels, laid out as one board in the order the flow runs (1, 3 and 5 on the left; 2, 4 and 6 on the right). Point at a panel, or at its step underneath, to light it up.
Procure to pay · steps 1–6
1Raise PR
2Approval
3Create PO
4Create GRN
5Quality check
6Invoice
1Raise PRLine items and cost summary in a floating panel.
2Approval rulesCriteria and stages decide who approves, set without code.
3Create PORequisition details carry over, so purchasing only adds price, tax and terms.
4Create GRNReceived quantity per line, with a delivery challan upload.
5Quality checkAccepted and rejected quantities, a reason and a photo.
6Record invoiceLinked to its PO and GRN for the 3-way match.
Smart routing: three doors, five landing spots
Trial users, buyers and returning users start differently. Two checks decide where each one lands, so nobody sees a wizard they don't need.
Diamonds are system checks. A returning buyer whose trial expired skips setup entirely, and only multi-entity owners ever see a picker.
05 · Design decisions
Seven decisions that shaped the product
Decision
Decision
Decision=Floating panels
P2 · Every create and edit form
Floating screens instead of page loads
Problem
Master-detail navigation reloads the page for every record. Teams lose their place in long lists.
Decision
Forms slide in over the list as a panel. The list stays visible behind, and closing returns you to the same row.
Option A · Master-detail
→
←
Every record is a new page. Coming back reloads the list and loses your filters and place.
Option B · Floating panel · chosen
The list stays behind a panel. Close it and you're on the same row, ready for the next entry.
Wireframes redrawn for this case study to show the two patterns I compared, using Odoo's master-detail flow from my research as option A.
Sneak peek
Sales invoice. Line items, totals and a payment QR in one panel, with the orders list still behind it.
Sneak peek
Same pattern in Procurement. Requisitions, orders, receipts and invoices as tabs on one list, with every form opening over it.
Decision=Approvals
P3 · Dashboards and approvals
One tap for routine approvals, a full screen for the rest
Problem
Managers need to clear routine requests fast. A full review on a busy dashboard is one misclick away from releasing the wrong purchase order.
Decision
The dashboard card shows priority, amount and requester, with approve and dismiss for routine items. Anything that needs checking opens Approvals, where the full request and audit trail sit together.
Sneak peek
In Approvals. The full queue, with SLA breaches counted separately.
Sneak peek
On the dashboard. Priority tag, amount, requester, then approve or dismiss.
Decision=AI beside the work
P4 · Global shell · set by the brief
AI beside the work: the brief's call, my execution
From the brief
The PRD asked for AI chat that opens at the side, not floating, so people can keep using the tool while they ask.
My part
A permanent entry at the foot of the sidebar, a drawer that leaves the data visible, suggested prompts for common questions, and answers that link back to the real report.
Sneak peek
In context. The drawer shares the screen with the procurement workflow it is answering about.
Sneak peek
Answers link back to data. “View full report” opens the real report.
Decision=Onboarding
P5 · Onboarding
Six questions, then the dashboard
Problem
The PRD listed ten setup sections, from PAN and CIN to vendor masters and price lists. Asking for all of them up front stalls a trial.
Decision
Organization details are required. Every module setup is optional, skippable and resumable from a left-hand checklist. A final review lets people edit any section before they start.
Sneak peek
Step 1, required. Legal name, tax IDs, contact and address.
Sneak peek
Review. Each section shows as configured or pending, with an edit link.
Decision=Bookings + inventory
P1 · Bookings + inventory
Services are bookable, not just billable
Problem
Goods tools treat labour as a cost line. Booking tools can't link a staff member, a room and a machine to one slot.
Decision
Staff, rooms and equipment are all “resources” with weekly availability. A booking checks every resource it needs, and the catalogue holds products and services side by side.
Sneak peek
Bookings overview. Today's schedule and how busy each resource is.
Sneak peek
Availability. Set per day, by time range or specific slots.
Decision=Multi-entity
Multi-entity owners
One login, every branch, one comparison
Problem
Owners with several businesses log in and out of each to compare them.
Decision
They land on an entity picker with a consolidated dashboard and reports that compare entities side by side. Approvals are pooled across entities.
Sneak peek
Entity picker. Status, role and last activity on each card.
Sneak peek
Consolidated reports. Revenue contribution by entity over time.
Decision=Reporting
Reporting
Custom exports as a five-step wizard
Problem
A blank “build your report” screen asks owners to think like analysts.
Decision
Pick a module, then fields, filters and a date range, then review and download a CSV. Pre-built reports cover the common cases.
Sneak peek
Step 2 of 5. Fields shown as chips, with the stepper always visible.
Sneak peek
Pre-built first. Monthly sales, valuation, procurement and returns.
Same shell everywhere: learn one module, know them all
Every module opens on its numbers and quick actions, then lists, then floating forms.
InventoryOrdersBookingsMulti-entity
InventoryStock trend, fast and slow movers, low-stock alerts.
OrdersOrders and invoices trend, revenue by channel, top customers.
BookingsWeek calendar of every booking by time slot.
Multi-entityConsolidated revenue, spend and order breakdown across entities.
06 · Responsive & visual system
Designed for the phone in the warehouse too
I designed every dashboard screen and every website page for mobile, tablet and desktop. Owners check numbers on the move, and store staff receive goods with a phone in hand.
Dashboard, desktop. Two-column widgets beside a fixed sidebar.
Dashboard, mobile. KPIs in a 2×2 grid, everything else in one column. Approve becomes a full-width button.
Homepage, mobile. Feature tabs, the before-and-after table and pricing cards stack into one column.
Desktop
Full sidebar, KPI row, side-by-side widgets and panels that slide in over lists.
Tablet
The same modules reflowed for touch, for counters and receiving desks.
Mobile
The sidebar becomes a menu button, KPIs sit in a 2×2 grid, and widgets and cards stack into a single column.
Visual system: calm navy shell, one action colour
ERP screens are dense, so the palette stays quiet and lets status colours and the teal action colour stand out.
Palette
Shell navy#0F172B
Action teal#019F93
Mint surface#E3F4F3
Canvas#F4F4F6
Card#FFFFFF
Notice#FEF5EA
Navy holds the sidebar and footer. Teal marks every primary action and selected state, and nothing else.
Status language
ApprovedPending approvalRejectedIn transitDraft
The same five states across PRs, POs, orders, bookings and approvals, so a colour always means the same thing.
07 · Marketing website
A website that sells by industry
I designed the marketing site in the same visual language as the app. It leads with the “one screen” promise, then shows each industry the modules it would use. Six pages, laid out as one board.
HomeIndustriesFeaturesPricingResourcesBook a demo
HomeThe promise, three-step setup, a before-and-after table and pricing.
IndustriesTrading, salons, clinics, fitness and tutoring, each with the modules it uses.
FeaturesEvery module and how they connect, on a dark “foundation” band.
PricingThree plans, a full comparison and a competitor table that admits what Quorum doesn't do.
ResourcesSetup guides, checklists and walkthrough videos for owners and their accountants.
Book a demoA 30-minute walkthrough on the visitor's own business type.
08 · Outcome & reflection
Designed, handed off, being built.
Quorum is in development, so there is no usage data yet. This is what I delivered, and the metrics I'd track from launch to test the design.
It was a pleasure working with Yashita for our website and SaaS platform design. She was extremely professional and understood our requirements very quickly. She delivered on a range of design requirements single-handedly, on time and with extremely high quality output. I would definitely work with Yashita in the future as well and would recommend everyone reaching out to her for all design requirements.
The client's founders · Quorum
What I delivered
Research: 8 competitors, a feature matrix and positioning
IA for 10 modules plus onboarding, with a glossary
Happy-path flows for every module, including routing logic
App UI for 8 modules and the multi-entity views
Every screen designed for mobile, tablet and desktop
A six-page marketing website, also responsive
How I'd measure it after launch
Time to first PO
From signup to the first purchase order. Tests whether the six-question onboarding gets people working quickly.
Entry speed
Documents created per session with floating screens. Compare against a sample of Odoo users if the client can recruit them.
Approval turnaround
Median time in “Pending” and the share of SLA breaches, before and after workflow rules.
Hybrid adoption
Share of accounts using both Bookings and Inventory. The core bet of the product.
Vocabulary first
Writing the glossary before the screens gave everyone one meaning for each term, and it decided the labels on screen.
Consistency scales a solo designer
One shell, one panel pattern and one status language let me cover eight modules and three breakpoints alone.
Next, test with real operators
I'd run task-based sessions with store managers and owners: receive a delivery, raise a PO, finish onboarding.
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
Sneak peek
