So, you're designing a user interface. A user interface that will be used by a user. Users are people. People are sometimes, often, and generally, idiots.

Not all users are idiots. Some are intelligent, thoughtful, logical people; but there's no guarantee you're going to win the user bingo and end up with one of them. So, as a general rule of thumb I've always worked to one guiding principle: "The user is an idiot, treat them as such".

That is not to say that you should belittle a user's intelligence with any interface design. You should try and allow a user to function independently of your guidance, but at all times provide support for anyone who isn't as capable.

There are various ways to ensure that all users, even the most dumbfounded, can understand and navigate using your interface. Most often it can be achieved by being clear and concise, removing options for failure, being consistent, and giving appropriate feedback at opportune times.

By having a clearly lain out structure to whatever you're designing, be that an app, webpage or anything else; the key is in creating a hierarchy of visual elements. Visual elements that the user focuses in on, discarding for the moment the surrounding parent elements until they find precisely what it is they want to deal with at that moment in time.

We as humans, are very focused, we focus in on a task, deal with it, then move on to something else. By creating a drill-down structure to your user interface or data hierarchy, you allow the focus to be centred on relevant elements, forgoing the transitionally irrelevant ones. Get this wrong, split related items apart visually and you're essentially blocking a user's ability to narrow in on and focus on a single thing, you're forcing them to deal with a much larger scope at any given point.

Removing options for failure is an exercise of restraint on your part. The instinct is to create an all-singing all-dancing interface, where the user can do anything that they could possibly need to. You've already failed, stop what you're doing, go back to the start and ask the question "What does the user need to do here?". Not, "What can the user do?"; not, "What are the options available to the user?"; No. You need to know what the basic, required, without this the user would be lost, functionality should be. These are the key calls to action or fundamental operations your system provides.

The more complex stuff should be there, but perhaps not at this level of your interface. Should a user be able to edit metadata held against blog posts at the top level listing in a CMS? No, certainly not. Bury those actions further down. You're overloading the simpleton, giving him too many places to go wrong. Your interface should be a roadmap with clearly marked signs as to the direction the user should take. If the idiot gets lost, or chooses wrongly, it's your fault!

Consistency is key, don't surprise the dumbard, he scares easily and is likely to run into the arms of another. Be structurally and interactively consistent, your interface shouldn't be too much of a shock to the user — wherever it is, you should be leading them through by the hand.

Your interface should adopt a learn-once apply-everywhere methodology. You should still innovate as much in possible in your interaction design, but not as to be so different as to cause confusion. Don't innovate at every opportunity!

Know what is expected of your interface and meet those expectations. If you're not going to meet those expectations then either provide alternatives or guide the user towards an alternative.

You should be striving to meet expectations in terms of application colour schemes, navigation design, grouping of elements and similarities between interactions with the OS chrome and your interface.

Feedback is important. Regardless of what you do, Joe or Jane public is going to get it wrong at some point. You shouldn't punish their stupidity, you should educate against it! If something goes wrong and it's the users' fault, tell them so.

Error messages are just plain wrong. If your user does something wrong you need to guide them towards doing something right, especially if you can guide them to an action that solves any problems they've created.

You should be making destructive actions less afordable than positive ones. If you want to delete a saved document it really shouldn't be as easy as creating a new one. Giving appropriate feedback and alerting the user to non-recoverable actions should allow them to pause to consider the impact of what they're trying to do.

Tell the idiot where they are, what they can do to get back to an initial state, and don't make it destructive to get back there. Allow recovery wherever possible, users that leave half way through editing a document can, rightly, expect to pick back up where they left off.

Give the user contextual feedback. Let them know what the results of their actions will be and give them the option of opting out of completing the process they've started. Be assertive with the options available to the user, give them definitive ways to proceed but don't ever back them into a corner where there's "nothing else to do there"; always give them the option of cancelling the operation, right up to the last opportune moment.

Approach every new project knowing that your solution isn't unique. You're not solving something that nobody else has addressed before. Even if you are, someone else is hot on your heels, ready to take the best elements of what you've done and add to those.

Anyone else approaching the same problem that you've solved is going to take what you have, find a better way of relating to the idiot user you have and capturing your business.

Don't over reach. You won't win the user war by offering the most feature filled app or service; you're better off doing less infallibly than doing a lot infuriatingly.