Shariq Rafeh
Back to the short version
Service DesignSystems ThinkingFull write‑up

Fixing the print request bottleneck for an 800‑student school

A single administrator, three intake channels, and up to 50 open print jobs at once. This is the process I ran solo, the fix I already shipped, and the redesign I’d build next.

My roleVisual Lead & Reprographics Administrator
ScopeSolo‑run service, ~800 students, ~100 staff
BasisFirst‑hand operational experience
StatusOne stage shipped, one conceptual
A note on how this was built

This isn’t a formal research project — it’s a job I actually did.

I was the sole reprographics administrator handling every print request for the school — from teachers, the admin team, the ops team, and the Senior Leadership Team (SLT). Everything in the problem section below is drawn directly from doing that job, not from interviews or surveys.

The intake form in Part One is something I actually designed and shipped. The dashboard in Part Two is a concept I didn’t get to build before my contract ended — I’m presenting it as a proposed direction, not a validated, tested solution, and I’ve been explicit below about where I’d want real validation before building it for real.

How I worked

Methods, adapted for a solo, embedded role.

There was no research budget and no separate research phase — I was the practitioner and the researcher at once. That’s a real, recognised approach (participant‑observation / auto‑ethnographic research), not an excuse for skipping process. Here is specifically what I did and what it produced.

01 — Observation

Embedded / participant observation

Running the service daily, for every one of ~100 staff, gave continuous first‑hand exposure to failure points as they happened — not a snapshot from a handful of interviews.

02 — Synthesis

Pain‑point clustering

Recurring breakdowns (lost requests, missed deadlines, double‑booking, big‑job collisions, manual status chasing) were grouped into named problem themes rather than treated as one‑off incidents.

03 — Mapping

Current‑state process mapping

Laying out the real submit → review → print → notify → collect flow made visible exactly which steps were automatic and which were manual labour dressed up as “just how it works”.

04 — Segmentation

Proto‑persona development

Behaviour patterns across ~100 staff were synthesised into three requester archetypes so design decisions stayed tied to who was actually affected, not an abstract “user”.

05 — Framing

“How might we” reframing

Pain points were turned into direction‑setting questions — e.g. “How might we make queue status visible without adding a step for requesters?” — before jumping to screens.

06 — Iteration

Build → fail → adjust, twice over

Spreadsheet failed in real use → replaced with a mandatory‑field form, which shipped and worked. The same loop applied one level up produced the queue concept in Part Two.

The problem

Requests came from everywhere, and nothing kept track of them.

Staff sent print requests however was convenient to them in the moment — there was no single channel.

Email
Teams
In person
No queue,
no record

On a normal week I was holding 10–20 open requests in my head and across scattered messages. During exam season or big booklet runs, that climbed past 50 at once — on top of jobs that could run over 100,000 pages in a single order, printed on two machines in one room, by one person.

1Person running the entire service for ~100 staff
10–50Concurrent open requests, normal week vs. peak
100k+Pages in a single exam/booklet print run
2Printers available for all of it

The failure mode wasn’t one big disaster — it was small breakdowns that happened a few times every term, at exactly the wrong moments:

  • Requests got lost. I’d forget who sent something, what it was for, or lose track of the actual file — especially when it arrived as a Teams message sent days earlier.
  • Deadlines got missed, particularly when an SLT request landed last‑minute and had to jump the queue with no system for deciding what else it bumped.
  • Double bookings happened on the two print room machines with no shared view of what was already scheduled.
  • Printer downtime made everything worse. A jam ate time I didn’t have slack for, and there was no way to signal a deadline was at risk before it was missed.
  • Big jobs and daily jobs competed for the same two machines, with no formal way to protect time for exam or booklet printing without day‑to‑day requests silently slipping.
  • Every status update was a manual message. A feasibility check on Teams, then a ready‑for‑collection message once printed. At 10–50 concurrent requests, that’s up to a hundred messages typed by hand, on top of actually running the print room.
Who I was designing for

Three requester patterns, not one generic “user”.

These are proto‑personas — composites built from real behaviour patterns observed across ~100 staff over the course of the role, not individual interview subjects. I’m labelling them as such deliberately: this is what you build when you don’t have a research budget but do have direct, repeated, first‑hand exposure to how different groups actually behaved.

Everyday Requester

Classroom teacher · ~15–20 print jobs a term
Goals

Get handouts and worksheets printed reliably, without extra admin work.

Frustrations & behaviour

Before the form: got the spec wrong — missing copies count, wrong paper size, forgot to attach the file — causing reprints and delay. After submitting: no visibility into where the request stood, so she’d message the admin just to check.

“I just want to know it’s actually in the queue and roughly when it’ll be ready — I shouldn’t have to message reprographics to find out.”

Urgent Senior Requester

SLT / Senior Leadership · low volume, high urgency
Goals

Get leadership materials — governor packs, urgent memos — printed fast, regardless of the existing queue.

Frustrations & behaviour

Often bypassed the form entirely for anything urgent, because Teams or in‑person felt faster. When the form was used, still expected the request to jump the queue automatically. Genuinely low‑notice by the nature of the role.

“I don’t have three days’ notice for a governors’ meeting — I need whoever’s printing this to know it’s urgent the second I hit send.”

Big-Job Coordinator

Exams / booklet printing · low frequency, very high volume
Goals

Get large, predictable print runs (mock papers, booklets — 100,000+ pages) scheduled and completed on time without derailing daily printing.

Frustrations & behaviour

Mainly a scheduling and lead‑time problem, not a confidentiality one in practice. Needed capacity confirmed well ahead of the exam window, not discovered two days out that regular printing had pushed the job back.

“I just need to know my slot is locked in weeks out — not find out two days before that regular printing pushed us back.”
Shipped & live Part one — what I actually built

A structured intake form to kill the misprint problem.

My first fix was a plain shared spreadsheet. It failed — people didn’t fill it in properly, lost the link, or had no proper way to attach the actual file to print. The spreadsheet asked people to structure information without giving them a structured way to enter it, so it collapsed back into the same mess.

What worked was replacing it with a Cognito Form, hosted on a link on the school SharePoint intranet so it was always in the same findable place. Every field that affected how the job was printed was made mandatory, so a request physically couldn’t be submitted incomplete.

Print Request Form — Cognito Forms

Your name & email *J. Marsh
Job type *Class handout
Colour or black & white *B&W
Single or double sided *Double
Paper size — A4 / A3 *A4
Paper stock — normal / card *Normal
Lamination *No
Number of copies *32
Needed by *Fri 14 Nov
File — upload or SharePoint link *worksheet_wk9.pdf
What this actually fixed Because every spec field was mandatory, ambiguous or incomplete requests — the direct cause of misprints — stopped happening. It also gave every request a permanent, findable record with the file attached or linked, instead of relying on my memory of a Teams thread from three days ago.

The submission‑to‑collection lifecycle looked like this once the form was in place: a request came in and I got an email notification; I’d review it and, if the requested deadline wasn’t realistic, message the requester on Teams with a revised estimate; once the job was printed, I’d message them again to say it was ready for collection from my room, G015.

What it didn’t fix: once a request landed, it was still just a list of individual form submissions. No queue view, no way to see everything open at once, no prioritisation logic — and both status touchpoints were messages I had to remember to type and send myself, every request, every time. And because the form lived on a link, not everyone used it: urgent, last‑minute asks still tended to arrive by Teams or in person, which is exactly where things had broken down before.

Concept — not built Part two — what I’d build next

The real gap wasn’t intake. It was visibility.

The form solved data quality. It didn’t solve knowing, at a glance, what was open, what was overdue, what was double‑booked, and what the two big cyclical jobs were doing to everyone else’s turnaround time. That’s the layer I’d design next — a lightweight queue sitting on top of the intake I already had working, not a replacement for it.

How this fits reality: the school already runs on Microsoft 365 and had just adopted Cognito Forms — no procurement, no new logins, nothing to relearn on the submission side. The queue is designed to be fed automatically from the existing form (e.g. via Power Automate into a SharePoint list), so staff behaviour doesn’t change and the only new thing is what I see as the administrator, plus one lightweight self‑serve status check for requesters.

How I’d want the redesign to behave:

  • One queue, always current. Every submitted request appears automatically — nothing needs re‑entering.
  • Priority is visible, not verbal. Urgent requests are flagged distinctly, but I still see the whole queue, so a rush job’s impact on everyone else is visible before I commit to it.
  • Big cyclical jobs get protected capacity. Exam and booklet runs are planned against real capacity ahead of time, instead of competing job‑by‑job with daily requests.
  • Status updates send themselves. A status change notifies the requester and updates their lookup page — replacing the two Teams messages I was typing by hand for every single request.

Admin Queue — Reprographics Dashboard

New6
Y11 Mock Paper — Science
Big JobDue Mon
Assembly Handout
Due Thu
SLT — Governor Pack
UrgentDue Tmrw
In Progress4
Yr7 Homework Booklet
Printer A
Dept Meeting Agenda
Printer B
Blocked1
Art Dept — Card Stock
Stock Low
Ready · G0153
Newsletter — Nov
Auto‑notified
Trip Consent Forms
Auto‑notified
Collected9
Staff Bulletin
Closed

Capacity Planner

Mon
Tue
Wed — Exam
Thu — Exam
Fri
Daily requests Protected big‑job capacity

Auto‑Notify, No Login

Ready — Room G015

Y11 Mock Paper · Printed Fri

Anticipated — not measured This wasn’t built before my contract ended, so nothing here is a result — it’s what I’d expect based on where the time and friction actually went, and exactly what I’d track from day one if it were built: fewer manual status messages; visible rather than silent trade‑offs; fewer exam‑week surprises; and a measurable signal on how often the form gets bypassed.
Key decisions

Why it looks like this and not something flashier.

Why keep Cognito Forms instead of replacing it with something custom?

It already works and staff already know it. Replacing a tool that solved a real problem just to make the portfolio screens prettier would be designing for me, not for the school.

Why not fully automate prioritisation?

Some prioritisation calls are political, not logical — an SLT request isn’t automatically more important than a Year 11 exam paper. The queue makes trade‑offs visible so a human still makes the call, rather than hiding the decision inside an algorithm.

Why no login for the status check?

Staff already ignore tools that ask for another password. A lookup by email or reference number keeps the friction near zero, which matters more here than it would for a tool people are required to use daily.

Why still worry about requests bypassing the form?

Because they did before, and nothing in the redesign forces the behaviour to change — it only makes the cost of bypassing visible, since an off‑form request has no record in the queue. That’s a real limitation, addressed rather than designed away.

Honest limitations

This is a concept, and I’m not pretending otherwise.

Part One is real and shipped. Part Two is not — I didn’t get to build or test it before my contract ended, so I’m not going to claim results I don’t have. If I were taking this further, here is specifically what I’d validate first:

  • Interview the staff who still bypassed the form for urgent requests, to find out whether it’s habit, speed, or a genuine gap in the form — no “urgent” option, for instance.
  • Sit with SLT specifically to understand how they’d react to a visible trade‑off screen, before assuming they’d accept a queue telling them what their request bumps.
  • Test the capacity planner against a real exam period to see if the daily/big‑job split holds up, or if exam weeks need to fully suspend daily requests instead.
  • Measure, if built: requests submitted off‑form, average messages‑per‑week asking “is this done”, and missed‑deadline count per term, against the pre‑dashboard baseline.
Reflection

What this taught me about designing inside real constraints.

The instinct when you see a messy process is to design the most complete system possible. The more useful skill turned out to be the opposite — noticing that the spreadsheet failed not because spreadsheets are bad, but because it asked busy people to self‑organise without structure, and that the fix wasn’t a bigger tool, it was mandatory fields. The queue in Part Two follows the same logic: add the layer that’s actually missing (visibility) without touching the part that already works (intake), and stay honest about which part is proven and which is still a hypothesis.

That’s the long version.

Prefer the summary? The short version covers the same story in about two minutes.

Back to the short version
Next case study: Career Information Boards