Deem @ Work — eProcurement
Corporate buying with twenty-six approvers, four catalogue types and five kinds of user. The job was to make an enterprise purchase feel like a consumer one — without hiding what it actually costs you to make it.
Create requisition — the whole screen. Spend balance and cart stay in the header; the requisition's own total, product count and purpose sit above everything else. The 26 Approvers panel expands in place to draw the entire approval path before submission — supervisor, then IT, marketing and sales in parallel, then accounts, two tiers of management, and finally the CEO. Below it: the three-step progress bar, and the cart grouped by category with per-category totals, every line labelled by where it came from — hosted, punch-out or off-catalogue.
approvers a single requisition could pass through — drawn as a path before submission.
user groups written up separately: employee, buyer, approver, receiver, observer.
catalogue types unified in one buying flow: hosted, punch-out, off-catalogue, Deem.
wireframe batches, versioned to v14–v22 through client review.
-
Agree what the product is, in writing
Week one produced a stakeholder vision report: “One Deem” — one product serving SMB, mid-market and Fortune 500 — with business, product and design goals written down. Everything later got argued against that page rather than against opinion.
-
Draw the ecosystem before the screens
We mapped the whole procure-to-pay loop — users, four catalogue types, cart, project and standard requisitions, approval, purchase order, supplier, shipment, receipt, payment close. The information architecture was cut from that diagram, not from a feature list.
-
Five user groups, not one “user”
Employee and buyer — the infrequent and the frequent purchaser — plus approver, receiver and observer. Each was written up as what they need to know and what they need to do, and the navigation followed from where those diverged.
-
Put the cost of buying on screen
Spend limit, current requisition cost and remaining balance travel with the buyer through the entire flow, and the approval path is drawn before submission. Policy shown at the moment of the decision, rather than enforced afterwards by a rejection.
-
Design the approval, not just the request
Approvals were the hard part: groups where any three of four can approve, all-or-nothing requisitions, line-item reject and modify, expedite that routes via a supervisor, approve-on-behalf when someone misses their cutoff. Each got its own task flow.
-
Batch the delivery
Wireframes shipped in three batches — requisition and punch-out, then approvals and purchase orders, then projects, templates and subordinate management — versioned to v14–v22 through client review, then specified to pixel level and built as HTML.
“Upfront information on steps and time required to get the product delivered… Inform users about the corporate buying policy.”Stakeholder Vision Report · 21 October 2014
- Home & recommendations
- Off & punch-out catalogue
- Search & compare
- Cart & requisition
- Shipping & billing
- Approvals
- Purchase orders
- Receiving
- Projects & budgets
- Requisition templates
- Manage subordinates
- Customer administration
The engagement ran from ecosystem map through interaction specification to coded pages — eight weeks of front-end build sat inside the same scope as the design. What engineering received was a working interface with its rules already settled, not a set of images to interpret.
Show the queue before the request
Drawing all twenty-six approvers as a path turns an invisible corporate process into something a buyer can see and plan around — and makes the organisation's own approval sprawl impossible to ignore.
Policy as information, not a blocked button
Spend limit and balance stay on screen for the whole flow. Compliance designed as something you can see while deciding, rather than something that rejects you afterwards.
One product, three market sizes
“One Deem” meant the same interface serving a ten-person company and a Fortune 500 with four approval tiers. Templates, projects and a dynamic subordinate tab are where that variation was absorbed instead of forking the product.