E-Procurement System
How can a system carry the complexity of procurement — the process, information and expertise — so school staff don’t have to?
- COMPANY
- ELLAUX for a research & consulting firm working with the Ministry of Education
- ROLE
- Sole UX / Product Designer
- YEAR
- 2022
A better purchasing experience started by understanding the work schools were already carrying.
E-Procurement System
Digital procurement · Education
An end-to-end procurement system designed to help schools manage requests, approvals, supplier selection, purchasing, delivery and accountability in one connected flow.
- The Work
- Research · Journey mapping · Product architecture · UX/UI · Concept & usability validation
- Research
- 25 participants · Administrative managers · School principals · School staff
- Team
- Technology specialists · Project stakeholders
[PROLOGUE_CONTENT_PLACEHOLDER]
How I turn evidence into decisions — and decisions into learning.
we want to create.
we’re seeing.
- 01Trigger / Entry PointWhat set this work in motion?
- 02Desired OutcomeWhat change were we trying to create?
- 03Initial Evidence / Customer RealityWhat did we know — and what was still unclear?
- 04Customer MechanismWhat was driving the behavior we saw?
- 05Customer OpportunityWhat customer need or tension could we act on?
- 06Strategic ChoiceWhere did we choose to intervene — and what did we leave out?
- 07SolutionWhat did we design to change that?
- 08Critical AssumptionsWhat had to be true for it to work?
- 09Evidence / TestingHow did we test what we believed?
- 10Observed EffectWhat actually happened?
- 11Updated UnderstandingWhat do we understand differently now?
Chapter I
The Work Behind the Purchase
Why a seemingly simple purchase demanded more time, expertise and coordination than schools could realistically give it.
Trigger / Entry Point
The project began with a clear organizational ambition: replace a procurement process that was costly, inefficient and difficult to govern with a digital system that could support schools more effectively.
What was not yet clear was why the existing process was failing schools so deeply — or what the new system would need to take on in order to change that.
Create a procurement process that helps schools make better purchasing decisions, stay compliant, reduce waste, and spend less time managing the process manually.
Customer Reality / Evidence
We repeatedly heard about:
- 1time lost chasing requests and approvals;
- 2uncertainty about where purchases stood;
- 3difficulty comparing suppliers and quotes;
- 4limited procurement and negotiation expertise;
- 5fear of missing Ministry requirements;
- 6reluctance to change poor-performing suppliers because doing so meant more work.
“We often have delays in the procurement process because we need a system that provides real-time updates and tracks our orders.”
“We’re not making the most of our budget because we lack the bargaining expertise and resources to find the best deals.”
“We often struggle to find suppliers who can provide high-quality products at affordable prices.”
“Without a set purchasing procedure, we’re often left unsure how to approach transactions, resulting in a lot of back-and-forth.”
“Having everything in one place is essential, so that budget management, transaction management, and management and the supplier work in harmony.”
One purchase.
Several owners.
Procurement in schools involves multiple people, with different goals, constraints and perspectives.
School Staff Member
“I just need what I need to do my job.”
- Request what they need
- Follow up on status
- Focus on students, not process
School Administrator / Procurement Owner
“I need to keep everything on track.”
- Manage requests and process
- Ensure compliance
- Work with limited time and resources
Principal / Approver
“I need to make the right decisions.”
- Review and approve
- Be accountable for spending
- Ensure value for the school
Supplier
“I need a fair and clear process.”
- Understand requirements
- Submit competitive offers
- Build long-term relationships
The procurement process
From request to accountability — many steps, many places where things get stuck.
1.Request
Unclear requirements
2.Approval
Slow approvals
3.RFQ (quote gathering)
Manual outreach to suppliers
4.Compare offers
Hard to compare apples to apples
5.Select supplier
More back and forth
6.Sourcing / purchase order
Tracking is manual
7.Delivery / follow-up
Uncertainty about delivery
8.History / accountability
Information scattered
A system that didn’t carry the process
Behind these pain points was a deeper issue: the system was not carrying the process — people were.
- People carry it manually
- Workload exceeds available time/expertise
- Shortcuts become rational
- Purchasing quality and compliance suffer
The Opportunity
From a fragmented process to a shared system
Chapter II
Make the Right Way Easier
How customer reality became a clear opportunity — and where we chose to intervene.
The Opportunity
Help schools follow the right process, make informed choices and maintaincompliance without asking educators and administrators to becomeprocurement specialists.
The product needed to carry more of the procurement work.
Strategic Choice
A system for the whole process.
We chose to move the complexity schools were carrying into the product — encoding the workflow, rules, context and decision support into one connected system.
Yes
Encode the process into the product
Guide the workflow
Request → approval → RFQ → comparison → sourcing → order → delivery → history
Carry the rules
Approvals · compliance requirements · documentation · supplier criteria
Carry the context
Status · ownership · communication · budget · contracts · history
Support the decision
Comparable quotes · supplier information · compliance · pricing
Keep the process moving
Pending actions · notifications · handoffs · follow-up
No
Leave the process on the user
Marketplace only
Point solutions
More training
A faster old workflow
Automation alone
Next Up
Chapter III — Put the Process Into the Product
Chapter III
Put the Process Into the Product
How that strategic choice became a connected procurement system.
Each part of the system took on work that had previously depended on people remembering, coordinating and connecting the process themselves.
Make the work visible
See the work before it becomes a problem.
Role-based views surface status, ownership, budget and pending work — so people can see what matters without chasing updates.
Admin Dashboard
See the whole operation at a glance.
Spend, savings, contracts and pending work become visible in one shared view.
School Staff Dashboard
Know where every request stands.
Staff can follow a purchase from requisition through delivery without chasing the people managing it.
Requisition Management
Give every purchase a clear starting point.
Ownership, approvals, budget and supporting context stay attached from the first request.
Build the rules into the flow
Put procurement know-how into the product.
The workflow asks for the information, terms and requirements needed to move forward — reducing reliance on memory or procurement expertise.
Create New RFQ
Know what to define before asking suppliers to respond.
Budget, delivery, payment terms and specifications are built into the flow so a complete RFQ does not depend on procurement expertise.
Keep the process moving
Turn open work into clear action.
Waiting quotes, urgent requests, overdue orders, approvals and deliveries surface when attention is needed — keeping handoffs moving.
RFQ Management
Know where supplier action is missing.
Responses, urgency and communication stay visible while the RFQ is active.
Sourcing Management
Keep orders moving after the decision.
Purchase orders, confirmations, deliveries and exceptions remain visible through sourcing and fulfillment.
Support the decision
Compare the decision, not the paperwork.
Supplier responses arrive in a shared structure — bringing price, fit, history, terms and exceptions into the same decision space.
RFQ Responses
Make the trade-offs visible.
Comparable supplier information turns scattered quotes into a decision teams can evaluate with confidence.
Preserve continuity
Let the purchase carry its own history.
Supplier details, commercial terms, documents and activity stay attached as the purchase moves from order through delivery, invoice and accountability.
Purchase Order
Bring the commercial context together.
Products, supplier information, delivery, payment and documentation live with the same purchase.
Procurement Terms
Let the rules travel with the purchase.
Payment, delivery, warranty and contractual terms remain part of the working record.
Order History Log
One purchase. One continuous story.
Requests, approvals, RFQs, comments, orders, delivery and invoices remain traceable from beginning to end.
Chapter IV
Test What Had to Be True
How we challenged the assumptions underneath the direction.
If the product was going to carry the process, it had to reduce the knowledge, coordination and decision burden of procurement — while fitting the reality of how schools already work.
The system had to create relief, not a new process people would have to work around.
Validation
We used concept and usability validation to identify where the system genuinely reduced effort — and where it risked becoming another layer of work.
Four assumptions. Tested against reality.
We focused on the beliefs most critical to whether the system could truly carry more of the procurement process.
Assumption 01
Guidance had to replace expertise, not require it.
People should be able to move through procurement confidently without already knowing how procurement works.
What held up
Users could follow the core flow and understand what was expected next without prior procurement expertise.
What still needed work
Some procurement language and less-frequent scenarios still required explanation. The product could reduce the learning burden, but onboarding and contextual guidance still mattered.
Assumption 02
The system had to fit the work.
The product had to support the way requests, approvals and handoffs actually happen — without forcing people to reorganize their work around the tool.
What held up
The connected workflow reflected the way requests, approvals and supplier handoffs moved through the process.
What still needed work
Compliance proved more variable than a single fixed flow could capture. Additional rules, exceptions and institution-specific requirements still needed to be embedded without making the experience heavier.
Assumption 03
Structure had to reduce effort and time.
Shared status, clear next steps and connected context needed to reduce chasing, remembering and manual coordination.
What held up
Shared visibility and connected history reduced the need to reconstruct what had already happened or chase basic status.
What still needed work
A complete budget picture depended on information that existed before the system. Historical data import — and eventually integrations — became necessary to avoid creating a new reconciliation task.
Assumption 04
Decision support had to make good procurement easier.
The system needed to help people compare options and understand trade-offs without adding another layer of analysis.
What held up
Structured supplier responses made comparison easier and surfaced meaningful differences in price, fit and terms.
What still needed work
Not every purchasing decision could be reduced to the same criteria. Users still needed room to inspect exceptions, apply judgment and understand why one option appeared stronger than another.
What this changed
The direction held up — but the testing showed where the system still needed to carry more.
More compliance logic · Better onboarding · Historical data import · Room for real-world exceptions
The goal stayed the same: make the process lighter without asking users to reorganize their reality around the product.
Chapter V
What Became Clearer
What the evidence changed about the product, the problem and the next decision.
The direction held up. The evidence made it more precise.
The Product
Carry more, without becoming heavier.
The system needed to absorb more of the procurement knowledge, rules, history and exceptions — while keeping that complexity light for the people using it.
Contextual guidance, flexible compliance logic and access to existing data became part of what “carrying the process” really meant.
The Problem
Necessary complexity wasn’t the enemy.
The real burden came from people having to remember, coordinate and reconstruct that complexity themselves.
The goal became clearer: preserve the rigor procurement requires, while removing as much of the cognitive and coordination burden as possible.
The Next Decision
Find the next burden the system should absorb.
The next priorities were the places where work could still fall back onto the user.
Onboarding and in-context guidance · variable compliance requirements · historical data import and integrations · flexibility for real-world exceptions.
The interface was only
the visible part.
Making procurement easier didn’t mean simplifying what matters. It meant making its necessary complexity easier to carry.
“Can I see the full
final experience?”
I wish.
Much of this work belongs to my client and can’t be shared publicly. What I can show here is part of the process, systems, and decisions behind it.
If you’d like to go deeper, I’m happy to walk through what I can share privately.
Let’s talk →