Here is what I learned working on a virtual world for kids.

I had the pleasure of working on a virtual world for 8-13 year olds called green.com we tracked the user behavior of tens of thousands of tomorrows users and learned the most effective UI methodologies possible to help children quickly figure out how to use the application. Here is a link to the project overview http://www.designcortex.com/green. The following is what we learned:

1. The close button is an X you fool! (Create a visual language, standardize and don't re-invent)

   - Images are better looking and more concise than text when a user is familiar with it. But icons can also be mysterious and confusing when used wrong. Use stylized versions of iconography with which your users are already familiar. For example don't re-invent the close button or the favorite icon those are commonly the same in all application and once you have decided on a version of them keep them standardized through out the application. As for new icons we found that gradual exposure was better so as not to overwhelm them at first look at the application. We found that it helped to use UI elements that looked like buttons, were iconic, memorable, ubiquitous and central to the theme of the game or application. Ex: Attack as a category in a Star Wars Game could feasibly be a Light Saber which represents all cases even if you were using a blaster to attack. Why? Because the Light Saber is an icon of Star Wars. It means combat and so a user is likely to intuatively know what it means. Once a user associates the icon with a certain function they will inherently look for that icon to avoid reading. It should speed their access to the function and allow them to find it more easily, this is why once you decide on the look and feel of an icon it should be standardized within your application. Think about iconic graphical elements central to the theme of your game or application and start to create a consistent visual language across your project’s UI. Obviously commonly understood UI like cancel, close, save, ok, etc are well understood and do not necessarily need icons nor mouse over descriptions as described in the next rule.

2. What does the red button do? (Mouse over descriptions)

   We found that users instinctively moused over buttons to determine what it was before clicking on it. Any button mouse over should always have a description bubble of what it does that shows up a half second after the mouse over. To associate the icons created in the rule above with a function they have to ultimately discover in some way what the icon does. A mouse over description is a common and standard way to do this. Windows and Mac have trained users to mouse over things to determine what it does before clicking on it. In the case that the button has text and the text integrated into the button, as long as it describes well enough what the button does there should be no need for a mouse over description.

3. Its a web page damn it! (Don’t forget the browser is part of your UI)

   URLs should be considered an open API to the application in the web page. Use deep linking and consider the use of the back button. Our application was a flash virtual world and users would instinctively click the back button which would just unload their game and navigate them away from our site. We then implemented deep linking in flash to eliminate this problem. Consider where it makes sense to permalink (permalink stands for permanent link to a resource or application state) to states in the program through the URL. What states of the application would some one want to email to some one in the form of a link. Spend some time thinking about how the user would expect the game or application to behave when clicking forward and backward or bookmaking a certain URL.

4. I like clicking on big shiny things duuuh! (Buttons need to be recognized as buttons)

   Buttons need to posses one or many of the following style elements: shiny, drop shadowed, beveled and rounded corners. It must activate on a mouse over in some way (light up, description bubble, glow, pops out, gets bigger, animates, etc, etc). Without this people are much much less likely to click them or even recognize them as clickable.

5. How do I get to my inventory...uh click inventory you idiot! (Links or clickable texts are always underlined)

   the text should make it obvious to what the link does. If it needs a mouse over description you should consider integrating the text into a button and using the rules for buttons. HTML will force you to use hyper links styles but in Flash you need to make sure clickable text is identifiable as clickable.

6. I know your creative but we don't need 10 different looks (Thematic consistency of UI elements and UI enclosures)

   - Once a function or set of utilities have been tied to a specific look or feel, that design should remain consistent where ever they are used this is heavily referenced in rule #1.

7. Dude keyboards are complicated, too many buttons dude! (Clicking is primary, add keyboard usage only when necessary)

   Even with instructions only half our users figured out that you use the keyboard to control the character. If the keyboard is used, it should be a secondary yet superior means of interacting. If the use of the keyboard is not superior then there is no need for keyboard control. Typically, web pages only interact with mouse clicks except when the user is filling out a form or chatting. Typically the web browser reserves the right to use keyboard input for application commands like control-c and such. Thus the user will not expect to be able to control the web application by directly using the keyboard. If you want to use keyboard controls, then there has to be an appealing reason beyond the simple mouse click interactions. An example is a character in a game. On a game console people will use keys, in a web application on a computer people will click for a bit and then give up in most cases before even attempting to use the arrow keys to control the character. So why use they keyboard at all? In the case of game play, keyboard control can often be more agile, precise and fun than simple mouse interactions. Imagine playing Mario Brothers, Pac Man, or Quake 3 Arena with only a mouse, it would be significantly less fun and perhaps even frustrating. In a Mario like web application scenario, the mouse should be there as a way to get them started quickly and then find ways to expose them and train them to use the superior keyboard method during their exploration of the product. When using keys you should be careful of conflicts that can arise between different browsers’ hot keys and the keys you choose for your application.

8. Why is the characters head cut off? (Make sure your design fits on the screen)

   People 60 percent of people just didn't scroll down when the application was bigger than their window. Build UI with multiple screen resolutions in mind. Keep in mind the space that is taken up at the top of the screen when they web browser is expanded full screen. This can vary widely depending on the browser and number of toolbars installed, also keep in mind widescreen monitors and devices like the Iphone. Consider the following design formats:
   1. Scale the UI to the view port
   2. Provide multiple sizes
   3. Design for the minimum resolution, typically 800x600 (I don’t recommend this one, unless it’s the majority of your users, like if you have a large amount of iphone users.)
   4. Optimize for the most common resolution (cater to your best customers), but allow it to work at a bare minimum using scroll bars when run at the minimum resolution. (believe me, 800x600 users are use to it)

9. Oh wait there was more, what is a scroll bar? (Design for above the fold)

   Design for above the fold. Above the fold is what we call the area of the page that you can depend on the user immediately seeing without scrolling in the vast majority of browser types and screen resolutions. (If you already have sizable traffic I suggest getting metrics on this to determine your “above the fold" zone.) If your page or UI is too large and scrolling is the only way around it, then you have to keep a few things in mind.
   1. Make it obvious the page scrolls. It should (artificially, if need be) extend a noticeable amount bellow the fold so as to make it obvious that there is a scroll bar and thus more on the page to scroll down to see.
   2. Cut off a graphic or the UI enclosure in a way that makes it obvious that the page has ended prematurely.

10. UI should be intuative for the average user

    - Don’t forget the stupid people, ok they are not stupid, but don’t forget that we software designers are not your average users. Even if you are designing an application for computer literate people it should be sleek and intuitive. Seek out to understand the way that your audience uses your product. You should always be cultivating this kind of knowledge. Here are some things you can do:

1. 1. Depending on your audience, ask friends, the secretary, your kids, your mom and your dad to use the application. Watch. Listen. Learn. You might even just watch them use the computer for a while.
   2. Attend focus group sessions that your company may hold with target users. Silently observe and note how they interact. Refrain from strangling.
   3. If you already have traffic and a base feature set then track usage statistics using Webometrics like Google Analytics.

Measuring Success

When you design features, if you can, find ways to test the design using Webometrics. All features should be made with a single goal in mind and you should design tests to determine if that goal is being met. At the very least you should run tests on major features. When doing this ask questions such as the following:

1. 1. What percentages of users use this feature?
   2. How often does each user access it?
   3. If it is a repeatly used feature do they use it over and over.
   4. What are the most popular ways the feature is accessed?
   5. If the feature isn’t used much then why? Is this because it is in essence not popular no matter what? Is this because they could be confused on how to access it? Are they accessing it, but it is frustrating them for extended periods of time?
   6. Don’t just track if they open a sub UI or panel, find out if they fiddle with it once the panel has been opened.
   7. How much time do they spend using the feature?
   8. Does a long time mean it takes a while to figure out or are they just enjoying using the feature? Judge effectiveness by the nature of the feature. Some interactions should be quick, others more involved.

Conclusion:

In the end web application usability is largely tied to user retention which often translates into dollars. Your application runs in a web browser, with web analytics, you know every time they access the application, how they use it and if they come back. If your application is already proven as market viable (some products are just unpopular regardless of good or bad UI design) then user retention can be a great indicator of good usability. This is one of the most difficult things to track and should be on everybody's mind. What allows you to retain users? This is the big question. Without going into super statistics mode, to get a general feel for this, you will need to separate the Webometrics in to the following three groups of users: Those who only visit the site once, those who comeback 2-x number of times, and those that comeback more than x number of times (the x value will depend on the nature of your product). Time combined with visits might be a better indicator of retention. Focus on how the site monetizes to determine what creates your definition of target retention. You can then see what features each group uses, how they use them and try to determine UI trends that lead to a greater conversion of users. Eventually you will begin to have an intuitive feeling for these things and have the confidence to make design decisions on the fly with less testing. To start with don’t get arrogant, the proof is in the pudding, get the data to prove to your self you have an understanding of your user base. Even after you have a grip on it, you should run tests once and a while. If you have the budget there is no harm in running them often.

Definitions :

UI Enclosure - the graphics that make up the panel, window or borders where the UI lives.
Above the fold - Above the fold is what we call the area of the page that you can depend on the user immediately seeing without scrolling in the vast majority of browser types and screen resolutions.
Permalink
Webometrics
User Conversion
User retention - How you mejor that users come back to use the web applicaiton enough times to monetize or spend enough time on the site to monetize.