Principle of least astonishment

I recently stumbled across this idea in a Hacker News comment.
The principle of least astonishment applies to user interface and software design. A typical formulation of the principle, from 1984, is: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."

In general engineering design contexts, the principle means that a component of a system should behave in a way that users expect it to behave; that is, users should not be astonished by its behavior
In my experience it's often a good idea to draft your program's public API before actually building it. Don't let implementation details influence design.

The hidden cost of touchscreens

Amber Case expresses her frustrations towards the use of touchscreen in modern machines. Being software-driven, touchscreens are a lot more flexible than analog interfaces, but they come with their own tradeoffs.
Serious interfaces — those that are repeatedly used by a knowledgeable professional and/or in potentially hazardous situations, should not be touchscreen based. If a touchscreen must be used, it should be embedded alongside a set of fixed, physical buttons that support muscle memory and single actions.
My takeaway is that we should stop making everything more “high-tech” for the sake of it, and shouldn’t be afraid to take a step back and evaluate our creations from first principles.

Optimistic UIs in under 1000 words

Igor Mandrigin gives an illustrated introduction to optimistic UIs. You may have not heard of optimistic user interfaces yet, but they're all over the web.
Optimistic UIs don’t wait for an operation to finish to update to the final state. They immediately switch to the final state, showing fake data for the time while the real operation is still in-progress.
Optimistic user interfaces are a core concept in today's web applications. Our interfaces expect a user action to succeed, so they don't need to wait for a server response to move on to the next task.
It is a very simple concept behind a fancy name. Yet it can make a huge impact on your users’ happiness. Firstly, it makes your app feel faster. User can start doing something else while your app uploads a Hilarious Betty the Cat Picture or posts a Smart And Ironic Comment to a discussion. Secondly, it streamlines the experience by removing unnecessary states and distractions. The app will look simpler and more friendly.

Twenty years, twenty lessons

Mark Rosewater is a game designer for Magic the Gathering, an immensely popular trading card game. He gave an hour-long talk at a game development conference about the lessons he learned in 20 years of game design. Afterwards, these lessons were published as a three part column.
What I've learned over the years is that you shouldn't change your players to match your game; you should change your game to match your players. Don't get yourself into a fight you're probably not going to win. Human behavior is a powerful force. We are creatures of habit and instinctually fear change.
The articles focus on game design, but the lessons are applicable to anything that requires design thinking.

Mark precedes every lesson with an anecdote, explaining what went well or what didn't. Another one of my favorites:
Players' need for individuality is strong, which means that they will be looking to find a small corner of your game where they can feel a special connection. Big things tend to gather too much attention, so it's in the smaller details where players will attach the strongest emotionally, which means that the details are actually far from insignificant.
I don't have any prior knowledge of the game myself, so don't worry about not understanding parts in spite of the topic. If the first six lessons piqued your interest, here are parts two and three.

Akin's Laws of Spacecraft Design

Dave Akins wrote 42 laws you should abide by when building spacecrafts. I'm not planning to build a spaceship any time soon, but apparently there are a lot of similarities with web development. A few examples:
  • Engineering is done with numbers. Analysis without numbers is only an opinion.
  • Design is based on requirements. There's no justification for designing something one bit “better“ than the requirements dictate.
  • Don't do nuthin' dumb.
  • Space is a completely unforgiving environment. If you screw up the engineering, somebody dies
Well, that last one is absolutely not applicable to the average web developer, but it's a good one to keep it this in mind next time something goes wrong in production.