Most design reviews happen on the best day a product will ever have. Someone is rested, the wifi is strong, the prototype is open on the nice monitor, and the person clicking through it has been told exactly what it’s for. Under those conditions almost anything works.
Nobody who uses what I make will ever be in that room.
They’ll be on a Tuesday. It’s 08:47, stand-up is in thirteen minutes, it’s raining, the phone is on 12%, and they’re holding a coffee in the hand they’d normally tap with. They aren’t reading your onboarding. They aren’t admiring your empty state. They want one thing done so they can get on with the next one.
That’s the screen I design for, and I’ve started calling the check I run on it the Tuesday test.
What the Tuesday test actually is
It isn’t a method. It’s a question a design has to answer before I let it feel finished: would this still work on someone’s worst ordinary day? Not a disaster, just ordinary-bad. Tired, distracted, one bar of signal.
Then I try to break it on purpose.
- One thumb. Can the main action be reached and finished with one hand, on a bus, without a second try?
- One bar. What happens when the request is slow or fails? Does the screen say what went wrong, keep what the person typed, and let them try again? Or does it go blank and quietly eat their work?
- Interrupted. Put it down for ten minutes and come back. Does it remember where you were?
- Skimmed. If someone reads only the first six words of every label, do they still end up in the right place?
- Tired. If an instruction needs concentration to understand, it’s too clever.
- Rested
- Strong wifi
- The nice monitor
- Told exactly what it’s for
- 08:47, raining
- One bar, 12% battery
- Coffee in the tapping hand
- Stand-up in thirteen minutes
Why “the average user” is the wrong target
Designing for an average user quietly means designing for the best day, because that’s the only day you can easily see. The worst day is where the real costs live: the wrong button pressed, the form abandoned at step four, the call to support that should never have happened. Ordinary-bad days aren’t rare. They’re most days.
It’s also where inclusive design stops being a separate workstream. Someone with astigmatism squinting through glare, someone anxious and rushing, someone on an old phone in a lift: these aren’t edge cases, they’re the same Tuesday. If a screen holds up there, it tends to hold up for everyone.
Where it gets literal
At Honeywell I designed conversational AI for regulated industrial products: aerospace, fire and life safety, building technologies. In that world “the worst day” isn’t a figure of speech. The person on the other end might be in a noisy space, wearing gloves, in a hurry, being told something they need to understand once and correctly. That changes what you count as polish. Clarity stops being a nice-to-have and becomes the product.
How I actually run it
- I open the prototype on a real phone, not the desktop preview. The desktop preview flatters everything.
- I throttle the network and watch what the design does while it waits. Waiting is a screen too.
- I write the worst-day version of every error message first. The happy-path copy is easy; the sentence a stressed person reads when something fails is the one that earns trust.
- Where I can, I run sessions where people actually work, not in a meeting room, and I ask them to do the task the way they’d do it on a Monday.
The best-day version of any product is easy to build and easy to love. I’d rather ship the Tuesday version.