Today I stopped for a smoke.

As I got back onto the scooter, I turned the key, pressed the starter, and... nothing.

No sound. No struggle. Just silence.

My first reaction wasn't curiosity. It was panic.

Not because the scooter had broken down—but because my dad might find out where I was.

I tried again.

Nothing.

Maybe the battery?

I looked at the dashboard. Everything seemed normal.

Maybe the side stand?

No warning.

Maybe the fuel?

The gauge still showed there was petrol left.

I tried kick-starting the scooter over and over again until I was exhausted. Still nothing.

By this point my mind wasn't thinking logically anymore. It was racing through worst-case scenarios. I even asked the nearby shopkeeper if he had a bottle of petrol I could borrow. He didn't.

Then, almost by accident, I looked at the handlebar.

The kill switch.

It was in the OFF position. I must have brushed against it while parking and never noticed. What made it worse was how subtle it was. The switch itself was black, blending into the black plastic housing around it. There wasn't a bright red cap, no obvious contrast, nothing that drew my attention to the fact that the engine had been disabled.

I flipped it back.

The scooter started instantly.

The scooter was never the problem.

The interface was.

As designers, we often think about making things beautiful or easy to use. But moments like this remind me that the real job of design is helping people understand why something isn't working.

This scooter is filled with electronics.

It tells me when the side stand is down. It flashes indicators. It warns me about fuel. It has diagnostic lights and digital readouts.

But it never tells me the one thing that actually prevented the scooter from starting.

A tiny switch on the handlebar silently disables the engine, yet the dashboard offers no explanation.

Imagine if, instead of silence, the display simply said:

Kill switch is OFF. Turn it ON to start the engine.

My entire experience would have lasted two seconds instead of ten anxious minutes.

That made me question something else.

Why does a scooter even need a kill switch?

On motorcycles, especially larger ones, the answer makes sense. In racing, off-roading, or emergency situations, instantly cutting the engine without taking your hands off the bars can be genuinely useful.

But on an automatic scooter?

You already have an ignition key. The rider isn't shifting gears. The number of situations where a kill switch is genuinely useful becomes much smaller.

Yet the extra control remains, introducing another hidden state the rider has to remember.

Every control we add carries a cost.

Not just manufacturing cost.

Cognitive cost.

Every switch asks the rider to remember one more thing. Every hidden state creates another opportunity for confusion.

The irony is that this wasn't a mechanical failure at all.

It was a communication failure.

The scooter knew exactly why it wouldn't start.

It simply refused to tell me.

Instead, it left me guessing between fuel, battery, engine problems, and expensive repairs.

Machines often know far more than they communicate.

Design is deciding what deserves to be communicated, and when.

This experience reminded me that good design isn't about preventing every mistake.

People will always make mistakes. We'll press the wrong button, leave switches in the wrong position, and forget things.

Good design catches us before panic begins.

Sometimes innovation isn't inventing a new feature.

Sometimes it's adding one sentence:

"Kill switch is OFF."

Because the difference between a broken machine and a broken experience is often just information.