The Anti-Magic Principle

I’m worried this will sound banal but it’s been a helpful guiding principle for us and we’ve caused ourselves a lot of grief by violating it in the past, before we got our heads around it. So if it sounds banal I bet I’m either conveying it poorly or you’ve already internalized it!

The Anti-Magic Principle is that software shouldn’t do anything seemingly magical. It should be as simple and transparent and predictable and convention-following as possible. It can apply to big things like the auto-widening yellow brick road, and to little things like suppressing the display of a checkbox in the UI when it’s not applicable. When a user remembers that a checkbox used to be somewhere and now it’s not, that’s confusing and frustrating. Better to gray something out than to have it magically disappear.

Here are some more examples:

  1. It turned out to be a bad idea to let the default date for the add-data form magically update to the new day when the deadline hit.
  2. Having data magically know to display in HH:MM because you used the string “hours” as your goal units: bad idea.
  3. Trying to intelligently decide whether to have the road dial expanded or collapsed in an attempt to avoid confusing newbees. (See an example of this causing confusion though in the meantime we found a compromise that seems ok.)
  4. The odometer reset feature probably never should’ve been allowed by the Anti-Magic Principle but it is admittedly very powerful and useful so maybe it’s an exception.
  5. We used to magically suppress reminders if you’d already entered data for that day. That made it seem like the bot was randomly flaking out.
  6. Self-destructing pessimistic presumptive reports (PPRs) is another violation that I think I’m ok with.

“Any sufficiently sophisticated technology is indistinguishable from magic to the user” - some dude somewhere

I get the consistency thing. But there’s nothing like “it does that?! Wow”. I’d love beeminder to have features like slowly cranking up the slope over time until a certain slope is reached, without me adjusting it manually. But that would be close to magic at this point. When magic works, it can be amazing.


This seems like a variation on the Principle of Least Astonishment: software should do whatever least surprises the user. If you have a clearly labeled switch that does something “wow” or magical, like an acceleration variable for automagically increasing the slope as @mufflon suggests, that should be ok.


Great stuff!

Also related, from the field of web usability: Jakob’s Law:

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.

More information:


Interesting! I’m a big fan of POLA, but one (in general, not saying it’s a problem here) should also not forget the principle of “one single person got confused by something, so we assume everyone else who kept quiet about it was also confused so let’s better undo the entire thing!” :wink:
And it’s hard to find a balance between the two. Specifically: How do you know that the quiet mass is or is not actually ok with said thing?


Ideally, by running usability tests as a part of your iterative design process. And you may need to test far fewer users than you might assume. The Nielsen Norman Group recommends 5 users for most tests of a single design.


Ha! Yes! Huge thanks to @zedmango for pointing out the Principle of Least Astonishment. Ironic how I reinvented that wheel instead of using the existing term. I also agree with @zedmango that magic can be good as long as it doesn’t violate POLA so POLA may be the better, more general principle. But… I also think there are cases where violating POLA can be good if it reduces magic. See the criticism of DWIM where trying to minimize user surprise by doing what they meant instead of what they said tends to backfire.

So maybe anti-magic and least-surprise mostly overlap but the principle I really want is neither the intersection nor the union but something else that I haven’t figured out how to formulate yet?

Or maybe POLA just needs a corollary: don’t try to be clever about reducing surprise because it tends to backfire. Simplicity, transparency, and predictability are your friends.