The text message that would have made the wait bearable

A few weeks ago I spent half a day in a veterinary hospital waiting room with my dog Tupí. Our usual clinic couldn’t take us, and neither could the many others we called. So we did what everyone else there had done: we went to where the door was open… and waited.

After a couple of hours together, strangers start talking. First about their pets, then about another thing we had in common, which was waiting. The conversation drifted to the human hospital, where everyone agreed it was worse. I had a story to contribute: a 15-hour emergency wait, a few years back, for something no clinic would see on short notice. Some hospitals in Québec now publish average wait times and occupancy for each emergency, which helps before you leave the house. Once you’re inside, though, nobody can tell you when your name comes up.

A woman there had a solution: “Why can’t they just text me when it’s almost my turn?”

I’d had the same idea years ago. It’s not a bad idea. Wait at home, eat, sleep, come back when called. Fewer bodies in the room, calmer staff, a better evening for everyone. It would be cheap to build, and if a hospital asked me to design it I could have a prototype very fast. Although, there are really good reasons to slow down on this.

What the Feature Accepts

Every solution carries a model of the world inside it. The text message carries this one: an emergency room is a place where you queue so long it is worth going home in the meantime. The feature makes that bearable, maybe even enjoyable. But it does not touch the source of the problem.

Let’s look at what it leaves standing. There is no path to care that does not end in an emergency room, because the places that used to absorb a sore throat, walk-in clinics, have mostly changed to be on appointment only, and appointments are usually weeks out, if you can find any. The emergency room has become the front door by default. The text message would be a very nice doorbell on it.

The usual framing is capacity: more doctors, more beds, and the queue shrinks. There is truth in it, and I am not in a position to argue health policy. The case against, as a designer, is narrower: the queue is a symptom, and the system producing it is one with no front door. Building comfort into the queue is a bet that the queue is permanent.

Pain and Problems Are Both Real

This is not an argument against the feature. The woman in the waiting room was right. The pain is real, and a product team that dismissed it would deserve to lose her.

It is an argument about order. In product works the ask almost always arrives as a solution for a pain, phrased as a solution for a problem: a text message, a dashboard, an export button, a faster form. Solving it as stated is usually the fastest way to make a user happy this quarter. A “quick win” so to speak. It is also, often enough, the way a broken process becomes a permanent one, because once the pain is gone nobody has a reason to go to look for its cause. In medicine, a treatment that relieves the symptom and lets the disease progress already has a name. It is not a “cure.”

I have been on both sides of this. I have built the doorbell when the budget, the mandate and the calendar left no room for the door. I have also watched teams build three generations of doorbells for a door nobody had been allowed to question.

Three questions before building the ask

When a request comes in already shaped as a feature, I try to ask three things before I say yes.

• What does this feature accept as permanent? Write the sentence down. “Emergencies are places you wait long enough to go home.” If the sentence is something the organization would never put on a wall, that is information.
• Who gets quieter if we build it? A feature that relieves pain also removes the pressure that pain was putting on the system. Sometimes that is the point. Sometimes the pressure was the only thing keeping the real problem visible.
• What is the smallest version that treats the pain without closing the question? A text message that also logs why each person came, and whether a clinic could have seen them, treats the same pain and keeps the door problem on the table. Same cost, different model of the world.

None of this is a reason to refuse the ask. Organizations have limited resources, limited mandates and limited influence over the systems around them. Sometimes treating the pain is the only honest thing within reach, and doing it well is good work. The failure is not building the doorbell. The failure is building it and calling the door fixed.

The Open Question

So where is the line? When is it right to treat the pain and not the problem, and when does a feature that makes a broken system livable become the thing that lets it stay broken?

I don’t think there is a general answer. I think the question has to be asked out loud, every time, before the first wireframe. If you have a case where you drew that line, in either direction, I would like to hear how you decided.