The One Thing Operators Want From Software
Only tools that survive the ten busiest minutes of dismissal rush make it. A campus operator on the one thing she wants from software, and how she gives feedback.
What the Desk Looks Like at 3 p.m.
At 3 p.m., before the first dismissal shuttle pulls up, the desk gets its last quiet stretch of the day. This is when I run through today’s dismissal roster once, check whether any student’s schedule has shifted because of a makeup class, and test the desk phone and the tablet battery. On the memo board, I also jot down a couple of names of students whose pickup arrangements changed today. Many afternoons at the ELA campus hold together on these thirty minutes of preparation.
From 4:20 to 4:50, over the span of thirty minutes, some seventy students head out in staggered waves. In that window the desk phone rings five or six times, and the intercom keeps paging classrooms to track down students. While taking a parent’s call asking “Where is my child right now?”, my eyes have to confirm the student at the front door while my hands find that student’s class and dismissal method on the screen.
The Ten-Minute Dismissal Rush Test
Every piece of software an operator uses gets judged against this window. So our team has a test that every new tool has to pass: can we actually use it during the busiest ten minutes of the dismissal rush? The checklist is short. Can I operate it one-handed with the phone wedged against my shoulder? Does reaching the student I am looking for take no more than three screen transitions? Does the first screen load in under three seconds? If the screen goes dark while I take a call, can I get right back to where I left off? And is the thing I need to do right now immediately visible?
An attendance app we evaluated this spring looked flawless on the feature sheet. The analytics screens were pretty and the report types were plentiful. But when we tried it during rush, getting to student search took five taps, and by the second week Angela at the desk was printing the paper roster again. That was the end of the test.
Plenty of tools look good during the quiet hours. Whether a tool is the real thing gets decided by the busiest ten minutes.
Tools That Show the Next Action
What operators want from software comes down to one thing. Not a well-organized screen, but the next action. During rush, what I need is not today’s attendance graph but a single line: “This student rides the shuttle today, departing in five minutes.” My favorite feature in Rubric, the system we use, is just as modest. It is a small change added last month that moves students whose dismissal time shifted because of a makeup class to the top of that day’s roster.
I do look at the analytics screens, of course. But only after 5:30, once the rush is over and the desk has gone quiet. Even within the same tool, different hours of the day call for different screens. Back in the ten minutes of rush, that one line at the top of the roster means the 4:20 version of me has one less call to make.
How I Give Feedback to the Dev Team
Last year I asked Justin on the dev team, “It would be nice to have a dashboard where I can see everything at a glance.” Two weeks later, a dashboard actually arrived. It had six graphs, and nobody opened it during rush. The dev team did nothing wrong. I had described a solution, not a scene. That is how two weeks of development time got spent.
I changed how I give feedback after that. Now I write down only three things. When it happened. What I was trying to do at that moment. How many taps it took and how many seconds. I keep a stopwatch in the desk drawer for the timing. Here is one I sent last month, word for word: “4:32 p.m., two shuttles arriving at once. Checking one student’s dismissal method while on a call. Seven taps, forty seconds.” I do not write solutions. The dev team is better at that side than I am.
Meetings got shorter after the switch. It took Justin less than five minutes to answer, “This one doesn’t need a new screen. We just need to move a button.”
Whenever a fix ships, I time it again during the next week’s rush. The day a forty-second check dropped to twelve seconds, I sent that number back as my reply: “Down to twelve seconds. Survived this rush too.” The conversation between the dev team and the desk still runs on these numbers.