The 15 Golden Rules of UI design and flow.

Last night a good friend of mine showed me the latest Need for Speed game on the iphone / ipad. Quite an impressive feat of rendering and a relatively good game to boot. However, the front end, wow, a classic case in UI mis-engineering. Loads of stats, pages and pages of bits and pieces to wade through – a classic case of over stimulating the player with lots of decisions they have no business making – stuff that will significantly change their game play experience but being made at a time when the user often has no experience of what changes actually mean.

It got me thinking about the Golden Rules of UI design, as proposed by Jake. So here’s the way I think UI should be built for Best Experience. NOTE – I’m sure everyone can find a couple of edge cases where the advice isn’t as valid as it might be. Suffice to say that these rules are designed for general case usage, not every possible situation your UI may get itself into.

1) Never more than 3 presses of any button before you are playing. If Id can do it for an online game (Quake 3), then so can you. The player doesn’t want to be presented with screen after screen of stats they need to understand or, worse still, affect. They want to PLAY, first and foremost. Your first 15 minutes of game play should NOT be preceded by 20 mins of screens that the player is confused by.

2) Hide complexity. This is what Advanced tabs are for. When guiding the player into the game play experience, everything not immediately relevant – ie anything that can’t be defaulted and is unlikely to be changed – needs to be hidden into other dialogs. The idea is not that the complexity is removed (although that’s not a bad thing either) but that it’s not required. Sure, enable people to change stats, but do not require them to, or even force them into looking at what they can change. That percentage of people who want to do things like that will find the dialogs to do this stuff – but be assured that that percentage of people who will want to fiddle is way less than 50%. Ergo over 50% of your players will be presented with knobs and features they don’t want to touch, and it will only confuse them.

3) Present all messages to your players in one place. Consistently. You need to train your players to look in one place, and one place only, for all communication from the game to them. The trick there, of course, is to filter it so that they aren’t overwhelmed with messages from the game (or other players within it) and miss essential information within a spam list. But that’s filtering and we’ll talk about that later. Caveat – the one time where you can break this rule is highlighting incorrect or missing input. Web pages do this a lot when you are filling out forms, and this IS permissable. Although if you are doing that, do NOT just use color of text to indicate an error – this doesn’t work for the color blind. What you need to do is inversely highlight the text, so instead of just the text being red, it’s the background that’s red. That way it’ll show up even to color blind people.

4) Filtering messages, and displaying implications. Messages that are displayed are good – the more information you share, the better right? Well that’s true, up to a point. Eventually, if messages are *constantly* being spewed at the user, they switch off. Messages that are repetitive – “Are you sure you want to do this?” – become spam and are ignored or clicked through and often messages that are important get missed among the spam. Having a time/ count for repetitive dialogs is a good thing – so the use is show one dialog maybe three times, then not again until a preset time out is hit – 5 mins from the last time this dialog would have been show is a pretty good default. So this way the user is not constantly clicking through the same dialog and being annoyed by it.
Also, allow the user to filter certain message types isn’t a bad thing either. Allowing the user to ignore warnings or messages from the scripting system is good. This does require that each message is now typed, so you can tell what group it’s a part of, but that’s just good practice.
Also, keep a log of all messages (unfiltered) and insure the user knows where it is, so if they need to, they can go look at it later.
One other thing about messaging worth mentioning is that it’s *key* to inform the user about implication of changes they make, particularly in tools. If someone in Unreal Ed clicks the “Everything has dynamic lighting” button, then they need to be told, quite categorically, what the impact of that is likely to have on their frame rate. The traditional approach of putting text on a screen explaining what each button does is often insufficient because more often than not impact of a given control is actually variable based on either content or other settings. Setting “everything to dynamic lighting” is NOT a bad thing to do if you have one object in scene with 2000 polys in it – it only really matters when you are rendering 400 objects in a 10k poly world. So basically my point is that some internal analysis of changes that a control change can make, measured against other impactful controls can be MASSIVELY useful for the user. Again though, some count of how many times that dialog/message is displayed is also imperative because there are always edge cases where what the app thinks is potentially undesirable behavior is what’s required, and being constantly warned about it gets old very fast.

5) Following on from 3) – consistency in all UI’s provided is key here. The obvious stuff – always use either radio buttons OR check boxes, but don’t mix, always use the same text side justification, font and sizes for all dialogs etc – are easy to deal with. But there are other, more subtle stuff. For example – if you need to provide pathing in your tools, ALWAYS use a browser button – never expect users to type in paths directly. XCode is a particularly good example of how bad this can get. Another good example is using sliders instead of requiring values to be typed in (although still allowing that to be done if need be).
One of the most important parts of the inputting of data is to avoid allowing the user to impart bad or conflicting data in the first place. So much code is in place in applications to deal with bad data, but it’s always better to not allow bad data to be input in the first place. That’s why using pre-populated drop downs is always better, because then you are *sure* you aren’t getting misspelled words, bad case mixing or just plain bad data.

6) As an extension of 5) – if it’s possible to avoid typing on the part of the user, do so. Populate drop down menu tabs, and provide default text in any required typing on the users part so they don’t _have_ to type anything if they don’t want to. Everything should have a default.

7) It’s ok to get to dialogs from multiple places – Windows  XP does this to great effect, allowing you to get to the same set of control dialogs from multiple avenues. That’s ok. The caveat that comes with this is that the dialogs themselves are inviolate.  They are the same no matter where you come from – they look and perform exactly the same regardless of the path used to get to them. No adding extra controls or removing them if you come down path A instead of path B.

8) Extending 6 – control exist in one place and one place only. Controls never feature in more than one dialog, and you *certainly* do not duplicate controls that look the same but function differently – that’s an exercise in frustration in understanding on the part of the user. Again, XCode suffers from this immensely.

9) Never more than 3 levels of dialog depth. Possibly 4 if you are doing an RPG. The bottom line here is that user can and will get confused in where they are, what they are doing and why. You also need to indicate where they are in your dialog tree – back buttons are good, but a (small) indicator of where someone is in your tree is even better – think pathing indicators in Explorer windows.

10) Dialog transitions. No dialog transition should last more than 150ms – 200ms tops. It doesn’t matter how clever you are and how pretty your transitions are, users want a snappy response time, particularly if they are navigating through UI dialog trees. Pretty / lengthy transitions are like jokes. Cool the first couple of times, then annoying because you just want to get to something else fast.

11) Anything that effects anything visually should be changed in real time. So if you are messing with lighting or changing clothing on an avatar or some such, this should happen in real time, so the user can see what’s going on as they change stuff. Sometimes this isn’t possible – where one change is impactful on another (changing scripting values for example, where one is valid until you change another), but if you can do it, you absolutely should do it.

12) Save Everything Configurable. Every window size change, every position change, every modification you allow a user to make, save it. Have easily restorable defaults for each thing you allow to be reset, but ensure you save everything a user changes, so it’s there for the next session. Remembering dialog layout (even docked dialogs) is a huge time saver for users.

13) Separate information and changeable data. Information that the user cannot change needs to be displayed in a way that makes it very obvious that it’s static. Changable information needs to be presented either in a slightly different font, color, size or in some way that makes it discernable that it’s changeable. This actually ties in with point 2) – if a user realizes that some data is changeable, if they are tweak inclined, they will then go looking for a way to change and start exploring your dialog UI structure to find where to change it.

14) For PC developers – check to see if your dialogs actually are on screen when you open them. All too often users will change their monitor set up and suddenly a saved dialog position is now off screen. You need to check for this. I’ve fallen afoul of this more than once, *cough*.

15) Lastly, and this one will probably be the most controversial of the lot – Do you design for data change flow, or do you design for grouping like data together? To give some background – design for data change flow means that you group lots of unlike data together in one screen / dialog / UI sessions, so following the flow of what the user needs to do in order to get to where they need to go – input name, select character type, select game type, select server, into game, for example. Each of these elements is a differing ‘type’ of data. Most games would make them separate screens, with lots of extra buttons/info that the user *could* use to allow them to tweak the experience, but practically almost never will. This is the ‘like data’ grouping approach, where each screen is designed around a feature and the user loaded with potential options.  A data flow screen would put all of the explicit features that the user *has* to select or change on one screen, allowing them to see it all in one go, make their selections and move forward immediately. One is all about options, and the other is about simplification and fast access to where the user really wants to go, IE in game. (Obviously this approach isn’t perfect, particularly if you want the user to select something that is a response to an earlier control manipulation – E.g. Select Server Type -well you aren’t going to be able to select a specific server until a type has been selected – but in cases like this I refer you to point 6), specifically “Everything should have a default”. In this case a default server type should be selected and the server list for that type already populated.)

My personal response to this issue is that both approaches, are, in fact legal and even desirable. I prefer to present the data flow approach as a default – because most people will actually use that anyway, particularly on first usage of you app. Allowing them to go the Like Data approach later is good, because those who want the complexity can find it, where as those that don’t (and that’ll be most of your users, never fear)  never need to be exposed to it. It all ties in with point 2 – the complexity is there but it’s not required.

So there you go. 15 golden rules that, in broad strokes, result in a more streamlined and generally more user friendly experience.

Source:http://altdevblogaday.com/2011/02/10/the-15-golden-rules-of-ui-design-and-flow/