Post

Principle of Least Astonishment

The Principle of Least Astonishment in Technical Writing

Principle of Least Astonishment

How Music Production Taught Me About Usability and Documentation

Back in my college days, I had to commute over 3 hours daily to and from college. To make the time worthwhile, I started listening to A State of Trance (ASOT) regularly. I was always curious about how music is produced—and being in Mumbai, I had plenty of ways to explore it.

That’s around the time DJs were beginning to rise. Some of them, who had once dropped out of school, are now famous.
Life, yeah…?


My First Encounter with FL Studio

I discovered that most DJs and producers use a tool called FL Studio to create music like EDM, Trance, and Dubstep.

Once I got my hands on the software, I went into binge-learning mode, watching tutorial after tutorial.
Within a year, I had a solid grasp of the fundamentals of music production, even though I didn’t pursue mastery at the time.

But one thing stuck:
Whenever I explore any music or video editing tool—I pick it up fast.
Why?


The Principle of Least Astonishment (POLA)

“The principle of least astonishment (POLA) states that a component of a system should behave in a way that most users will expect it to behave, minimizing confusion and surprise.”Wikipedia

Let’s say I try using Camtasia, Premiere Pro, or Shotcut.

If these tools didn’t follow similar design principles as FL Studio—like timelines, playlists, drag-and-drop,layering—I’d struggle. I might even drop them entirely.

“Every extra step you make a user take reduces adoption.”Steve Krug (not me!)

Another small but powerful example:
Pressing CTRL + D to duplicate works across many tools.
That consistency reduces learning friction.


Why Consistency in Documentation Matters

Let’s assume you’re a technical writer for a product called Alien Listener Keyboard—a futuristic web keyboard to help humans communicate with intergalactic visitors.

Recently, the company updated the keyboard alphabets:
From A, B, C, D, E, F, G, H to I, J, K, L, M, N, O.

Now Meet Rohit:

A long-time user, Rohit, presses A—as per the old design—but nothing happens.He searches the documentation, which still refers to A.
Frustrated, he gives up…
And fails to contact Jadoo.


The Lesson?

Had the documentation team been informed about the update,Rohit would have had a better experience, and maybe even established first contact.


Have You Faced This?

Have you ever struggled with outdated documentation that didn’t reflect the product’s latest changes?

If yes, you already understand how powerful accurate, updated, and intuitive documentation can be.

This post is licensed under CC BY 4.0 by the author.