I’m in the process of finishing a spec for a new idea that we (i.e. Flickswitch) are working on (codename: RebelMoose, isn’t that a great name?). I was going though the latest wire frames, and wondered what guidelines I would like to see if I was the one implementing the ideas. So I wrote a few guidelines and put it in the spec.

These turned out to be good general principles, so here they are in full, copypasta from the spec, with only some project-sensitive details removed.

1.  Polish Matters. What it says on the box. This idea has been tried before by others, so it better be good to differentiate it from the rest of the smelly herd. Give it a mani and a pedi at minimum.
2. Simple parts, clearly connected. Actions to be clearly labeled, consistent, with a clear call to action to move on to the next step. Steps already taken need to be reversible in all cases where it makes sense.
3. Don’t be clever. Be clear.
4. No surprises. Do the least work possible per action (keep background magic to a minimum and make sure it’s fully transparent and non-destructive). Always aim to do the least surprising thing.
5. No one true religion. People think in different ways. Provide multiple paths to salvation information.
6. Beautiful URLs. Love your routes or that .htaccess file – bring a lunch, stay for the day. URLs should always be copy-pastable. Where possible, make them pretty, but the most important thing is that they should contain all state information to recreate an exact same view when copied.
7. Idempotent refreshes. CTRL+R should not create a mess.
8. Concise communication.  Chat to the user when stuff has been updated – using very short sentences (no-one reads anything, especially not on a screen, you are an exception) – but be informative. Be specific, too: “R 1000 deposited in savings account number 012345” is better than “Money deposited” as an alert.
9. Be visible when giving feedback. Alerts go above the fold, we colourbox form fields during validation, and keep the validation feedback close to the element that can be used to act on the feedback.
10. All alerts to be easily dismiss-able and should, where possible, auto-dismiss after, say, 20 seconds. But log them and provide an action log where they can all be viewed in reverse chronological order – like a mini-facebook feed for your RebelMoose life.
11. Validation feedback. Validation feedback needs to be actionable – if it isn’t then don’t provide the feedback.
12. Make it safe. Things like “still two steps until the crocodiles will be released” make things safe for the user. Don’t delete anything (set flags in the DB). Destructive / dangerous actions should spell out what they do and when it will happen (e.g. “when you click ‘Change Baby’ we will loosen the diaper clasps”).
13. Be snappy. Make something happen. Something needs to happen immediately after a user did something. This must not be dependent on connection speed – it needs to happen client side. It can be as simple as minor visual state changes.
14. Options – do you speak it? “OK / Cancel” are not grammatically correct options for “Yes / No” questions. Yes / No buttons are inferior to verb-based dialogs (because “Log out / Cancel” is clearer than “OK / Cancel”). Make sure the verb corresponds with the action you describe. Multi-word / made-up verbs are fine (“all nouns can be verbed”). Examples:
    1. Terrible: “Do you want to withdraw R 100 from Savings?” -> [OK] [Cancel]
    2. Not emetic: “Do you want to withdraw R 100 from Savings?” -> [Yes] [No]
    3. Better, not perfect: “About to withdraw R 100 from Savings” -> [Withdraw] [Cancel]
15. Simplicity, revisited. Deliver substance. Say what you mean, briefly. Avoid using unnecessary ornamentation as a quick fix for something that could be better done by choosing UI parts more carefully.
16. Timelessness. If you can imagine a future where you or someone else would do a
    specific thing better, do that better thing right now.
17. Solve the right problem. Be pragmatic. Don’t blindly follow accepted wisdom if a
    pragmatic approach would lead to a more intuitive solution.
18. Be consistent. Our primary audience for the site will not be technical people – and since the new template eschews affordances* in favour of flat design we need to be especially consistent in order to imply meaning.
    1. Consistent icons and icon placement. Always use similar icons in the same way throughout.
    2. Consistent colour choices. Colour should convey semantic meaning. For example, green can work for forward / updated / success alerts, grey for back and cancel, bright blue for final step confirmation buttons, orange for warnings (need to be actionable), red for errors and failures, etc.
    3. Rely on the user’s sordid past. They know certain dated and distasteful UI elements like old friends. Don’t make them relearn the controls for novelty’s sake. Form elements to be standard-ish. Radio buttons, specifically, to look like radio buttons, not like toggle buttons. Switches can be used for on – off stuff, just make sure the semantics makes sense. Clarity before beauty, conventional usage before novelty. Remember: Be clear, not clever.
    4. Badges and icons can be useful stand-ins for affordance in flat design. Use accordingly to give info about how controls can be used, but very sparingly. Again – always be consistent, e.g. if one cancel button gets an undo icon, then all cancel buttons should have one – so don’t go mad with these things.

Just some principles to help you turn wire frames into reality. Nothing can tick all the boxes – but this is helpful in compromise situations. I expect I’ll be adding to this list in my head for a long time.

 

 

*Affordance: Originally a psychology term, but is used in the field of Human-Computer Interaction design in a different way. I use Don Norman’s definition from The Design of
Everyday Things: “…the term affordance refers to the perceived and actual properties
of the thing, primarily those fundamental properties that determine just how the thing
could possibly be used. […] Affordances provide strong clues to the operations of things.
Plates are for pushing. Knobs are for turning. Slots are for inserting things into. Balls
are for throwing or bouncing. When affordances are taken advantage of, the user knows
what to do just by looking: no picture, label, or instruction needed.”.