Designed a new role-based procurement dashboard for SPG where approvers, school admins, and finance admins see different data and actions, enabling governed purchasing, faster approvals, and finance-ready invoices.
I translated complex procurement governance rules into an end-to-end workflow with clear roles, states, and approvals, keeping UI changes minimal to reduce build risk.
Role
Product Designer (UX/UI)
Client
Box of Books (MindArc)
Contributors
1 Product Owner (BoB), 1 PM, 1 Designer (me) and 3 Engineers
Timeframe
2023
Product type
New procurement gateway (standalone)
Role-based dashboards
Focus
Approver and admin dashboards
Order review workflow
Permissions
Finance outputs
Context
BoB planned to launch a B2B School Procurement Gateway (SPG) as a standalone site, with SSO from the existing BoB platform and a workflow for departments, budgets, expense codes, approval limits, and invoice exports.
A key requirement was that “user and approver dashboards” be defined and scoped as part of SPG, rather than relying on an existing internal tool.
SPG is a multi-system workflow: marketplace purchasing, governance approvals, and supplier fulfilment, connected through a custom UI layer and middleware.
The Problem
SPG needed to support governed purchasing without turning into a complex system that users have to “learn around”. The dashboard experience had to make it easy to:
👀
See what requires action
(especially approvals)
📄
Review orders with the right governance context
budgets, department, expense code, PO reference where required
♽
Track status through the lifecycle
pending, approved, rejected, fulfilled
📤
Export invoices
and reports
for finance and reconciliation
Constraints
Minimal visual changes by design
Because this is an operational dashboard, the goal was usability, clarity, and correctness over visual reinvention. We kept UI changes minimal and focused effort on:
Role-based information architecture
Workflow states and decision actions
Validation and guardrails
Auditability (notes and history)
Exports and invoice access
My approach
Design capabilities by role first, then map to modules
Instead of designing “one dashboard”, I mapped which roles needed which functions, then structured the app to only show relevant modules and actions based on permissions.
Roles
This reduces UI noise and prevents accidental access to high-risk actions.
Same product shell, different capabilities by role to reduce noise and governance risk.
Design solution
1) Role-based dashboard overview
The dashboard uses a shared layout but presents different emphasis by role:
Approver: focus on pending approvals and order statuses
School Admin: school-level order oversight and operational visibility
Finance Admin: budget and payment visibility, reporting and exports
This aligns to SPG’s need for reporting dashboards across user, budget owner, and approver contexts.
School details, recent orders, budget status, payment summary, order summary, time range.
2) Orders as a queue plus review workflow
Orders is the operational hub, with role-specific actions:
Order Approver
sees orders awaiting their decision
reviews order details
approves, rejects, or requests changes
can reassign approvals when needed (leave coverage)
School Admin
sees school-wide orders
manages order exceptions and assignments
supports governance configuration and operational maintenance
Finance Admin
views orders filtered to school
exports reports (CSV)
downloads invoices for ERP processes
Tabs by order state, export to CSV, search, status, invoice download, export to CSV.
3) Single-order review designed for one-pass decisions
The order review screen is designed to reduce approval ping-pong by surfacing:
line items and totals
governance fields per line (location, expense code, department, budget)
primary decision actions grouped together (approve, reject, reassign)
notes and history for auditability and async collaboration
This directly supports the required approval loop: submit → approver review → approve/reject/request info → loop until approved.
Tabs by order state, export to CSV, search, status, invoice download, export to CSV.
4) Users and Settings gated by permission
Users: only School Admin can edit users, roles, defaults, and limits
Settings: school details, addresses, chart of accounts, budgets, departments
BoB Admin: platform-level views and imports (cross-school)
This matches SPG onboarding needs (users, roles, approval limits, chart of accounts, budgets, departments) while keeping high-risk configuration out of everyday workflows.
Tabs by order state, export to CSV, search, status, invoice download, export to CSV.
Where the purchaser flow fits
Purchasing happens in the marketplace, but the dashboard is where governance is enforced and decisions are made. The purchaser flow captures required governance metadata so orders arrive review-ready in the approval queue (reducing missing info and rework).
Key design decisions
Decision 1: Permissioned UI instead of “one heavy dashboard”
Show only what each role needs, to reduce cognitive load and prevent mistakes.
Decision 2: Make order state and ownership explicit
Internal tools fail when users don’t know what happens next. Status visibility across list and detail screens makes the workflow trackable.
Decision 3: Put governance context at the decision point
Approvers can only approve quickly if budgets, departments, and expense codes are visible in the review screen.
Decision 4: Separate high-risk admin configuration
Users, budgets, and chart of accounts are governance controls. They belong behind admin permissions, not in the primary workflow.
Outcomes
Internal dashboard UX is mostly about clarity of responsibility and state, not visual creativity.
“Minimal UI change” can be the right decision, but only if the interaction model and state design are significantly improved.
Trust level: Medium. Your narrative is consistent with an internal governance dashboard. Confidence becomes high only when you add 2–3 annotated screenshots that demonstrate the state and workflow improvements.
Early Validation
Stakeholder walkthroughs (what we validated)
Ran structured walkthroughs with BoB stakeholders to validate the end-to-end procurement workflow: submit → approve/reject/reassign → invoice access → export.
Used realistic scenarios (multi-line orders, missing coding fields, approval exceptions) to confirm the dashboard supports how schools actually operate, not just happy paths.
Cross-functional reviews (what we validated)
Validated interaction patterns, states, and edge cases with the solution architect and engineers to ensure the UI matched system constraints and integration realities.
Confirmed role-based access rules: approvers, school admins, and finance admins see different modules, data, and actions, reducing UI noise and governance risk.
QA readiness (what we reduced)
Held internal QA-style reviews before milestones to identify gaps early (permission leaks, unclear status states, missing confirmation feedback, export and invoice retrieval paths).
↓
Next validation
When SPG is live, measure:
approval cycle time (submitted → approved)
rejection reasons (missing codes, budget mismatch)
export usage (CSV, invoice downloads)
support tickets tied to approvals, budgets, and invoice retrieval
Key challenges
Governance without friction: capturing departments, budgets, and expense codes without turning purchasing into form work.
Role complexity: designing one product that behaves differently for approvers, school admins, and finance admins without fragmenting the experience.
State clarity: making “pending, approved, rejected, unfulfilled” unambiguous so ownership and next steps are obvious.
Feasibility across systems: ensuring UI states and actions align with what the integration can guarantee.
What I learned
Internal dashboard UX is mostly about clarity of responsibility and state, not visual creativity.
“Minimal UI change” can be the right decision, but only if the interaction model and state design are significantly improved.
Trust level: Medium. Your narrative is consistent with an internal governance dashboard. Confidence becomes high only when you add 2–3 annotated screenshots that demonstrate the state and workflow improvements.
1) Role-based UI reduces mistakes more than UI polish
The biggest UX win came from showing only the functions each role needs, rather than redesigning visuals.
2) “Status” is not metadata, it’s the primary UX
Users make decisions based on state and ownership. Clear statuses in list and detail views prevented confusion and repeated follow-ups.
3) Decision screens must be “one-pass”
Approvals slow down when context is fragmented. Bringing order summary, governance fields, and actions into a single review surface reduced back-and-forth.
4) Admin configuration is product risk
Users, budgets, and chart of accounts are high-impact settings. Gating these behind admin permissions is a UX and safety decision.
Feasibility validation is a design skill: many “UX issues” were actually system-state or data-contract issues. Aligning early with solution architecture prevented expensive rework later.
Role-based UI is a safety mechanism: hiding irrelevant actions is not just decluttering, it reduces operational mistakes and governance risk.
A one-pass review screen is the difference between smooth approvals and email chasing: approvals speed up when context and actions live in one place.
Internal tools need explicit confirmation and audit trails: users need to know what changed, who did it, and what happens next.
Custom app for School's admin
Overview dashboard, order management, payment management, User management & Budget Allocation User and Budget allocations,
Procurement App
Orders
Overview dashboard, order management, payment management, User management & Budget Allocation, User and Budget allocations
Final Design
School Procurement Marketplace - streamlines with tailored supply options, categorised shopping, admin-approved orders, and efficient delivery, reducing administrative burden.