Student Order Administration
The outcome
*The strongest comparison comes from the busiest part of the school year, when school orders and related support requests peak.
The problem
Orders reached us in three different ways, and each created manual work for system administrators.
School orders
Schools emailed student lists. The system administrator checked accounts, created missing ones, sent login details and entered the order into a spreadsheet for Finance.
Bookstore orders
Bookstores emailed their orders. The system administrator processed them and sent vouchers back.
Student orders
Students ordered through LearningBox. iDEAL orders gave immediate access, while employer-paid orders needed a manual payment check before access could continue.
The trigger of this project is because one of our two system administrators was retiring. We needed to reduce the manual workload without simply replacing the role.
As the only designer, I worked across the research, information architecture, flows, prototypes and final UI.
Research
Ive interviewed the bookstore purchaser, finance team and shadowed both system administrators for two weeks and logged 211 tasks across 64 orders.
An order took 14 minutes of administrator time on average. 38% of that time was spent checking information, such as whether a package belonged to a school or whether a student already had an account.
I also reviewed 60 support tickets and grouped the recurring problems.
The biggest ones were package corrections, access issues, duplicate accounts and wrong courses.
Product direction
Our first idea was to build a separate administration application.
I changed direction after talking to two school administrators from smaller schools. At both schools, the same person taught students, managed accounts and ordered materials. One even kept a printed login list for five different tools.
Adding another application would give them one more system to manage.
So I proposed extending LearningBox instead, using role-based navigation and views. School administrators could then manage teaching, students and orders in the same platform.
This meant adjusting the legacy database and added two sprints compared with a separate application. After discussing the trade-off with the Product Owner, we decided the reduced operational complexity was worth it.
Designing the workflows
System administrators handled almost every order, creating unnecessary back-and-forth communication in between.
I moved relevant steps to the people who already had the required information, leaving system administrators to handle exceptions.
Let school place their own orders
A school can now complete a class order in about 4 minutes, instead of waiting up to 2 days for a system administrator to process it during busy periods.
Let bookstore purchasers order vouchers from the system
Bookstores previously relied on system administrators to correct orders when the wrong package was selected. I made the flow more error-proof by letting purchasers select the school and curriculum, with the system automatically choosing the right package. Unused vouchers can also be returned directly.
Give students 14 days grace period
Employer-funded students previously had to wait for payment and a manual check before getting access. Together with Finance, we introduced a 14-day access period while waiting for the invoice to be paid.
Give system administrators one overview
System administrators still handle invoices, returns and reminders, but these tasks are now managed from one overview instead of across separate workflows.
By giving system administrators one overview, it also became easier for Finance to create VAT reports. Reporting time was reduced from 6.5 hours to 1.5 hours.
Testing
I tested the main flows with 3 school administrators and 1 bookstore purchaser using a clickable prototype.
We also tested the edge cases together with the Product Owner, developers and Finance:
- Schools with multiple course packages and different rules
- A mix of voucher, school-admin and student purchasing
- Orders for several classes
- Returns and credit invoices
- Employer-paid orders and the 14-day access period
The aim was to make sure the model still worked when real school structures got messy, not just when everything followed the happy path
Reflection
This project taught me that complex B2B products aren't always about simplifying the interface. Often, the harder part is deciding who should make each decision and where that decision belongs in the workflow.
I also became more careful about edge cases. It's easy to keep adding features for every exception. In this project, I tried to keep the common workflow simple while making the less common cases safe to handle.