Simple is beautiful.

Today we kick off a new two-week series that will focus on key design principles for developers. Today is just the overview; we’ll go through one of these each day for the next two weeks so make sure you join us for it!

10. Anticipate your user’s expectations. This means knowing your users. Testing, surveys and analytic software are good ways to discover who your users are. (Silverback) But there are some fairly common expectations that are good places to begin. Buttons should look like buttons, clickable links should be distinct from standard text. Part of this is using common metaphors in your icons (GUN = DELETE). The goal is for your interface to get out of the way and let the user succeed. There’s a place for being unique and original, but when it becomes a impediment that keeps your users from being able to use your tool well, it needs to go.

9. What’s easiest for a developer is not always what’s easiest for a user. This is often hard because one of the key jobs for a developer is efficiency within a program. But this means “thinking outside the box”, literally. Efficiency in phone software says you take the numbers a user inputs and dial them. But if you think outside the box, what about the frustrating repetition of entering the same number day after day? Reducing the act of remembering and pressing ten digits along with the send key down to a single, assignable “quick dial” button takes more development, but it enhances productivity.

8. Feedback, feedback, feedback. Tell your user what’s going on. If you’re going to make them wait, give them an hourglass, a throbber, a spinning beach ball—something to indicate that the application is working and that their input has been received. * And when a task is complete, let them know it was successful in a very obvious way (common metaphors: check, green, thumbs up). If it fails, let them know that as well (common metaphors: x, exclamation point, red or yellow, thumbs down).

7. When it comes to readability, contrast is your friend. Non-essential elements like form labels or toolbar headers where users could probably infer what data is there from the context can afford being less readable. Black text on a white background is especially important when your users will be reading lots of text or entering data.

6. If it’s more important, it should be bigger. This of course requires you to have an “interaction hierarchy” for your application. That’s a big fancy term that means you have a plan for how you want users to use your application. In fact, one of the reasons small, lightweight web apps have succeeded in this area while big, bloated suites have fallen by the wayside is because web apps are often put together by individuals or teams of small, focused, single-minded groups that share the same vision and purpose for an app. The larger suites often fall prey to bureaucracy (death by committee) and this ambivalence of purpose comes out in the design. For blogging software, creating a new post is the most common/important task, so it needs to be prominent: larger font, contrasting color, etc. (Don’t make me break into “I like big buttons and I cannot lie.”)

5. The most common tasks should be the easiest to accomplish. In fact, the default settings should be what 90% of your users will want and if you’re going to allow people to change them, make it easy to. Forms — tab index, default values. Install or upload paths — customizable defaults. Also make it easy to get back to the initial settings.

4. Help your users get oriented. Your users should know where they are at all times. There are several visual tools you can use to help users get oriented: tabs, breadcrumbs, “current state” menu items. If your application or website requires a login, remind people of the state. Are they logged in? How do they know? How do they log out? And a good way to test this is to have people not familiar with the software site down and try it out.

3. Be forgiving. Your users are not stupid, but they may be uninformed, confused or mistaken. You’ve done everything you can to eliminate this confusion, but you also need to protect them when they do make a mistake. This has a LOT of implications from an interaction design standpoint: undo, autosave, error checking, spell-checking; but this principle applies to visual design as well. Actions that have the potential to do more damage should be clearly marked (without slowing users down). Getting back to “the way things were” should also be clearly marked so users feel more comfortable to explore. Alienating users when they make a mistake is the quickest way to lose them.

2. Be consistent. Consistent placement of controls, consistent keyboard shortcuts, consistent branding. The only exception to this rule is when dealing with things that are different. Make sure that different functions are sufficiently inconsistent; the greater the difference between their function, the greater visual distinction you need between them.

1. What your application can do is not nearly as important as what users do with your application.